StorageTek Enterprise Library Software

HSC および VTCS の管理

バージョン 7.2

E70167-01

2015 年 12 月

StorageTek Enterprise Library Software HSC および VTCS の管理、バージョン 7.2

E70167-01

著作権 © 2015, Oracle and/or its affiliates. All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション (人的傷害を発生させる可能性があるアプリケーションを含む) への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性 (redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporation およびその関連会社は一切の責任を負いかねます。

Oracle および Java はオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeon は、Intel Corporation の商標または登録商標です。すべての SPARC の商標はライセンスをもとに使用し、SPARC International, Inc. の商標または登録商標です。AMD、Opteron、AMD ロゴ、AMD Opteron ロゴは、Advanced Micro Devices, Inc. の商標または登録商標です。UNIX は、The Open Group の登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様と Oracle Corporation との間の契約に別段の定めがある場合を除いて、Oracle Corporation およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様と Oracle Corporation との間の契約に定めがある場合を除いて、Oracle Corporation およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

図のリスト

表のリスト

タイトルおよび著作権情報

はじめに

- 対象読者

- 前提条件

- ドキュメントのアクセシビリティについて

- このガイドについて

新機能

1 ツールキット

- HSC ツールキット

- VTCS ツールキット

2 CDS の管理

- CDS のバックアップ

- バックアップの頻度

- BACKup ユーティリティーによる CDS のバックアップ

- CDS ロギングの管理

- 定期的なログファイルのオフロード

- ログファイルの拡張と再割り振り

- 手動による別の CDS コピーへの切り替え

- CDS の拡張

- CDS の循環

- CDS の名前の変更

- CDS Disable および Enable コマンドを使用した CDS の名前の変更

- CDS の再配置

- カタログ化されていない CDS コピーの再配置

- CDS のスワップ

- CDS の復元

- バックアップコピーからの CDS の復元

3 TapePlex の管理

- ライブラリハードウェアの管理

- ACS の管理

- SL8500 冗長電子デバイスの管理

- デュアルライブラリコントローラ構成

- SL8500 冗長電子デバイス環境

- SL8500 LC 操作

- ACS ステータスの表示

- 冗長 LC の操作上の概要

- LC 切り替えの概要

- LC 切り替えの結果

- 自動 LC 切り替え

- オペレータによる LC 切り替え

- CAP の手動回復

- エンター機能がアクティブなときに切り替えが行われる

- イジェクト機能がアクティブなときに切り替えが行われる

- CAP が自動モードに設定されているときに切り替えが行われる

- CAP の管理

- 手動 RTD の定義

- テープデータの保護

- ネイティブテープデータの保護

- VTV データの保護

- MVC データの保護

- ライブラリボリュームの管理

- ボリュームレポートの使用

- エラントボリュームおよび選択されたボリューム

- VOLPARM と外部ラベルが一致しないステータス

- VOLPARM に含まれていないボリューム

- スクラッチサブプールの管理

- VOLRPT を使用したクリーニングカートリッジの使用状況の追跡

- マウントパフォーマンスの最適化

- ボリュームアクセスセキュリティーの使用

- RACF 属性

- Write Once/Read Many (WORM) のサポート

- スクラッチボリュームの管理

- スクラッチボリュームの追加

- Nearline ボリュームの定義

- 新しい LSM の作成

- 既存の LSM へのボリュームの追加

- カートリッジの挿入

- ボリュームのイジェクト

- スクラッチボリュームのイジェクト

- クリーニングカートリッジの管理

- クリーニングカートリッジの選択

- クリーニングカートリッジのイジェクト

- 使用済みクリーニングカートリッジの手動によるイジェクト

- 問題の解決

- エラントカートリッジの回復

- 重複/読み取り不能 VOLSER の入力

- 重複ボリュームの入力

- 外部ラベルがないカートリッジまたはラベルを読み取れないカートリッジの挿入

- CAP の RECOVERY ステータスをクリアする

- 割り振り済み CAP の解放

- ホスト間通信サービスの復元

- 失われた可能性のあるマウント要求の解決

- 失われたマウント応答の解決 (ORH)

- 遅延応答ハンドラ

- マウント、マウント解除、移動、およびスワップに必要なオペレータ応答

- ソフトウェア診断の使用

4 VTCS ダッシュボードの使用

- 仮想テープのステータスの確認 (日次)

- Virtual テープのステータスを確認するには、次のことを実行します。

- Nearline テープのステータスの確認 (日次)

- Nearline テープのステータスを確認するには、次のことを実行します。

- 概要の把握 (週次)

- VTV レポートの使用

- MVC レポートの使用

- サマリー

5 VTCS Must Do (不定期) タスクリストの操作

- 強制スペースリクレイム、強制移行、および強制リコールの実行

- MVC スペースリクレイムの実行

- 強制 VTV 移行の実行

- 強制 VTV リコールの実行

- RTD の操作

- RTD デバイスタイプの変更

- VSM と MSP 間でのトランスポートの共有

- MVC の操作

- MVC の追加

- VTV の定義

- ボリューム定義の検証と適用

- MVC のプールからの除去

- MVC の永続的除去

- MVC の一時的除去

- MVC のドレイン

- MVCMAINT による MVC 属性の変更

- MVC または VMVC の検証

- 単一 VMVC に対する MV の実行

- MVC プールによる MV の実行

- MVC volser による MV の実行

- ストレージクラスによる MV の実行

- VTSS の操作

- 保守のための VTSS の休止

- VTSS の削除

- VTV の操作

- スクラッチ VTV の削除

- DELTSCR を実行する JCL の例

- VTVMAINT による VTV 属性の変更

- VTV マネージメントクラスの変更および MVC からの VTV のリンクの切断

- オフラインの VTSS における VTV の論理マウント解除

- Cross-TapePlex Replication (CTR) によって複製された VTV の管理

- RECONcil による VTV ストレージクラスの変更

- RECONcil ジョブの実行

- FOR_LOSTMVC を使用した VTV の回復

- FOR_LOSTMVC による回復手順

6 マネージメントクラスおよびストレージクラスによる最新のソリューション

- VTCS CDS レベル

- マネージメントクラスおよびストレージクラスについて

- VTCS マネージメントおよびストレージクラスの作成と使用: 基本

- VSM マネージメントおよびストレージクラスの作成および使用

- マネージメントクラスおよびストレージクラスの保守

- マネージメントクラスおよびストレージクラスの管理に使用できる最先端技術

- 共有 MVC 上での複数の作業負荷のグループ化

- 単一の作業負荷の別々の MVC のセットへの分散

- データのアーカイブ

- アーカイブの使用上の注意

- VTV メディアと場所の再統合

- RECONcil の例

- RECONcil の使用上の注意

- Named MVC プールかそうでないか

- Named MVC プールの作成と使用

7 VTCS の問題の検出と修正

- 一般的な問題の修正

- VTV マウントのパフォーマンスが悪い場合

- 移行のパフォーマンスが悪い場合

- 移行の障害

- メッセージの拡張

- Display STORCLas

- 拡張された MVC プールの検証

- 拡張されたストレージクラスの検証

- RTD/MVC の障害

- 不良な MVC の確認

- データチェックによる MVC の回復

- RTV ユーティリティーの使用法

- RTV ユーティリティーで回復できる VTV

- セキュリティーに関する注意事項

- JCL の例

- MVC 上の VTV のリスト

- volser の指定による単一 VTV の変換

- VOLSER とブロック ID の指定による単一 VTV の変換

索引

図のリスト

- 3-1 デュアル LC 構成

- 3-2 ボリュームレポート (VOLPARM と外部ラベルの不一致)

- 3-3 ボリュームレポート (スクラッチサブプール)

- 3-4 ボリュームレポート (クリーニングカートリッジ)

- 4-1 Display MVCPool からの出力例 (プール名の指定がない場合)

- 4-2 Display MVCPool からの出力例 - ACS01 で問題

- 4-3 VTVRPT の出力例

- 4-4 VTVRPT (UNAVAIL オプション) からの出力例

- 4-5 MVC サマリーレポートの例

- 4-6 MVC 詳細レポートの例 (追加フィールド)

表のリスト

- 1-1 HSC オペレータコマンド

- 1-2 HSC PARMLIB 制御文

- 1-3 HSC ユーティリティー (指定されていない場合は SLUADMIN)

- 1-4 診断

- 1-5 HSC パフォーマンスツール

- 1-6 VTCS ツールキット

- 3-1 スクラッチボリュームの管理タスクとツール

- 3-2 HSC ソフトウェア診断ツール

- 4-1 Display VTSS からの出力例 - 正常な VTSS のステータス

- 4-2 Display VTSS からの出力例 - 運用上の大きな問題がある VTSS

- 4-3 Display VTD の出力例 - 正常な稼働

- 4-4 Display SCRATCH の出力例

- 4-5 VT Display RTD コマンドの出力例 - すべてが良好

- 4-6 VT Display RTD コマンドの出力例 - RTD に問題

- 5-1 VTSS の状態

- 5-2 代替 VTV コピーと回復処理

- 6-1 サポートされている VTCS バージョンの CDS レベル

はじめに

Oracle の StorageTek Enterprise Library Software (ELS) は、次の基本ソフトウェアで構成されるソリューションです。

- StorageTek ストレージ管理コンポーネント (SMC)

- StorageTek ホストソフトウェアコンポーネント (HSC)

- StorageTek 仮想テープ制御ソフトウェア (VTCS)

- StorageTek 並行障害回復テスト (CDRT)

対象読者

このガイドは、ELS の管理を行う Oracle またはお客様の担当者を対象としています。

前提条件

このガイドで説明しているタスクを行うには、次の事項についての知識が必要です。

- MSP 操作環境

- JES

- Enterprise Library Software (ELS)

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility Program の Web サイト (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc) を参照してください。

Oracle Support へのアクセス

サポートをご契約のお客様には、My Oracle Support を通して電子支援サービスを提供しています。詳細情報は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs) を参照してください。

このガイドについて

このガイドは、HSC および VTCS の運用を管理する担当者に向けて記述されています。HSC/VTCS は基本的にはサーバーであり、すべてのサーバーと同様、これを適切にインストールおよび構成し、効果的なポリシーを作成し、十分な注意を払って管理すれば、自己管理処理を行います。HSC および VTCS には、CDS の維持のような共通タスクがあり、実ボリュームでの作業と VTV や MVC での作業のように、並行で処理されながら別個に処理されるタスクもあります。これら 3 つのコンポーネントでの割り振りメンバーの管理については、SMC の管理を参照してください。

「十分な注意を払って管理する」には何が必要なのでしょうか。「HSC と VTCS を管理する」のに必要な条件とは何でしょうか。次に、このガイドの各セクションと対応する管理タスクについて説明します。

- ツールキットには、HSC および VTCS の管理に使用するツールを表で示しています。このセクションでは、これらのツールの特定のタスクや機能について説明します。詳細については、『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください。

- CDS の管理では、CD の保護方法と、1 つ以上の CDS のコピーが失われた場合の回復方法を説明します。

- TapePlex の管理では、TapePlex を管理するために必要な、定期的および要求時に実行するタスクについて説明します。

- VTCS ダッシュボードの使用では、運用上、実行しなければならないタスクについて説明します。ここでは、VTCS システムの健全性をモニタリングするほかにも、強制 MVC スペースリクレイムのバッチジョブなど、いくつかの重要項目も説明します。

- VTCS Must Do (不定期) タスクリストの操作では、VTCS で必要なときに行うべき項目を説明しています。
定期的な管理と要求時の管理には、これらの 2 つのカテゴリや解決する問題の間に重複があるように重複する領域があります。ほとんどの場合、管理タスクを慎重に行えば、多くの問題を解決する必要はありません。また、その逆も生じえます。「定期的」および「要求時」という 2 つの一般的なカテゴリがあり、必要に応じて調整する必要があります。

- マネージメントクラスおよびストレージクラスによる最新のソリューションでは、VTCS の最先端での実装の基盤となるマネージメントクラスとストレージクラスについて説明します。

- VTCS の問題の検出と修正は、問題が発生した場合の対策について述べています。

新機能

このリビジョンには、次の更新が含まれています。

ELS 7.2 にはクライアント/サーバー通信のための新しい XAPI セキュリティー機能が導入されており、SMC HTTP サーバーではデフォルトとして有効になります。

- MVC または VTV を構成から削除する場合の volser に関する制限を追加。
MVC の操作または「VTV の操作」を参照。

- 若干のドキュメント修正。

1 ツールキット

次の表に、HSC と VTCS の管理に必要なツールをインタフェースごとに示します。ツールの詳細については、『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください。

注記:
重要: HIPER 通知を受信するように登録してください。Oracle では、ユーザーが保守を最新の状態に保つのを支援したり、事前に問題を回避したりするために、ナレッジベースのアラートドキュメントとして HIPER 通知を発行しています。HIPER 通知の完全なリストを取得するには、My Oracle Support (MOS) のホームページからキーワード「HIPER」を検索します。また、MOS の「電子メールによるホット・トピック」で新しい HIPER 通知アラートドキュメントを受信するよう登録もしてください。ナレッジベースの記事 793436.1 (MOS ホームページから番号で検索可能) には、電子メールによるホット・トピック機能と登録方法が説明されています。関心のあるすべての Oracle StorageTek 製品を電子メールによるホット・トピックのプロファイルに追加するようにしてください。特定の製品を含めるには、「追加」をクリックするだけです。次に、「製品の追加」ボックスの「製品」フィールドに「StorageTek」と入力し、表示されたリストから製品を選択します。各製品を選択するときに「アラート」ドキュメントタイプにチェックマークを付けるようにしてください。

HSC ツールキット

表1-1 HSC オペレータコマンド

コマンド:

機能:

参照トピック:

CDS ENABLE/DISABLE

CDS コピーの切り替え、拡張、または移動を行います。

手動による別の CDS コピーへの切り替え

COMMPATH

通信設定を変更します。

スクラッチボリュームの追加

DISPLAY ACS

ACS のステータスを表示します。ACS、LMU、およびステーションについてのハードウェアの状態と、使用可能なスクラッチボリュームおよび空きセルなどが表示されます。

ACS の管理

DISPLAY ALL

DISPLAY ACS コマンドの出力に加え、LSM および CDS のステータスを表示します。

ACS の管理

DISPLAY CAP

CAP 情報を表示します。

スクラッチボリュームの追加

DISPLAY EXCEPTNS

ライブラリハードウェアの問題を表示します。

ライブラリハードウェアの管理

DISPLAY LSM

LSM のステータスを表示します。

カートリッジの挿入

DISPLAY SCRATCH

サブプールに基づいてスクラッチカウント情報を表示します。

スクラッチボリュームの追加

DISPLAY THRESHLD

Warn コマンドによって設定された限界値を表示します。

スクラッチボリュームの追加

DISPLAY VOLUME

物理ボリュームの情報を表示します。

エラントボリュームおよび選択されたボリューム

EJECT

最大 9999 のカートリッジをイジェクトします。

カートリッジの挿入

ENTER

1 つまたは複数のボリュームを入力します。

カートリッジの挿入

MNTD AUTOCLN EJCTAUTO

自動ドライブクリーニングと MAXCLEAN 値を超えたクリーニングカートリッジの自動イジェクトを決定します。

クリーニングカートリッジの管理

MODIFY

LSM および CAP の状態を変更します。

- ACS の管理

- スクラッチボリュームの追加

OPTION ENTDUP

重複ボリュームの入力に対する応答を決定します。

重複ボリュームの入力

RELEASE

CAP を解放して、使用できるようにします。

割り振り済み CAP の解放

SMC RESYNCH

失われたマウントを再処理します。

スクラッチボリュームの追加

SCRATCH

特定のボリュームをスクラッチします。

スクラッチボリュームの追加

UNSCRATCH

特定のボリュームをアンスクラッチします。

スクラッチボリュームの追加

WARN

スクラッチ警告の限界値を設定します。

スクラッチボリュームの追加

表1-2 HSC PARMLIB 制御文

制御文:

機能:

参照トピック:

CDSDEF

CDS コピーのデータセット名を指定します。

- CDS の拡張

- CDS の名前の変更

- CDS の再配置

表1-3 HSC ユーティリティー (指定されていない場合は SLUADMIN)

ユーティリティー:

機能:

参照トピック:

BACKUP

プライマリ CDS のバックアップを作成します。

BACKup ユーティリティーによる CDS のバックアップ

FMTLOG

ログファイルを事前フォーマットします。

CDS ロギングの管理

LOGUTIL

CDS の回復にログファイルを利用します。

バックアップコピーからの CDS の復元

OFFLOAD LOGFILE

現在のすべてのログファイルからトランザクションをオフロードし、新しいログファイルをアクティブにします。

CDS ロギングの管理

RESTORE

バックアップコピーから CDS を復元します。

バックアップコピーからの CDS の復元

スクラッチ変換 (SLUCONDB)

HSC スクラッチリストを TMS スクラッチリストの情報を基に更新します。

スクラッチボリュームの追加

SCREDIST

ACS 内の指定した LSM 間で、スクラッチボリュームの数のバランスを維持します。特定のサブプールだけのバランスをとるオプションも用意されています。

スクラッチボリュームの追加

SET LOGFILE

ログファイルデータセットを指定します。

CDS ロギングの管理

SET VOLPARM

すべてのタイプのボリュームとプールを定義します。

- スクラッチボリュームの追加

- Nearline ボリュームの定義

- スクラッチボリュームの追加

UNSELECT

ボリュームの選択したステータスをリセットします。

エラントボリュームおよび選択されたボリューム

VOLRPT

物理ボリュームのレポートを出力します。

ボリュームレポートの使用

表1-4 診断

診断ツール:

機能:

参照トピック/ドキュメント:

汎用トレース機能

汎用トレース機能 (GTF) は、最近の履歴の低レベルな情報を出力します。

スクラッチボリュームの追加

監視プログラム呼び出しと異常終了のダンプ (ABEND)

SVC および ABEND のダンプはソフトウェア障害の診断に利用できます。

スクラッチボリュームの追加

エラー記録データセットレコード

ソフトウェア障害は、これらのエラー記録データセットに記録されます。4480 カートリッジサブシステムおよび 3278 端末サブシステムのエラー記録データセット (ERDS) のレコードは、MSP ルーチンによって書き出されます。

スクラッチボリュームの追加

HSC LIST コマンド

LIst コマンドは、HSC データ構造を表示して、HSC の診断をサポートするために使用されます。このコマンドは、Oracle のサポート担当者からの指示に従って使用してください。

ELS コマンド、制御文、およびユーティリティーリファレンス

表1-5 HSC パフォーマンスツール

パフォーマンスツール:

機能:

参照トピック:

アクティビティーレポート

さまざまなライブラリアクティビティーのパフォーマンス値を示す詳細なレポートを生成します。

マウントパフォーマンスの最適化

スクラッチ再分配ユーティリティー

特定の ACS 内の LSM 間でスクラッチボリュームを再分配します。

- マウントパフォーマンスの最適化

- スクラッチボリュームの追加

WARN コマンド

HSC が ACS でスクラッチカートリッジの数が不足していることをオペレータに通知する際の限界値を指定します。

スクラッチボリュームの追加

CAPPREF コマンド

CAP の優先値を指定します。

スクラッチボリュームの追加

SMF レコード

ACS のアクティビティーとパフォーマンスのデータを解析用に記録します。

マウントパフォーマンスの最適化

VTCS ツールキット

表1-6 VTCS ツールキット

コマンド:

機能:

参照トピック/ドキュメント:

AUDIT

HSC CDS 内の MVC および VTV 情報を更新します。

- RTD デバイスタイプの変更

- RTD デバイスタイプの変更

- オフラインの VTSS における VTV の論理マウント解除

DELETSCR

スクラッチ VTV を VTSS から削除し、移行された VTV のリンクを MVC から切断します。

MVC スペースリクレイムの実行

DISPLAY

VTCS に関するすべてのステータスを表示する主要なツールの 1 つです。

- 仮想テープのステータスの確認 (日次)

- 仮想テープのステータスの確認 (日次)

- MVC スペースリクレイムの実行

- MVC スペースリクレイムの実行

- VTV マウントのパフォーマンスが悪い場合

- VTV マウントのパフォーマンスが悪い場合

- RTD/MVC の障害

- VTV マウントのパフォーマンスが悪い場合

MIGRATE

VTV の MVC への要求移行を実行します。

MVC スペースリクレイムの実行

MVCDRAIN

現在およびスクラッチ済みのすべての VTV を MVC からリコールします。オプションで、MVC を「仮想的に」イジェクトします (ライブラリから物理的にイジェクトしないで、VSM で使用できないようにします)。

MVC スペースリクレイムの実行

MVCMAINT

MVC 属性を設定します。

RTD デバイスタイプの変更

MVCPLRPT

MVCPOOL およびストレージクラスを管理します。

ELS コマンド、制御文、およびユーティリティーリファレンス

MVCRPT

VSM システムの MVC のステータスを報告します。これは、2 つ目の主な指標です。

- 仮想テープのステータスの確認 (日次)

- MVC スペースリクレイムの実行

- 一般的な問題の修正

RECALL

強制 VTV リコールを実行します。

MVC スペースリクレイムの実行

RECLAIM

強制 MVC スペースリクレイムを実行します。

MVC スペースリクレイムの実行

RECONCIL

VTV メディアと場所を再統合します (VTV をあるストレージクラスから別のストレージクラスへ移動します)。

VTSS の操作

RTV ユーティリティー

MVC に含まれる VTV を Nearline ボリューム (実テープボリューム) のデータセットに変換します。

一般的な問題の修正

SET MIGOPT

次の移行パラメータを変更します。

- 同時処理する自動移行、即時移行、および限界値までの移行タスクの最大数および最小数。

- 上限 AMT および下限 AMT。

- 仮想テープのステータスの確認 (日次)

- MVC スペースリクレイムの実行

VARY RTD

RTD の状態を変更します。

- 仮想テープのステータスの確認 (日次)

- VTSS の操作

VARY VTSS

すべてのホスト上の VTSS の状態を変更します。

VTSS の操作

2 CDS の管理

CDS には重要なデータが含まれるため、CDS の管理は重要なタスクです。次のセクションでは、CDS の保護方法と、CDS の 1 つまたは複数のコピーが失われた場合のこれらの回復方法について説明します。CDS の計画と作成については、『HSC および VTCS の構成』を参照してください。

CDS のバックアップ

CDS のすべてのコピーで障害が発生した場合 (つまり、プライマリ、セカンダリー、およびスタンバイのすべてのコピーが失われた場合) は、バックアップから CDS を復元する必要があります。CDS のバックアップは、ディスクのミラー化などの ELS 以外の機能、Fujitsu ARCS や Fujitsu DARCV などの他社のバックアップソフトウェア、または IBM FlashCopy などの他社の Point-In-Time コピーソフトウェアを使用して実行できます。ただし、CDS の整合性や完全性が保証されないため、Oracle ではこれらの方法を推奨していません。

代わりに、HSC BACKUP ユーティリティーを使用してスナップショットバックアップを作成することをお勧めします。

バックアップの頻度

Oracle では、CDS のバックアップを少なくとも 1 日に 1 回実行することを推奨します。CDS ロギングを使用している場合は、CDS をバックアップしたあとすぐに、ログファイルのオフロードを実行することもお勧めしています。これにより、回復に使用するバックアップファイルに対応するログオフロードファイルを、回復中に選択できます。

また、構成の変更や次のような重要なイベントを実行する前にも、CDS をバックアップするようにしてください。

- SLUADMIN SET ユーティリティーの実行

- VTCS CONFIG ユーティリティーの実行

- CDS の移動

- CDS の拡張

- CDS のマージ。

BACKup ユーティリティーによる CDS のバックアップ

BACKup ユーティリティーの実行:

1. SLSBKUP データセットを割り振ります。
CDS よりも少し大きく指定してください。サイズは見つかった差分の数によって異なります。ただし、現在の CDS よりも 5% 大きいサイズを推奨します。

バックアップデータセットは RECFM=F、BLKSIZE=4096 でフォーマットされます。論理レコードの長さは LRECL=0 と指定できます。この場合、LRECL=0 はデフォルトでブロックサイズになることを示します。

2. BACKup ユーティリティーを実行します。
CDS は、データが SLSBKUP データセットにコピーされるまでの間、予約状態となります。ほかの機能は、バックアップ処理中に CDS データセットにアクセスできません。

- HSC がアクティブでない場合は、JCL で SLSCNTL、SLSCNTL2、および SLSSTBY DD 文を指定して、バックアップに使用するプライマリ、セカンダリ、およびスタンバイの CDS を識別する必要があります。

- HSC がアクティブな場合に、JCL で SLSCNTL、SLSCNTL2、および SLSSTBY DD 文を指定して、バックアップに使用するプライマリ、セカンダリ、およびスタンバイの CDS を識別している場合は、ユーティリティーを実行しているホストで HSC がアクティブな場合でも、DD 文が使用されます。HSC がアクティブで、これらの DD 文を省略した場合は、ユーティリティーを実行しているホストで HSC の稼働が使用するデータセットが使用されます。
プライマリ、セカンダリ、およびスタンバイ CDS をバックアップする JCL の例:

//JOBBKUP   job (account),programmer
//S1        EXEC PGM=SLUADMIN,PARM=MIXED
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//SLSBKUP   DD DSN=backup.dataset.name(+1),DISP=(NEW,CATLG,DELETE),
//             UNIT=SYSDA,SPACE=
//SLSCNTL   DD DSN=primary.dataset.name,DISP=SHR
//SLSCNTL2 DD DSN=secondary.dataset.name,DISP=SHR
//SLSSTBY DD DSN=standby.dataset.name,DISP=SHR
//SLSPRINT  DD SYSOUT=A
//SLSIN     DD *
BACKUP

CDS ロギングの管理

HSC トランザクションロギングサービスは、情報を 1 つ、またはオプションで 2 つのログファイルに記録する HSC の内部サービスです。CDS のすべてのコピーで障害が発生した場合 (つまり、プライマリ、セカンダリー、およびスタンバイのすべてのコピーが失われた場合) は、バックアップからの回復に時間がかかる場合があります。バックアップから回復するときに、CDS ロギングを利用して、CDS および VSM サブシステムのデータの内容を再同期できます。それぞれの構成ではじめてロギングを設定する場合は、『HSC および VTCS の構成』を参照してください。次のセクションでは、CDS ロギングを管理する方法を説明します。

注記:
ログファイルを使用する回復では、ログデータの解析と必要な MVC 監査文の構築を行なって、最新のデータへのアクセスを復元します。これによって CDS が障害の発生前とまったく同じ状態に回復されるわけではありません。たとえば、VTV は複数の MVC に存在する場合があります。監査では VTV のすべてのコピーに対するアクセスが回復されますが、これらのコピーが存在する MVC は、CDS が失われる前と正確には同じにならない可能性があります。CDS ロギングの目的はデータへのアクセスを回復することです。これはビット単位での CDS の回復ではありません。

定期的なログファイルのオフロード

ログファイルがいっぱいになってロギングが停止しないように、定期的にログファイルをオフロードする必要があります。オフロードのための最適な事例を次に示します。

- PROC を設定して、ログファイルを定期的にオフロードします。通常またはピーク時の運用状態でログファイルがいっぱいになるまでの経験上の計測時間に基づいて、その間隔でログのオフロードを実行します。

- また、SLS1781E メッセージを代行受信するように自動処理パッケージを設定することも検討してください。このメッセージは、ログファイルデータセットの使用量が 70% 以上になると表示されます。

- また、CDS の定期バックアップを実行するときにログファイルのオフロードを実行するようにスケジュールしてください。これにより、回復に使用するバックアップファイルに対応するログオフロードファイルを回復中に選択できます。

- CDS が (3 つのコピーすべて) 失われた場合や、何らかの理由で信頼性が低下した場合は、ログファイルをオフロードしないでください。このような場合は、「CDS の復元」を参照してください。

ログファイルの拡張と再割り振り

ログファイルを何らかの理由で拡張または再割り振りする必要がある場合は、次の手順に従います。

1. 新しいログファイルを作成しフォーマットします。
割り振られるログファイルのサイズは、現在使用しているシステムが生成するトランザクション数とオフロードを実行する頻度によって異なります。Oracle では、実稼働のログファイルのサイズを決定する前に、テスト用のログファイルの割り振りおよびアクティブ化を行い、ファイルがいっぱいになるまでにかかる時間を判断することをお勧めしています。

JCL の例:

//FMTLOG  JOB (account),REGION=1024K
//S1 EXEC PGM=SLUADMIN,PARM=MIXED
//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//SLSLOG1 DD DSN=hlq.CDSLOG1,DISP=(,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(CYL,100)
//SLSLOG2 DD DSN=hlq.CDSLOG2,DISP=(,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(CYL,100)
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
FMTLOG

2. SET LOGFILE を実行して、新しいログファイルを指定します。
JCL の例:

//SETLOG  JOB (account),REGION=1024K
//S1 EXEC PGM=SLUADMIN,PARM=MIXED
//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
SET LOGFILE(hlq.CDSLOG1,hlq.CDSLOG2)

3. OFFLOAD LOGFILE を実行して、古いログファイルをオフロードします。

//JOBOFFL job (account),programmer
//S1        EXEC PGM=SLUADMIN,PARM=MIXED
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//SLSOFFLD DD DSN=offload.dataset.name(+1),DISP=(NEW,CATLG,DELETE),
//             UNIT=SYSDA,SPACE=
//SLSCNTL   DD DSN=primary.dataset.name,DISP=SHR
//SLSCNTL2 DD DSN=secondary.dataset.name,DISP=SHR
//SLSSTBY DD DSN=standby.dataset.name,DISP=SHR
//SLSPRINT  DD SYSOUT=A
//SLSIN     DD *
OFFLOAD LOGFILE

HSC が自動的に新しいログファイルへの切り替えを行います。

手動による別の CDS コピーへの切り替え

「CDS のバックアップ」で説明したように、複数の CDS コピーを指定した場合にプライマリ CDS で障害が発生すると、HSC は自動的に別の CDS コピーに切り替えを行います。通常は別の CDS コピーへの切り替えを手動で行う必要はありません。基本的に、手動による切り替えが必要となるのは次のような状況です。

- CDS を移動または拡張する場合。

- HSC が CDS コピーを自動的に切り替えたあとに、古いプライマリを削除、再割り振り、および再作成する場合。再割り振りされたプライマリ CDS を有効にすると、HSC は有効な CDS データをバックアップコピーからこの CDS に再コピーします。

CDS コピーの切り替え、拡張、または移動には、CDS ENABLE/DISABLE コマンドを使用します。詳細は、『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください。

CDS の拡張

CDS EXpand コマンドを使用すると、VOLPARM データ、VTCS CONFIG データ、または外部に保管されたボリュームデータを CDS に追加できます。そのほかの構成を変更するときに、CDS のサイズ増加が必要となる可能性がある場合は (LIBGEN に FUTRACS および FUTRLSM パラメータを使用していないときに、新しい ACS および LSM を追加する場合など)、CDS EXpand 以外の手法を使用する必要があります。詳細は、『HSC および VTCS の構成』の「TapePlex の再構成」を参照してください。

注意:
Oracle は、CDS EXpand コマンドを発行する前に、すべての CDS コピーのバックアップを作成することを推奨します。拡張操作中に障害が発生すると、通常は CDS を使用できなくなります。CDS EXpand コマンド発行前に CDS のバックアップを作成し、拡張操作中の障害に備えて、CDS の最新のコピーが利用できるようにしておくことが重要です。

CDS EXpand のガイドラインは次のとおりです。

- CDS EXpand の使用中に、HSC はアクティブである必要があり、テープのアクティビティーを進行できます。

- 複数のホストから CDS Enable および Disable コマンドを同時に発行しないでください。同時に発行した場合、エラーメッセージが出されることがあります。この場合は、『ELS メッセージおよびコード』を参照して、ユーザーのアクションが必要かどうかを判断してください。

- 拡張操作の結果と矛盾しないように、必要に応じて HSC PARMLIB の CDSDEF 制御文を更新します。

- より大きな事前割り振り済みデータセットへの CDS の復元は、動的な CDS の拡張には使用できません。追加のスペースがフォーマットされていないため、そのままの状態では使用できません

- Oracle では、すべての CDS を同じ容量の DASD スペースに割り振ることを推奨します。CDS の使用可能なスペースは、最小の DASD スペースの割り振りで CDS に収まる 4096 バイトのブロック数で決まります。

すべての CDS を拡張するには、次の手順に従います。

1. CDS DISABLE コマンドを使用して、各 CDS を (1 回につき 1 つ) 無効にします。

2. より大きなプライマリスペースを使用して、各 CDS を再割り振りします。
セカンダリスペースを指定しないでください。すべての CDS でエクステントは 1 つだけである必要があります。

3. CDS ENABLE コマンドを使用して、各 CDS を再度有効にします。

4. CDS EXpand コマンドを入力します。
CDS EXpand コマンドの 1 回の呼び出しで、HSC で認識されている (つまり、有効な) すべての CDS が同時に拡張されます。

CDS の循環

CDS の自動切り替えまたは手動切り替えにより、CDS 名が変更されることはありません。一連の CDS Disable および Enable コマンドを使用して、順序を元に戻し、データセット名を期待される役割に一致させることができます。

CDS を循環させるには:

1. Display CDS コマンドを入力して、CDS の現在のステータスと割り当てを表示します。

SYS000001 = ELS.SYSCNTL2
PRIVOL = PROD02 FLAGS(40) ACTIVE
SYS000002 = ELS.SYSCNTL
SECVOL = PROD01 FLAGS(40) ACTIVE

この出力結果は、SYSCNTL (元のプライマリ) がセカンダリになり、SYSCNTL2 (元のセカンダリ) がプライマリになっていることを示しています。

2. 現在のプライマリを無効にします。

CDS DISABLE PRIMARY

ELS.SLSCNTL2 が無効になり、ELS.SLSCNTLT が新しいプライマリになります。

3. ELS.SLSCNTL2 をアクティブなセカンダリとして、再度有効にします。

CDS ENABLE DSN(ELS.SLSCNTL2)

4. Display CDS コマンドを入力し、CDS が循環されたことを確認します。

SYS000001 = ELS.SYSCNTL
PRIVOL = PROD02 FLAGS(40) ACTIVE
SYS000002 = ELS.SYSCNTL2
SECVOL = PROD01 FLAGS(40) ACTIVE

CDS の名前の変更

CDS の名前を変更する方法は 2 とおりあります。

- CDS Disable および Enable コマンドを使用して、HSC を停止せずに名前を変更します。

- HSC を停止し、BACKup および RESTore ユーティリティーを使用して名前を変更します。

BACKup および RESTore ユーティリティーを使用する場合、HSC の停止が必要になるのは明らかに不便ですが、CDS のバックアップが作成されるという利点もあります。

CDS Disable および Enable コマンドを使用した CDS の名前の変更

コマンドを使用して CDS の名前を変更するには、次の手順に従います。

1. 名前を変更する CDS をすべてのホストで無効にします。
例:

CDS DISABLE DSN(ACS.DBASEOLD)

2. CDS を含むデータセットの名前を変更します。
たとえば、ACS.DBASEOLD の名前を ACS.DBASECPY に変更します。

3. CDS を新しい名前で有効にします。
例:

CDS ENABLE DSN(ACS.DBASECPY)

名前を変更した CDS に対する Enable コマンドが失敗した場合は、CDS の定義がコマンドを発行する前の状態に戻されます。アクティブな CDS と矛盾しないように、HSC PARMLIB の CDSDEF 制御文を変更します。

CDS 名はデータベースハートビート (DHB) レコードに記録されます。HSC の初期設定時に、DHB 内のデータセット名は、HSC PARMLIB 内の CDSDEF 制御文に指定されているデータセット名と比較されます。

CDSDEF 文で指定したデータセット名が、DHB に記録されている、いずれの CDS 名とも一致しない場合、その CDS は無効になります。指定した CDS がすべて無効になった場合、HSC は初期化されません。プライマリ、セカンダリ、およびスタンバイ CDS に対する有効な CDS の割り当ては、データベースハートビートレコードに記録された CDS の割り当てに基づいて行われます。

CDS の名前変更が必要な場合は、次の名前変更の手順で説明しているように、HSC BACKup および RESTore ユーティリティーを使用してください。MSP、TSO ISPF、またはサードパーティーのユーティリティーを使用して、BACKup および RESTore ユーティリティーを実行せずに CDS の名前を変更しないでください。

CDS の再配置

CDS を再配置するには、次の手順に従います。

1. 再配置する CDS をすべてのホストで無効にします。
例:

CDS DISABLE DSN(ACS.DBASECPY)

2. 新しいデータセットを適切な CDS 属性を使用して割り振ります。

詳細は、『HSC および VTCS の構成』を参照してください。

3. CDS で手順 2 で割り振りしたデータセットを有効にします。
例:

CDS ENABLE DSN(ACS.DBASENEW)NEWLOC

注記:
指定されていなければ、MSP はカタログサービスを使用してボリュームとユニットの定義を解決します。

名前の変更または再配置の操作が失敗すると、CDS の定義がコマンドを発行する前の状態に戻されます。アクティブな CDS と矛盾しないように、CDSDEF 制御文を変更します。

カタログ化されていない CDS コピーの再配置

ACS.DBASECPY は無効化および削除され (または、カタログから外され)、ACS.NOTCATLG が割り振られてカタログ化されていると想定します。次のコマンドはカタログ化されていない CDS コピーを再配置します。

CDS ENABLE DSN(ACS.NOTCATLG) NEWVOL(HSC001),NEWUNIT(ABC)

このコマンドの CDS 定義と矛盾しないように、CDSDEF 制御文を変更します。名前の変更または再配置の操作が失敗すると、CDS の定義がコマンドを発行する前の状態に戻されます。

CDS のスワップ

HSC のコマンドまたはユーティリティーを使用した CDS の再配置とは対照的に、ディスクのデータセットを、ユーザーに影響を与えることなく別の位置にスワップできるようにするサードパーティーのソフトウェア製品は多数あります。HSC は、TDMF、FDRPAS、または P/DAS のスワップ操作が行われてから数秒以内に、CDS に保存されたデバイスアドレス情報を動的に更新するように機能強化されています。これにより、HSC および VTCS のユーティリティーは常に新しい CDS の位置を使用できます。

この強化では、CDS を無制限に移動する機能は提供されていません。PPRC またはスワップ操作以外の方法で CDS を移動するには、CDS の VOLSER への変更が必要です。CDS の VOLSER が変更された場合は、CDS の従来の SLUADMIN BACKup および RESTore の処理を使用して、デバイスアドレスとボリュームのシリアル情報をリセットする必要があります。

CDS の復元

CDS のすべてのコピーで障害が発生した場合 (つまり、プライマリ、セカンダリー、およびスタンバイのすべてのコピーが失われた場合) は、バックアップから CDS を復元する必要があります。CDS の複数のコピーがあり、そのうちの 1 つが失われた場合は、CDS ENABLE/DISABLE コマンドを使用して、有効なコピーで作業を継続し、エラーのあるコピーを再作成することができます。詳細については、「手動による別の CDS コピーへの切り替え」を参照してください。

注意:
CDS のすべてのコピーが失われたと考えられる場合は、Oracle ソフトウェアサポートに連絡して、実際にバックアップから CDS を復元する必要があることを確認し、必要に応じて復元処理のサポートを受けてください。

復元を実行する前に、破損した CDS の新しいバックアップを作成するか、あとで分析できるように現在のすべての CDS コピーを名前を変更して保存してください。

注記:

- RESTORE のプロセスは、CDS バックアップの作成に使用される SLUADMIN BACKUP と同じです。

- 復元を実行する前に、破損した CDS の新しいバックアップを作成するか、あとで分析できるように現在のすべての CDS コピーを名前を変更して保存してください。

バックアップコピーからの CDS の復元

バックアップコピーから CDS を復元するには:

1. いずれかのホストで HSC がまだ稼動している場合は、その HSC システムを停止します。
ロギングが有効な場合は、手順 2 に進み、VSM データを再同期します。それ以外の場合は、手順 3 に進みます。

2. CDS にアクセスできる場合は、通常のログファイルのオフロードジョブを実行します。

このオフロードは、前回のオフロード以降の VSM アクティビティーを取り込むために行います。

//JOBOFFL job (account),programmer
//S1        EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//SLSOFFLD DD DSN=offload.dataset.name(+1),DISP=(NEW,CATLG,DELETE),
//             UNIT=SYSDA,SPACE=
//SLSCNTL   DD DSN=primary.dataset.name,DISP=SHR
//SLSCNTL2 DD DSN=secondary.dataset.name,DISP=SHR
//SLSSTBY DD DSN=standby.dataset.name,DISP=SHR
//SLSPRINT  DD SYSOUT=A
//SLSIN     DD *
OFFLOAD LOGFILE

CDS にアクセスできない場合は、LOGDSN パラメータを使用してログファイルをオフロードします。通常の CDS ロギングプロセスは、CDS に保存されているログ情報を使用します。CDS にアクセスできない場合は、現在のログファイルにあるロギング情報を使用する必要があり、そのログファイルを LOGDSN パラメータで指定します。

//JOBOFFL job (account),programmer
//S1        EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//SLSOFFLD DD DSN=offload.dataset.name(+1),DISP=(NEW,CATLG,DELETE),
//             UNIT=SYSDA,SPACE=
//SLSPRINT  DD SYSOUT=A
//SLSIN     DD *
OFFLOAD LOGFILE LOGDSN(hsc.log1)

注記:
CDS にアクセスできない場合、CDS を復元したあとに、LOGDSN オプションを使用しないで OFFLOAD LOGFILE ユーティリティーを実行しようとすると、オフロードが失敗するか、誤ったログのオフロードファイルが作成される可能性があります。

3. 最新の正常なバックアップから CDS を復元します。

//JOBREST job (account),programmer
//S1        EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//SLSBKUP   DD DSN=backup.dataset.name(0),DISP=SHR
//SLSCNTL   DD DSN=primary.dataset.name,DISP=SHR
//SLSCNTL2 DD DSN=secondary.dataset.name,DISP=SHR
//SLSSTBY DD DSN=standby.dataset.name,DISP=SHR
//SLSPRINT  DD SYSOUT=A
//SLSIN     DD *
RESTORE

注意:
RESTORE の JCL で、使用しているすべての HSC データセット (プライマリ、セカンダリ、スタンバイ) を指定することが重要です。

詳細は、『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください。

注記:
ローカルおよびリモートリンクのライブラリが独立して CDS を実行している場合は、BACKup および RESTore を実行するときに特別な注意が必要です。ローカルおよびリモートのライブラリを接続するリンクを中断する場合は、これらの注意事項に従ってください。詳細は、『ELS レガシーインタフェースリファレンス』を参照してください。

回復にログファイルを使用している場合は、手順 4 に進みます。それ以外の場合は、手順 9 に進みます。

4. 復元された CDS が正しいログファイル情報を参照していることを確認します。

- SET LOGFILE(OFF) を実行します。

//SETLOG  JOB (account),REGION=1024K
//S1 EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
SET LOGFILE(OFF)

- FMTLG ユーティリティーを実行して、ログファイルを再フォーマットします。

//FMTLOG  JOB (account),REGION=1024K
//S1 EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//SLSLOG1 DD DSN=hlq.CDSLOG1,DISP=(,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(CYL,100)
//SLSLOG2 DD DSN=hlq.CDSLOG2,DISP=(,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(CYL,100)
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
FMTLOG

- SET LOGFILE をもう一度実行して、新たに初期化したログファイルの名前を指定します。

//SETLOG  JOB (account),REGION=1024K
//S1 EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
SET LOGFILE(hlq.CDSLOG1,hlq.CDSLOG2)

5. LOGUTIL コマンドを実行して、回復に必要なデータセットと AUDIT MVC コマンドを生成し、そのデータセットでコマンドを実行します。

次の例では、最新の正常な CDS バックアップが 2009 年 5 月 12 日の午後 10 時に作成されていることを想定しています。

- LOGIN 文は、各オフロードログファイルの DD 文を、最新の正常なバックアップで作成されたログファイルから、2 で作成したログファイルまで指定しています。

- LOGUTIL GENAUDIT は、VSM データを回復するコマンドを含むデータセットの DD 名として、RECVCMD を指定します。

//JOBLOGR job (account),programmer,REGION=1024k
//S1 EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//LOGIN        DD DSN=offload.dataset.name(-2),DISP=OLD
//             DD DSN=offload.dataset.name(-1),DISP=OLD
//             DD DSN=offload.dataset.name(0),DISP=OLD
//RECVCMD      DD DSN=offload.dataset.genaudit,DISP=(,CATLG,DELETE),
//                UNIT=SYSDA,SPACE=
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
LOGUTIL FROMDATE(2009-5-12) FROMTIME(22:00:00)  LOGDD(LOGIN)
GENAUDIT COMMANDS(RECVCMD)

6. 現在 LOGPOL=REQUIRED が VTCS 構成に指定されている場合:

LOGPOL=OPTIONAL を CONFIG GLOBAL 文に指定して CONFIG を実行し、VTCS 構成のロギングを一時的に無効にします。これは、HSC/VTCS がアクティブでないときに MVCMAINT コマンドを正常に実行するために必要です。

7. 監査対象の MVC を読み取り専用ステータスに設定します。
HSC/VTCS がアクティブでないときに MVC を監査する場合は、MVCMAINT READONLY(ON) コマンドを実行します。これにより、HSC/VTCS がアクティブのときに MVC が使用されないことが保証されます。

//JOBAUDIT job (account),programmer,REGION=1024K
//S1 EXEC PGM=SLUADMIN,PARM='execution parameters'
//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
MVCMAINT READONLY(ON) MVC( +
mvc1 +
mvc2 +
…    +
mvcn +
)

8. LOGPOL=REQUIRED が VTCS 構成で必要な場合:
LOGPOL=OPTIONAL を手順 6 (前述) で一時的に指定した場合は、LOGPOL=REQUIRED を CONFIG GLOBAL 文に指定して CONFIG を実行します。

9. ホストの 1 つで HSC を再起動しますが、テープのアクティビティーは開始しません。

10. CDS の VSM 以外の部分を回復するために、すべての ACS で SLUADMIN AUDIT を実行します。

//JOBAUDIT job (account),programmer,REGION=1024k
//S1 EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
AUDIT ALL

注記:
ライブラリの監査が開始したら、手順 11、手順 12、および手順 13 を並行して実行できます。

11. すべての VTSS を監査します。

//JOBAUDITV job (account),programmer,REGION=1024k
//S1 EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
AUDIT VTSS(VTSS0,VTSS1)

12. スクラッチ同期を実行します。

SLUCONDB を実行して、HSC のスクラッチステータスを TMS と同期します。詳細については、ELS のコマンド、制御文、ユーティリティーに関するリファレンスを参照してください。

13. ロギングを使用している場合は、手順 5 で作成したデータセットから回復コマンドを使用して、対象となる MVC を監査します。

//JOBRMVC job (account),programmer,REGION=1024k
//S1 EXEC PGM=SLUADMIN,PARM=’execution parameters’
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//SLSIN DD DSN=offload.dataset.genaudit,DISP=SHR
//SLSPRINT DD SYSOUT=*

ロギングを使用していない場合に監視が必要な MVC を判別するには、Oracle ソフトウェアサポートにお問い合わせ下さい。

14. すべてのホストで HSC を起動します。

15. テープのアクティビティーを再起動します。

3 TapePlex の管理

一般的に、TapePlex の管理は VTCS の管理に似ています。つまり、(1) 定期的および継続的に TapePlex の健全性を監視し、(2) 必要なときに必要に応じた作業を行います。ただしこの章では、TapePlex の物理的要素および正常な動作に必要な作業について説明するときは、定期的なタスクと必要に応じたタスクを混在させて説明します。SMC/HSC/VTCS はサーバーソフトウェアであり、自己訂正するように設計されています。同様に、ライブラリハードウェア自体にも冗長性と回復力が備わっています。したがって、ソフトウェアとハードウェアのステータスを頻繁に確認し、発生した問題をすべて修正してさえいれば、TapePlex 管理タスクのほとんどは処理できていることになります。

ライブラリハードウェアの管理

ステータスの確認に最適なツールの 1 つとして、DISPLAY EXCEPTNS という名前のコマンドがあります。ここでの「例外 (exception)」は最適とは言えないハードウェア条件です。期待されるコマンド出力は、「No ハードウェアコンポーネント名 problems were detected」という一連のメッセージです。システム上の問題が発生している場合は、これらの出力から、ハードウェアは正常で、ソフトウェアに問題があることがわかります。

一方、「CAP Not Operational (CAP が動作不能)」、「Robot Hand needs Maintenance (ロボットハンドの保守が必要)」、「LSM is Offline (LSM がオフライン)」などの出力が表示される場合は、ソフトウェアとハードウェアのどちらに問題があるかを判断するために、さらに詳しい情報が必要となります。したがって、これらのメッセージのいずれかが表示された場合は、メッセージを『ELS メッセージおよびコード解説書』で調べて、詳細な説明とユーザーとしての対応を確認してください。場合によっては、対応は明確で簡単です。ロボットハンドの保守が必要な場合は、CSE に連絡します。ただし、対応がそれほど明確にならない場合もあります。LSM がオフラインの場合、明確な処置とはこれをオンラインに戻すことです。ただし、LSM が保守のために停止している場合や、ドライブデバイスのアドレスを変更している場合は、作業が完了するのを待ってから、LSM をオンラインに戻す必要があります。

このように、DISPLAY EXCEPTNS を第一の診断ツールとして使用して、問題がないことを確認するか、問題がある場合はこれを解決し、さらにアクティビティーレポートと ACS の日次レポートを使用して、ライブラリのパフォーマンスを調整します。ライブラリハードウェアの管理という観点から、次のタスクは何でしょうか。次のセクションでは、ステータスを確認するコマンドやコマンドが示す条件への対応について詳しく説明します。

ACS の管理

DISPLAY ACS と DISPLAY ALL の 2 つもよく使用されるコマンドで知っている必要があります。DISPLAY ACS は、ACS のステータスを表示します。ACS、LMU、およびステーションについてのハードウェアのステータスと、使用可能なスクラッチボリュームおよび空きセルなどが表示されます。DISPLAY ALL は、これに加えて LSM と CDS のステータスも表示します。状態がオンラインまたは動作していないコンポーネントも表示されます (切断された ACS、オフラインまたはスタンバイモードのステーション、オフラインの LSM など)。LSM および CAP の状態を変更するには MODIFY コマンドを使用し、ACS の状態を変更するには VARY コマンドを使用します。ただし、上の説明に従って、適切なコマンドを入力する前に、ハードウェアの状態を変更する理由とその方法について確認してください。LSM を保守のためにオフラインに変更する必要がある場合は、その LSM に対するテープアクティビティーが休止されていることを事前に確認してください。同様に、LSM をオンラインに変更する場合は、保守が完了していることを事前に確認してください。

SL8500 冗長電子デバイスの管理

冗長電子デバイスオプションを使用すると、ライブラリコントローラスイッチの自動化により、ライブラリコントローラ (LC) 障害に起因する制御経路のダウン時間を最小限にすることができます。この構成において、2 番目のライブラリコントローラはローカルエリアネットワークにケーブルで接続し、LSM (複数も可) に接続しています。HSC は、アクティブ LC と呼ばれる 1 つのライブラリコントローラにすべての作業を指示しますが、スタンバイと呼ばれる 2 番目の LC は、準備のできたバックアップ用として常に電源投入されています。アクティブ LC とスタンバイ LC は動的に指定され、それらの役割は環境の条件によって変わります。

このセクションで説明するコマンドやユーティリティーについては、『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください。

デュアルライブラリコントローラ構成

この実装では、デュアル LC 構成とは、導入され、1 つのライブラリにネットワークで 1 列に接続された 1 対の LC のことです。これが唯一の有効な構成です。図3-1 は、この構成の例を示しています。

図3-1 デュアル LC 構成

次の規則がデュアル LC 構成に適用されます。両方の LC に適用されます

- すべてのホストに接続する

- いつでも電源投入できる

- LAN 0 および LAN 1 の両方に接続する。

アクティブ LC に障害が起こると自動切り替えが行われて、スタンバイがアクティブ LC の役割を引き継ぎます。HSC は、この切り替えを通知されるとオペレータにそれを知らせます。ほとんどの未完了要求が再駆動されて、それ以降のライブラリ要求はすべて新しくアクティブになった LC に送られます。障害を起こした LC が修復され、電源投入されると、今度はこれがスタンバイの役割を引き継ぎます。

オペレータコマンドの SWitch は、スタンバイ LC を動的にアクティブ化するのが望ましい場合に使用できるものです。オペレータが Switch コマンドを発行すると、スタンバイ LC は、リブートを開始するように前のアクティブ LC に命令したあとでアクティブ LC の役割を引き継ぎます。前のアクティブ LC が正常にリブートすると、その LC はスタンバイ LC の役割を引き継ぎます。

注記:
デュアル LC 環境での操作に関して、警告と予防措置があります。これらの要件に精通するには、冗長 LC の操作上の概要を参照してください。

HSC の導入時に、アクティブ LC とスタンバイ LC の両方にネットワーク接続を指定する必要があります。

SL8500 冗長電子デバイス環境

ライブラリ要求は、すべてのネットワーク接続パスが LC に対してオフラインになっているか、またはすべてのネットワーク接続パスが作動不能な場合には、自動化されません。冗長電子デバイス環境で、アクティブ LC へのすべてのネットワーク接続パスが動作不可能な場合は、HSC SWitch コマンドを使用してワークロードをスタンバイ LC に移動します。

SL8500 LC 操作

ライブラリコントローラ (LC) は、HSC を通してホストからのマウントとマウント解除要求に応答して、要求をそれぞれ該当する LSM に渡し、要求された物理的なアクションを実行します。

このセクションで説明している手順は次のとおりです。

- ACS ステータスの表示

- 「冗長 LC の操作上の概要」。

注記:

- LC をリブートすると、次のメッセージの前にエラーメッセージが表示されます。

... ACS AA LSM LL ready; ...

これは無視してかまいません。このメッセージのあとに表示されるエラーメッセージは無視しないでください。

- ライブラリ制御パネルの説明、電源オンや電源オフの方法、およびスタンドアロン LC と冗長 LC の両方の構成でライブラリコントローラをブートする方法については、該当する Oracle ハードウェアのオペレータガイドを参照してください。

ACS ステータスの表示

LC のステータスを判別するには、次のコマンドを発行します。

Display Acs acsid

コマンドの応答は、次をリスト表示します。

- ACS の現在のステータス

- 次を含む現在の冗長 LC のステータス (構成した場合)

- HSC/LC 互換性レベル

- アクティブ LC

- スタンバイ LC

- 各 LC のオンライン、オフライン、またはスタンバイステータス

冗長 LC の操作上の概要

冗長電子回路構成では、アクティブ LC に障害が発生した場合に引き継ぐことができるバックアップ LC が提供されます。(デュアル LC オプションについては、デュアルライブラリコントローラ構成を参照してください。)いずれの LC もアクティブにできますが、アクティブな LC にすることができるのは 1 回につき 1 つのみです。各 LC は LAN 上でほかの LC のステータスを定期的に検査します。HSC は、アクティブ LC に対するすべての入出力を指示します。

デュアル LC 構成で LC の電源をオンにすると、スタンバイステータスに入り、アクティブ LC があるかどうかを検査します。アクティブ LC が存在する場合は、2 番目の LC がスタンバイとして準備のできた状態を保ちます。アクティブ LC が存在しない場合は、完全に初期化される最初の LC がアクティブの役割を引き継ぎます。

LC の電源が両方とも正常にオンになると、次の HSC メッセージが表示されます。

... ACS AA: RE LIBID C1 is configured; Active is y, Standby is ready

ここでは、y は「A」または「B」の構成済み LC 識別子です。

LC 切り替えの概要

アクティブ LC の機能は、次の形で切り替わる場合があります。

- アクティブ LC における自己検出障害または電源装置問題による自動切り替え。

- すべてのオンラインステーションが通信不能になったあとに (SWitch コマンドを使って) オペレータが行なった切り替え。

- オンラインステーションがアクティブ LC と通信できるときに (SWitch コマンドを使って) オペレータが行なった切り替え。

- アクティブ LC のリブートスイッチが押された場合。

- アクティブ LC の電源がオフになった場合。

LC 切り替えの結果

LC 切り替えが行われると、一連のコンソールメッセージがアクティブ LC とスタンバイ LC のステータスの変化を追跡します。クリティカルなステータスの変化のメッセージは高輝度表示され、その状態が訂正されるかまたはほかのメッセージで置き替えられるまでそのまま画面上に残ります。

ステータスが変わって、スタンバイ LC の準備が整うと、次のメッセージが表示されます。

... ACS AA: RE LIBID C1 is configured; Active is y, Standby is ready

ステータスの変化があり、LC エラーが起こると、次のメッセージが表示されます。

... ACS AA: : RE LIBID C1 Is Not configured; Active Is y, Standby is not ready

ステータスの変化があり、スタンバイ LC の準備が整っていない場合は、次のメッセージが表示されます。

... ACS AA: : RE LIBID C1 Is configured; Active Is y, Standby is not ready

前のメッセージで、y は「A」または「B」の構成済み LC 識別子です。

LC 切り替えが行われると、HSC は各 LC に応答指令信号を送って現在のステータスを判別します。各ステーションのステータスは、オンライン、オフライン、スタンバイ、オンライン保留、オフライン保留、または強制オフライン保留として保持されます。Display Acs acsid コマンドを使用して、各ステーションおよび LC のステータスを確認します。

注記:
LSM が初期化を完了するまで、LC の切り替え中は自動モード CAP がロックされます。

自動 LC 切り替え

LC マイクロコードは、ACS を稼動し続けるために LC エラーを検出および報告し、対処します。注意する必要があるのは、これは自動的に行われるので、一部の作業は LC 内で処理中である可能性があるということです。スタンバイ LC は、アクティブの役割を引き継ぐと、HSC にその変化したステータスを通知し、LC 準備完了信号を送ります。HSC は、ACS の中の各種 LSM 内の転送中カートリッジに関する新規のアクティブ LC が提供する回復情報を読み取ります。そのあと、HSC は次を行います。

- 移動中のカートリッジの現在位置を反映して、待ち行列にある要求を変更するか、「完了」のマークを付けます

- すべての未完了の要求をアクティブ LC に送信します

- 要求を正常に完了できなかったときには、カートリッジをエラントとしてマーク付けします。

注記:
エンター操作およびイジェクト操作は、LC 切り替え後に再起動が必要な場合があるので注意してください。

オペレータによる LC 切り替え

通信中のネットワーク接続がある場合は、LC の切り替えを開始する前に、LC をすぐに切り替える必要があるかどうか、または切り替えを開始する前に処理を完了できるかどうかを判別します。LC を切り替える必要性がそれほど差し迫っていない場合は、LSM がアイドルに近い状態になるまで待機してください。

ライブラリ ID の LC 切り替えを開始するには、次のコマンドを発行します。

SWitch Acs acsid LIB libid

このコマンドは、スタンバイ LC を経由して切断された LC に送られ、切断された LC はリブートされます。次の一連のイベントが起こります。

1. HSC が次のメッセージを発行します

... ACS AA: Switch initiated, expect notification in 20 seconds

2. スタンバイ LC がアクティブ LC の役割を引き継ぎます (「ACTIVE」標識が点灯します)。

3. オンラインの LSM が高速初期設定を実行します。

4. 各 LSM の準備が整うと、HSC が次のメッセージを発行します。

... ACS AA LSM LL Ready; Temp Outage Queue Will Be ReDriven

5. 前のアクティブ LC のリブートが正常に完了すると、今度はその LC がスタンバイ LC の役割を引き継ぎます。

処理がアクティブである間に SWitch コマンドが発行されると、いくつかの LSM 内でカートリッジが移動中の状態になることがあります。「自動 LC 切り替え」の説明にあるとおり、回復手順が自動的に行われます。LC 準備完了信号を受け取ると、HSC は LSM が高速初期設定を完了するのを待ってから、一時機能停止待ち行列の処理によって要求を再駆動します。

CAP の手動回復

特定の CAP 機能が要求 (エンター/イジェクト) を処理しているときに LC 切り替えが行われると、切り替えの完了後に回復のための手動介入が必要です。次に、さまざまな CAP シナリオと、それぞれに適した解決手順を示します。

エンター機能がアクティブなときに切り替えが行われる

切り替えが行われ、エンター機能がアクティブな場合は、切り替えの完了後に、2 つのイベントが同時に、または個別に発生する可能性があります。

- 切り替えが行われると、カートリッジが HSC/ELS によって選択されますが、LSM ホームセルに移動されません。切り替えの完了後にカートリッジが選択されますが、LSM セルに移動できません。

- LSM に移動する CAP 内のカートリッジが、移動中にライブラリから SLS0699I - 03/01 エラーのメッセージを受け取ります。切り替えの完了後に CAP 内にカートリッジがあるため、ライブラリはその CAP を予約します。ライブラリは、カートリッジが取り出されるまで CAP の所有権を保持します。これは SL8500 ライブラリの通常の動作です。

解決の手順:

- SL8500 オペレーターズガイドの手順を使用して、SLC でカートリッジを CAP から手動で削除します。

- 対象となる特定の CAP に対して Display Cap aa:ll:cc コマンドを発行します。

- CAP がオフラインの場合は、Modify CAP aa:ll:cc,online コマンドを発行します。

- ENter aa:ll:cc コマンドを発行して、CAP のエンター機能を再起動します。

- CAP が自動の場合は、次を発行します。

CAPP x aa:ll:cc MANual
CAPP x aa:ll:cc AUTO

自動モードにリセットされます。

- 前のエンター機能から削除されたカートリッジのバランスを CAP に挿入します。

- SLS0251E メッセージに volser が重複していることが示される場合は、UNSELECT ユーティリティーを実行してその volser を選択解除します。そのあとで、volser を LSM にエンターできます。
volser を入力して、メッセージ SLS0694D が表示され、重複をどう扱うか尋ねられたら、論理的に削除すると応答するようにしてください。

イジェクト機能がアクティブなときに切り替えが行われる

イジェクト機能がアクティブなときに切り替えが行われると、切り替えの完了後に、CAP に移動する LSM 内のカートリッジが、移動操作の対象のライブラリから SLS0699I メッセージ - 03/01 エラーを受け取ります。切り替えの完了後に CAP 内にカートリッジがあるため、ライブラリはその CAP を予約します。ライブラリは、カートリッジが取り出されるまで CAP の所有権を保持します。これは SL8500 ライブラリの通常の動作です。

解決の手順:

- SL8500 オペレーターズガイドの手順を使用して、SLC でカートリッジを CAP から手動で削除します。

- 対象となる特定の CAP に対して Display Cap aa:ll:cc コマンドを発行します。

- CAP がオフラインの場合は、Modify CAP,online コマンドを発行します。

- EJECT vol-list または vol-range aa:ll:cc コマンドを再発行するか、EJECt ユーティリティーを再起動して、カートリッジのバランスをイジェクトします。

- イジェクト機能よりも前に CAP が自動であった場合は、CAPP x aa:ll:cc manual を発行してから、CAPP x aa:ll:cc auto を再発行して、それを自動モードにリセットします。

CAP が自動モードに設定されているときに切り替えが行われる

CAP が自動モードに設定されているときに切り替えが行われると、切り替えの完了時に、メッセージ SLS0699I に 07/05 エラーの戻り/理由コードが、CAP の保持中にライブラリから表示されることがあります。これは、切り替えの完了後に CAP が完全に初期化されなかったためです。これは SL8500 ライブラリの通常の動作です。

解決の手順:

- 切り替え対象のライブラリにある最後の LSM に対するメッセージ SLS0668I が発行されるまで待ちます。

- 自動 CAP ごとに CAPPref prefvalue aa:ll:cc MANual を発行します。

- 自動にする CAP ごとに CAPPref prefvalue aa:ll:cc AUTO を発行します。

CAP の管理

DISPLAY CAP は、CAP の設定とステータスを表示します。MODIFY CAP は、CAP の状態を変更します。DISPLAY CAP では、基本的なステータス情報に加え、CAP の状態を変更するかどうか、またその場合はいつ行うかを判断するために役立つ重要な情報も表示されます。

- CAPid

- CAP サイズ: PCAP (優先 CAP)、21 セルまたは 14 セルのモデル 9740 (標準 CAP)、40 セル (拡張 CAP)、20 セル (9360 CAP)、30 セル (9360 オプション CAP)、または 39 セル (SL8500 CAP)

- CAP を所有するホストのホスト ID

- 優先順位: CAP 優先値

- CAP モード: クリーニング、ドレイン、イジェクト、エンター、またはアイドル状態

- CAP ステータス: アクティブ、自動モード、手動モード、オフライン、オンライン、回復が必要

CAPPREF コマンドを使用すると、CAP モード (手動または自動) と選択の優先値 (0-9、9 の優先順位がもっとも高い) を設定できます。手動モードの CAP ではロックの解除に ENTER コマンドが必要ですが、自動モードの CAP では必要ありません。通常は、HSC PARMLIB メンバーの構成で CAPPREF コマンドに CAP のモードと優先値を指定し、これらの設定を使用して実行します。CAP の設定を変更する必要がある場合は、CAPPREF コマンドを入力して動的にそれを行うことができます。たとえば、システムで挿入とイジェクトが高い頻度で発生している場合は、拡張 CAP に対して CAP の優先を上げることができます。警告: CAP の優先値を設定する際は、優先 CAP (PCAP) の優先順位を常に 0 にして (特に要求がないかぎりは選択せずに)、それらを通常使用できる状態にしておいてください。

手動 RTD の定義

DR の状況では、利用可能な自動テープリソースがない可能性があります。ライブラリ外の VSM の構成をサポートするために、存在しない ACS に手動 RTD を定義する必要があります。

手動 RTD を定義するには、次の手順に従います。

1. LIBGEN マクロを生成して、存在しない ACS を定義します。
SLIDRIVS マクロは、手動 RTD のデバイスアドレスを定義します。

注記:
存在しない ACS の LSM を SL8500 または SL3000 として定義して、MODIFY CONFIG コマンドを利用できます。

2. SLICREAT ユーティリティーを実行して、新しい CDS をフォーマットします。

3. SET SLIDRIVS ユーティリティーを実行して、手動 RTD の MODEL を設定します。次に例を示します。

SET SLIDRIVS(400,401,402,403) MODEL(T9840C)

注記:
同じパネルにある手動 RTD は、デバイスタイプが同じである必要があります。

4. VTCS CONFIG ユーティリティーを実行して、VSM システムを定義します。

5. VTCS IMPORT ユーティリティーを使用して、手動 RTD で使用する MVC を新しい CDS にインポートします。
これらの MVC はライブラリ外ボリュームとして処理されます。

テープデータの保護

このセクションでは、実際および仮想の両方のテープボリューム上でデータの上書きを防止するために使用できる ELS 機能について説明します。

ネイティブテープデータの保護

Oracle/StorageTek T9840、T9940B、および T10000 テープカートリッジは、テープ上に存在するデータの再書き込み不可能な保護ソリューションを提供する VOLSAFE セキュアメディアテクノロジーを使用して順序付けすることができます。VOLSAFE カートリッジは、WORM (Write Once Read Many) カートリッジとも呼ばれます。

データが VOLSAFE セキュアメディアに書き込まれると、付加することはできますが、修正または削除することはできません。これらのカートリッジには、非 VOLSAFE カートリッジと差別化する物理的、視覚的、電子的な機能があります。

VTV データの保護

VSM システムは、VTV 用に VOLSAFE 保護を提供するようになりました。VTV にはスクラッチマウントされるときに保護属性が割り当てられ、この属性は VTV が非スクラッチであるかぎり維持されます。VOLSAFE 保護された VTV をスクラッチするには、TAPEVOL クラスの RACF ALTER 権限が必要です。

VTCS は、MGMTclas WRITE パラメータを使用してこの保護を有効にします。このパラメータでは、次のように VTV VOLSAFE ポリシーを指定します。

MANY

デフォルト。VOLSAFE 書き込み保護なしを指定します。

ONCE

読み取り専用保護を提供します。非スクラッチになると、VTV は変更できません。

MVC データの保護

HSC は MVC がスクラッチであるとマークされることを許可しませんが、たとえばつぎのような MVC データを保護するその他の方法を検討してください。

- HSC タスクのみが MVC ボリュームに書き込むことができるように RACF 権限を確立する。

- MVCMAINT ユーティリティーを使用して、MVC を読み取り専用に設定する。

- VOLSAFE 保護されたメディアを MVC として使用する。ネイティブのテープと同様に、データが VOLSAFE セキュア MVC に書き込まれると、付加することはできますが、修正または削除することはできません。

- VOLSAFE ボリュームが含まれる任意の MVC プールの POOLPARM MVC NORECLAM パラメータを指定して、プールのスペースリクレイムを防止します。これにより、書き込み可能 EOT 位置が保証されます。

- VOLSAFE MVC について、すべての VTV リコール処理は影響を受けません。

ライブラリボリュームの管理

ライブラリボリュームの管理には、ボリュームレポートの使用からクリーニングカートリッジの管理まで、さまざまなタスクが含まれます。ここでは、ボリュームレポートの使用法から説明します。

ボリュームレポートの使用

VOLRPT ユーティリティーは、ライブラリ内の物理ボリュームの管理に役立つボリューム情報を出力します。VOLRPT ユーティリティー機能は統合ユーザーインタフェースを使用します。これにより、テキスト、XML、およびカンマ区切りテキスト (CSV) の出力形式を利用できます。XML および CSV 形式を要求する方法、出力内容の説明、およびコマンド構文の詳細な説明については、『ELS コマンド、制御文、およびユーティリティーリファレンス』および『ELS プログラミングリファレンス』を参照してください。

VOLRPT を定期的に実行して、ボリュームの例外条件を表示して解決したり、次のセクションで説明するようなボリュームのステータスだけを表示することもできます。

- エラントボリュームおよび選択されたボリューム

- VOLPARM と外部ラベルが一致しないステータス

- VOLPARM に含まれていないボリューム

- スクラッチサブプールの管理

- 「クリーニングカートリッジの管理」。

VOLRPT には、他にも多くの使用法があります。ボリュームを選択する方法や VOLRPT 出力をソートする方法については、『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください。

エラントボリュームおよび選択されたボリューム

VOLRPT 制御カードの例を示します。

VOLRPT SORT(LOC) INCLUDE(SEL,ERR)

この要求は、すべてのエラントカートリッジや選択されたカートリッジのレポートを、位置順に生成します。

「選択された」ステータスは、通常は一時的で、カートリッジがスクラッチされているか、別の位置に移動されていることを表します。レポートの「選択された」ボリュームごとに、DISPLAY VOLUME コンソールコマンドを発行して、ボリュームの選択が解除されているかどうかを確認してください。ボリュームが選択されたままの場合は、ボリュームが選択されている間にホストが異常終了した可能性があることを示しています。ボリュームが現在使用中でないことが明らかな場合は、UNSELECT ユーティリティーを実行して、「選択された」ステータスをリセットできます。

エラントボリュームは、最後に確認された位置にないボリュームです。エラントボリュームをイジェクトまたはマウントしようとすると、HSC はホームセル、最後に確認されたソース位置、および最後に確認された宛先位置にあるボリュームを検索します。ボリュームがこれらのいずれの場所にもない場合は、ACS の監査を実行してボリュームを探さなければならない場合があります。

VOLPARM と外部ラベルが一致しないステータス

VOLRPT 制御カードの例を示します。

VOLRPT INCLUDE(NONMEDEQ)

この要求は、カートリッジのメディアラベルが VOLPARM のメディアタイプに一致しないすべてのボリュームのレポートを生成します。

メディアの前に付加される文字は、検出された不一致のタイプを示します。アスタリスク「*」は、ラベルが VOLPARM のメディアコードと一致しなかったことを意味します。マイナス記号「-」は、ボリュームに一致する VOLPARM がなかったことを意味します。これらのボリュームには、「*NON-VOLPARM*」のスクラッチサブプールも表示されます。「@」の文字は、ボリュームに物理メディアラベルがないことを意味します。

このコマンドの出力例を図3-2 に示します。

図3-2 ボリュームレポート (VOLPARM と外部ラベルの不一致)

VOLPARM に含まれていないボリューム

サブプール合計のみに *NON-VOLPARM* プールのボリュームが表示される場合は、これらのボリュームの詳細なリストを取得できます。これらのボリュームを選択する特別な制御カードはありませんが、INCLUDE(NONMEDEQ) を使用できます。また、VOLPARM のメディアがボリュームラベルのメディアと一致しないボリュームも確認できます。

スクラッチサブプールの管理

次のコマンドを実行すると、サブプールの合計を、サブプール、ライブラリの位置、およびメディアタイプごとに示すレポートを表示できます。個々のボリュームは表示されません。

VOLRPT SUMM(SUBPOOL) NOVOL

このコマンドの出力例を図3-3 に示します。

図3-3 ボリュームレポート (スクラッチサブプール)

VOLRPT を使用したクリーニングカートリッジの使用状況の追跡

次のコマンドを使用すると、クリーニングカートリッジのみが含まれるレポートを、使用回数順に生成できます。

VOLRPT VOL(CLN%%%) SORT(USE) DESCEND

出力例を図3-4 に示します。

図3-4 ボリュームレポート (クリーニングカートリッジ)

クリーニングの使用回数は、右端の「Times Selected」というラベルの付いたフィールドに表示されます。クリーナーの使用限度を超えている場合は、レポート中央の「Cln Use」というフィールドに「Y」と示されます。

マウントパフォーマンスの最適化

「最適なマウントパフォーマンス」は、実際のテープボリュームのマウントおよびマウント解除にかかる時間で測定されます。この目的で最適なツールはアクティビティーレポートです。このレポートは、SMF レコードからデータを取得し、ACS と LSM 全体でマウント/マウント解除アクティビティーのバランスを調整するために役立つ情報を出力します。このレポートには、発生したマウントおよびマウント解除アクティビティーの合計が、次のように出力されます。

- スクラッチマウント/合計マウント、およびマウント当たりの平均時間

- 非スクラッチマウント/合計マウント、およびマウント当たりの平均時間

- 別の LSM にあるスクラッチマウント/合計マウント、マウント 1 回当たりの平均時間、およびパススルーの平均数

- 別の LSM にある非スクラッチマウント/合計マウント、マウント 1 回当たりの平均時間、およびパススルーの平均数。

アクティビティーレポートでスクラッチマウントが原因のパフォーマンスの問題が見つかった場合は、HSC スクラッチ再分配ユーティリティーを使用して、特定の ACS 内の LSM 間でスクラッチボリュームを再分配できます。スクラッチボリュームが不足している場合は、スクラッチ同期を実行してデータが最新でないボリュームをスクラッチするか、ACS に追加のスクラッチボリュームを入力することができます。

ボリュームアクセスセキュリティーの使用

HSC ボリュームアクセスユーザー出口 (SLSUX14) は、ボリュームのセキュリティーチェックを実行します。SLSUX14 が有効な場合、マウント、イジェクト、およびスクラッチリクエストに対してボリュームのセキュリティーチェックが実行されます。

プログラミングの詳細は、『ELS プログラミングリファレンス』でボリュームアクセスユーザー出口 (SLSUX14) に関する説明を参照してください。

SLSUX14 は、リクエストを完了または拒否できます。SLSUX14 でのコーディングで、RACROUTE マクロの発行やその他の方法を使用して、リクエストが処理されるのか拒否されるのかを判断できます。もう 1 つのオプションは、リクエストの成功/拒否を判断するために、RACROUTE および RACF 定義を使用して HSC がセキュリティーチェックを実行することをSLSUX14 で示すことです。一方の SLSUX14 リターンコードは、TAPEVOL クラスがボリュームアクセスチェックに使用されることを指定します。もう一方の SLSUX14 リターンコードは、ボリュームアクセスチェックに使用するために、ユーザー出口が RACF クラスをパラメータリストに置いたことを指定します。その後、HSC はその RACF クラスをボリュームセキュリティーチェックに使用します。

RACF 属性

次のボリュームリクエストを発行するユーザーは、HSC が RACROUTE マクロを実行するときに、リクエストが成功するためには別の RACF 権限が必要です。

- MOUNT – RACF UPDATE 権限は、マウントの続行を許可します。

- MOUNT – RACF READ 権限は、マウントの続行を許可します。ボリュームは、書き込み保護状態でマウントされます。

- EJECT – イジェクトリクエストの場合、ユーザーは RACF UPDATE 権限が必要です。

- SCRATCH – スクラッチリクエストの場合、ユーザーは RACF CONTROL 権限が必要です。

次に、RACF 権限を設定するコマンドの例を示します。

RDEFINE TAPEVOL 111111 UACC(NONE)
PERMIT 111111 CLASS(TAPEVOL) ID(USER1) ACCESS(READ)
PERMIT 111111 CLASS(TAPEVOL) ID(USER2) ACCESS(UPDATE)
PERMIT 111111 CLASS(TAPEVOL) ID(USER3) ACCESS(CONTROL)

この例で示すように、USER1 はボリューム 111111 を読み取りアクセス (書き込み保護) でマウントできます。USER2 はボリューム 111111 を書き込みアクセスでマウントできます。その他すべてのユーザーの場合、111111 のマウントリクエストは拒否されます。USER3 は、スクラッチリクエストを実行できます。

Write Once/Read Many (WORM) のサポート

次の例の更新されたコマンドセットに示すように、WORM シナリオをサポートするために SLSUX14 を「スクラッチしない」ポリシーを強制するときに使用できます。

RDEFINE TAPEVOL 111111 UACC(NONE)
PERMIT 111111 CLASS(TAPEVOL) ID(USER1) ACCESS(READ)
PERMIT 111111 CLASS(TAPEVOL) ID(USER2) ACCESS(UPDATE)

この例で、USER3 にはボリューム 111111 に対する CONTROL アクセスがなくなりました。そのため、RACF 構成を定義して CONTROL 権限を取得するユーザーを除き、すべてのユーザーからのボリューム 111111 に対する SCRATCH リクエストは拒否されます。

スクラッチボリュームの管理

スクラッチボリュームの管理では、基本的に十分な (ただし、多すぎない) 数のスクラッチボリュームを用意して、これらを適切な位置 (ボリュームメディアと互換性のあるデバイスタイプを十分に備えた LSM) に配置します。表3-1 に、スクラッチボリュームの管理タスクと、それに関連するツールを示します。

表3-1 スクラッチボリュームの管理タスクとツール

タスク

ツール

注

十分な数のスクラッチカートリッジの保守

- Warn コマンド - スクラッチ警告の限界値を設定します。

- Display THReshld コマンド - スクラッチカウントとスクラッチ限界値の情報を、サブプール名、ACS ID、LSM ID、メディア、および記録方式ごとに表示します。

一般的な注意:

Warn コマンドはスクラッチ警告の限界値の設定に使用し、Display THReshld コマンドはスクラッチボリュームのレベルと限界値のモニタリングに使用します。

スクラッチボリュームが不足している場合は、スクラッチ同期を実行し、スクラッチボリュームを再分配したあと、スクラッチボリュームを追加します。詳細については、「スクラッチボリュームの追加」を参照してください。

CDS のスクラッチステータスと TMS のステータスの同期

- クライアント/サーバー構成用の HSC SLUCONDB スクラッチ変換ユーティリティー (および、SMC テープ管理抽出 (SMCUDBX) ユーティリティー)。

上記のように、スクラッチ同期を実行してスクラッチボリュームを解放できます。一般的には、日次の TMS を実行したあとにスクラッチ同期を実行します。

スクラッチボリュームの再分配

HSC スクラッチ再分配ユーティリティーを使用して、特定の ACS 内にある LSM 間でスクラッチボリュームを再分配します。

「マウントパフォーマンスの最適化」で説明しているように、スクラッチが適切に分配されていない場合は、ライブラリパフォーマンスが低下する場合があります。スクラッチの再分配は、ACS 内の指定した LSM 間でスクラッチボリュームの数のバランスを調整し、サブプールによって実行できます。

特定のボリュームのスクラッチ

- HSC SCRAtch コマンドは、1 つまたは複数のボリュームをスクラッチします。

- HSC UNSCratch コマンドは、1 つまたは複数のボリュームをアンスクラッチします。

コマンド許可がある場合は、指定したボリュームを実際にスクラッチおよびアンスクラッチできます。ただし一般的には、明確な理由がないかぎり、特定のボリュームを明示的にスクラッチしないでください。代わりに TMS を使用して、ボリュームのスクラッチステータスの管理とスクラッチ同期を行なってください。

スクラッチサブプール情報の表示

Display SCRatch

コマンドを実行したホストのスクラッチサブプール情報だけを表示します。すべてのスクラッチサブプール情報を表示するには、VOLRPT ユーティリティーを使用してください。

スクラッチボリュームの追加

ライブラリへのスクラッチボリュームの追加は一般的なタスクです。このタスクは次の 2 つのケースに分類されます。

- 新しい LSM の作成

- 既存の LSM へのボリュームの追加

どちらの場合も、「Nearline ボリュームの定義」で説明するように、まず新しいボリュームの POOLPARM および VOLPARM の定義を作成する必要があります。

Nearline ボリュームの定義

Nearline ボリュームを定義するには、次の手順に従います。

1. ボリュームのスクラッチプールを定義する POOLPARM 文を作成します。
たとえば、ホスト MSP1 と MSP2 で使用するスクラッチプールを定義する場合は、次のようになります。

POOLPARM NAME(SYS19840P22)TYPE(SCRATCH)HOSTID(MSP1,MSP2)LABEL(SL

2. VOLPARM 文を作成して、ボリュームを定義します。
たとえば、9840C ボリュームの範囲を定義する場合は、次のようになります。

VOLPARM VOLSER(C2000-C2999)MEDIA(STK1R)RECTECH(STK1RC)

3. SET VOLPARM コマンドを入力して、ボリューム定義を適用します。

SET VOLPARM APPLY(YES)

新しい LSM の作成

POOLPARM および VOLPARM の定義を行なったあと、次のいずれかの方法を使用して新しい LSM を作成します。

- 1 つまたは複数の CAP を自動モードに設定し、新しいカートリッジを使用して CAP のオープンと挿入を繰り返します。

- LSM が Streamline 以外のライブラリであり、挿入できる十分な大きさがある場合:

1. LSM アクセスドアを開きます。

2. カートリッジを LSM のストレージセルに手動で配置します。

3. アクセスドアを閉じてロックします。

4. LSM で HSC Audit を実行します。
完全な LSM の監査には時間がかかりますが、CAP によるカートリッジの挿入も時間がかかる可能性があります。したがって、どちらの方法が早いかを判断する必要があります。

既存の LSM へのボリュームの追加

POOLPARM および VOLPARM の定義を行なったあと、「カートリッジの挿入」の説明に従ってカートリッジを挿入します。

カートリッジの挿入

カートリッジは、ACS に挿入するまでは単なるカートリッジですが、挿入したあとは CDS のボリュームになります。スクラッチカートリッジ、非スクラッチカートリッジ、MVC で使用するカートリッジ、またはクリーニングカートリッジを挿入できます。

カートリッジを挿入するには、次の手順に従います。

1. カートリッジを挿入する LSM がオンラインであることを検証します。
たとえば、LSM 00:00 のステータスを確認するには、次のようにします。

DISPLAY LSM 00:00

SLS0054I メッセージ「LSM 00:00 now online」は、検証が成功したことを示します。このメッセージが表示されない場合は、問題が何であるかを判断し、少なくとも MODIFY LSM aa:cc ONLINE コマンドを入力して、オンラインに戻す必要があります。

2. CAP モードを確認します。

たとえば、LSM 00:00 の PCAP のステータスを確認するには、次のようにします。

DISPLAY CAP 00:00:02

CAP モードが自動の場合は、手順 4 に進みます。それ以外の場合は、手順 3 に進みます。

3. CAP モードが手動の場合、サイトの慣習に応じて、次の 2 つの方法を選択できます。

- CAP モードを自動に変更します。
たとえば、手順 2 の PCAP の場合は、CAP の優先値を 0 (PCAP で常に必要) に設定し、モードを自動に設定します。

CAPPREF 0 00:00:02 AUTO

- ENTER を使用して、CAP でカートリッジを挿入する準備をします (モードは手動のまま)。
たとえば、手順 2 の PCAP の場合、CAP で挿入の準備を行い、挿入したカートリッジのスクラッチステータスをオンに設定するには、次のようにします。

ENTER 00:00:02 SCRATCH

注記:
すべての CAP がイジェクトに使用されている場合は、SENter コマンドを使用して、CAP でカートリッジのエンターをスケジュールできます。

4. 使用している LSM タイプのオペレータガイドの説明に従って、カートリッジを挿入します。

ボリュームのイジェクト

次のセクションで説明するように、ボリュームのイジェクトが必要となる理由は基本的には 3 つあります。

- 定義しているスクラッチボリュームが多すぎて、特定のボリュームのための空き領域が一時的に必要になった場合。「スクラッチボリュームのイジェクト」を参照してください。

- 現在使用していないボリュームがあり、これらを外部に保管する場合。詳細は、『ELS 障害回復およびオフサイトデータ管理ガイド』を参照してください。

- メディアの保証期限に近付いている 9x40 ボリュームがある場合。図3-2 に示すボリュームレポートの右端に %MWL 列が表示されています。この列は、ボリュームに使用されているメディアの保証期限に至るまでのパーセンテージを示しています。この値が %100 の場合は、ボリュームの保証期限を超えていることを示しています。

注記:
9x40 ボリュームの場合、カートリッジの寿命を通じてのマウント回数が、メディア情報レコード (MIR) に保存されます。マウント解除処理中に、HSC は MIR から読み取ったマウント回数の値を使用して %MWL を計算します。HSC がライブラリ常駐ボリュームの MWL% を報告するためには、ボリュームがライブラリにエンターされたあと、少なくとも一度はマウントおよびマウント解除されている必要があります。ボリュームがイジェクトされるときに、関連する CDS VAR レコードは削除されます。そのボリュームがライブラリの外部にある間、HSC はそのボリュームの MWL% をレポートできません。ただし、マウント回数は MIR に保持されているため、ボリュームがライブラリにもう一度エンターされて、少なくとも一度マウントおよびマウント解除されると、そのボリュームがライブラリに常駐している間、HSC はボリュームの MWL% を再度レポートできるようになります。
トランスポートが MIR を読み取りまたは書き込みできない場合、ドライブは新しい MIR をボリュームの別の場所で再初期化できます。MIR の処理中にエラーはほとんど発生しません。ドライブは必要に応じて新しい MIR を再構築しますが、障害のあった MIR から代替 MIR にマウント回数の値を転送できない場合があります。この場合、ドライブは代替 MIR でマウント回数を 0 に初期化します。0 以外であったボリュームのマウント回数が 0 になったことに (たとえば、ボリュームレポートで MWL% をモニターしていて) 気付いた場合は、SYSLOG を検証してこのボリュームをデータチェックし、テープドライブを検証します。これらの検証に基づいて、このボリュームが耐用期限切れかどうかを判断してください。

メディア保証期限の機能には、次の要件が必要です。

- テープライブラリ LMU 互換性レベル 21

- T9x40 トランスポート (1.42 ドライブファームウェア)

注記:
メモリーの制約により、T9840B はサポートされません。

- T10000A および T10000B (1.38 ドライブファームウェア)

- PTF SES700 L1H154V

- 使用期間が終了して交換が必要なクリーニングカートリッジがある場合。「使用済みクリーニングカートリッジの手動によるイジェクト」を参照してください。

スクラッチボリュームのイジェクト

スクラッチボリュームをイジェクトするには、次の手順に従います。

1. ボリュームをイジェクトする LSM がオンラインであることを確認します。
たとえば、LSM 00:00 のステータスを確認するには、次のようにします。

DISPLAY LSM 00:00

SLS0054I メッセージ「LSM 00:00 now online」は、検証が成功したことを示します。このメッセージが表示されない場合は、問題が何であるかを判断し、少なくとも MODIFY LSM aa:cc ONLINE コマンドを入力して、オンラインに戻す必要があります。

2. EJECT を使用して、イジェクト操作を開始します。
たとえば、メディア STK1R および記録方式 STK1RC の 100 のスクラッチボリュームを、プール SYS19840P1 からイジェクトする場合は、次のようになります。

EJECT SCRTCH SUBPOOL(SYS19840P1)VOLCNT(100) MEDIA(STK1R) RECTECH(STK1RC)

WAITCAP(YES) がデフォルトです。

3. CAP を空にするように支持するオペレータメッセージが表示された場合は、ボリュームを CAP から取り除きます。

クリーニングカートリッジの管理

ELS を構成するときには、十分なクリーニングカートリッジを定義するようにしてください。そうでない場合は、『HSC および VTCS の構成』で方法を確認してください。クリーニングカートリッジの定義を行なったあと、「カートリッジの挿入」の説明に従って挿入します。また、クリーニングカートリッジを管理するために、MNTD を (PARMLIB メンバーまたはコマンド経由で) 使用して実行できる作業があります。

注記:
クリーニングカートリッジを管理するために、HSC では CLN のあとに 3 桁の数字が続く接頭辞の付いた外部ラベルをそれらに付ける必要があります。ただし、一部の LTO カートリッジには、この形式でない外部ラベルが付けられます。この場合、LTO クリーニングカートリッジの外部ラベルの取得方法については、Oracle の担当者に問い合わせてください。

クリーニングカートリッジの選択

ドライブのクリーニングが必要なときにクリーニングカートリッジを自動的に選択するには、「自動クリーニング」オプションをオンに設定します。

MNTD AUTOCLN(ON)

ドライブのクリーニングプロセスによって、クリーニングが必要なドライブにもっとも近い LSM 内のクリーニングカートリッジが選択されます。クリーニング処理が完了すると、「フロート」オプションによって、このカートリッジがそのホームセルに返されるか (フロートオフ)、それとも現在の LSM 内の新しいホームセルが割り当てられるか (フロートオン) が判別されます。フロートをオンに設定すると、パススルー処理が減少するため、パフォーマンスが向上します。

MNTD FLOAT(ON)

クリーニングカートリッジのイジェクト

POOLPARM MAXCLEAN パラメータは、ある特定のクリーニングカートリッジセットのクリーニング処理の最大数を指定します。ELS で、MAXCLEAN 値を超過しているクリーニングカートリッジを自動的にイジェクトするには、次を入力します。

MNTD EJCTAUTO(ON)

ExLM を実行している場合は、ExLM でスケジュールに基づいてクリーニングカートリッジのイジェクトを管理できます。この場合は、「自動イジェクト」をオフに設定します。これは、「完全自動の」データセンターで非常に役立ちます。

ExLM がない場合は、自動イジェクトを推奨します。この方法を使用しない場合は、CLEAN コマンドを使用して手動でクリーニングをスケジュールし、「使用済みクリーニングカートリッジの手動によるイジェクト」で説明しているように、使用限度を超えた (消耗した) カートリッジを手動でイジェクトする必要があります。自動イジェクトには、使用可能な CAP が必要です。CAP が使用できない場合は、手動によるイジェクトが必要です。

最近のドライブは、消耗したクリーニングカートリッジを識別して、MAXCLEAN の使用カウントに関係なく ELS に通知します。「自動イジェクト」がオンになっている場合は、ライブラリが「消耗」状態を検出したときにカートリッジがイジェクトされます。それ以外の場合は、ExLM を使用して、「消耗した」クリーニングカートリッジのイジェクトをスケジュールできます。

クリーニングカートリッジをイジェクトしたあと、通常は新しいカートリッジを挿入して、使用していたカートリッジを交換します。挿入するクリーニングカートリッジの volser が ELS にまだ定義されていない場合は、クリーニングカートリッジを定義する方法について、『HSC および VTCS の構成』を参照してください。

使用済みクリーニングカートリッジの手動によるイジェクト

使用済みのクリーニングカートリッジを交換するには、次の手順に従います。

1. カートリッジをイジェクトする LSM がオンラインであることを確認します。
たとえば、LSM 00:00 のステータスを確認するには、次のようにします。

DISPLAY LSM 00:00

SLS0054I メッセージ「LSM 00:00 now online」は、検証が成功したことを示します。このメッセージが表示されない場合は、問題が何であるかを判断し、少なくとも MODIFY LSM aa:cc ONLINE コマンドを入力して、オンラインに戻す必要があります。

2. EJECT を使用して、イジェクト操作を開始します。
たとえば、9840 クリーニングカートリッジの範囲をイジェクトするには、次を実行します。

EJECT (CLN300-CLN310) SEQ(YES)

WAITCAP(YES) がデフォルトで、ボリュームは CAP に順に配置されます。

3. CAP を空にするように支持するオペレータメッセージが表示された場合は、クリーニングカートリッジを CAP から取り除きます。

4. 交換するクリーニングカートリッジを挿入する CAP の CAP モードを確認します。

たとえば、LSM 00:00 の PCAP のステータスを確認するには、次のようにします。

DISPLAY CAP 00:00:02

5. CAP モードが手動の場合、サイトの慣習に応じて、次の 2 つの方法を選択できます。

- CAP モードを自動に変更します。
たとえば、手順 4 の PCAP の場合は、CAP の優先値を 0 (PCAP で常に必要) に設定し、モードを自動に設定します。

CAPPREF 0 00:00:02 AUTO

- ENTER を使用して、CAP でカートリッジを挿入する準備をします (モードは手動のまま)。
たとえば、手順 4 の PCAP の場合、CAP で挿入の準備を行い、挿入したカートリッジのスクラッチステータスをオンに設定するには、次のようにします。

ENTER 00:00:02 SCRATCH

問題の解決

次のセクションでは、考えられる問題の解決策について説明します。

エラントカートリッジの回復

HSC が LSM 内でボリュームの位置を確認できない場合、カートリッジはエラント状態になります。カートリッジは、次の状況でエラントになる可能性があります。

- オペレータが FORCE オプションを使って LSM をオフラインに変更した。

- ボリュームが、CDS で指定されたセル位置にない。

- LMU 内で回復不能なエラーが発生した。

- LSM 内で回復不能なエラーが発生した。

エラントボリュームの回復は、次の場合に自動的に実行されます。

- エラントのマークが付いたカートリッジを HSC が使用しようとした場合。

- ACS が接続されるとき。

- LSM がオンラインに変更されるとき。

- ホスト間回復が実行されるとき。

HSC は次のメッセージを発行します。

... Attempting to locate errant volume VVVVVV

カートリッジの元のソース位置または宛先位置を確認してカートリッジが見つかった場合、HSC はそのカートリッジのエラントステータスを解除します。

カートリッジが見つからなかった場合、オペレータは次のメッセージに応答するよう求められます。

... Volume VVVVVV not found; Eject or Ignore (E|I)?

これには、次のいずれかを応答してください。

- カートリッジがライブラリ内にないことがたしかな場合は、「E」と応答します。カートリッジが CDS から削除 (論理的にイジェクト) されます。

- カートリッジの場所がわからない場合は、「I」と応答して、カートリッジをエラントステータスのままにします。この場合、そのカートリッジに対して監査追跡情報が保存されます。これは、カートリッジを手動で見つける必要が生じた場合に役立つものです。
カートリッジがあとから見つかると、HSC はそれをエラントと認知して、エラントステータスを解除します。そのカートリッジは、ホームセル位置に返されるか、または要求のために選択されたものとマークされます。

重複/読み取り不能 VOLSER の入力

次では、VOLSER 関連の問題について説明します。

重複ボリュームの入力

すでに CDS に記録されているボリュームを入力しようとすると、HSC はそのホームセル位置または宛先位置を確認して元のカートリッジを探します。ボリュームが見つかった場合、重複するボリュームは HSC によって拒否されます。

ボリュームが見つからない場合は、OPTion ENTdup コマンドの設定に従って、次のような応答が返されます。

- OPTion ENTdup が Auto に設定されている場合、元のボリュームは CDS から自動的に削除され、新しいボリュームが入力されます。

- OPTion ENTdup が Manual に設定されている場合、HSC は次のメッセージを出力してオペレータの操作を要求します。

... ENTER of volume VVVVVV encountered missing duplicate volser;
(Logically) Delete, or Ignore (D,I)?

「D」と応答して元のボリュームを CDS から削除し、新しいボリュームを入力します。

注記:
コマンドの構文とパラメータについては、『ELS コマンド、制御文、およびユーティリティーリファレンス』の OPTION コマンドと制御文の説明を参照してください。ライブラリが分割されていて、重複したボリュームが別のパーティションに入力される場合は、重複したボリュームを Streamline ライブラリに入力できます。

外部ラベルがないカートリッジまたはラベルを読み取れないカートリッジの挿入

読み取れないラベルが付いたテープカートリッジは、CAP を介してライブラリに挿入することができません。ラベルが付いていないか、またはロボットが読み取れないラベルの付いたカートリッジをエンターしようとすると、次の HSC メッセージが出力されます。

... UnNamed Cartridge in CAP CELL AA:LL:RR:CC;
reply "V,volser" or "EJECT"

次のいずれかを実行します。

- 「V,volser」と応答し、カートリッジに VOLSER を割り当ててそれをエンターする。指定された VOLSER は、CDS 内でそのカートリッジに永続的に割り当てられます。

注記:
ラベルが付いていないか、または読み取れないラベルの付いたカートリッジを手動でライブラリに挿入すると、これらのカートリッジは監査中にイジェクトされます。すべてのカートリッジに外部メディアラベルを付けることをお勧めします。

- 「EJECT」と応答して、CAP のロックが解除されたら、カートリッジを CAP から取り出す。

CAP の RECOVERY ステータスをクリアする

CAP のステータスが RECOVERY の場合は、次の手順を使用して CAP を強制的に回復します。

注記:
この手順を使用しても RECOVERY ステータスをクリアできない場合は、「割り振り済み CAP の解放」の手順を試してください。

CAP の RECOVERY ステータスをクリアするには、次の手順に従います。

1. 次のコマンドを発行します。

ENTER capid

ここで、cap-id は回復対象の CAP です。

次のことが起こります。

1. LSM ロボットが CAP に移動し、CAP カタログを実行します。

2. カートリッジが CAP 内で検出された場合、オペレータに対して、カートリッジを取り出すよう指示するメッセージが出力されます。

3. HSC が次のメッセージを発行します。

... Open CAPid AA:LL:CC for entering when unlocked

4. CAP ENTER のインジケータが点灯するか、表示パネルに Enter が表示されます。

2. その CAP に対して DRAin コマンドを発行します。
CAP はロックされ、そのステータスは INACTIVE に設定されます。

割り振り済み CAP の解放

注意:
この手順を使うのは、CAP が使用中でない場合だけにしてください。活動状態のコマンドまたはユーティリティーから CAP を解放すると、予測できない結果が生じる可能性があります。たとえば、次のような事態が起こります。

- CAP が終了する

- エラントカートリッジ

- CAP 内に HSC が認識できないカートリッジが残される

活動状態の処理が CAP を使用しているときに、ホストが回復を実行しないで終了すると、CAP はそのホストに割り振られたままの状態になり、それ以外のホストでは使用できなくなります。HSC がそのホストで再起動されると、初期化のあとに CAP が解放されます。そうでなければ、次のコマンドを接続されたホストから出すと、この CAP を解放できます。

RELEASE capid

ここでは:

capid は解放したい CAP を指定します。

HSC はメッセージを発行して、CAP の解放についての確認を求めます。

- 解放を取り消す場合は「N」と応答します。

- 解放を続ける場合は次の手順に従ってください。

1. CAP を目で検査したり、ほかのホストから Display Cap コマンドを出したり、またはほかのユーザーに問い合わせたりして、CAP が使用中ではないことを確認してください。

2. メッセージに対して「Y」と応答してください。
すると、さらにメッセージが出されて、CAP が解放されることを確認します。

ホスト間通信サービスの復元

COMMPath コマンドと制御文を使用すると、HSC ホスト間の多重通信サービスを定義できます。このタイプのサービスを設定した場合、ホストが現在の通信経路でメッセージを送ろうとしたときにエラーが起こると、HSC は経路切り替えを自動的に実行します。定義された経路に応じて、同等の経路 (LMU 経路間) か、またはパフォーマンスの低い方式のいずれかへ自動切り替えが行われます (たとえば、VTAM から LMU へ)。

切り替えが発生すると、HSC は次のメッセージをコンソールに出力してユーザーに通知します。

... A communications path switched from XXXX1 to XXXX2; ...

ここでは:

XXXX1 は以前の通信経路を指定します。

XXXX2 は現在の通信経路を指定します。

このメッセージは、切り替えを開始したホスト、または障害のあったホストも示されます。

HSC が下方切り替えを行なったあとは、COMMPath コマンドを使用しなければ上方切り替えを実行できません。

上方切り替えを実行するには、次の手順に従います。

1. 切り替えの原因となった問題を見つけて修正してください。

2. 次のコマンドを出して、以前の通信方式に戻ってください

COMMPATH HOSTID(hostid) METHOD(method)

ここでは:

hostid はコマンドの対象となるホストを指定します。

method は現行方式としたい方式を指定します。

失われた可能性のあるマウント要求の解決

次のいずれかの理由でマウントが失われた可能性があります。

- HSC がアクティブで SMC が非アクティブの場合、MSP メッセージおよび TMS メッセージ (またはその一方) は、代行受信されません。

- HSC が非アクティブで SMC がアクティブの場合、MSP メッセージおよび TMS メッセージ (またはその一方) は代行受信されますが、マウント要求を受信する自動ライブラリ制御システムはありません。

- LMU のハードウェアエラーが発生する可能性があります。

一般的に、これらの問題を解決するには、SMC RESYNC コマンドを使用して、失われたマウント要求をすべて再実行します。

失われたマウント応答の解決 (ORH)

マウント要求は、LMU からの応答が受け取られていないために、HSC の待ち行列の 1 つに入れられたままになる場合があります。このような場合、ボリュームは選択ステータスのままになり、遅延応答ハンドラ (ORH) によってオペレータにそのことが通知されます。

遅延応答ハンドラ

ORH は、各 ACS のすべての待ち行列を 30 秒に 1 度走査して、応答待ち時間間隔の期限を超えている要求の通し番号を識別します。時間間隔の期限が過ぎると、次のメッセージが出力されます

... ORH interval expired: ...

そして、ORH は要求のタイプコードを確認します。マウント、マウント解除、移動、およびスワップ以外の要求タイプコードのすべてに対して、ORH は要求の待機時間を 3、5、10、または 60 分の増分で自動的に延長して、メッセージを出します。

... ORH interval extended: ...

マウント、マウント解除、移動、およびスワップに必要なオペレータ応答

マウント、マウント解除、移動、およびスワップの各要求に対して、オペレータに次のメッセージによる応答要求が出力されます。

... ORH: ABORT/EXTEND...

これには、次のいずれかを応答してください。

- ABORT - 操作を要求したタスクには、要求が ORH によって異常終了したと通知されます。これによりボリュームの選択ステータスが解除されるため、オペレータは作業の進行上の必要に応じて HSC Mount または DISMount コマンドを発行できます。トランスポート関連の障害の場合、ABORT 応答を使用する必要があります。例としては、パススルーポート、SL8500 エレベータ、ロボット、トランスポートの障害があります。

- EXTEND - ORH は要求にさらに 10 分間の延長時間を与え、現在の待ち行列に置いたままにします。要求できる延長回数に制限はありません。

ソフトウェア診断の使用

一部の問題は自力では解決できない場合があります。通常は、Oracle ソフトウェアサポートに連絡し、指示に従って表3-2 に示すいくつかの HSC ソフトウェア診断ツールを使用します。

表3-2 HSC ソフトウェア診断ツール

診断ツール

説明

汎用機能 (GTF) 追跡 (GTRACE)

汎用トレース機能 (GTF) は、最近の履歴の低レベルな情報を出力します。HSC は、稼働中に重要なイベントに対して GTRACE 要求を発行します。フォーマット ID とイベント ID (FID と EID) は、HSC JCL プロシージャーの EXEC 文のパラメータ (PARM=) として指定します (手順の例については、『HSC 構成ガイド』の「HSC START 手順の作成」を参照してください)。

Supervisor 呼び出し (SVC)、ダンプ (SDUMP)、および異常終了 (ABEND)

ダンプ

SVC および ABEND のダンプはソフトウェア障害の診断に利用できます。HSC JCL では SYSUDUMP、SYSMDUMP、または SYSABEND の各 DD 文は使用しないでください。これらの ABEND タイプでは、HSC アドレス空間に関する十分な情報が表示されません。

エラー記録データセット (ERDS)

ソフトウェア障害は、これらのエラー記録データセットに記録されます。4480 カートリッジサブシステムおよび 3278 端末サブシステムのエラー記録データセット (ERDS) のレコードは、MSP ルーチンによって書き出されます。

LIst コマンド

LIst コマンドは、HSC データ構造を表示して、HSC の診断をサポートするために使用されます。このコマンドは、Oracle のサポート担当者からの指示に従って使用してください。

Display コマンド

Display コマンドには、診断に役立つさまざまなオプションが用意されています。

4 VTCS ダッシュボードの使用

「VTCS ダッシュボードの使用」とは、基本的に MVC レポートと VTC レポートを確認することです。仮想テープ構成の主要なコンポーネントは VTSS、VTD、VTV、RTD、および MVC であるため、当然のように、日次または週次の多数のルーチンがこれらすべてを正常に稼働させるために実行されています。

仮想テープのステータスの確認 (日次)

VTSS を Nearline ACS の仮想物、VTD を Nearline の実テープドライブの仮想機能、および VTV を Nearline ボリュームの仮想物と考えると、VTSS、VTD、および VTV のすべてが正常に稼働していることを確認することが重要である理由がよくわかります。

Virtual テープのステータスを確認するには、次のことを実行します。

1. Display VTSS コマンドを入力します。

表4-1 のような表が表示されます。

表4-1 Display VTSS からの出力例 - 正常な VTSS のステータス

VTSS 名

容量 (MB)

DBU

上限 AMT

下限 AMT

VTV カウント

MX MT

MN MT

DEF ACS

AUTO MIG

状態

HBVTSS16

56,209

55

80

60

2440

6

3

02

-

ONLINE

HBVTSS17

56,209

50

80

60

2180

6

3

02

-

ONLINE

HBVTSS18

56,209

52

80

60

2288

6

3

01

-

ONLINE

HBVTSS19

93,184

45

80

60

1900

6

3

01

-

ONLINE

表4-1 は、「正常に稼働している」4 つの VTSS のステータスを示しています。

- まず、すべての VTSS はオンラインで、通常はこれが正常です。

- LAMT はすべてが 60、HAMT はすべてが 80 です。これは、VTSS の使用率を最適化し、効果的な自動移行を促進するのに適した範囲です。

- DBU はすべて HAMT より低い値で、正常です。これは、自動移行が開始されるまでに、VTSS に拡張する余地があることを意味します。これらの VTSS により多くの作業をルーティングして、仮想テープへの投資の最適化を検討することも可能です。

- 各 VTSS に 8 台 の RTD が接続されているとします。MX MT (最大移行タスク) は 6 に設定され、MN MT (最小移行タスク) は 3 に設定されます。これは適切な数値です。最大の 6 は 2 つの RTD をリコール/リクレイムに残し、最小の 3 は複数の移行が一度に開始された場合に、その負荷を処理できるだけのタスクを確保します。

Display VTSS が正常でないと思われる場合は、表4-2 のようになります。

表4-2 Display VTSS からの出力例 - 運用上の大きな問題がある VTSS

VTSSNAME

容量 (MB)

DBU

上限 AMT

下限 AMT

VTV カウント

MX MT

MN MT

DEF ACS

AUTOMIG

状態

HBVTSS16

56,209

90

80

60

27,888

4

2

02

-

ONLINE

HBVTSS17

56,209

92

80

60

28,974

4

2

02

-

ONLINE

HBVTSS18

56,209

90

80

60

22,005

4

2

01

-

ONLINE

HBVTSS19

93,184

92

80

60

26,009

4

2

01

-

ONLINE

表4-2 は、大きな運用上の問題がある 4 つの VTSS のステータスを示しています。

- 少なくともそれらはすべてオンラインです。そうでない場合、オフラインまたは保守モードにする理由がないかぎり、Vary VTSS コマンドを入力してオンラインに戻します。

- DBU の値はいずれも大きすぎます。90 以上の範囲は VTSS による VTV の自動移行に支障があることを意味しており、これは、次の理由から驚くことではありません。

- 各 VTSS に 8 台 の RTD が接続されているとします。MX MT (最大移行タスク) は 4 に設定され、MN MT (最小移行タスク) は 2 に設定されていますが、これは現在の移行の負荷を考えるとたしかに少し軽くなっています。
問題を解決するには、手順 2 に進みます。

2. 手順 1 で確認した内容が好ましくない場合は、現在の動作パラメータを調整します。

まず、移行タスクの量を増やします。

set migopt vtss(vtssname) maxmig(8) minmig(8) high(70) low(40)

これで、すべての VTSS 上で、すべての RTD が移行に関与するようになりました。DBU が管理可能になるまでこの状態を維持します。そのあと、最大 6、最小 3 などに戻します。また、AMT を低い値は 40、高い値は 70 に変更します。これによって問題は解決し、次回から移行がすぐに開始され、バッファーが低い DBU に当てられるようになります。

次に、Display VTD を入力して、システムの VTD の概要を取得します。

表4-3 に Display VTD の出力例を示します。

表4-3 Display VTD の出力例 - 正常な稼働

ドライブ

LOCATION

VTV

ステータス

A800

HBVTSS16

X00778

MOUNTED

A801

HBVTSS16

X00775

MOUNTED

A802

HBVTSS16

-

AVAILABLE

A803

HBVTSS16

-

AVAILABLE

表4-3 で、ふたたび正常な状態に戻り、いくつかの VTD が使用中で、そのほかは使用可能な状態になっています。

すべての VTD で、VTV がマウントされている場合はどうでしょうか。これは、利用できるドライブがない場合にジョブ割り振りエラーの危険があるため、適切だとは言えません。これが、手順 2 で発生したような問題であるなら、それを受け入れ、あとで VTD データの流入をうまく処理できるようにワークロードを調整するだけでかまいません。しかし、これが長期間に及ぶ問題である場合は、VTSS を追加したり、より大きな容量と多くの VTD を持つ VTSS にアップグレードしたりする必要があります。

3. ここで、表4-4 に示されている出力を生成する Display SCRATCH コマンドを入力して、十分なスクラッチ VTV が手元にあることを確認します。

表4-4 Display SCRATCH の出力例

サブプール名

スクラッチカウント

VIR000

14,364

VIR0002

13,582

VIRTUAL

19,132

VIRTUAL1

9,905

表4-4 に表示されているのは、HSC サブプールの VTV スクラッチカウントです。VTV に HSC サブプールを使用しない場合、システムに定義されているすべての VTV の VTV スクラッチカウントが表示されます。スクラッチカウントには、利用できるスクラッチ VTV がいくつかあるかぎり、適正または不適正な数値というのはありません。「利用できるスクラッチの適正数値」は、システム環境のニーズとワークロードによって変わります。

表4-4 に各サブプールで使用できるスクラッチが 50 以下と表示されたとしたら、少し心配になるかもしれません。その場合、次の 1 つまたは複数のことを実行できます。

- データが最新でない VTV をスクラッチすることにより、VTV の VOLSER を解放する。これは、システム内の VTV の合計が十分であるのに、利用できるスクラッチボリュームが十分でない場合に行う手段です。
実際は、スクラッチを行うのはユーザーではなく、この処理を実行するように設定されている TMS であるため、初期構成で、VTV の VOLSER を TMS に定義しておくべきです。定義しなかった場合は、戻って定義します。それよりも、VTCS CONFIG 文で VTV の範囲を追加したのに、新しい範囲を TMS に追加するのを忘れている可能性の方が高いでしょう。この場合も、戻って問題を修正します。これについては、『ELS のインストール』ですべて説明されます。

ただし、TMS で VTV をスクラッチとしてマークすることは解決の一部でしかありません。このほかにも、VSM 管理者のだれかが VTV データを最新でない (そのため書き込み可能) とマークし、それが VTSS 常駐の VTV の場合はそれらをバッファーから削除しています。

VTV データを実際に削除することは重大な決定であるため (データは消去されます) そのつど判断します。これを「要求時」タスクと言います。そのため、このルーチンを行う場合は、「MVC スペースリクレイムの実行」を参照してください。

- POOLPARM または VOLPARM を使用して VTV を追加する。これは、次善の選択肢です。最新でないデータのある VTV がまったくない場合は、これを実行します。POOLPARM または VOLPARM だけで解決しない場合は、適切な TMS の定義なども行う必要があります。これについても、『ELS のインストール』ですべて説明されます。

- TAPEREQ 文または SMS ルーチンを変更し、追加の VTV を定義するまでの間、テープ作業を一時的に Nearline の HSC 処理に転送する。これは本質的に、もともと VSM に送信しようとしていたデータを Nearline テープに直接送信することになり、あとの処理も簡単ではないため、おそらく最後の選択肢になります。それでも、利用できる Nearline リソースがあり、スクラッチボリュームにデータを書き込む緊急の必要性がある場合、これが (一時的に) 取るべき方法となります。

Nearline テープのステータスの確認 (日次)

「仮想テープのステータスの確認 (日次)」では、システムの VTSS、VTD、および VTV を正常に稼働させることの重要性について説明しました。

VSM の Nearline コンポーネント (RTD および MVC)、VTV の移行先とリコール元、そしてバックグラウンドで実行される MVC スペースリクレイムを考えると、この部分に十分な注意を払う価値があることがわかるでしょう。

Nearline テープのステータスを確認するには、次のことを実行します。

1. Display RTD を入力します。
適切な状態の場合、表4-5 のようになります。

表4-5 VT Display RTD コマンドの出力例 - すべてが良好

RTD

ステータス

マウント

割当

ホスト

VTSS

B200

ONLINE/FREE

-

-

-

HBVTSS16

B201

ONLINE/FREE

-

-

-

HBVTSS16

0B79

ONLINE/FREE

-

-

-

HBVTSS16

0B7A

RECALL VTV

DMV051*

DMV051

EC20

HBVTSS16

1600

MSP1 :MIGRATE

-

-

-

-

1601

MSP1 :MIGRATE

-

-

-

-

表4-5 では、RTD の移行、リコール、そして新しい作業用のバランスが良いため、処理が滞りなく実行されます。表4-6 ではそうなりません。

表4-6 VT Display RTD コマンドの出力例 - RTD に問題

RTD

ステータス

マウント

割当

ホスト

VTSS

B200

MSP1 :MIGRATE

-

-

-

-

B201

MSP1 :MIGRATE

-

-

-

-

0B79

MSP2 :MIGRATE

-

-

-

-

0B7A

MSP2 :MIGRATE

-

-

-

-

1600

MSP1 :MIGRATE

-

-

-

-

1601

MSP1 :MIGRATE

-

-

-

-

表4-6 が手順 2 で行なった一種の緊急手段の結果である場合は、状態が正常に戻るまで待つほかありません。しかし、利用できる RTD がほかにある場合、たとえば MSP および VSM と手動で共有している RTD がある場合は、それらを MSP に対してオフラインにして、Vary RTD を使用し、それらを VTCS に対して利用可能にします。

2. 次に、Display MVCPool コマンドを使用して、MVC の状態を確認します。

図4-1 は、MVC プール名が指定されていない Display MVCPool の出力を示しているため、システムのすべての MVC 情報が参照できます。

図4-1 Display MVCPool からの出力例 (プール名の指定がない場合)

図4-1 は、MVC コレクションが正常な状況であることを示しています。複数の ACS と MVC メディアタイプに、十分な空き MVC (100% 利用可能なスペース、移行された VTV を含まない) と十分な空き容量があります。リクレイムに選択可能な MVC の数は比較的少なく、自動スペースリクレイムが移行/リコール処理の邪魔にはならないだろうことを意味しています。

使用済み MVC は、空き MVC に対して問題ないようですが、ACS 01 の ECART、ZCART メディアには問題があります。これらの MVC について、少し調べてみましょう。これらの MVC を表すストレージクラスと、これらのストレージクラスに対応するマネージメントクラス、いくつかの VTV をスクラッチした可能性のあるマネージメントクラスを調べます。

Display MVCPool の結果、図4-2 のように表示された場合はどうでしょうか。

図4-2 Display MVCPool からの出力例 - ACS01 で問題

ご覧のように、ACS 01 で状況が悪くなっています。ここで何をすべきでしょうか。次のことを順番に検討します。

- 要求リクレイムを実行して、スペースを解放します。詳細については、「MVC スペースリクレイムの実行」を参照してください。

- 「RTD デバイスタイプの変更」の説明のように、MVC を追加します。

- これらの MVC を表すストレージクラスと、これらのストレージクラスに対応するマネージメントクラス、いくつかの VTV をスクラッチした可能性のあるマネージメントクラスを調べます。
フォローアップとして、現在のポリシーを再検討し、必要に応じて調整します。これらのポリシーを変更すると、空き MVC か、または MVC 上に空きスペースを作成できる場合があります。

概要の把握 (週次)

これはそれほど複雑ではなく、基本的にほかの主要な 2 つのステータス確認用ツール (MVC レポートおよび VTV レポート) を週次で実行することから構成されます。

VTV レポートの使用

注記:
VTV レポートは、次のいずれかのコマンドを使用して実行します。

- VTVRPT BASIC。EXPORT コマンドを使用して MVC に移行されたすべての VTV コピーを表示します

- VTVRPT COPIES。EXPORT コマンドを使用して MVC に移行されたすべての VTV コピーと、EEXPORT コマンドによって移行されたすべての VTV コピーを表示します

まず、VTV レポートは図4-3 のように表示されます。

図4-3 VTVRPT の出力例

VTV レポートは一見すると膨大で、直感的ではないように見えます。システム内にある各 VTV を確認するために必要なすべてのデータが、多数の行に出力されています。

VTV レポートを各自の状況でより便利に活用するにはどうすればよいでしょうか。まず、VOLSER のリスト、VOLSER の範囲または個々の VOLSER に対して VTVRPT ユーティリティーを実行できます。検証したい特定の VTV がある場合は、これらの選択方法のいずれかを使用してください。

次に、VTVRPT ユーティリティーで OPTION(UNAVAIL) パラメータも指定できます。これは、図4-4 のように、利用できない VTV のレポートを生成します。

図4-4 VTVRPT (UNAVAIL オプション) からの出力例

常駐していると考えている VTV にアクセスできないジョブ (または VTCS) のレポートがあった場合は、OPTION(UNAVAIL) が最善の選択肢です。

また、VTVRPT ユーティリティーの XML 出力が持つ柔軟性を活用できます。選択したレポートおよびユーティリティーに対して、構造化 XML またはカンマ区切り (CSV) XML の出力を生成できます。

構造化 XML と CSV の出力にはどのような違いがあるのでしょうか。次のことを考えてみます。

- 構造化 XML には、各コマンドまたはユーティリティーに示されるすべてのタグと構造が含まれています (選択したプログラミング言語を使用して、必要に応じて処理できます)。

- CSV 出力を利用すると、必要なタグ (および順番) だけを選択できます。各出力行には、固定数のフィールドがカンマで区切られていて、それをスプレッドシートやレポートライターに入力して、カスタマイズ後に分析したりレポートにしたりできます。

システム環境のニーズに応じて基本的な VTV レポートを効果的にカスタマイズできる方法が 2 つあります。このトピックの詳細については、『ELS プログラミングリファレンス』を参照してください。

MVC レポートの使用

最後に、MVC サマリーレポートを見ていきます。これは、図4-5 のようになります。

図4-5 MVC サマリーレポートの例

MVC サマリーレポートは、標準の VTV レポートと非常によく似ています。探しているものが明確であれば有用ですが、おそらく明確でないと情報が多すぎるでしょう。

MVC 詳細レポートから得られる追加フィールドは、より詳細な概要を得るのに役立ちます。図4-6 に注目してください。

図4-6 MVC 詳細レポートの例 (追加フィールド)

次は、必要な場合に診断作業に利用できる、MVC 上の VTV に関する詳細情報です。

VTV レポートで利用できるようになったように、MVC レポートでも次のいずれかを実行できます。

- 構造化 XML またはコンマ区切り (CSV) XML で出力を作成できます。詳細は、『ELS プログラミングリファレンス』を参照してください。

サマリー

これまで、VTCS ダッシュボードの使用方法について説明してきました。Named MVC プールを使用する場合の MVC プールレポートの実行など、ほかにも実行可能な (おそらく、今後実行可能になる予定の) タスクは数多くあります。ただし、これは「要求時」管理タスクに関する情報です。

この章で重要な点は、仮想テープのステータスの確認 (日次)とNearline テープのステータスの確認 (日次)で説明されている日次処理、「概要の把握 (週次)」で説明されている週次処理、および VTCS システムを適正に実行し続けることです。

5 VTCS Must Do (不定期) タスクリストの操作

「VTCS Must Do (不定期) タスクリスト」には「As-Needed (要求時) タスクリスト」という別名があります。たとえば、今週は DELETSCR を実行して、貴重な VTSS および MVC スペースを使用しているスクラッチされた VTV のリストを削除することを計画しているとします。そして、作業は正常に実行されました。どれくらいしたらまた同じ操作が必要となるのでしょうか。特に、スクラッチで削除のポリシーを変更していない場合はどうでしょうか。回答: 翌日、1 月後、または 1 年後かもしれませんが、同じ操作を繰り返すでしょう。

ただし、心配はありません。このマニュアルでは、Must Do (不定期) タスクリストを切り詰めるのに役立つ手順を示します。また、「VTCS ダッシュボードの使用」で説明したように、MVC レポートと VTV レポートに注意していれば、リストを用意する必要すらありません。これらのレポートが、Must Do (不定期)/As Needed (要求時) タスクをいつ実行すればよいのかを知らせてくれます。

ほとんどポリシー決定である別のクラスの「Must Do (不定期)」タスクもありますが、これらもここで説明します。この理由として、(a) これらは本質的に先を見越した動作であり、ベストプラクティスの「As Needed」タスクの価値を 2 倍にします。また、(b) これらは、利点があるとき (またはないとき) にいつでも使用、取り消し、および再導入できる運用上の技術であることが挙げられます。まず、「強制スペースリクレイム、強制移行、および強制リコールの実行」に示す、3 つの作業について説明します。

強制スペースリクレイム、強制移行、および強制リコールの実行

これらのタスクはオプションですが、特に強制スペースリクレイムは、強く推奨されるベストプラクティスです (理由はあとで説明します)。

MVC スペースリクレイムの実行

周知のとおり、VSM はリクレイムを実行しているホストごとに、MVC スペースを自動的にリクレイムします。これは、スペースリクレイム処理が常に作業を探していて、バックグラウンドタスクであったとしても、断片化された多数の MVC がある場合は、特に処理のピーク時に、スペースリクレイム作業が移行/リコールに大きく影響する可能性があることを意味します。

MVC サマリーレポートまたは Display MVCPool によって、システムの MVC が高い割合で断片化していることが判明した場合 (およびこのレベルが CONFIG RECLAIM THRESHLD パラメータまたは MVCPool THRESH パラメータで指定された値を下回っている場合) は、強制 MVC スペースリクレイムを時間外バッチジョブとしてスケジュールすることをお勧めします。

強制 MVC スペースリクレイムは、RECLaim を使用して実行します。『ELS コマンド、制御文、およびユーティリティーリファレンス』には、強制リクレイムを最適化してもっとも効果的に実行するための有益なツールが説明されています。

- MVCPOOL、STORCLAS、ACSid、または MVC パラメータのいずれか 1 つだけを使用して、処理する MVC のリストをフィルタ処理できます。「VTCS ダッシュボードの使用」で説明したように、MVC レポートと VTV レポートを使用して、対象を MVC プール、ストレージクラス、特定の ACS、または MVC の範囲やリストに制限できます。このリストを RECLaim への入力として使用します。
いずれかのパラメータを指定しないと、スペースリクレイムでは空きスペースをもっとも必要とする Named MVC プール (実装されている場合) またはメディアタイプ (複数の MVC メディア環境) から MVC が選択されます。

- パラメータの MAXMVC (1 回のスペースリクレイムタスクで処理される MVC の最大数)、THRESH (リクレイム処理の候補となる MVC の断片化割合)、および CONMVC (VTCS がドレイン処理またはリクレイム処理で同時に処理する MVC の最大数) は、強制リクレイムの対応する CONFIG RECLAIM グローバルパラメータをオーバーライドします。これにより、強制移行を自動移行よりも細かく調整できます。

- NOWAIT は処理を高速化します。また、CONMVC は 1 回で処理する MVC の数に影響を与える別の調整方法です (詳細は、『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください)。

- ELAPSE は、指定した間隔で強制リクレイムが発生していないことを検知する方法です。この期間にリクレイムがなければ、ジョブは停止します。

- VTCS は、もっとも「厳格な」制限要素を使用します。たとえば、RECLAIM を実行して、ELAPSE を 5 時間、MAXMVC を 10 に指定し、かつ VTCS が 1 時間に 10 の MVC をリクレイムすると、ELAPSE 値の期限が終了する前にリクレイムが終了されます。

- RECLAIM 要求を処理するには、VTCS および HSC がアクティブでなければなりません。

強制 VTV 移行の実行

すでに説明したように、VTCS/ELS は基本的にサーバーです。たとえば、VSM は自動的に VTSS スペースを管理し、VTV の移行を行なって、最適なデータ可用性、リソース使用状況、およびデータ保護のバランスを維持します。

安定した環境では問題ありませんが、VSM システムが大量のアプリケーションデータを受信しようとしている場合はどうでしょうか。回答: 前述のピーク時のテープ処理イベントが発生する前に、強制移行バッチジョブを実行して、VTSS スペースを解放する必要があります。

強制移行は MIGRATE を使用して実行し、次のオプションを指定できます。

- VTV を移行できます。

- volser (繰り返し許可)

- マネージメントクラス

- VTV に関連付けられたデータセット名 (もっとも効果的)。

また、DELETE(YES) オプションも利用して、正常な移行のあとに VTSS から VTV を削除することもお勧めします。一般的には、DELete (YES) (デフォルト) は再アクセスの可能性が低い VTV に対して使用します。再アクセスの可能性が高い VTV に対しては DELete (NO) を指定して、重要なデータを利用可能にし、すばやく移行を実行できます。

- NOWAIT オプションは、処理の高速化に役立ちます。MIGRATE 形式 1 を使用します。詳細は、『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください。

- また、MIGRATE 形式 2 を使用して、VTSS のすべてまたは一部に対して、限界値を指定した強制移行を実行できます。これは、必要な DBU を得るのに適したツールであり、VTCS は詳細を処理します。

SET MIGopt を使用することで AMT の値を低くし、強制移行を効果的に発生させることもできます。

強制 VTV リコールの実行

VTCS は、ジョブがテープに移行された (VTSS 常駐でない) VTV 上のデータセットを要求したときに、自動リコール処理を開始します。上の状況の逆の場合はどうなるでしょうか。たとえば、年末の処理を実行していて、テープ上にしかない VTV からデータを読み取るジョブがあることに気付いたとします。この場合の解決策は強制リコールです。

RECALL では、必要な操作を高い柔軟性で実行できます。

- MIGRATE と同様に、VTV は VOLSER、マネージメントクラス、または関連するデータセット名からリコールできます。

- VTV をリコールする VTSS を指定できます。指定しない場合は、デフォルトで作成元の VTSS にリコールされます。VTSS のリコールポリシーには関連する考慮事項があります。詳細は、『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください。

- RECALWER により、読み取りデータチェック発生時に VTV をリコールするかどうかを指定できます。

- NOWAIT オプションは処理を高速化します。

RTD の操作

「VTCS の問題の検出と修正」で、多くの RTD 管理について説明しています。それらは、ほとんどが排他的なエラー回復シナリオです。RTD に関するベストプラクティスは、十分な数の RTD を準備して、すべてを稼働状態にして維持することです。RTD は移行、リコール、およびリクレイムに使用されます。したがって、これらのジョブのすべてに対して適切な割合の RTD を維持することは、負荷を分散するための重要な処理です。運用パラメータを使用してこの割合を調整するには、「仮想テープのステータスの確認 (日次)」を参照してください。

RTD 運用パラメータの調整に加え、VTCS の Vary RTD コマンドも主要なツールです。このコマンドは RTD の状態を変更します。RTD をオンラインまたはオフラインに切り替えることができます。また、RTD で保守が必要な場合は、保守モードに切り替えることもできます。

主要な要求時タスクには関連があり、最初の 2 つは Vary RTD を使用します。

- 「RTD デバイスタイプの変更」。基本的に、システムにある RTD の一部またはすべてをアップグレードする方法です。

- MVC メディアを指定する方法を考慮する必要があります。これらは実際に MVC 考慮事項ですが、RTD デバイスタイプの変更によって発生します。詳細は、『HSC および VTCS の構成』を参照してください。

RTD デバイスタイプの変更

RTD デバイスタイプを変更する際は、次の手順を使用します。RTD デバイスタイプを変更するには、すべてのホスト上の VTCS を停止する必要がありますので注意してください。

RTD デバイスタイプを変更する際は、次の手順を使用します。

1. VSM ポリシーを再検討します。
たとえば、この RTD デバイスタイプが移行に使用されている場合、マネージメントクラスとストレージクラスの定義を調べると良いでしょう。

2. 古い RTD を VTCS に対してオフラインにします。

3. 新しい RTD デバイスが新しい MSP デバイスアドレスを使用している場合、次を実行します。

- MSP に新しいアドレスを定義します。

- DECOMP を実行して、CONFIG 文を出力します。

- CONFIG 文を編集して、RTD アドレスを新しい値に変更します。

- CONFIG RESET を実行します。

注意:
新しいトランスポートを MSP に対してオンラインにしないでください。そうしないと、Nearline トランスポートとして割り当てられてしまいます。

4. 新しい RTD をインストールします。

5. トランスポートが置き換えられた LSM をオフラインステータスにします。

6. トランスポートが置き換えられた LSM をオンラインステータスにします。

7. 新しい RTD を VTCS に対してオンラインにします。

8. 必要に応じて、MVC を追加します。
詳細については、「MVC の追加」を参照してください。

VSM と MSP 間でのトランスポートの共有

VSM では、VSM と MSP の間でのトランスポートの動的共有はサポートされていません。つまり、1 つのトランスポートを MSP に対して、また RTD として VSM に対して両方同時にオンラインにすることはできません。ただし、VTCS に対してオンラインになっている RTD について、それを VSM に対してオフラインに切り替えたあと、MSP に対してオンラインに切り替え、純粋な Nearline ドライブとして使用することは可能です。また、その逆も可能です。もちろん、考慮すべき点もいくつかあります (以下を参照)。

注意:

- VSM と MSP との間でトランスポートを共有できるようにするには、両者からの物理的な接続が必要です。たとえば、ESCON ディレクタを使えば、MSP と VSM の両方を同じ RTD に物理的に接続できます。

- したがって、MIM や JES、GDM、またはテープ自動スイッチなどの仕組みを使って RTD を管理しないでください。そうしないと、1 つの RTD が MSP と VSM の両方に対してオンラインになり、データが失われる可能性があります。
ただし、RTD が MSP に対して定義されている場合、Vary RTD を使って RTD を VSM に対してオフラインに切り替えたあと、MSP VARY コマンドを使ってそのトランスポートを MSP に対してオンラインに切り替えることができます。ただし、RTD を VSM に対してオフラインに切り替えると、移行、リコール、およびリクレイムの処理に影響が及ぶ可能性があります (特に VSM 負荷のピーク時)。同様に、あるトランスポートが MSP に対して定義されており、VSM に対しても RTD として定義されている場合、それを MSP に対してオフラインに切り替えたあと、VSM に対してオンラインに切り替えることができます。各 VTSS では、MVC で使用されるメディアタイプごとに最低 2 つずつ、ライブラリに接続されたトランスポートが RTD として必要です。

ヒント: 追加の RTD (1 VTSS あたり最大 8 個まで) をバックアップとして定義し、それらを必要になるまで VSM に対してオフラインにしておくことをお勧めします。オンライン RTD の 1 つが故障した場合、その故障した RTD をオフラインに切り替え、修理や交換が完了するまでバックアップ RTD をオンラインに切り替えることができます。また、VTV の移行やリコールの処理の負荷がピークに達したときにも、バックアップ RTD をオンラインに切り替えることができます。

あるトランスポートが VSM に対して RTD としてオンラインになっている場合、その RTD の LOGREC タイプ OBR および MDR レコードには常にチャンネルパス ID として 00 が表示されますが、この ID はホストには何の意味も持ちません。そのトランスポートは MSP に対してオンラインになっていないからです。

MVC の操作

すでに説明したように、仮想エンティティーの 1 つだけに説明を制限することは困難です。MVC には VTV が含まれます。結局はもう一方についても言及せざるをえないため、一方だけを分離して説明することは困難です。また、VTV について言及するときは、VTSS および VTD についても述べていることになります。

したがって次のセクションでは、さまざまな理由で実行される一般的な「要求時」タスクを、MVC を使用して実行する基本的な手順を説明します。たとえば、MVC を追加するのは、以前のシナリオで説明したようにスペースを使い果たしそうな場合や、予防的な保守や問題発生を回避するためです。

注記:
SET VOLPARM または CONFIG MVCVOL 処理の結果として MVC が構成から削除される場合:

- volser を VTV として構成に再度挿入することはできません。

- volsers をネイティブ HSC テープに使用しないでください。

メッセージ SLS6944I は、削除された MVC の数を示します。

MVC の追加

ELS 7.2 では、すべてのボリュームの追加がこれまでよりもかなり簡単になりました。HSC VOLPARM および POOLPARM 文を使用して、すべてのボリュームとそのプール (ネイティブ Nearline ボリューム、クリーニングカートリッジ、MVC、および VTV) を定義し、HSC SET VOLPARM ユーティリティーを使用してそれらをロードします。詳細は、『HSC および VTCS の構成』および『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください。

MVC を追加するには、次の手順に従います。

1. MVC を定義する VOLPARM 文を作成します。
たとえば、暗号化される T10000 フル容量ボリュームの範囲を定義する場合は、次のように指定します。

VOLPARM VOLSER(T10K2000-T10K2999)MEDIA(T10000T1)RECTECH(T1AE)

2. MVC プールを定義する POOLPARM 文を作成します。
たとえば、リクレイムパラメータを指定する T10000 MVC プールを定義する場合は、次のように指定します。

POOLPARM NAME(SYS1MVCT1)TYPE(MVC)MVCFREE(40) MAXMVC(4) THRESH(60) START(70)

3. 必要に応じて、MGMTCLAS または STORCLAS 文を作成または更新します。

たとえば、新しい MVC メディアタイプを追加した場合は、『HSC および VTCS の構成』の推奨手順に従います。

4. 必要に応じて、POLICY または TAPEREQ 出力パラメータを更新します。
たとえば、手順 3 で新しいマネージメントクラスを作成した場合は、TAPEREQ または POLICY 文を、新しいマネージメントクラスを指すように更新または作成します。

5. 必要に応じて、VTV を定義します。
定義が必要な場合は、「VTV の定義」に進みます。それ以外の場合は、「ボリューム定義の検証と適用」に進みます。

VTV の定義

VTV を定義するには、次の手順に従います。

1. VTV を定義する POOLPARM または VOLPARM 文を作成します。
たとえば、ホスト MSP1 と MSP2 で使用する 2 つの VTV の範囲を定義する場合は、次のようになります。

POOLPARM NAME(SYS1VTV1)TYPE(SCRATCH)
VOLPARM VOLSER(V5000-V5499)MEDIA(VIRTUAL)
POOLPARM NAME(SYS1VTV2)TYPE(SCRATCH)
VOLPARM VOLSER(V5500-V5999)MEDIA(VIRTUAL)

2. 「ボリューム定義の検証と適用」に移動します。

ボリューム定義の検証と適用

1. SET VOLPARM を実行して、VOLPARM/POOLPARM 文を検証します。

SET VOLPARM APPLY(NO)

APPLY(NO) は、文をロードせずに検証します。結果が適切であれば、手順 2 に進みます。それ以外の場合は、ボリューム定義を修正してから、手順 2 に進みます。

2. SET VOLPARM を実行して、VOLPARM/POOLPARM 文をロードします。

SET VOLPARM APPLY(YES)

3. 実際のカートリッジを ACS に挿入します。

4. 詳細については、「カートリッジの挿入」を参照してください。

MVC のプールからの除去

MVC をプールから除去する場合は、どのような理由があるでしょうか。一般的なシナリオでは RTD の古いドライブを技術的に新しいドライブに入れ替えたり、古いメディアの使用を停止したりする場合などがあります。いずれの場合も、プールに新しい MVC を追加 (MVC の追加) し、古いメディアを除去 (「MVC の永続的除去」) します。

MVC を一時的にプールから除去する場合もあります。たとえば、不良なメディアや不良の疑いのあるメディアを入手した場合です。このような場合は、不良メディアを取り外して、別のメディアに交換します。基本的に、同じ VOLSER で交換します (「MVC の一時的除去」)。

MVC の永続的除去

MVC をプールから永久に除去するには、次を行います。

1. MVCDRain を入力して、MVC をドレインします。

たとえば、MVCDRain を実行して、ストレージクラス STORCL1 で MVC をドレインし、実際には MVC をイジェクトして要求の送信後に制御を戻すには、次を入力します。

MVCDRAIN STORCLAS(STORCL1) EJECT NOWAIT

2. MVC が ACS 内で必要なくなった場合、HSC Eject コマンドを使用して、ACS から MVC をイジェクトします。

3. その MVC に対して定義した、セキュリティーの制限事項とテープ管理システムの制限事項を除去します。

VOLPARM および POOLPARM 定義を使用していて、仮想 CDS レベルが G 以上の場合は、手順 4 に進みます。それ以外の場合は、手順 5 に進みます。

4. Nearline (非 VTCS) の使用に対してテープ volser を再利用し、VOLPARM/POOLPARM 定義を使用する場合:

1. 除去する MVC を対象とする POOLPARM/VOLPARM 文を更新します。

2. すべてのホストで SET VOLPARM APPLY(YES) を実行して変更を適用します。

3. HSC SCRAtch コマンドを実行して、MVC でなくなったボリュームをスクラッチします。

5. Nearline (非 VTCS) の使用に対してテープ volser を再利用し、VOLPARM および POOLPARM を使用しない場合は、次のいずれかを実行します。

1. HSC EJECT コマンドを発行して、MVC を ACS から除去します。

2. カートリッジに付いている外部バーコードラベルを変更します。
元の MVC volser が CDS 内に記憶されており、これらの volser は MVC としてしか使用できないため、外部バーコードラベルを変える必要があります。

3. カートリッジを再度 ACS に挿入します。

または

1. 新しい CDS データセットを作成します。

2. DELVirt を指定する HSC MERGECDS ユーティリティーを実行して、不要な MVC の範囲を除去します。

注記:
新しい CDS データセットが作成されるため、このオプションを使用する場合はすべての HSC を停止する必要があります。

MVC の一時的除去

MVC をプールから一時的に除去するには、次の手順に従います。

1. MVC に対して MVCDRain Eject コマンドを入力します。
たとえば、MVCDRain を実行して、ストレージクラス STORCL1 で MVC をドレインし、実際には MVC をイジェクトして要求の送信後に制御を戻すには、次を入力します。

MVCDRAIN STORCLAS(STORCL1) EJECT NOWAIT

これにより、次が行われます。

- MVC 上のすべての VTV をリコールし、新しい MVC に再移行します。

- MVC を VTCS の移行に選択できないようにします。

2. MVC を MVC プールに戻すには、MVC に対して MVCDRain コマンドを入力します。

MVC に EJect パラメータを指定せずに MVCDRain コマンドを入力すると、再度それが使用できるようになります。

たとえば、MVCDRain を実行して、ストレージクラス STORCL1 で MVC をドレインし、要求の送信後に制御を戻すには、次を入力します。

MVCDRAIN STORCLAS(STORCL1) NOWAIT

注記:
別の方法として、MVCMAINT を使用して、MVC を読み取り専用としてマークする方法があります。これにより、VTCS は MVC を移行に選択できなくなりますが、VTV は MVC から除去されません。MVCMAINT を使用して、読み取り専用をオフにすることもできます。
VOLPARM/POOLPARM の定義を使用する場合は、POOLPARM 文に NOMIGRAT オプションを指定して、MVC が新しい移行で使用されるのを防ぐことができます。

MVC のドレイン

MVCDRain を使用して、MVC を「ドレイン」します (MVC のすべての VTV をリコールします)。一般的には、次の場合に MVC のドレインを行います

- MVC レポートまたは Display によって、MVC にデータチェックエラーがあることが判明した場合。VSM はその MVC に移行を行わないため、MVC プールからその MVC を除去する必要があります。

- MVC レポートまたは Display によって、MVC にデータチェックエラー以外のエラーがあることが判明した場合。

- ストレージクラスまたは Named MVC プールが使用中でなく、関連する MVC を削除または再使用する場合。

ドレインする MVC を選択するときに、次のいずれかのパラメータを指定できます。

- MVCid。VOLSER で 1 つ以上の MVC をドレインします。

- MVCPOOL。Named MVC プール内の MVC をドレインします。Named MVC プールの詳細については、『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください。

- STORCLAS。ストレージクラスに MVC をドレインします。ストレージクラスの詳細については、『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください。

MVCDRain を使用すると、CONFIG RECLAIM CONMVC 設定をオーバーライドできます。ホストごとに MVCDRain を実行して、CONMVC 値と等しいホストでドレインタスクを開始できます。これらのドレインタスクは、ほかのホストで開始されたドレインタスクと同時に実行できます。

次の点にも注意してください。

- VMVC の場合、MVCDRAIN で EJECT パラメータを指定すると、VTV を物理的に削除します。

注意:
DRCHKPT ユーティリティーや CONFIG GLOBAL PROTECT パラメータを使用して VMVC の CDS バックアップの内容を保護する場合、MVCDR EJECT を指定すると CDS バックアップの VMVC に関する内容が無効化されます。

- VMVC と MVC の両方の場合、MVCDRAIN で EJECT パラメータを指定しないと、VTV を削除しませんが、VTV が VMVC/MVC にないことを示すように CDS レコードを更新します。

詳細については、ELS のコマンド、制御文、ユーティリティーに関するリファレンスを参照してください。

MVCMAINT による MVC 属性の変更

MVCMAINT も同様に VSM に関する便利なツールです。そのパラメータによって、機能が決まります。

- 最初に、MVC VOLSER (範囲、リスト、個々の VOLSER) と MANIFEST は、MVC の 2 つの選択基準です。MVC VOLSER はわかりますが、マニフェストはなぜでしょうか。マニフェストファイル (MVC とそれに含まれる VTV のリスト) は、EXPORT を実行するときに作成します。これは、MVC をシステム間で移動するときに必要です。MVC を新しいシステムにインポートするとき、読み取り専用モードで動作を開始するのがおそらく良い方法だと言えます。そうすれば、正しく定義されるまで、それらは上書きされません。

- READONLY (ON または OFF)。前の項目を参照してください。また、MVC をプールに追加する場合の説明を思い出してください。スクラッチステータスで ACS に入力することもできますが、すべてを非スクラッチとして取り込んでからあとで整理することもできます。新しい MVC を書き込み可能にする必要がある場合は、MVCMAINT READONLY(OFF) を使用します。

- LOST (ON または OFF)。MVC のロストはどのように発生するのでしょうか。たとえば、MVC がロストする可能性はあるのでしょうか。本当とは思えないかもしれませんが、ロストする場合があります。たとえば、VTCS によって開始された MVC のマウントが完了しなかった場合 (エラーで完了した場合とは対照的に)、VTCS は CDS で MVC に「ロスト」のマークを付け、使用を回避します。
「ロスト」した MVC 上に存在する多重化された VTV は、代替 MVC からリコールされます。VTCS は、ほかに使用可能な MVC がない場合を除き、「ロスト」ステータスの MVC を移行に使用しません。「ロスト」ステータスにある MVC が正常にマウントされた場合、MVC レコードの「ロスト」ステータスは解除されます。

MVC が実際にはロストしていないことがわかっている場合はどうでしょうか。回答: MVCMAINT を使用して、LOST ステータスをオフにすることができます。

MVCMAINT にはおもしろい使用方法があります。一時的に手動モードになっている LSM がある場合はどうでしょうか。LOST(ON) を使用することで、LSM での MVC の選択を (一時的に) 回避できます。LSM が自動モードに戻ったときに、LOST(OFF) で処理を元に戻します。

- ERROR (ON または OFF)。MVC はさまざまな理由で (誤って) エラーステータスになります。次に例を示します。

- VTCS が、RTD にマウントされたボリュームを MVC として認識しない。これは MSP ジョブが MVC を更新することが原因となって発生することがあります。MVC に何が起きたかを判断します。有効な VTV データが含まれていない場合、ボリュームを初期化し、MVC プールに戻します。

- MVC への書き込み不可。これは、サムホイールが読み取り専用に設定されているか、セキュリティーパッケージが VTCS によるボリュームへの書き込みを許可していない可能性があります。サムホイールをリセットするか、セキュリティーパッケージの規則を MVC への書き込みを可能にするように変更してください。

- 不良なブロック ID が検出された場合。MVC を (VTCS) 監査して、状況を修正する必要があります。
エラー状態を修正したら、MVCMAINT を使用して MVC ステータスを ERROR(OFF) にリセットします。

- EJECT (ON または OFF) は、MVC の「論理イジェクト」ステータスを指定します。このステータスはどのように設定され、なぜ変更する必要があるのでしょうか。MVCDRAIN を使用して MVC を明示的にドレインする場合、ほとんどの場合はメディアが不良であると考えられます。したがって、「論理イジェクト」ステータスを設定して使用を回避します。そのあと、実際に MVC をイジェクトしていくつかのテストを実行し、正常であることを確認して再挿入します。このとき、MVCMAINT を使用して EJECT(OFF) を設定します。

- 次に、T9840/T9940 メディアに固有の MVC 属性のグループがあります。いずれにも ON/OFF のスイッチがあります。

- WARRANTY。VTCS がメディア保証期限切れを検出し、WARRANTY ステータスを ON に設定します。または、SMF、LOGREC データ、または MVC レポートと VTV レポートを使用して耐用期限が近付いている MVC を検出し、MVCMAINT を使用して手動で WARRANTY ON を設定することもできます。保証期限が切れたことを知ることにより、メディアの耐用年数が切れる前にメディアの交換を計画できます (次の項目を参照してください)。MVC が誤って保証期限切れとマークされたことがわかっている場合はどうでしょうか。回答: MVCMAINT を使用して、保証期限切れのステータスをリセットします。

- RETIRED。VTCS は自動的にメディア耐用期限切れを検出し RETIRED ステータスを ON に設定します。前の説明と同じように、SMF、LOGREC データ、または MVC レポートと VTV レポートを使用して耐用期限が近付いている MVC を検出し、MVCMAINT を使用して手動で RETIRED ON を設定したり、誤って耐用期限切れにマークされた MVC のステータスを RETIRED OFF にリセットしたりすることもできます

- VTCS は自動的に不正なメディア情報領域 (MIR) を検出し、INVLDMIR ステータスを ON に設定します。MIR の回復は、トランスポートのオペレータパネルを介して利用できるユーティリティー、または MPST を介して利用できるユーティリティーのいずれかを使用して行うことができます。MIR を再度作成したあとは、MVCMAINT を使用して、MVC を INVLDMIR OFF に設定できます。

注記:
MVCMAINT の実行により、MVCMAINT ジョブによって影響を受けるボリュームの MVC レポートも生成されます。

MVC または VMVC の検証

MEDVERfy ユーティリティーは、MVC または VMVC (ELS 7.1 および VLE 1.2 以上のみ) で VTV データを読み取れることを検証することで、メディア検証 (MV) を実行します。VLE では MEDVERfy により、複製解除された VMVC を「元に戻す」(再構築する) ことができることを確認します。

このユーティリティーは MVC に関する検証の合格または不合格をレポートし、XML 出力も生成します。MEDVERfy ユーティリティーの詳細は、『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください。

次のセクションでは、MV に対して MEDVERfy ユーティリティーを使用する例を示します。

単一 VMVC に対する MV の実行

MEDVERFY   MVC(VMC000)

この例では、次のようになります。

- MEDVERfy は、単一の VMVC を選択します。

- MAXMVC のデフォルトは 99 に設定されます。

- CONMVC のデフォルトは 1 に設定されるため、1 回につき 1 つの MVC のみ処理されます。

- タイムアウトは指定されていません。

MVC プールによる MV の実行

MEDVER   MVCPOOL(MP1)

この例では、次のようになります。

- MEDVERfy は、処理のため、MVC プール MP1 内の MVC を選択します。

- FREQency は指定されず、MAXMVC のデフォルトは 99 に設定されるため、MEDVERfy は最後の検証の時間に基づいて最適な 99 個の MVC 候補を選択します。

- CONMVC のデフォルトは 1 に設定されるため、1 回につき 1 つの MVC のみ処理されます。

- タイムアウトは指定されていません。

MVC volser による MV の実行

MEDVER   MVC(MVC000-MVC049) CONMVC(2) TIMEOUT(720)

この例では、次のようになります。

- MEDVERfy は、処理のために、MVC volser を 50 個の範囲で選択します。

- FREQency は指定されず、MAXMVC のデフォルトは 99 に設定されるため、MEDVERfy は指定された 50 個すべての MVC を処理します。

- CONMVC は 2 であるため、MEDVERfy は 2 つの MVC を同時に処理します。

- MEDVERfy は、タイムアウトするまで 12 時間実行されます。

ストレージクラスによる MV の実行

MEDVER   STORCLAS(SC1) MAXMVC(50) FREQ(365)

この例では、次のようになります。

- MEDVERfy は、処理のため、ストレージクラス SC1 内の MVC を選択します。

- MAXMVC は 50 であり、FREQency は 365 日に指定されるため、MEDVERfy は 1 年以上検証されていない最適な 50 個の MVC 候補を選択します。

- CONMVC のデフォルトは 1 に設定されるため、1 回につき 1 つの MVC のみ処理されます。

- タイムアウトは指定されていません。

VTSS の操作

主な作業は、VTCS Vary VTSS コマンド/ユーティリティーを使用した、VTSS のオンライン、オフライン、または休止状態への切り替えです。常に何の作業をしているか、それを行う理由、VTSS をオフラインまたは休止状態にいつ切り替えるかを把握してください。多くの場合は、VTSS の保守が必要であるか、構成から VTSS を削除するためです。これらについては、「VTCS の問題の検出と修正」で説明しています。

最初に、次のチャートで、VTSS をサポートする各モードに変更するときに何が発生するか (そして、可能な場合は常に OFFline ではなく QUIESCED を使用する理由) を説明します。

表5-1 VTSS の状態

指定する Vary VTSS のパラメータ

VTSS の最初の状態

VTSS の次の状態

ONline

オンライン保留状態 - オンライン保留状態では、すべてのホストでオンラインプロセスは開始されていますが、完了はしていません。

オンライン - オンライン状態では、VTSS はオンラインで使用可能な状態です。また、フロントエンドおよびバックエンドの両方の作業を ACCEPT します。オフライン状態の VTSS をオンラインにすると、VTCS は VTSSAUDIT を実行するように警告メッセージを発行します。

QUIESCED

休止中 - この状態では、VTCS は VTSS に対する DD の割り振りは行いません。保留中のマウントを ACCEPT し、unit=aff チェーンで長時間実行されているジョブが完了できるようにします。すべての VTD が未使用状態 (MSP で VTD の UCB が割り振られていない状態) になると VTSS は休止状態に遷移します。休止処理中状態では、VTSS は、移行、リコール、AUDIT などのバックエンド作業を ACCEPT し、処理します。

休止状態 - 休止状態では、VTSS は、移行、リコール、AUDIT などのバックエンド作業を ACCEPT して処理します。したがって、VTSS が休止状態でも、リコールまたは移行を実行するコマンドやユーティリティーを使用できます。

OFFline

オフライン保留状態 - オフライン保留状態では、すべてのホストでオフラインプロセスが開始されていますが、完了はしていません。VTCS は、VTSS をすぐにシャットダウンし、アクティブ状態のタスクとキュー内のタスクをすべてパージします。VTSS サーバータスクは終了し、新しいフロントエンドおよびバックエンド作業は受け入れられません。VTCS は新規 VTV の作成および既存 VTV のマウント/マウント解除を代替 VTSS (使用可能な場合) 上でのみ行います。

オフライン - オフライン状態では、VTSS はすべてのホストに対してオフライン状態になり、フロントエンドおよびバックエンド作業は受け入れられません。

オンライン状態の VTSS と MVC に VTV のコピーが存在しているときに、ジョブがその VTV を要求すると、VTCS は代替 VTSS (使用可能な場合) に VTV を自動的にリコールします。

注記:
クライアント/サーバー環境 (クライアントホスト上の SMC/HTTP サーバー) では、VTCS は長時間実行されているジョブがクライアントホストで有効であるかどうかを判断できません。VTSS がオフライン状態になったあと、(a) VTD を MSP に対して明示的にオフラインにするか、(b) クライアントホスト上の仮想テープの活動が停止していることを確認してください。
クラスタ VTSS または Cross-TapePlex Replication (CTR) の構成では、VTSS への Clink をオフラインに変更して、レプリケーションと電子的なエクスポート処理を停止してください。

保守のための VTSS の休止

VTSS を保守する前に、次のように VTSS を休止します。

1. ホストごとに、VTSS VTD をオフラインに変更します。
ホストごとに、すべてのデバイスがオフラインになるまで待ちます。VTD は割り振りがなくなるまでオフライン処理を続行しないことに注意してください。長時間実行ジョブが VTD を使用している場合は、ジョブが完了するまで待つかジョブを取り消す必要があります。

2. 指定の VTSS が定義されている VTCS システムから、VTSS を QUIESCED に変更します。
各 VTCS システムで、VTSS が休止状態であることを示すメッセージ SLS6742I を待機します。

3. オプションで、データを VTSS から移行できます。

4. 指定の VTSS が定義されている VTCS システムから、VTSS を OFFLINE に変更します。
各 VTCS システムで、VTSS がオフライン状態であることを示すメッセージ SLS6742I を待機します。これで、VTSS を保守できるようになります。

VTSS の削除

VTSS を削除するのは次のような場合です。2 つの別々の VSM システムがあり、一方のワークロードは増大し、もう一方のワークロードは減少しています。解決法: システム A から VTSS を取り出し、システム B に追加します。『Installing ELS』では VTSS を追加する方法について説明しているため、このセクションは VTSS を削除するための操作に限定します。

VTSS を削除するには:

1. VTSS を削除する前に、次を行います。

- 削除する前に VTSS を空にする必要はありません。必要なのは、すべての VTV が完全に移行されているか確認することです。また、削除した VTSS に新しい作業がルーティングされないように、TAPEREQ 文などほかのパラメータを変更することも検討してください。

- VTSS から 1 つのデバイスタイプ/ACS の組み合わせをすべて削除する場合は、すべての VTV が完全に移行されていることもまず確認してください。上記のように、VTSS の変更された移行機能を反映するために、ほかのパラメータを変更することを検討してください (たとえば、ACS と媒体を指定するストレージクラスを指しているマネージメントクラスなど)。

2. VTSS を休止状態にします。
オフラインになったら、手順 3 に進みます。

3. VTSS を削除し、CONFIG を再実行して論理的に削除します。

次に、構成から物理的に除去した VTSS2 へのホストアクセスを拒否するように、CONFIG を実行して構成を更新する JCL の例を示します。この例では、パラメータを指定せずに VTSS2 の VTSS 文を再指定して、この VTSS へのホストアクセスを拒否しています。

//UPDATECFGEXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR
//SLSCNTLDD DSN=FEDB.VSMLMULT.DBASEPRM,DISP=SHR
//SLSCNTL2DD DSN=FEDB.VSMLMULT.DBASESEC,DISP=SHR
//SLSSTBYDD DSN=FEDB.VSMLMULT.DBASETBY,DISP=SHR
//SLSPRINTDD   SYSOUT=*
//SLSINDD   *
CONFIG
GLOBALMAXVTV=32000MVCFREE=40
RECLAIMTHRESHLD=70MAXMVC=40  START=35
VTSSNAME=VTSS1  LOW=70 HIGH=80  MAXMIG=3  RETAIN=5
RTDNAME=VTS18800 DEVNO=8800 CHANIF=0A
RTDNAME=VTS18801 DEVNO=8801 CHANIF=0I
RTDNAME=VTS18802 DEVNO=8802 CHANIF=1A
RTDNAME=VTS18803 DEVNO=8803 CHANIF=1I
RTDNAME=VTS18811 DEVNO=8811 CHANIF=0E
RTDNAME=VTS18813 DEVNO=8813 CHANIF=1E
VTDLOW=8900 HIGH=893F
VTSSNAME=VTSS2

VTV の操作

このセクションでは、必要に応じて実行する必要があるもっとも一般的なタスクとして、スクラッチ VTV の削除および VTV 属性の変更について説明します。

注記:
SET VOLPARM または CONFIG MVCVOL 処理の結果として VTV が構成から削除される場合:

- volser を MVC として構成に再度挿入することはできません。

- volsers をネイティブ HSC テープに使用しないでください。

メッセージ SLS6944I は、削除された VTV の数を示します。

スクラッチ VTV の削除

スクラッチ VTV の削除には 2 つの方法があります。

- ポリシーを使用して、VTV のマネージメントクラスで DELSCR(YES) を指定し、HSC を使用して実際のスクラッチを実行します。

- 特定のタスクでは、DELETSCR ユーティリティーを使用します。DELETSCR は VTSS からスクラッチ VTV を削除し、移行済みの VTV を MVC から切断します。バージョン情報が保存されていますが、削除された VTV は非初期設定とマークされます。

『ELS のインストール』ではスクラッチ VTV の削除について取り上げているため、以降の情報は「As Needed」バージョンについて説明します。

注意:
DELETSCR を使用してスクラッチ VTV を削除した場合、それらの VTV 内にあるデータは消失し、回復できません。

VTV の削除は、「ほかに手段がないから」といった理由で実行するようなものではありません。スクラッチ VTV を手動で削除する必要がある場合は、 のシナリオに問題があるということです。

オペレータコマンドによる不注意な VTV の削除を防ぐために、DELETSCR は SLUADMIN ユーティリティーのみで、次のような機能を備えています。

- VTV は、VOLSER (個々の VOLSER、リスト、または範囲)、マネージメントクラス、または HSC スクラッチプールで指定できます。MVC レポートと VTV レポートを使用して、対象を識別する最適な方法を見つけ、対応する DELETSCR オプションを適用してください。指定できるオプション (VTVid、MGMTclas、または SCRpool) は 1 つだけです。いずれのオプションも指定しない場合、DELETSCR は対象となるすべての VTV を削除します。これは適切な方法である可能性がありますが、この方法を使用する場合は注意してください。

- 必須の NOTREF パラメータは、VTV が参照されてからの日数 (1 - 999) を指定します。NOTREF は効果的な猶予期間で、指定した猶予期間内に参照された VTV は削除されません。

- MAXVTV パラメータ (オプション) は、DELETSCR が削除する VTV の最大数を指定する便利なパラメータです。これは最大であり、ターゲットではないので注意してください。ピーク時以外に DELETSCR を実行する場合は、MAXVTV を使用しなくてもかまいません。問題が発生している場合は使用するとよいでしょう。
MAXVTV の範囲は 0 - 999 です。0 を指定するとどうなるでしょうか。この場合、DELETSCR は VTV を削除しませんが、DELETSCR を実行した場合に削除される VTV の数がサマリーレポートに表示されます (つまり、そのレポートはただのスナップショットです)。

- 最後に、DELETSCR のレポートで作業結果を確認できます。レポートには標準的なレポートと詳細レポートがあります (DETAIL パラメータで指定)。

DELTSCR を実行する JCL の例

次に、DELETSCR を実行する JCL の例を示します。これは、マネージメントクラス MC1 で、60 日間参照のないスクラッチ VTV を最大で 800 削除し、詳しいレポートを作成します。

//DELETSCR EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINTDD SYSOUT=*
//SLSINDD *
DELETSCR MGMTCLAS(MC1) NOTREF(60) MAXVTV(800) DET

VTVMAINT による VTV 属性の変更

VTVMAINT も使いやすいツールで、次のような VTV の保守に使用します。

- VOLSER (範囲、リスト、個々の VOLSER) で VTV を選択します。

- 「VTV マネージメントクラスの変更および MVC からの VTV のリンクの切断」で説明するように、VTV のマネージメントクラスを変更するため、VTV を MVC からリンク切断します。

- VTV のマネージメントクラスを変更します。これは、VTV の管理方法を変更する場合に行います。ほかの方法もありますが、「VTV マネージメントクラスの変更および MVC からの VTV のリンクの切断」で説明するように、最適なツールは明らかに VTVMAINT です。

- オフライン VTSS 内の指定された VTV を論理的にマウント解除します。これについては、「オフラインの VTSS における VTV の論理マウント解除」で詳しく説明しています。

- 「Cross-TapePlex Replication (CTR) によって複製された VTV の管理」。

注記:
VTVMAINT を実行すると、VTVMAINT ジョブの影響を受けるボリュームの VTV レポートも生成されます。

VTV マネージメントクラスの変更および MVC からの VTV のリンクの切断

VTVMAINT を使用すると VTV のマネージメントクラスを変更できます。新しいマネージメントクラスが別のストレージクラスを指定している場合、MVC 上の VTV の現在の場所が不適切になります。VTVMAINT を使用し、VTV のマネージメントクラスおよびストレージクラスを変更する方法を次に示します。

VTV のマネージメントクラスを変更し、そのリンクを解除するには:

1. VTV をリコールします。
手順 2 でリンク解除が成功するには、VTV が VTSS 常駐である必要があります。

2. VTVMAINT ULINKMVC を使用し、それが配置されている MVC と VTV のリンクを解除します。

3. VTVMAINT MGMTclas を使用し、新しいマネージメントクラスを割り当てます。

4. VTV を再移行して正しい MVC に配置します。または VTV を MVC に適宜移動する手順については、RECONcil による VTV ストレージクラスの変更を参照してください。

オフラインの VTSS における VTV の論理マウント解除

VTSS がオフラインになった時点で VTV がマウント済みで、VTV のコピーが MVC に存在している場合、VTV がオフラインの VTSS にマウント済みのステータスになっているため、VTCS は移行済みの VTV を代替 VTV にリコールしません。この場合、VTVMAINT を使用すると、オフライン VTSS 内で VTV を論理的にマウント解除し (CDS 内のマウントされたビットをオフにします)、代替 VTSS へ VTV をリコールできます。VTCS は、正常にマウント解除された各 VTV を SMF サブタイプ 14 レコードの SMF14STA フィールドに記録します。VTVRPT(UNAVAIL) オプションはオフライン VTSS 内の使用できない VTV のステータスを報告します。詳細は、『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください。

VTV の MVC コピー (存在する場合) が使用できない VTV の内容と同一だということが十分確認できないかぎり、オフライン VTSS 内の使用できない VTV をマウント解除しないでください。確認しないでマウント解除した場合、代替 VTSS に古いデータで VTV をリコールする危険があります。たとえば、読み取り用にマウントされた VTV は代替 VTSS へのリコール用のマウント解除には安全です。ただし、書き込み用にマウントされた VTV は更新され MVC コピーが古いものになっている場合があるため、マウント解除することが安全とは限りません。

次に論理的に VTV をマウント解除し、別の VTSS からその VTV にアクセスする一般的な手順を示します。

論理的に VTV をマウント解除し、別の VTSS からその VTV にアクセスするには次のようにします。

1. 次のコマンドを実行して、VTCS に対して VTSS をオフラインにします。

VT VARY VTSS(name) OFFLINE

I/O がアクティブ状態で VTSS に障害が発生した場合、MSP は VTD を BOX し、マウントされた VTV を MSP 的にマウント解除します。ただし、VTSS がマウントされている VTV を実際にマウント解除する前に VTSS との通信が失敗した場合は、引き続き VTCS に対しオンラインの場合があります。したがって、最初に VTCS に対し VTSS をオフラインに変更する必要があります。

MSP が VTD を隔離し、マウント済みの VTV をマウント解除した場合は、手順 3 に進みます。それ以外の場合は、手順 2 に進みます。

2. VTV を MSP 的にマウント解除します。

VTV がオフラインの VTSS にマウントされていると MSP が認識している場合には、別の VTSS の VTD に VTV を再マウントすることはできません。次のいずれかを実行します。

- MSP UNLOAD コマンドを使用して VTV をマウント解除します。

- VARY OFFLINE コマンドを実行して、VTV がマウントされている VTD をオフラインにします。これにより、VTV もマウント解除されます。

3. オフラインの VTSS と論理的にマウント解除する VTV を指定して、VTVMAINT を実行します。

たとえば、オフライン VTSS01 上にある VTV VV6823、VV6825、および VV6688 を論理的にマウント解除する場合には、JCL に次の SLSIN DD 文をコピーします。

VTVMAINT DISMOUNT VTV(VV6823,VV6825,VV6688) VTSS(VTSS01)

マウント解除された VTV の移行されたコピーが存在し、オンライン VTSS からアクセス可能な場合、VTV へアクセスするのにこの VTSS が使用できます。

注意:
オフラインの VTSS にマウント中の VTV のコピーが変更されたあとに、移行されていない場合には、代替 VTSS にリコールする MVC のコピーは最新のものではありません。したがって、Oracle では、これらの現在のものでない MVC コピーをリコールしないことを強く推奨します。

ヒント:
オフライン VTSS が、オンラインに戻る準備ができているとき、VTSS を使用する本番ジョブの実行前に VTSS を AUDIT することを Oracle は強く推奨します。また、VTSS VARY ONLINE コマンドの発行前に VTD の "BOX" ステータスをクリアするようにしてください。

Cross-TapePlex Replication (CTR) によって複製された VTV の管理

VTVMAINT を使用すると、CTR によって複製された VTV のステータスを変更できます。

- VTV の所有 TapePlex を変更するには、VTVMAINT OWNRPLEX を使用します。

- VTV を参照する TapePlex の名前を削除するには、VTVMAINT DELEXpot を使用します。

- VTV を参照する TapePlex の名前を追加するには、VTVMAINT ADDEXpot を使用します。

詳細は、『ELS 障害回復およびオフサイトデータ管理ガイド』を参照してください。

RECONcil による VTV ストレージクラスの変更

「VTV マネージメントクラスの変更および MVC からの VTV のリンクの切断」で説明したように、VTVMAINT を使用して VTV のマネージメントクラスを変更できます。これにより、そのストレージクラスが変更される可能性があります。また、VTV を別のストレージクラスに明示的に変更した場合はどうでしょうか。回答: RECONcil を使用します。

最初の RECONcil ジョブ (SLUADMIN ユーティリティーのみ) を送信する前に、VTV のストレージクラスを変更する理由を確認しておきます。基本的に 3 つの理由があります。

- 上で説明したように、VTV のマネージメントクラス/ストレージクラスを明示的に変更している場合。

- VTV が間違ったメディア、間違った ACS、またはその両方にある場合。

- 利用できない状態が相当期間続いていた ACS がオンラインに戻った場合。この場合、まず、影響を受ける VTV の MGMTclas 文の MIGpol パラメータを変更して別の ACS (必要に応じてメディア) を指示します。元の ACS がオンラインに戻ったときに、MGMTclas 文の MIGpol パラメータを元の ACS を指示するように変更し、更新された MGMTclas (または STORclas) 文を指定している RECONcil を実行して VTV を元の ACS に移動します。

この説明では、RECONcil を使用した、VTV の不正なストレージクラス (不正な MVC メディア、ACS 位置、またはその両方) の再統合について説明しています。データのアクセス頻度が低下した VTV を、アクセス主体メディア (T9840 カートリッジなど) から、ストレージ主体メディア (T9940 カートリッジなど) および拡張保管 ACS またはオフサイトに移動する場合はどうでしょうか。この場合、一般的に MGMTCLAS 文の ARCHAge/ARCHPol パラメータを使用してアーカイブポリシーを設定します。これにより、ARCHAge 値が超過したとき、および VTV がリコールおよび再移行されるときに、ARCHPol 仕様に従って VTV の移動が自動的に発生します。

したがって、自動的なアーカイブポリシーは自動移行と似ています。どちらもいずれ発生しますが、1 つ以上の VTV が実際に間違った場所にある場合は、移動が発生するのを待っている時間はありません。この場合は、RECONcil を使用します。

RECONcil ジョブの実行

RECONcil を使用して VTV の ACS/メディアを変更するには、次の手順に従います。

1. 再統合が必要かどうかを検証する VTV を選択するには、次のいずれかの RECONcil パラメータを指定します。
STORclas - 1 つ以上のストレージクラスを指定します。ここで、RECONcil は次のことを行います。

- 指定したストレージクラスの ACS とメディアの定義を検索します。

- 現在ストレージクラスにある MVC をスキャンします。MVC ACS とメディアが、ストレージクラスの定義と一致するかどうか確認されます。一致しない場合は、エラーのある MVC と VTV が表示されます。

MVC - MVC のリストまたは範囲を指定します。RECONcil は次のことを行います。

- 指定した MVC の実際の ACS とメディアを確認します。

- 実際の MVC ACS/メディアが、MVC のストレージクラス定義と一致するかどうか確認されます。一致しない場合は、エラーのある MVC と VTV が表示されます。

MGMTclas - 1 つ以上のマネージメントクラスを指定します。RECONcil は次のことを行います。

- MGMTclas MIGpol パラメータで指定した ACS とメディア定義を検索します。

- 指定したマネージメントクラスに現在ある VTV をスキャンします。VTV が、MGMTclas MIGpol の指定に一致する ACS/メディアのある MVC にあるかどうか確認されます。ない場合は、エラーのある MVC 上の VTV が表示されます。

VTV - VTV のリストまたは範囲。RECONcil は次のことを行います。

- 指定した VTV のマネージメントクラス (1 つ以上) を確認します。

- MGMTclas MIGpol パラメータで指定した ACS とメディア定義を検索します。

- 指定したマネージメントクラスに現在ある VTV をスキャンします。VTV が、MGMTclas MIGpol の指定に一致する ACS/メディアのある MVC にあるかどうか確認されます。ない場合は、エラーのある MVC 上の VTV が表示されます。

注記:
想像できると思いますが、いずれの選択パラメータも指定しなかった場合、VTCS はすべての VTV を検証します。この詳細は、手順 2 で説明します。

2. RECONcil をはじめて実行するときは、デフォルトを受け入れます。このときはレポートのみが生成されます。データの移動は行われず、再統合の候補となる VTV が報告されるだけです。

注意:
VTV を再統合すると、リソースを大量に消費する可能性があるため、最初は MOVEVTV を指定せずに RECONcil を実行し、MOVEVTV を指定する前に必要に応じてジョブを調整することを強くお勧めします。

3. 必要に応じて、RECONcil ジョブを調整します。
たとえば、手順 2 でレポートを実行していて、再統合に長時間かかりそうな場合は、次を実行することを検討します。

- 処理のピーク時を避けて RECONcil を実行します。強制 MVC スペースリクレイムの場合と同じです。

- RECONcil ユーティリティーのパラメータを使用して、CONFIG RECLAIM THRESHLD、MAXMVC、および CONMVC の設定をオーバーライドし、再統合のパフォーマンスを最適化します。

- 再統合の最大時間を、ELAPSE パラメータに分単位で指定します。

注記:
再統合に影響する複数の制限要素があります (たとえば、MAXMVC および ELAPSE)。VTCS は、もっとも厳格な制限要素を実現します。たとえば、RECONcil を実行して、ELAPSE を 5 時間、MAXMVC を 10 に指定し、かつ VTCS が 1 時間に 10 の MVC を再統合すると、ELAPSE 値の期限が終了する前に再統合が終了されます。

- ARCHive ユーティリティーで使用できる RECONcil POLICYdd オプションは、診断に役立ちます。POLICYdd はレポートの生成のみを行い、代替の MGMTclas 文を含むファイルを示します。

ヒント:
これは基本的に大切なツールです。たとえば、VTV マネージメントクラスの変更および MVC からの VTV のリンクの切断に従って一部の VTV マネージメントクラスを変更し (ストレージクラスの仕様を含む)、RECONcil を実行したとすると、その結果はどうなるでしょうか。実際に VTV のマネージメントクラスを変更する前に、結果を確認できます。

注記:
POLICYdd パラメータを指定する場合を除き、RECONcil 要求を処理するには、VTCS と HSC がアクティブである必要があります。

4. これで、必要な微調整や非ピーク時スケジュールタスクがすべて完了しました。
次に、RECONcil を実行する JCL の例を示します。

- ストレージクラス LOCALPROD1 および LOCALPROD2 の VTV を再統合します。

- RECONcil ジョブに対して、MAXMVC を 60、CONMVC を 8、および ELAPSE を 60 にそれぞれ設定します。

//RECONCIL    EXEC PGM=SLUADMIN
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINTDD SYSOUT=*
//SLSINDD *
RECON MGMT (LOCALPROD1,LOCALPROD2) MAXMVC(60) CONMVC(8)
ELAPSE(360) MOVEVTV

実行後の RECONcil レポートには実行結果が表示され、必要に応じて処理を再調整して再実行できます。

FOR_LOSTMVC を使用した VTV の回復

LOGUTIL FOR_LOSTMVC 文を使用すると、失われた MVC または破損した MVC に存在していた VTV を回復できます。LOGUTIL FOR_LOSTMVC 文の動作と、もっとも効果的な使用方法について

FOR_LOSTMVC ユーティリティーは CDS と (必要に応じて) ログファイルの構造をスキャンし、失われた MVC または破損した MVC 上にある、volser を指定したすべての VTV を識別します。また、表5-2 で説明する代替 VTV コピーからの回復方法のいずれを使用するかを決定します。LOGUTIL FOR_LOSTMVC は、失われた MVC または破損した MVC に存在していたすべての VTV と、その回復方法を示すレポートを生成します。また、これらの MVC それぞれのサマリー情報も出力されます。

表5-2 代替 VTV コピーと回復処理

代替 VTV コピーのカテゴリ

回復処理

カテゴリ 1: 現在、VTSS が常駐している。

回復は常駐コピーから行います。回復コマンドを要求すると、失われた MVC または破損した MVC から VTV をリンク解除するために VTVMAINT ULINKMVC コマンドが生成されます。

カテゴリ 2: 現在、1 つまたは複数の代替 MVC コピーにリンクされている。

回復は、次の 4 つの項目に基づいて最適な代替 MVC から行います。

- MVC に対して、CDS に MVC レコードが存在しているか。

- MVC のステータスが「ロスト」であるか。

- MVC のステータスが「破損」であるか。

- MVC でデータチェックを実行しているか。

回復コマンドを要求すると、VTVMAINT ULINKMVC コマンドと RECALL コマンドが生成され、失われた MVC または破損した MVC から VTV をリンク解除したあとに、MVC がリコールされます。

カテゴリ 3: Cross TapePlex Replication で複製されている。

VTV のコピーを含む、最初に見つかったリモート TapePlex を使用して、VTV を回復します。

回復コマンドを要求すると、EEXPORT ULINKMVC コマンドが生成されます。これらのコマンドは、現在 VTV が存在しているリモート TapePlex から実行する必要があります。COMMANDS データセット内のコメントは、これらのコマンドを実行する必要がある TapePlex を示しています。コマンドは、失われた MVC または破損した MVC から VTV をリンク解除し、Cross TapePlex Replication により VTV をふたたびローカルの TapePlex に複製します。

カテゴリ 4: VTV データをまだ含んでいる可能性がある 1 つまたは複数の MVC コピーに以前リンクされていた。

以前リンクされていた MVC の 1 つが、回復 MVC として選択されます。これらの MVC コピーはログファイルで検索され、まだ VTV のコピーを含んでいる可能性があります。選択した回復 MVC を監査する必要があります。リンクされていた MVC コピーのうち回復に使用できる最適なコピーは、代替 MVC と同じ条件に基づいて選択します。

回復コマンドを要求すると、AUDIT コマンドが生成され、MVC を監査し、これを VTV にリンクしようとします。

MVCMAINT READONLY(ON) コマンドが AUDIT MVC に対して生成されます。

カテゴリ 5: 回復不能。

コピーは失われた MVC または破損した MVC のみに存在し、回復することができません。

注記:
回復コマンドを要求すると、カテゴリ 1、2、3、および 4 では MVCMAINT コマンドも生成されます。これらの文は、失われた MVC または破損した MVC を読み取り専用および破損としてマーク付けし、それらがリコールまたは移行の対象として選択されないようにします。

FOR_LOSTMVC による回復手順

注記:
この手順の JCL 例では、CDS コピーに対する DD 文を示していません。HSC がアクティブで、LOGUTIL を実行しているシステムでアクティブな CDS を使用する場合は、このままで有効です。それ以外の場合は、CDS コピーに対する DD 文を指定する必要があります。

FOR_LOSTMVC を使用して VTV を回復するには:

1. まず、失われた MVC または破損した MVC の volser のみを使用して、LOGUTIL FOR_LOSTMVC コマンドを実行します。

たとえば、次の例は次の内容を示しています。

- ロギングデータセットは LOGIN です。

注記:
LOGUTIL FOR_LOSTMVC を実行するときにダミーの LOGDD を指定すると、CDS のロギングがアクティブになっていないシステムで回復を行うこともできます。回復は CDS 内のデータに限られますが、すべての VTV が常駐していて代替 MVC コピーにあるか、Cross Tape Replication によってエクスポートされている場合は、これも有効な方法になります。

- 破損した MVC の volser は DMV509 です。

- 回復コマンドは、データセット RECVCMD に記録されます。

//JOBLOGR job (account),programmer,REGION=1024k
//S1 EXEC PGM=SLUADMIN,PARM=MIXED
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//LOGIN        DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-2),DISP=OLD
//             DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-1),DISP=OLD
//             DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(0),DISP=OLD
//RECVCMD      DD DSN=FEDB.VSMLMULT.RECVCMD,DISP=(CATLG,DELETE),
//                UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE),
//                DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920)
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
LOGUTIL LOGDD(LOGIN)
FOR_LOSTMVC MVC(DMV509) COMMANDS(RECVCMD)

2. 手順 1 による LOGUTIL FOR_LOSTMVC レポートを確認します。

回復する VTV を選択し、失われた MVC または破損した MVC から回復する VTV を指定して LOGUTIL FOR_LOSTMVC を再実行します。例:

//JOBLOGR job (account),programmer,REGION=1024k
//S1 EXEC PGM=SLUADMIN,PARM=MIXED
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//LOGIN        DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-2),DISP=OLD
//             DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-1),DISP=OLD
//             DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(0),DISP=OLD
//RECVCMD      DD DSN=FEDB.VSMLMULT.RECVCMD,DISP=(CATLG,DELETE),
//                UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE),
//                DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920)
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
LOGUTIL LOGDD(LOGIN)
FOR_LOSTMVC MVC(DMV509) VTV(DX009) COMMANDS(RECVCMD)

注記:
指定した VTV が失われた MVC または破損した MVC にない場合、この VTV は無視されます。

破損した MVC 上にある、指定した VTV のすべてを回復する場合は、手順 3 に進みます。

3. 指定した VTV を回復するには、手順 2 で指定した回復データセット内のコマンドを実行します。

注記:

- 回復データセット内のコマンドは、FOR_LOSTMVC の実行後にできるだけすみやかに (標準の SLUADMIN JCL を使用して) 実行し、正確さを保証する必要があります。

- Oracle では、回復コマンドを COMMANDS ファイル内で、次の順序で実行することをお勧めしています。

1. すべての EEXPORT ULINKMVC コマンド。

2. すべての MVCMAINT READONLY(ON) コマンド。

3. すべての AUDIT コマンド。

4. EEXPORT ULINKMVC または AUDIT コマンドがあった場合は、FOR_LOSTMVC を再実行します。新規の実行では、新しく生成された COMMANDS ファイルに EEXPORT または AUDIT コマンドがないようにします。ある場合は、手順 a に戻ります。

5. すべての MVCMAINT READONLY(ON) ERROR(ON) コマンド。

6. すべての ULINKMVC コマンド。

7. すべての RECALL コマンド。

8. RECONcil ユーティリティー
指定したすべての失われた MVC または破損した MVC で、CDS に存在し候補となる VTV が少なくとも 1 つあるものに対して、MVCMAINT コマンドが生成されます。MVCMAINT コマンドは、失われた MVC または破損した MVC に読み取り専用ビットとエラー/破損ビットを設定して、これらがリコールまたは移行で割り振られないようにします。各 MVCMAINT コマンドには、最大で約 3000 の MVC が含まれます。

4. RECONcil ユーティリティーを実行して、各 VTV に対して正しい数の MVC コピーが作成されることを確認します。
例:

//JOBLOGR job (account),programmer,REGION=1024k
//S1 EXEC PGM=SLUADMIN,PARM=MIXED
//STEPLIB      DD DSN=hlq.SEALINK,DISP=SHR
//LOGIN        DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-2),DISP=OLD
//             DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-1),DISP=OLD
//             DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(0),DISP=OLD
//RECVCMD      DD DSN=FEDB.VSMLMULT.RECVCMD,DISP=(CATLG,DELETE),
//                UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE),
//                DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920)
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
RECONCIL VTV(DX009)

6 マネージメントクラスおよびストレージクラスによる最新のソリューション

このセクションを使用すると、VTCS マネージメントおよびストレージクラスを作成し、それらに関連する一般的なタスクを実行することができます。

VTCS CDS レベル

最新のソリューションに関して重要なことは、現在の CDS VTCS レベルと、そのレベルで何が可能で何が不可能かを確認することです。表6-1 では、CDS レベルと各レベルで使用可能な機能を示しています。

表6-1 サポートされている VTCS バージョンの CDS レベル

VTCS CDS レベル:

VTCS/NCS バージョン:

拡張機能:

E

6.0、6.1、6.2、7.0

- 4 MVC コピー

- 800M ビットの VTV

F

6.1、6.2、7.0、7.1、7.2

- NCO (Near Continuous Operations)

- 双方向クラスタリング

- CDS の I/O パフォーマンスの改善 - 仮想スクラッチサブプールの管理に必要な I/O の低減

G

6.2、7.0、7.1、7.2

- 400M ビット/800M ビット/2G ビット/4G ビットの VTV

- 標準/大規模の VTV ページ

- 1 MVC あたり 65000 個の VTV

H

7.1、7.2

- 動的リクレイム

- 自律デバイスのサポート

マネージメントクラスおよびストレージクラスについて

さまざまな最先端のインプリメンテーションのコンポーネントである VTCS マネージメントクラスおよびストレージクラスは、次の処理を実行します。

- VTCS マネージメントクラスは、VTCS が VTV を管理する方法を指定します。HSC MGMTclas 制御文はマネージメントクラスとその属性を定義します。たとえば、MGMTclas 文の DELSCR パラメータで、VTSS からスクラッチされた VTV を VTCS が削除するかどうかを指定します。

- また、マネージメントクラスでは VTCS ストレージクラスの指定もできます。VTCS ストレージクラスは、移行された VTV がどこに存在するかを指定します。HSC STORclas 制御文はストレージクラスとその属性を定義します。例:

MGMT NAME(PAYROLL) MIGPOL(LOCAC,REMAC)
STORCLAS NAME(LOCAC) ACS(00) MEDIA(STK1R)
STORCLAS NAME(REMAC) ACS(01) MEDIA(STK2P,ZCART)

このマネージメントとストレージクラスの組み合わせは、「マネージメントクラス PAYROLL の場合、ローカルおよびリモート ACS 内の個別の MVC に移行します。ローカル ACS では、必要な場合はすぐに戻せるように 9840 メディアに配置します。リモート ACS では ZCART より 9940 メディアを優先しますが、明らかにストレージに配置します。」ということを表しています。

はじめに、「VTCS マネージメントおよびストレージクラスの作成と使用: 基本」について説明します。これは、業務の必要に応じて調整できる基本的な手順です。次に「マネージメントクラスおよびストレージクラスの管理に使用できる最先端技術」について説明します。このセクションではさまざまな選択肢を示します。その中から各自の環境にもっとも適したものを選んでください。

VTCS マネージメントおよびストレージクラスの作成と使用: 基本

このパターン (TAPEREQ > POLICY > MGMTclas > STORclas) は頻繁に使用しますので、よく理解してください。これは、「マネージメントクラスおよびストレージクラスの管理に使用できる最先端技術」に示すすべての情報のベースとなるものです。

VSM マネージメントおよびストレージクラスの作成および使用

1. STORclas および MGMTclas 文を含む定義データセットを決定します。
MGMTclas および STORclas 文は、相互検証のために同じデータセットに存在している必要があります。

2. STORclas 制御文でストレージクラスを定義します。

3. 必要に応じて、MIGRSEL および MIGRVTV 文を使用して、移行ポリシーを調整します。

4. MGMTclas 制御文でマネージメントクラスを定義します。

MGMTclas 制御文は、さまざまなパラメータでストレージクラスを指定します。

5. HSC MGMTDEF コマンドで、制御文をロードします。

6. SMC POLICY コマンドでテープポリシーを指定します。

7. 次のいずれかの方法で、VTCS に対するポリシー名を指定します。

- SMC TAPEREQ 文。

- StorageTek DFSMS インタフェースに記述した SMS ルーチン。

マネージメントクラスおよびストレージクラスの保守

次の点に注意してください。

- マネージメントクラスをマウントに割り当てる場合は、常に SMC POLICY コマンドを使用してください。

- ポリシーは TAPEREQ 文または SMS ルーチンのいずれかで指定できます。

- POLICY VALIDATE を使用して、すべての SMC POLICY 文が VALID MGMTCLAS 名を参照していることを確認してください。

- VTVMAINT ユーティリティーを使用すると、VTV のマネージメントクラスを変更できます。また、VTVMAINT を使用して VTV のストレージクラスを直接変更することはできませんが、VTVMAINT を使用して VTV のマネージメントクラスを変更して、異なるストレージクラスを参照することはできることにも注意してください。

- 実装するポリシーを定義するのに必要な最小限のストレージクラスを使用してください。過剰にストレージクラスを使用すると、MVC マウントおよびマウント解除のオーバーヘッドが発生して VSM のパフォーマンスに影響を与える可能性があります。また、MVC には 1 つのストレージクラスの VTV しか含まれないため、過剰なストレージクラスを使用すると MVC スペースが十分に使用されない可能性があります。

- マネージメントクラス定義を削除することにした場合、VTV Report を実行して、そのマネージメントクラスがどの VTV にも割り当てられていないことを確認してください。この処理を行わないと、予測できない結果を招くことになります。

マネージメントクラスおよびストレージクラスの管理に使用できる最先端技術

次に、マネージメントクラスとストレージクラスを使用して実行できるタスクのうち、もっとも一般的なものだけを説明します。

- MVC メディア優先の STORclas MEDIA パラメータの使用法。MVC メディアの優先順位にはデフォルトが用意されていますが、これらは必要に応じて調整できます。詳細は、『HSC および VTCS の管理』を参照してください。

- 「共有 MVC 上での複数の作業負荷のグループ化」。これは導入部の例でしたが、企業が独自のデータセンターを持ち、使用できるリソースの利用を次のようにして最適化する場合に適しています。

- ローカルおよびリモートの ACS にある個別の MVC に重要なデータを二重化します。ローカル ACS では、必要な場合はすぐに戻せるように 9840 メディアに配置します。リモート ACS では、大容量メディアでのストレージのために ZCART より 9940 メディアを優先します。

- 2 つの重要なジョブストリーム (給与と経理) にこれらマネージメント/ストレージクラスへのアクセスを与えます。結果: すべての給与および経理データは、ローカルとリモートで二重化され、ストレージクラスの仕様で説明した適切なメディアの MVC の同一セット上にグループ化されます。

- 本稼働データも重要であるが、給与と経理データとは別セットの MVC にすることが望ましい場合。問題ありません。本稼働データ用に別のマネージメントクラス/ストレージクラスの組み合わせを作成するだけで完了です。

- 「単一の作業負荷の別々の MVC のセットへの分散」。すべてのサービスグループにとって頻繁に使用するタスクとなるので丁寧に学習してください。請求やセキュリティーのために、それぞれのクライアントに独自のリソースセットを与えたいと考えたことはありますか。その場合は作業負荷の分散が重要です。

- 「データのアーカイブ」。このシナリオでは、StorageTek の自動テープ/仮想テープ環境のみで、VTCS を使用して HSM と同様の処理を実行できます。つまり、MGMTclas 文の ARCHAge および ARCHPol パラメータを使用すると、マネージメントクラスの VTV に対して Archive Policy を設定できます。
StorageTek のストレージ管理ストラテジーである Information Lifecycle Management (ILM) の主要概念は、データは企業内での重要性や再利用パターンに適合するメディアに保存するということです。つまり、アクティブで重要なデータは高速アクセスが可能なメディアに格納するとともに複数のコピーを作成し、非アクティブで重要性の低いデータは大容量の低価格メディアにアーカイブします。このプロセスの自動化は、データストレージを管理する上でもっともコスト効率に優れた方法です。アーカイブでは、ILM を使って非アクティブなデータをアーカイブできます。VTCS アーカイブを使えば、VTV を異なるメディア (たとえば、高速アクセス 9840 メディアから大容量 9940 メディア) や異なる位置 (たとえば、ローカル ACS からイジェクトやボールト用のリモート ACS) に移動できます。詳細については、「データのアーカイブ」を参照してください。

- 「VTV メディアと場所の再統合」。アーカイブをプロアクティブな移動として考えます。ILM サイクルでは、始めにデータを適切なメディアに配置します。そして、時間の経過に合わせてほかのメディアに移動します。それでは、データが間違ったメディアに配置された場合はどうなるでしょうか。回答: RECONcil ユーティリティーを使用して、別のストレージクラスに移動します。

- VTV 移行の管理。ELS では、VTV 移行を詳細に管理できます。管理作業には、VTSS バッファーからのスクラッチ VTV の削除、即時移行の遅延間隔の指定、最大 VTV 常駐間隔の指定などがあります。詳細は、『HSC および VTCS の構成』および『ELS 障害回復およびオフサイトデータ管理ガイド』を参照してください。

共有 MVC 上での複数の作業負荷のグループ化

ストレージおよびマネージメントクラスを使用して、複数の作業負荷を共有 MVC 上でグループ化できます。たとえば、次の STORclas 文は、ストレージクラス LOC1、LOC2、REM1、REM2 を定義します。

STORCLAS NAME(LOC1) ACS(00) MEDIA(STK1R)
STORCLAS NAME(LOC2) ACS(00) MEDIA(STK1R)
STORCLAS NAME(REM1) ACS(01) MEDIA(STK2P,ZCART)
STORCLAS NAME(REM2) ACS(01) MEDIA(STK2P,ZCART)

- マネージメントクラス PAY および ACCOUNT は、両方ともストレージクラス LOC1 および REM1 を MIGPOL パラメータ上で指定しています。したがって、PAY および ACCOUNT の VTV は、ストレージクラス LOC1 および REM1 で定義された MVC 上で二重化され、グループ化されます。

- マネージメントクラス PROD は、MIGPOL パラメータ上でストレージクラス LOC2 および REM2 を指定しています。したがって、PROD の VTV は、ストレージクラス LOC2 および REM2 で定義された MVC 上で二重化され、グループ化されます。これらは、PAY および ACCOUNT とは別のものです。

MGMT NAME(PAY) MIGPOL(LOC1,REM1)
MGMT NAME(ACCOUNT) MIGPOL(LOC1,REM1)
MGMT NAME(PROD) MIGPOL(LOC2,REM2)

次は、仮想メディアを指定して、それぞれにマネージメントクラスの PAY、ACCOUNT、および PROD を割り当てるテープポリシーを定義しています。

POLICY NAME (PPAY) MEDIA(VIRTUAL) MGMT(PAY)
POLICY NAME (PACCOUNT) MEDIA(VIRTUAL) MGMT(ACCOUNT)
POLICY NAME (PPROD) MEDIA(VIRTUAL) MGMT(PROD)

最後に、この例では、ポリシーを次のように割り当てる TAPEREQ 文を示しています。

- PAYROLL.** の修飾子を持つデータセットには、PPAY ポリシーが割り当てられます。

- ACCOUNTS.** の修飾子を持つデータセットには、PACCOUNT ポリシーが割り当てられます。

- そのほかのすべてのデータセットには、PPROD ポリシーが割り当てられます。

TAPEREQ DSN(PAYROLL.**) POLICY(PPAY)
TAPEREQ DSN(ACCOUNTS.**) POLICY(PACCOUNT)
TAPEREQ DSN(**) MEDIA(VIRTUAL) POLICY(PPROD)

一度 MVC がストレージクラスに使用されると、その MVC に現在の VTV のコピーがある間、MVC は対象のストレージクラスに排他的に割り当てられた状態になります。この MVC 上の VTV のグループ化は、MVC がリクレイム処理を受けたあともそのまま維持されます。

注意:
デフォルトのストレージクラス (リクレイムまたは移行で MVC に最後に書き込まれた VTSS の名前) を使用して、作業負荷をグループ化することはできません。

単一の作業負荷の別々の MVC のセットへの分散

ストレージおよびマネージメントクラスを使用して、単一の作業負荷を別々の MVC のセットに分散できます。たとえば、次の STORclas 文は、ストレージクラス LOC、CUSTA、CUSTB1、CUSTB2 を定義します。

STORCLAS NAME(LOC) ACS(00) MEDIA(STK1R)
STORCLAS NAME(CUSTA) ACS(00) MEDIA(STK1R)
STORCLAS NAME(CUSTB1) ACS(00) MEDIA(STK1R)
STORCLAS NAME(CUSTB2) ACS(01) MEDIA(STK2P)

次の例は、次のマネージメントクラスを定義します。

- マネージメントクラス CUSTA は、ストレージクラス CUSTA を MIGPOL パラメータ上で指定しています。この顧客の希望に合わせて、VTCS はこのマネージメントクラスの VTV を CUSTA ストレージクラス (ローカル ACS の 9840 メディア) のみに単一化します。

- 顧客 B は保護の強化、すなわちローカルおよびリモート ACS の二重化を望むため、マネージメントクラス CUSTB は CUSTB1 および CUSTB2 ストレージクラスの両方を指します。

- 最後に、本稼働データに対してはローカル ACS/9840 メディアだけでよいため、マネージメントクラス PROD はそのように定義します。ほかの作業としては、最終的にストレージに移動できるように、このマネージメントクラスのアーカイブポリシーを設定します (データのアーカイブを参照)。

MGMT NAME(CUSTA) MIGPOL(CUSTA)
MGMT NAME(CUSTB) MIGPOL(CUSTB1,CUSTB2)
MGMT NAME(PROD) MIGPOL(LOC)

この例は、仮想メディアを指定して、それぞれにマネージメントクラスの PAY、ACCOUNT、および PROD を割り当てるテープポリシーを定義しています。

POLICY NAME (PCUSTA) MEDIA(VIRTUAL) MGMT(CUSTA)
POLICY NAME (PCUSTB) MEDIA(VIRTUAL) MGMT(CUSTB)
POLICY NAME (PPROD) MEDIA(VIRTUAL) MGMT(PROD)

最後に、次の例は、対応する TAPEREQ 文とポリシーの割り当てを示しています。

- HLQ CUSTA が指定されたデータセットには、PCUSTA ポリシーが割り当てられます。

- HLQ CUSTB が指定されたデータセットには、PCUSTB ポリシーが割り当てられます。

- そのほかのすべてのデータセットには、PPROD ポリシーが割り当てられます。

TAPEREQ DSN(CUSTA.**) POLICY(PCUSTA)
TAPEREQ DSN(CUSTB.**) POLICY(PCUSTB)
TAPEREQ DSN(**) POLICY(PPROD)

注意:
デフォルトのストレージクラス (リクレイムまたは移行で MVC に最後に書き込まれた VTSS の名前) を使用して、作業負荷を分散させることはできません。

データのアーカイブ

MGMTclas 文の ARCHAge と ARCHPol パラメータを使って、マネージメントクラスの VTV にアーカイブポリシーを設定できます。VTV の古さが ARCHAge 値を超えている場合、VTV は ARCHPol パラメータで指定されているストレージクラスのアーカイブに適していることになります。実際のアーカイブは、次の 2 つの方法のいずれかになります。

- 次に VTV のリコールと再移行が実行されるときに自動的に行われる。

- ARCHIve ユーティリティーを使用したオンデマンド。

これに対する「what if」は、コンプライアンスを保証するためのものである可能性があります。外部監査のためにデータを 7 年間保持する必要があるが、社内監査では毎年 1 回見られる可能性があるとします。この場合のソリューションは次のようになります。

TAPEREQ DSN(COMPLY.**) POLICY(PCOMPLY)
POLICY NAME(PCOMPLY) MEDIA(VIRTUAL) MGMT(COMPLY)
MGMT NAME(COMPLY) IMMMED(DELETE) MIGPOL(LOC1) -
ARCHAGE(365) ARCHPOL(REMDEEP)
STOR NAME(LOC1) ACS(00) MEDIA(STK1R)
STOR NAME(REMDEEP) ACS(01) MEDIA(STK2P)

このシナリオでは、次のように処理されます。

- すべてのコンプライアンスデータは即座にローカル ACS に移行され、9840 メディア上でグループ化されます。移行が成功したら、VTV は VTSS から削除されます。社内監査で翌年このデータが参照されるケースを考えて、このデータの「アーカイブ期間」は 365 日になっています。

- その後、データは、リモート ACS の 9940 メディアへアーカイブ (移動) 可能になります。

結果: 仮想リソースを最適化しながら、最適なコストでのコンプライアンス。

アーカイブの使用上の注意

前述したように、実際のアーカイブを使用する場合、VTV がリコールおよび移行されるまで待つ方法と、ARCHIve ユーティリティーを使用してオンデマンドで実行する方法の 2 つがあります。再移行を待つことの問題は、これがアクセスされない可能性が高いデータであることです。おそらく、VTV をアーカイブする最善の方法は、ARCHIve ユーティリティーを定期的または必要に応じて実行することでしょう。

ARCHive ユーティリティーを使用するためのヒントを次に示します。

- アーカイブする VTV を選択するために、次のパラメータのいずれかを指定できます。

- MGMTclas。指定されたマネージメントクラスの ARCHAge/ARCHPol パラメータが指定するストレージクラスに VTV をアーカイブします。

- VTV。それらの VTV に対して、マネージメントクラスの VTV のリストまたは範囲をアーカイブします。

注記:
MGMTclas または VTV に値を指定しない場合は、すべての VTV がスキャンされます。マネージメントクラスを使うことが多くなるでしょうが、VTV volser またはすべての VTV を使う状況もあり得ます。

- MOVEVTV パラメータを指定しないと、アーカイブ要求で処理する VTV、MVC、および M バイト合計という貴重な「what if」の概要を示すレポートだけを取得できます。そのため、Oracle では、まず ARCHIve を MOVEVTV なしで実行してから、MOVEVTV を指定する前に、必要に応じてジョブを調整することを強くお勧めします。詳細については、ELS のコマンド、制御文、ユーティリティーに関するリファレンスを参照してください。

- デマンドアーカイブはリソースを大量に消費する可能性があるので、通常は処理のピーク時を避けて ARCHIve を実行します。また、ARCHIve ユーティリティーを使用して CONFIG RECLAIM THRESHLD、MAXMVC、および CONMVC 設定をオーバーライドして、アーカイブのパフォーマンスを最適化することもできます。さらに、ELAPSE パラメータでアーカイブの最大時間を分で指定することもできます。アーカイブに影響する制限要素は複数あるので注意してください (たとえば、MAXMVC および ELAPSE)。VTCS は、もっとも厳格な制限要素を実現します。たとえば、ARCHIve を実行して、ELAPSE を 5 時間、MAXMVC を 10 に指定し、かつ VTCS が 1 時間に 10 の MVC をアーカイブすると、ELAPSE 値の期限が終了する前にアーカイブが終了されます。

- POLICYdd パラメータを指定する場合を除き、ARCHIve 要求を処理するには、VTCS と HSC がアクティブである必要があります。POLICYdd (「レポートのみ」モードを強制します) も拡張された「what if」機能を提供します。異なるアーカイブポリシー (異なる ARCHAge および ARCHPol 値) を使用して代わりの MGMTclas 文を 1 つまたは複数作成し、POLICYdd を使用して、各シナリオでのアーカイブポリシーとリソースの使用を表示できます。

- RECONcil ユーティリティーは、ARCHive に類似しています。それは、RECONcil もストレージクラス間 (つまり、MVC メディア間や ACS 間) で VTV を移動するためです。ARCHive をプロアクティブ、RECONcil をリアクティブと見なすと違いがわかります (「VTV メディアと場所の再統合」を参照してください)。

365 日が経過して、社内監査が実施されず、アーカイブのタイミングになったとします。以下の例は、次のように ARCHive を実行するための JCL を示しています。

- マネージメントクラス COMPLY の VTV を、リモート ACS の 9940 メディアにアーカイブします。

- ARCHive ジョブに対して、MAXMVC を 60、CONMVC を 8、および ELAPSE を 60 にそれぞれ設定します。

//ARCHIVE     EXEC PGM=SLUADMIN
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR //SLSPRINTDD SYSOUT=*
//SLSINDD *
ARCH MGMT(COMPLY) MAXMVC(60) CONMVC(8) ELAPSE(360) MOVEVTV

ヒント: MOVEVTV パラメータもレポートを提供するので、処理結果を確認できます。調整したパラメータで必要な対象がアーカイブされなかった場合は、ジョブを調整して再実行します。

VTV メディアと場所の再統合

RECONcil を使用して VTV メディアと場所を再統合することは、基本的に VTV をストレージクラス間で移動することを意味します。これは、ARCHive を使用したデータのアーカイブと同じでしょうか。データの移動という観点からは、そのとおりです。この作業を実行する理由という観点からは、これはプロアクティブではなくリアクティブです。通常、VTV の再統合は次の場合に行ないます。

- VTV が間違ったメディア、間違った ACS、またはその両方にある場合。

- 利用できない状態が相当期間続いていた ACS がオンラインに戻った場合。この場合、まず、影響を受ける VTV の MGMTclas 文の MIGpol パラメータを変更して別の ACS (必要に応じてメディア) を指示します。元の ACS がオンラインに戻ったときに、MGMTclas 文の MIGpol パラメータを元の ACS を指示するように変更し、更新された MGMTclas (または STORclas) 文を指定している RECONcil を実行して VTV を元の ACS に移動します。

再統合処理の詳細については、「RECONcil の例」を参照してください。

RECONcil の例

間違ったメディア、間違った ACS に存在する VTV を再統合するとします。どうやってそのことに気づくでしょうか。それは、「HSC および VTCS の管理」に説明したように、VTV レポートを毎週検証するからです。今週、本稼働 (PROD) マネージメントクラスのすべての VTV が間違ったメディアおよび間違った ACS に存在することに気付きます。さらに、ストレージクラスも正しくないようです。

どうしてこのようなことが起きたのでしょうか。それは、次のことを行なったからだと思われます。

STORCLAS NAME(LOC) ACS(00) MEDIA(STK1R)
STORCLAS NAME(CUSTA) ACS(00) MEDIA(STK1R)
STORCLAS NAME(CUSTB1) ACS(00) MEDIA(STK1R)
STORCLAS NAME(CUSTB2) ACS(01) MEDIA(STK2P
MGMT NAME(CUSTA) MIGPOL(CUSTA)
MGMT NAME(CUSTB) MIGPOL(CUSTB1,CUSTB2)
MGMT NAME(PROD) MIGPOL(LOC)

この例によると、マネージメントクラス PROD 内にあるものはすべて、最終的にローカル ACS 内の 9840 メディアに配置されます。しかし、実際には、リモート ACS 内の 9940 メディアにすべてあります。まるで違ったストレージクラス内にあるようです。

よく調べてみると、本稼働のマネージメントクラスが実際には次のようになっています。

MGMT NAME(PROD) MIGPOL(CUSTA)

これは別の理由からも好ましくありません。それは、ある顧客専用に想定されているのと同じ MVC に本稼働データが共存しているからです。それでは RECONcil を実行すべきでしょうか。おそらくそうではありません。RECONcil は VTV を間違ったストレージクラスから移動するだけで、現時点では、マネージメントクラスの文の記述によると CUSTA が正しいストレージクラスになっています。RECONcil を実行する前に、このマネージメントクラスを次のように修正する必要があります。

MGMT NAME(PROD) MIGPOL(LOC)

これで、次のように RECONcil を実行できます。

- マネージメントクラス PROD の VTV を、ストレージクラス LOC 内の更新された正しい場所に移動します。

- RECONcil ジョブに対して、MAXMVC を 60、CONMVC を 8、および ELAPSE を 60 にそれぞれ設定します。

//RECONCIL    EXEC PGM=SLUADMIN
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINTDD SYSOUT=*
//SLSINDD *
RECON MGMT(PROD) MAXMVC(60)
CONMVC(8) ELAPSE(360) MOVEVTV

RECONcil の使用上の注意

再統合する VTV を選択するために、次のいずれかのパラメータを指定できます。

- MGMTclas。MIGpol パラメータで指定したストレージクラスへ VTV を移動します。これは「RECONcil の例」で行なった処理です。マネージメントクラスが間違ったストレージクラスを指しているので、正しいストレージクラスを指すようにしてから、更新されたマネージメントクラスに対して RECONcil を実行します。

- STORclas。指定されたストレージクラスへ VTV を移動します。これは、ACS が利用できない状態が相当期間続いた場合などに使用します。

- MVC。MVC のリストまたは範囲上の VTV を再統合します。VTV は、VTV に対する MGMTclas 文の MIGpol パラメータで指定したストレージクラスに移動します。まずこれを使用し、続いて VTV オプションを使用できます。

- VTV。VTV のリストまたは範囲を再統合します。VTV は、VTV に対するマネージメントクラスの MIGpol パラメータで指定したストレージクラスに移動します。

注記:

- MGMTclas または VTV に値を指定しない場合は、すべての VTV がスキャンされます。

- VTV の再統合は大量のリソースを消費する可能性があるので、通常は処理のピーク時を避けて RECONcil を実行します。また、RECONcil ユーティリティーを使用して、CONFIG RECLAIM THRESHLD、MAXMVC、CONMVC 設定をオーバーライドして、再統合のパフォーマンスを最適化することもできます。さらに、ELAPSE パラメータで再統合の最大時間を分で指定することもできます。
再統合に影響する制限要素は複数あるので注意してください (たとえば、MAXMVC および ELAPSE)。VTCS は、もっとも厳格な制限要素を実現します。たとえば、RECONcil を実行して、ELAPSE を 5 時間、MAXMVC を 10 に指定し、かつ VTCS が 1 時間に 10 の MVC を再統合すると、ELAPSE 値の期限が終了する前に再統合が終了されます。

- MOVEVTV パラメータを指定しないと、再統合要求で処理する VTV、MVC、および MB 合計という貴重な「what if」の概要を示すレポートだけを取得できます。そのため、Oracle では、まず RECONcil を MOVEVTV なしで実行してから、MOVEVTV を指定する前に、必要に応じてジョブを調整することを強くお勧めします。
詳細については、ELS のコマンド、制御文、ユーティリティーに関するリファレンスを参照してください。

- POLICYdd パラメータを指定する場合を除き、RECONcil 要求を処理するには、VTCS と HSC がアクティブである必要があります。POLICYdd (「レポートのみ」モードを強制します) も拡張された「what if」機能を提供します。異なる再統合シナリオ (異なる MIGpol 値) を使用して代わりの MGMTclas 文を 1 つまたは複数作成し、POLICYdd を使用して、各シナリオでの再統合された VTV とリソースの使用を表示できます。

- RECONcil 要求を処理するには、VTCS および HSC がアクティブでなければなりません。

Named MVC プールかそうでないか

Named MVC プールは、すべてのサービスグループのジョブに適したツールです。Named MVC プールを使用すると、Named プール内にある MVC の所有権をアプリケーションに割り当てることができます。たとえば、顧客が MVC のグループを購入および所有するために法的な要件を満たす必要があるサービスグループでは、Named MVC プールの使用を選択できます。

しかし、Named MVC に関する特定要件がなく、MVC 上のクライアントデータをグループ化または区分する場合は、Named MVC プールを使用しないことを強くお勧めします。この方法ではなく、次のセクションで説明する方法を使用してください。

- 共有 MVC 上での複数の作業負荷のグループ化

- 「単一の作業負荷の別々の MVC のセットへの分散」。

上記のセクションでは、ストレージクラスを使用して、システム全体の MVC プールから MVC を選択し、その MVC のデータをグループ化または分散させる方法について説明します。この場合、単一の MVC プールだけを管理する必要があります。

Named MVC プールを作成する場合には、各プールを明示的に管理しなければなりません。たとえば、各プールに十分な空き MVC と使用可能な MVC スペースが存在しなければなりません。また、MVCPool MVCFREE、MAXMVC、THRESH、および START パラメータを使用して、各プールに個別のポリシーを設定しなければならない場合もあります。

Named MVC プールを使用する場合は、「Named MVC プールの作成と使用」に進みます。

Named MVC プールの作成と使用

Named MVC プールを作成して使用するには、次を実行します。

1. 既存の POOLPARM 文を変更し、Named MVC プールを定義する文を追加します。
POOLPARM NAME パラメータを指定しないと、VTCS は指定されたサブプールを作成せずに、指定したボリュームをデフォルトのプール (DEFAULTPOOL) に割り当てます。名前に DEFAULTPOOL および ALL の予約語を含む MVC プールは作成できません。

オプションの MVCFREE、MAXMVC、THRESH、および START パラメータを使用して Named MVC プールの値を指定します。これは CONFIG で指定したグローバル値をオーバーライドします。

たとえば、次の VOLPARM および POOLPARM 文は、CONFIG グローバル値をオーバーライドするリクレイムパラメータ値を使用して、Named プール SYS1MVCT1 の暗号化される T10000 フル容量ボリュームの範囲を定義します。

VOLPARM VOLSER(T10K2000-T10K2999)MEDIA(T10000T1)RECTECH(T1AE)
POOLPARM NAME(SYS1MVCT1)TYPE(MVC)MVCFREE(40) MAXMVC(4) THRESH(60) START(70)

2. SET VOLPARM を実行して、ボリュームとプールの定義を適用します。

SET VOLPARM APPLY(YES)

3. ストレージクラスを定義して、Named MVC プールに関連付けます。

たとえば、次の STORclas 文では、STORCL1 を定義し、このストレージクラスを Named MVC プール CUST1POOL に関連付けています。ストレージクラス STORC1 に MVC の使用が要求されると、MVC は Named プール SYS1MVCT1 からのみ選択されるようになります。

STOR NAME(STORCL1) MEDIA(T!AE) MVCPOOL(SYS1MVCT1)

4. 手順 3 で定義したストレージクラスを指定するマネージメントクラスを作成し、データを Named MVC プールにルーティングするときに、これらのマネージメントクラスを指定します。
詳細については、「VTCS マネージメントおよびストレージクラスの作成と使用: 基本」を参照してください。

5. 次のいずれかで、VTCS にマネージメントクラスを指定します。

- SMC TAPEREQ 文。

- StorageTek DFSMS インタフェースに記述した SMS ルーチン。詳細は、『SMC の構成と管理』を参照してください。

7 VTCS の問題の検出と修正

このセクションでは、問題発生時の対処方法について説明します。「VTCS ダッシュボードの使用」で説明された日次処理や「バックアップコピーからの CDS の復元」の要求時タスクをすでに実行したものの、問題がまだ解決されません。ここで、問題が発生したときに VTCS の動作を正常に戻す方法を判断します。まず、「一般的な問題の修正」で簡単な問題から説明します。

一般的な問題の修正

ここでの「一般的」は、最善の努力をしたにもかかわらず正常に動作する見込みがない状態を意味します。多くの場合、問題を見つける方法は VTCS ダッシュボードを別の角度から見ることであり、修正内容は要求時タスクの中にあります。

VTV マウントのパフォーマンスの問題を検討する前に、ほとんどの場合ユーザーが自分で診断して修復できる一般的な問題があります。妥当な範囲で努力してもうまくいかない場合、カスタマサポートに電話をかけます。また、ここではトレースなどのツールについては説明していません。これらのツールは、基本的に Oracle サービスの指示に従って使用してください。

VTV マウントのパフォーマンスが悪い場合

VTV のマウントが非常に遅いか、まったく行われない場合、次の内容を確認してください。

- マウント障害が単一の VTD で発生している場合は、通常、VSM がリコールできない MVC 常駐 VTV のマウントをホストが要求していることが原因です。その場合は、次を行なってください。

- Display Queue DETail コマンドを入力して、待ち状態のリコールを調べます。MVC に対する待ち状態のリコールがある場合、その MVC はほかの VTCS プロセスによって使用されている可能性があります。これは、Display Active DETail コマンドで確認できます。

- その MVC が使用中でない場合は、次に HSC DISPLAY VOLUME コマンドを実行します。MVC が実際に ACS 内にあるかどうか確認します。存在しない場合は、リコールが行われるよう MVC を再度 ACS 内に投入する必要があります。

- 次に、VTV をリコールするために MVC をマウントすることができる RTD を確認します。Display RTD コマンドを入力して、RTD の使用可否を調べます。使用可能な RTD が 1 台もない場合は、すべてのホスト上で Display を使用して、アクティブなプロセスおよび待機中のプロセスを調べます。
必要な場合は、Cancel を使用して処理をキャンセルし、RTD を解放してリコールを完了させます。Cancel を使用すると、VTCS はシステムリソースや情報に影響しないように処理を終了するため、取り消し処理に時間がかかる場合があります。たとえば、VTCS は、ハードウェアのタイムアウト期間が経過するのを待ってから、特定の RTD を使用する処理を終了する場合があります。

注記:
親タスクを取り消した場合は、親と同時に子タスクもすべて停止されます。子タスクを取り消した場合は、親タスクの処理が続行されます。

注意:
移行スケジューラに関連するタスクを MIGrate パラメータまたは特定の処理 ID を使用してキャンセルした場合、そのタスクは終了しますが、移行スケジューラは次の時間間隔が経過した時点で別の移行タスクを開始します。ただし、限界値までの移行を使用して現在の DBU より大きい値を指定すれば、自動移行は停止できます。

ヒント:
MGMTclas 文の IMMEDmig パラメータを KEEP または DELETE に設定すると、移行処理 (移行での RTD の使用) が優先されるため、RTD に対する入出力が増加する場合があります。

CONFIG MAXMIG および MINMIG パラメータの設定を変更すると、それぞれの VTSS で定義した RTD について、自動移行タスクとほかのタスク (リコールやリクレイムなど) 間のバランスを取ることができます。

- マウント障害が複数の VTD で発生している場合は、次の点について調べます。

- Display VTD コマンドを使用して、VTD のステータスを調べます。

- Display Active を入力します。アクティブなプロセスがない場合は、VTCS、HSC、すべての VTSS、およびすべての通信が正常に動作していることを確認します。

- VTSS スペースが十分あることを確認します。

- システムの MVC に十分な使用可能スペースがあるかどうかを確認します。

- 下限 AMT を大きくすると、VTSS スペースに常駐する VTV の数が多くなります。これにより、仮想マウントの障害を防ぐことができます。

- VTV のマウントに障害が発生した場合には、VTD がオンラインであっても、MSP VARY コマンドを実行して、VTD をオフラインにし、MSP UNLOAD コマンドを実行して、VTD をクリアしてください。次に、HSC MOUNT および DISMOUNT コマンドを使用して、操作を再試行してください。

移行のパフォーマンスが悪い場合

VTV の移行処理が非常に遅い場合は、次の点を調べてください。

- Display MIGrate を開始します。これにより移行タスクの動作状態が表示されます。正常に動作するように設定を調整できます (たとえば、MAXMING/MINMIG 値を大きくします)。

- 使用する RTD および MVC が、「仮想テープのステータスの確認 (日次)」に示すような適切な状態になっていることを確認します。詳しく調査するには、Display Queue DETail を使用して待機中のプロセスのステータスも確認します。多くのプロセスが RTD について待機中で、RTD を MSP と共有している場合は、トランスポートを MSP に対してオフラインにし、VSM に対してオンラインに変更できます。

注記:
JES 環境では、適切なユーザー Exit 変更を作成してインストールしていない場合、VTV マウントが失敗します。

移行の障害

移行のパフォーマンスが悪いことよりも問題となるのは、移行がまったく行われないことです。次のセクションで説明するように、VTCS では移行の障害について詳細な情報を入手できます。

- メッセージの拡張

- Display STORCLas

- 拡張された MVC プールの検証

- 拡張されたストレージクラスの検証

メッセージの拡張

移行障害の詳細な情報を示すために、メッセージ SLS6700E は次の複数のメッセージに変更されました。

- SLS6853E 移行は失敗しました ストレージクラス:stor-clas-name ACS:acs-id VTSS:vtss-name - MVCPool poolname は定義されていません

- SLS6854E 移行は失敗しました ストレージクラス:stor-clas-name ACS:acs-id VTSS:vtss-name - 指定されたメディアに MVC が見つかりません

- SLS6855E 移行は失敗しました ストレージクラス:stor-clas-name ACS:acs-id VTSS:vtss-name - 指定されたメディア/SC/ACS に MVC が見つかりません

- SLS6856E 移行は失敗しました ストレージクラス:stor-clas-name ACS:acs-id VTSS:vtss-name - 指定されたメディア/SC/ACS に使用可能な MVC が見つかりません

- SLS6857E 移行は失敗しました ストレージクラス:stor-clas-name ACS:acs-id VTSS:vtss-name - 要求されたメディアおよび ACS に RTD がありません

- SLS6858E 移行は失敗しました ストレージクラス:stor-clas-name ACS:acs-id VTSS:vtss-name - 要求されたメディアおよび ACS のすべての RTD がオフラインです

- SLS6859E 移行は失敗しました ストレージクラス:stor-clas-name ACS:acs-id VTSS:vtss-name - 不明な理由 (X'xx')

また、ストレージクラスの詳細を示すために上のメッセージのいずれかが表示されたあと、常にメッセージ SLS6860I が出力されます。次に該当する場合、SLS6860I は移行の要件を満たすにあたって発生したエラーもレポートします。

- MVC プールが定義されていない場合。

- MVC プールに、指定したメディアが含まれていない場合。

- MVC プールに、指定したメディアの空き MVC が含まれていない場合。

- VTSS/ACS に、移行 MVC を書き込むために定義された適切な RTD がない場合。

- 適切な RTD がすべてオフラインの場合。

結果として、これまでよりも詳細な情報が入手可能となり、実際に移行障害が発生したときに推奨される修正情報がより詳しく、より的確になりました。

Display STORCLas

Display は、STORCLas パラメータによって拡張されます。出力内容は次のとおりです。

- ストレージクラスの特性 (ACS、MVC プール、およびメディア)。

- VTSS からストレージクラスへの移行を待機中の VTV。

- 移行に使用する MVC の要件。

- 移行 MVC への書き込みに必要な RTD のデバイスタイプ。

- 移行の要件を満たすにあたって発生したエラー。

繰り返しますが、VTCS では移行シナリオの重要な要素 (ストレージクラス) に関する情報が表示されます。

拡張された MVC プールの検証

MVC プールの検証は、一般的な設定エラーを検査するように拡張されました。

- 有効な MVC プールが少なくとも 1 つ定義されているかどうか。定義されていない場合は、メッセージ SLS6845E が発行されます。移行できないため、VTCS 機能が大きく低下します。このメッセージが表示された場合、適切な MVC プールを定義する必要があります。次の項目を参照してください。

- デフォルトの MVC プール (DEFAULTPOOL) が存在するかどうか。DEFAULTPOOL は、Named MVC プールを指定していないストレージクラスに移行したとき、およびストレージクラスの !ERROR が発生した状況で使用されます。DEFAULTPOOL が存在しない場合は、メッセージ SLS6846W が発行されます。
STORCLAS 文に MVCPool(pool-name) をコーディングすることによって、ストレージクラスへの移行で特定の MVC Pool を使用することを指定します。 MVCPool(pool-name) をコーディングしない場合、VTCS は STORCLAS を MVCPool(DEFAULTPOOL) がコーディングされたかのように処理します。

拡張されたストレージクラスの検証

ストレージクラスの検証も、一般的な設定エラーを検査するように拡張されました。

- Named MVC プールをストレージクラスで指定する場合 (STORCLAS NAME(stor-clas-name) MVCPOOL(poolname))、VTCS はその Named MVC プールが定義されていることを確認します。したがって、STORCLAS NAME(stor-clas-name) MVCPOOL(poolname) をコーディングする場合は、Named MVC プールが存在することが確認されます。定義されていない場合、VTCS はメッセージ SLS6848W を発行します。このメッセージが表示された場合は、Named MVC プールを定義するか、ストレージクラスの定義を変更するか、またはその両方を行います。

- 同様に、Named MVC プールをストレージクラスで指定しない場合 (STORCLAS NAME(stor-clas-name))、VTCS は DEFAULTPOOL が定義されていることを確認します。したがって、STORCLAS NAME(stor-clas-name) をコーディングする場合、Named MVC プールを作成しない MVCPOOL 文が少なくとも 1 つ存在することを確認します。定義されていない場合、VTCS はメッセージ SLS6846W を発行します。このメッセージが表示された場合は、Named MVC プールを作成しない MVCPOOL 文を少なくとも 1 つコーディングするか、ストレージクラスの定義を変更するか、またはその両方を行います。

- MVC メディアをストレージクラスで指定する場合 (STORCLAS NAME(stor-clas-name) MEDIA(media-type))、VTCS は MVC プールに media-type のメディアが含まれていることを確認します (Named MVC プールが指定されていない場合は、DEFAULTPOOL が使用されます)。存在しない場合、VTCS はメッセージ SLS6849W を発行します。対応するプールにメディアタイプが存在することを確認するか、ストレージクラスの定義を変更するか、またはその両方を行います。

- ACS とメディアタイプをストレージクラスで指定する場合 (STORCLAS NAME(stor-clas-name) ACS(acs-id) MEDIA(media-type))、VTCS は指定のメディアタイプと互換性のある、指定した ACS に RTD があることを確認します。存在しない場合、VTCS はメッセージ SLS6851W を発行します。指定した ACS に必要な RTD が存在することを確認するか、ストレージクラスの定義を変更するか、またはその両方を行います。

- 特定の ACS を指定せずにメディアタイプをストレージクラスで指定する場合 (STORCLAS NAME(stor-clas-name)MEDIA(media-type))、VTCS は指定したメディアタイプと互換性のある構成に RTD があることを確認します。存在しない場合、VTCS はメッセージ SLS6851W を発行します。構成に必要な RTD が存在することを確認するか、ストレージクラスの定義を変更するか、またはその両方を行います。

RTD/MVC の障害

最初は、メディアまたはドライブの障害に気付いていない場合もあるでしょう。VTCS は MVC 上で読み取り/書き込みエラーを検出すると、その MVC を別の RTD へスワップします。MVC で読み取り/書き込みエラーが検出されなければ、最初の RTD にエラーがあるとみなされます。

メッセージ SLS6662A は、RTD が「保守モード」になっていることを示しており、このステータスは Display RTD の出力でも報告されます。通常、保守モードの RTD は、エラー状態になっているため、ハードウェアの操作またはサービス担当者による援助が必要です。回復モードの RTD は初期設定の最中なので (たとえば、オンラインにする際には) 注意してください。通常、回復モードの RTD は、エラー状態ではありません。

障害が発生している RTD をすぐに修理できない場合、または障害が発生している RTD がリモートの ACS に接続されている場合は、その RTD を構成から除去して、その RTD の割り振りが試行されないようにすることをお勧めしています。RTD の RTD 文を削除し、CONFIG を再実行します。

注意:
二重 ACS 構成 (1 つの VTSS に 2 つの ACS が接続されている構成) の場合は、どちらか片方の ACS 内のすべての RTD を、VTSS に対して長時間にわたり使用不可能な状態にしておかないでください。その ACS 内に使用可能な RTD がない場合は、その ACS への移行およびその ACS からのリコールを行えないため、VTSS スペースがいっぱいになる可能性があります。なお、この状態になると、ほかの ACS 内の RTD への移行も停止する可能性があります。

したがって、二重 ACS 構成において、片方の ACS 内のすべての RTD を長時間にわたって使用不可能にする必要がある場合は、前述の方法で、構成からそれらの RTD を除去してください。

不良な MVC の確認

上述の RTD に関するチェックリストをひととおり確認しても問題がない場合、また MVC スペースを増やしたり、MVC サマリーレポートと HSC ボリュームレポートの VOLSER を比較したりするなどできることはすべて行なった場合、MVC は実際に ACS 内にあります。そこにもない場合は、HSC ボリュームレポートにリストされていない MVC を再度投入するか、または取り替えます。

このような場合は、メディアに問題がある可能性があります。「仮想テープのステータスの確認 (日次)」で説明した MVC レポートと VTV レポートを使用すると、メディアの問題の種類を確認できます。そのセクションで、もっとも簡単な MVC 異常に対する修正はすでに説明しました。次に、MVC レポートと VTV レポートで表示される MVC の異常ステータスのすべてのリストと、その対処方法について説明します。

BROKEN

これは MVC、ドライブ、またはその組み合わせに問題があることを示す一般的なエラーステータスです。VTCS はこの状態の MVC を優先しません。一般的に、このステータスをクリアするには、次のようにします。

MVC が問題の原因である場合は、DRAIN(EJECT) コマンドを使用してサービスから MVC を除去してください。

RTD が問題の原因である場合は、MVCMAINT ユーティリティーを使用して MVC ステータスをリセットします。

BROKEN ステータスで注意が必要なのは、SLS6686、SLS6687、SLS6688、SLS6690 のメッセージが 1 つ以上発行されている場合です。これらのメッセージの詳細な回復手順については、『VTCS メッセージおよびコード』を参照してください。

DATA CHECK

データチェック状態がこの MVC に対して報告されています。VTCS はこの状態の MVC を優先しません。このステータスをクリアするには、次のようにします。

MVC 上のすべての VTV が二重化されている場合、イジェクトオプションなしで MVC の MVCDRain を使用します。これによりすべての VTV が回復され、サービスから MVC が除去されます。

MVC 上に二重化されていない VTV が存在する場合、MVC に対して VTCS AUDIT を行います。AUDIT は失敗します。AUDIT の終了後、イジェクトなしで MVCDRAIN を行います。これによりデータチェック域の前の VTV はブロック ID の昇順にリコールされ、データチェック域のあとの VTV はブロック ID の降順にリコールされます。この流れで VTV を処理することで、メディアからできるだけ多くの VTV を回復します。MVC 上に残っている VTV については、データを再生成する必要があります。

データチェックをクリアしたあとは、「MVC の永続的除去」の説明のように、データチェックエラーのある MVC を除去および交換します。この手順では、VTCS から MVC を除去して、Nearline に戻す方法についても説明しています。

DRAINING

MVC はドレイン中か、または MVCDRain に失敗しました。

IN ERROR

MVC がマウントされている間にエラーが起こりました。

INITIALIZED

この MVC は初期化されています。

LOST - FAILED TO MOUNT

VTCS は MVC のマウントを試行しましたが、15 分のタイムアウト時間内にマウントが完了しませんでした。VTCS は、ハードウェア障害、HSC 障害、または MVC が ACS から除去されたことによって発生する本状況からの回復を試みています。VTCS はこの状態の MVC を優先しません。

LOST(ON) ステータスにある MVC の後続マウントを正常に実行した場合、VTCS はステータスを LOST(OFF) に設定します。

エラーの原因を特定し、解決してください。次の場合については、VTCS の MVCMAINT ユーティリティーを使用して LOST(OFF) に設定することもできます。

LOST(ON) ステータスがすでに解決済みの LSM 障害またはドライブエラーによって設定されていた場合。

LOST(ON) ステータスが、MVC が ACS 外にあったために設定され、その MVC がすでに再入力済みの場合。

MARKED FULL

MVC は空き容量がなく、将来の移行候補になりません。

MOUNTED

MVC は RTD 上にマウントされています。

NOT-INITIALIZED

MVC は CONFIG ユーティリティーを使用して定義されていますが、今まで使用されたことはありません。

READ ONLY

MVC は次の要件のいずれかにより読み取り専用とマークされています。

- MVC は現在処理中のエクスポートまたは統合処理の対象です。読み取り専用状態により MVC は更新処理に対して保護されています。

- MVC メディアにファイル保護が設定されます。エラーを修正し、MVCMAINT ユーティリティーを使用して READONLY(OFF) を設定します。

- VTCS が MVC の更新を可能とする適切な SAF ルールが MVC には設定されていません。エラーを修正し (詳細は、『ELS のインストール』の「HSC と SMC、VTCS のセキュリティーシステムのユーザー ID の定義」を参照)、MVCMAINT ユーティリティーを使用して READONLY(OFF) を設定します。

BEING AUDITED

MVC は現在 AUDIT されているかまたは失敗した AUDIT の対象です。AUDIT が失敗した場合は、VTCS はこの MVC を移行に使用しません。この状態をクリアするためには、この MVC に対して AUDIT ユーティリティーを再実行します。

LOGICALLY EJECTED

MVC は MVCDRain Eject の対象であるかまたは MVC は RACROUTE の呼び出しによる更新のためにイジェクトされました。移行またはリコールにこの MVC は再使用されません。この状態をクリアするためには、MVC に対して Eject オプションなしで MVCDRain を使用します。

RETIRED

耐用期限切れステータス。VTCS は MVC からリコールしますが、MVC に移行しません。早急に MVC を置換してください。

WARRANTY HAS EXPIRED

MVC 保障期限切れステータス。VTCS は MVC の使用を継続します。MVC が耐用期限切れステータスになった時点で置換ができるように計画してください。

INVALID MIR

VTCS が 9x40 メディアの MIR (メディア情報レコード) が無効であることを示すステータスを RTD から受信しました。MIR が無効であることによってデータへのアクセスが妨げられることはありませんが、テープ上のレコードへのアクセス時に重大なパフォーマンス上の問題を発生させる可能性があります。有効な MIR エントリを持たないテープ上のエリアに対しては、MVC の高速検索ができなくなります。

VTCS はこの状態の MVC を優先しません。リコール時において、VTV が複数の MVC 上に存在する場合、VTCS は、無効な MIR を持つ MVC よりも有効な MIR を持つ MVC を優先的に選択します。VTCS は、移行がテープ先頭から開始される場合を除き、無効な MIR を持つ MVC を移行に使用しません。テープ先頭から移行した場合、MIR は修正されます。

VTCS は、無効 MIR 条件をマウントまたはマウント解除時に検出します。無効 MIR 条件がマウント時に検出され、別の MVC を使用して操作を完了可能な場合、VTCS は最初の MVC をマウント解除し、代替 MVC を選択します。VTCS による代替 MVC への切り替え機能は限定されたものであることについて注意が必要です。つまり、代替 MVC への切り替え機能が使用されるのは、主に移行および仮想マウント時です。

無効な MIR を持つ MVC については、エラーの原因 - メディアまたはドライブの障害によって発生している可能性があります - を特定し、解決してください。

MIR が無効な MVC を回復するには、INVENTRY ユーティリティーを実行します。たとえば、MVC707 を回復するには、次を入力します。

INVENTRY MVCID(MVC707)

データチェックによる MVC の回復

これは、「不良な MVC」の問題に関する特殊なケースで、MVC レポートと VTV レポートで MVC データチェックエラーが表示されたときに必要となります。

データチェックの発生した MVC を回復するには、次の手順に従います。

1. MVC に対して MVC AUDIT を実行します。
AUDIT は、MVC から VTV メタデータをシーケンシャルに読み取ろうとします。AUDIT はデータチェックが発生すると失敗し、MVC は AUDIT 中の状態のままになります。これにより、VTCS はこの MVC を出力に選択できなくなります。

2. MVC に対して MVCDRain Eject コマンドを実行します。
これにより、利用できるすべての VTV がリコールされ、新しいエラーのない MVC に再移行されます。これで、論理的に MVC が MVC プールから除去されます。

注記:

- MVC のエラーステータスのために、VTCS は必要に応じて代替 MVC から VTV をリコールします。

- エラーになっている MVC から VTV をリコールする必要がある場合 (他にコピーがない場合)、次のようになります。
データチェック域の前にある VTV は、ブロック ID の昇順にリコールされます。

データチェック域の後にある VTV は、ブロック ID の降順にリコールされます。

3. MVC から回復できなかった VTV があるか確認します。
MVC に対して MVC 詳細レポートを実行します。まだ MVC 上にあると報告された VTV がある場合、これらの VTV は回復できません。データを回復するには、別の方法を使う必要があります。

4. 次のいずれかを行い、障害のある MVC を管理します。
障害のある MVC を内部および外部ラベルが同じである初期化されたテープボリュームと交換します。

1. 障害のある MVC に対して HSC EJECT コマンドを入力します。

2. 代替 MVC に対して HSC ENTER コマンドを入力します。

3. 必要に応じて、テープを初期化します。

4. 新しい MVC に対して HSC AUDIT を入力します。

5. MVCDRAIN (EJECT なし) を実行して、MVC を MVC プールに戻します。

システムから MVC を除去します。

1. 障害のある MVC に対して HSC EJECT コマンドを入力します。

2. MVC プール定義を編集して、障害のある MVC をプールから削除します。

3. すべてのアクティブなホストで VT MVCDEF を入力して、新しい MVC プール定義を有効化します。

RTV ユーティリティーの使用法

RTV ユーティリティーは、通常 Oracle サービスからの指示を受けて使用するツールです。これは RTV が、VTCS を利用せずに VTV データを直接 MVC から読み取るように設計されているためです。たとえば、実際に CDS が失われた場合などに使用されます。

RTV はスタンドアロンユーティリティーで、MVC から VTV を読み取って圧縮解除し、単一の出力テープ (実テープボリューム) へ書き込みます。これにより、ユーザーアプリケーションがデータを読み取れるようになります。RTV ユーティリティーはスタンドアロンのユーティリティーなので、VSM がダウンしていても MSP システムが稼働していれば、RTV を実行できます。

RTV ユーティリティーで回復できる VTV

RTV ユーティリティーによって回復できる VTV を次に示します。

- 指定した MVC のすべての VTV または指定した VTV。MVC にある最新バージョンの VTV の位置が不明な場合には、VTV volser だけを指定してください。RTV は、この MVC で検出した VTV の中で最新バージョンの VTV を変換します。

- 指定した MVC の指定したブロック ID の位置にある VTV。LISTONLY パラメータ指定によりリストに含まれるブロック ID の値は、RTV ユーティリティーを使用して VTV を Nearline ボリュームに変換する場合の入力として使用できます。volser とブロック ID を指定すると、位置を特定する時間を短縮できます。

- 指定した MVC の論理データセットによって指定された VTV。volser と論理データセット番号を指定すると、volser とブロック ID を指定した場合よりも、位置の特定に時間がかかります。単一 VTV にアクセスする場合には、volser とブロック ID を使用するようにしてください。

注記:
複数の VTV を指定した場合、またはブロック ID または FILEnum パラメータのいずれも指定しない場合は、MVC 全体が読み取られ、MVC の内容が出力されます。VTV の最新のコピーだけが圧縮解除されるようにするには、MVC 全体を読み取る必要があります。

一般的な使用法のガイドライン

- 変換された VTV を含む出力ボリュームは、個々の VTV を格納できるように、VTV の最大サイズ以上の容量 (400M バイト、800M バイト、2G バイト、または 4G バイト) が必要です。

- VTCS の MVC および VTV レポートでは、RTV で回復する VTV のコピーを指定するための情報を取得できます。RTV ユーティリティーを実行する前に、このレポートの最新のコピーを作成してください。また、変換する VTV を特定するために、LISTONLY パラメータを使用すると、MVC 上にある VTV のリストを作成できます。
VTV のコピーが同じまたは別の MCV に複数存在する場合には、VTV および MVC レポートと LISTONLY の出力をよく調べて、VTV の最新のコピーを変換するのに正しい MVC を使用しているかどうか確認してください。

- RTV ユーティリティーは、変換されたボリュームについての情報でシステムカタログ、または TMC を更新しないため、手動でこれを行う必要があります。

セキュリティーに関する注意事項

- 変換する VTV と VTV を格納する MVC に対する読み取りアクセス権がないと、システムのセキュリティーアプリケーションが実行できません。アクセス権がないと、変換は失敗します。

- RTV ユーティリティーのロードライブラリが APF 許可されているかどうか確認してください。

- RTV は、TMS 保護をバイパスしません。すべての RTV テープマウントは、TMS に制御されます。

注記:
RTV ユーティリティーは、出力デバイスのテープ標準ラベルを書き換え、入力デバイスにラベル情報を記録する必要があるため、動的割り振りを行なってテープボリュームに対するラベル処理のバイパス機能 (BLP) を呼び出します。この操作を行うには、SWSRTV 実行可能コードを含むライブラリが APF 許可されていなければなりません。

JCL の例

次に、RTV ユーティリティーを使用する JCL の例を示します。

MVC 上の VTV のリスト

次に、MVC MVC001 上の VTV をリストする JCL の例を示します。

//JOBVRECJOB(account),programmer
//RUNRTV EXEC PGM=SWSRTV,PARM=’MIXED’
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINTDD SYSOUT=A
//SLSINDD *
RTV  MVC(MVC001)INUNIT(/1AB4) LISTONLY
/*
//

volser の指定による単一 VTV の変換

次に、RTV ユーティリティーで、MVC MVC001 上の VTV VTV200 を変換する JCL の例を示します。これは 3490E トランスポートにマウントされます。出力 (変換後の VTV VTV200) は、トランスポート 280 にマウントされた出力ボリュームに作成されます。RTV は、VTV の VTV VOLID を出力ボリュームにコピーします。

//JOBVRECJOB(account),programmer
//RUNRTV EXEC PGM=SWSRTV,PARM=’MIXED’
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINTDD SYSOUT=A
//SLSINDD *
RTV  MVC(MVC001) INUNIT(3490E) VTV(VTV200) CPYVOLID OUTUNIT(280)
/*
//

VOLSER とブロック ID の指定による単一 VTV の変換

次に、RTV ユーティリティーで、MVC MVC001 のブロック ID x'8EA484AB' にある VTV VTV200 を変換する JCL の例を示します。これは 3490E トランスポートにマウントされます。出力 (変換後の VTV VTV200) はトランスポート 480 にマウントされた出力ボリュームに作成されます。

//JOBVRECJOB(account),programmer
//RUNRTV EXEC PGM=SWSRTV,PARM=’MIXED’
//STEPLIBDD DSN=hlq.SEALINK,DISP=SHR
//SLSPRINTDD SYSOUT=A
//SLSINDD *
RTV  MVC(MVC001) INUNIT(3490E) VTV(VTV200) BLOCK(8EA484AB) OUTUNIT(480)
/*
//

索引
A  B  C  D  L  M  O  R  S  V  カ  ス  ダ  デ  バ  ホ  ユ  ラ  レ  移  一  回  割  診  制  通  履

A

ABEND ダンプ, 1.1

AUDIT, 5.5.3, 6.4.3

B

BACKup ユーティリティー

機能, 2.1.2

説明, 2.1.2

C

CAP での RECOVERY ステータス

クリア, 3.5.3

CAP の RECOVERY ステータスをクリアする方法, 3.5.3 CDS Disable コマンド, 2.5, 2.6.1 CDS のコピー (名前の変更), 2.6 CDS のスワップ, 2.8 CDS の移動 (名前の変更), 2.6 CDS の再配置, 2.6.1 COMMPath コマンドと制御文

使用法, 3.5.5

D

DISPLAY コマンド, 3.5.8

L

LSM へのカートリッジの挿入

ラベルがないか、または読み取れないラベルがある, 3.5.2.2

重複/読み取り不能 VOLSER, 3.5.2.1

M

MVC

スペースリクレイム

強制, 5.1

MVC プール

VT Display コマンド, 4.2.1, 4.2.1

O

ORH (遅延応答ハンドラ)

マウント、マウント解除、移動、およびスワップの各要求に必要なオペレータ応答, 3.5.7.2

概要, 3.5.7.1

R

RESTore ユーティリティー

実行する理由, 2.9.1

RTV ユーティリティー, 7.2

S

SET コマンド

SET SLIDRIVS

手順, 3.1.4, 5.5.4

V

VSM

VTV リコール

強制, 5.1.3

VTV 移行

強制, 5.1.2

管理

VTSS, 4.3

一般的な問題の解決, 7.1

強制移行、強制リコールおよび強制リクレイム, 5.1

VTCS

VTV 移行

強制, 5.1.2

ユーティリティー

AUDIT, 5.5.3, 6.4.3

RTV, 7.2

回復, 7.2

VTD

VT Display コマンド, 4.1.1

VTSS

管理, 4.3

VTV

マウントパフォーマンスが悪い場合, 7.1.1

リコール

強制, 5.1

移行

パフォーマンスが悪い場合, 7.1.2

移行のパフォーマンスが悪い場合, 7.1.2 強制移行, 5.1

カ

カートリッジ

LSM への入力

ラベルがないか、または読み取れないラベルがある, 3.5.2.2

重複 VOLSER, 3.5.2.1

カートリッジアクセスポート (CAP)

Display Cap コマンド時に RECOVERY ステータスをクリアする, 3.5.3

ス

スクラッチ

ボリューム

ACS での不足, 1.1

スクラッチサブプール

VT Display コマンド, 4.1.1

スペースリクレイム

強制, 5.1

ダ

ダンプ

プログラム, 3.5.8

デ

データベースハートビート (DHB) レコード

CDS Enable/Disable を使用した CDS の再割り当て, 2.5, 2.6.1

バ

バックアップ

CDS, 2.1.2

ホ

ホスト

ホスト間通信の復元, 3.5.5

ホストソフトウェアコンポーネント (HSC)

ホスト間通信の復元, 3.5.5

診断コマンド

Display, 3.5.8

ホスト間通信サービスの復元, 3.5.5

ユ

ユーティリティー

BACKup, 2.1.2

ラ

ライブラリストレージモジュール (LSM)

ラベルがないか、または読み取れないカートリッジの挿入, 3.5.2.2

重複 VOLSER の入力, 3.5.2.1

ラベル

ラベルがないか、または読み取れないカートリッジの挿入, 3.5.2.2

ラベルがないか、または読み取れないラベル, 3.5.2.2

レ

レポート

BACKup ユーティリティー, 2.1.2

移

移行

強制, 5.1

一

一般的な問題の解決, 7.1

回

回復

Display Cap コマンド時に RECOVERY ステータスをクリアする, 3.5.3

ホスト間通信の復元, 3.5.5

割り振り済み CAP の解放, 3.5.4

回復ユーティリティー, 7.2

割

割り振り済み CAP の解放, 3.5.4

診

診断

プログラムダンプ, 3.5.8

制

制御データセット (CDS)

スワップ, 2.8

名前の変更手順, 2.6

制御データセットの名前の変更, 2.6

通

通信

復元, 3.5.5

履

履歴

イベント (GTF トレース), 1.1

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。