「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 つの作業について説明します。
これらのタスクはオプションですが、特に強制スペースリクレイムは、強く推奨されるベストプラクティスです (理由はあとで説明します)。
すでに説明しているように、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 がアクティブでなければなりません。
すでに説明したように、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 の値を低くし、強制移行を効果的に発生させることもできます。
VTCS は、ジョブがテープに移行された (VTSS 常駐でない) VTV 上のデータセットを要求したときに、自動リコール処理を開始します。上の状況の逆の場合はどうなるでしょうか。たとえば、年末の処理を実行していて、テープ上にしかない VTV からデータを読み取るジョブがあることに気付いたとします。この場合の解決策は強制リコールです。
RECALL では、必要な操作を高い柔軟性で実行できます。
MIGRATE と同様に、VTV は VOLSER、マネージメントクラス、または関連するデータセット名からリコールできます。
VTV をリコールする VTSS を指定できます。指定しない場合は、デフォルトで作成元の VTSS にリコールされます。VTSS のリコールポリシーには関連する考慮事項があります。詳細は、『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください。
RECALWER により、読み取りデータチェック発生時に VTV をリコールするかどうかを指定できます。
NOWAIT オプションは処理を高速化します。
「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 デバイスタイプを変更するには、すべてのホスト上の VTCS を停止する必要がありますので注意してください。
RTD デバイスタイプを変更する際は、次の手順を使用します。
VSM ポリシーを再検討します。
たとえば、この RTD デバイスタイプが移行に使用されている場合、マネージメントクラスとストレージクラスの定義を調べると良いでしょう。
古い RTD を VTCS に対してオフラインにします。
新しい RTD デバイスが新しい MVS デバイスアドレスを使用している場合、次を実行します。
MVS に新しいアドレスを定義します。
DECOMP を実行して、CONFIG 文を出力します。
CONFIG 文を編集して、RTD アドレスを新しい値に変更します。
CONFIG RESET を実行します。
注意:
新しいトランスポートを MVS に対してオンラインにしないでください。そうしないと、Nearline トランスポートとして割り当てられてしまいます。新しい RTD をインストールします。
トランスポートが置き換えられた LSM をオフラインステータスにします。
トランスポートが置き換えられた LSM をオンラインステータスにします。
新しい RTD を VTCS に対してオンラインにします。
必要に応じて、MVC を追加します。
詳細については、「MVC の追加」を参照してください。
すでに説明したように、仮想エンティティーの 1 つだけに説明を制限することは困難です。MVC には VTV が含まれます。結局はもう一方についても言及せざるをえないため、一方だけを分離して説明することは困難です。また、VTV について言及するときは、VTSS および VTD についても述べていることになります。
したがって次のセクションでは、さまざまな理由で実行される一般的な「要求時」タスクを、MVC を使用して実行する基本的な手順を説明します。たとえば、MVC を追加するのは、以前のシナリオで説明したようにスペースを使い果たしそうな場合や、予防的な保守や問題発生を回避するためです。
注記:
SET VOLPARM または CONFIG MVCVOL 処理の結果として MVC が構成から削除される場合:volser を VTV として構成に再度挿入することはできません。
volsers をネイティブ HSC テープに使用しないでください。
メッセージ SLS6944I は、削除された MVC の数を示します。
ELS 7.2 では、ボリュームの追加が非常に簡単になりました。HSC VOLPARM および POOLPARM 文を使用して、すべてのボリュームとそのプール (ネイティブ Nearline ボリューム、クリーニングカートリッジ、MVC、および VTV) を定義し、HSC SET VOLPARM ユーティリティーを使用してそれらをロードします。詳細は、『HSC および VTCS の構成』および『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください。
MVCS を追加するには、次の手順に従います。
MVC を定義する VOLPARM 文を作成します。
たとえば、暗号化される T10000 フル容量ボリュームの範囲を定義する場合は、次のように指定します。
VOLPARM VOLSER(T10K2000-T10K2999)MEDIA(T10000T1)RECTECH(T1AE)
MVC プールを定義する POOLPARM 文を作成します。
たとえば、リクレイムパラメータを指定する T10000 MVC プールを定義する場合は、次のように指定します。
POOLPARM NAME(SYS1MVCT1)TYPE(MVC)MVCFREE(40) MAXMVC(4) THRESH(60) START(70)
必要に応じて、MGMTCLAS または STORCLAS 文を作成または更新します。
たとえば、新しい MVC メディアタイプを追加した場合は、『HSC および VTCS の構成』の推奨手順に従います。
必要に応じて、POLICY または TAPEREQ 出力パラメータを更新します。
たとえば、手順 3 で新しいマネージメントクラスを作成した場合は、TAPEREQ または POLICY 文を、新しいマネージメントクラスを指すように更新または作成します。
必要に応じて、VTV を定義します。
定義が必要な場合は、「VTV の定義」に進みます。それ以外の場合は、「ボリューム定義の検証と適用」に進みます。
VTV を定義するには、次の手順に従います。
VTV を定義する POOLPARM または VOLPARM 文を作成します。
たとえば、ホスト MVS1 と MVS2 で使用する 2 つの VTV の範囲を定義する場合は、次のようになります。
POOLPARM NAME(SYS1VTV1)TYPE(SCRATCH) VOLPARM VOLSER(V5000-V5499)MEDIA(VIRTUAL) POOLPARM NAME(SYS1VTV2)TYPE(SCRATCH) VOLPARM VOLSER(V5500-V5999)MEDIA(VIRTUAL)
「ボリューム定義の検証と適用」に移動します。
MVC をプールから除去する場合は、どのような理由があるでしょうか。一般的なシナリオでは RTD の古いドライブを技術的に新しいドライブに入れ替えたり、古いメディアの使用を停止したりする場合などがあります。いずれの場合も、プールに新しい MVC を追加 (MVC の追加) し、古いメディアを除去 (「MVC の永続的除去」) します。
MVC を一時的にプールから除去する場合もあります。たとえば、不良なメディアや不良の疑いのあるメディアを入手した場合です。このような場合は、不良メディアを取り外して、別のメディアに交換します。基本的に、同じ VOLSER で交換します (「MVC の一時的除去」)。
MVC をプールから永久に除去するには、次を行います。
MVCDRain を入力して、MVC をドレインします。
たとえば、MVCDRain を実行して、ストレージクラス STORCL1 で MVC をドレインし、実際には MVC をイジェクトして要求の送信後に制御を戻すには、次を入力します。
MVCDRAIN STORCLAS(STORCL1) EJECT NOWAIT
MVC が ACS 内で必要なくなった場合、HSC Eject コマンドを使用して、ACS から MVC をイジェクトします。
その MVC に対して定義した、セキュリティーの制限事項とテープ管理システムの制限事項を除去します。
VOLPARM および POOLPARM 定義を使用していて、仮想 CDS レベルが G 以上の場合は、手順 4 に進みます。それ以外の場合は、手順 5 に進みます。
Nearline (非 VTCS) の使用に対してテープ volser を再利用し、VOLPARM/POOLPARM 定義を使用する場合:
除去する MVC を対象とする POOLPARM/VOLPARM 文を更新します。
すべてのホストで SET VOLPARM APPLY(YES) を実行して変更を適用します。
HSC SCRAtch コマンドを実行して、MVC でなくなったボリュームをスクラッチします。
Nearline (非 VTCS) の使用に対してテープ volser を再利用し、VOLPARM および POOLPARM を使用しない場合は、次のいずれかを実行します。
HSC EJECT コマンドを発行して、MVC を ACS から除去します。
カートリッジに付いている外部バーコードラベルを変更します。
元の MVC volser が CDS 内に記憶されており、これらの volser は MVC としてしか使用できないため、外部バーコードラベルを変える必要があります。
カートリッジを再度 ACS に挿入します。
または
新しい CDS データセットを作成します。
DELVirt を指定する HSC MERGECDS ユーティリティーを実行して、不要な MVC の範囲を除去します。
注記:
新しい CDS データセットが作成されるため、このオプションを使用する場合はすべての HSC を停止する必要があります。MVC をプールから一時的に除去するには、次の手順に従います。
MVC に対して MVCDRain Eject コマンドを入力します。
たとえば、MVCDRain を実行して、ストレージクラス STORCL1 で MVC をドレインし、実際には MVC をイジェクトして要求の送信後に制御を戻すには、次を入力します。
MVCDRAIN STORCLAS(STORCL1) EJECT NOWAIT
これにより、次が行われます。
MVC 上のすべての VTV をリコールし、新しい MVC に再移行します。
MVC を VTCS の移行に選択できないようにします。
MVC を MVC プールに戻すには、MVC に対して MVCDRain コマンドを入力します。
MVC に EJect パラメータを指定せずに MVCDRain コマンドを入力すると、再度それが使用できるようになります。
たとえば、MVCDRain を実行して、ストレージクラス STORCL1 で MVC をドレインし、要求の送信後に制御を戻すには、次を入力します。
MVCDRAIN STORCLAS(STORCL1) NOWAIT
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 も同様に 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 として認識しない。これは MVS ジョブが 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 レポートも生成されます。MEDVERfy ユーティリティーは、MVC または VMVC (ELS 7.1 および VLE 1.2 以上のみ) で VTV データを読み取れることを検証することで、メディア検証 (MV) を実行します。VLE では MEDVERfy により、複製解除された VMVC を「元に戻す」(再構築する) ことができることを確認します。
このユーティリティーは MVC に関する検証の合格または不合格をレポートし、XML 出力も生成します。MEDVERfy ユーティリティーの詳細は、『ELS コマンド、制御文、およびユーティリティーリファレンス』を参照してください。
次のセクションでは、MV に対して MEDVERfy ユーティリティーを使用する例を示します。
MEDVERFY MVC(VMC000)
この例では:
MEDVERfy は、単一の VMVC を選択します。
MAXMVC のデフォルトは 99 に設定されます。
CONMVC のデフォルトは 1 に設定されるため、1 回につき 1 つの MVC のみ処理されます。
タイムアウトは指定されていません。
MEDVER MVCPOOL(MP1)
この例では:
MEDVERfy は、処理のため、MVC プール MP1 内の MVC を選択します。
FREQency は指定されず、MAXMVC のデフォルトは 99 に設定されるため、MEDVERfy は最後の検証の時間に基づいて最適な 99 個の MVC 候補を選択します。
CONMVC のデフォルトは 1 に設定されるため、1 回につき 1 つの MVC のみ処理されます。
タイムアウトは指定されていません。
主な作業は、VTCS Vary VTSS コマンド/ユーティリティーを使用した、VTSS のオンライン、オフライン、または休止状態への切り替えです。常に何の作業をしているか、それを行う理由、VTSS をオフラインまたは休止状態にいつ切り替えるかを把握してください。多くの場合は、VTSS の保守が必要であるか、構成から VTSS を削除するためです。これらについては、VTCS の問題の検出と修正で説明しています。
最初に、次のチャートで、VTSS をサポートする各モードに変更するときに何が発生するか (そして、可能な場合は常に OFFline ではなく QUIESCED を使用する理由) を説明します。
| 指定する Vary VTSS のパラメータ | VTSS の最初の状態 | VTSS の次の状態 |
|---|---|---|
|
ONline |
オンライン保留状態 - オンライン保留状態では、すべてのホストでオンラインプロセスは開始されていますが、完了はしていません。 |
オンライン - オンライン状態では、VTSS はオンラインで使用可能な状態です。また、フロントエンドおよびバックエンドの両方の作業を ACCEPT します。オフライン状態の VTSS をオンラインにすると、VTCS は VTSSAUDIT を実行するように警告メッセージを発行します。 |
|
QUIESCED |
休止中 - この状態では、VTCS は VTSS に対する DD の割り振りは行いません。保留中のマウントを ACCEPT し、unit=aff チェーンで長時間実行されているジョブが完了できるようにします。すべての VTD が未使用状態 (MVS で 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 を自動的にリコールします。 |
注記:
クライアント/サーバー環境 (MVS/CSC および LibraryStation またはクライアントホストの SMC/HTTP サーバー) では、VTCS は長時間実行されているジョブがクライアントホストで有効であるかどうかを判断できません。VTSS がオフライン状態になったあと、(a) VTD を MVS に対して明示的にオフラインにするか、(b) クライアントホスト上の仮想テープの活動が停止していることを確認してください。クラスタ VTSS または Cross-TapePlex Replication (CTR) の構成では、VTSS への Clink をオフラインに変更して、レプリケーションと電子的なエクスポート処理を停止してください。
VTSS を保守する前に、次のように VTSS を休止します。
ホストごとに、VTSS VTD をオフラインに変更します。
ホストごとに、すべてのデバイスがオフラインになるまで待ちます。VTD は割り振りがなくなるまでオフライン処理を続行しないことに注意してください。長時間実行ジョブが VTD を使用している場合は、ジョブが完了するまで待つかジョブを取り消す必要があります。
指定の VTSS が定義されている VTCS システムから、VTSS を QUIESCED に変更します。
各 VTCS システムで、VTSS が休止状態であることを示すメッセージ SLS6742I を待機します。
オプションで、データを VTSS から移行できます。
指定の VTSS が定義されている VTCS システムから、VTSS を OFFLINE に変更します。
各 VTCS システムで、VTSS がオフライン状態であることを示すメッセージ SLS6742I を待機します。これで、VTSS を保守できるようになります。
VTSS を削除するのは次のような場合です。2 つの別々の VSM システムがあり、一方のワークロードは増大し、もう一方のワークロードは減少しています。解決法: システム A から VTSS を取り出し、システム B に追加します。『Installing ELS』では VTSS を追加する方法について説明しているため、このセクションは VTSS を削除するための操作に限定します。
VTSS を削除するには:
VTSS を削除する前に、次を行います。
削除する前に VTSS を空にする必要はありません。必要なのは、すべての VTV が完全に移行されているか確認することです。また、削除した VTSS に新しい作業がルーティングされないように、TAPEREQ 文などほかのパラメータを変更することも検討してください。
VTSS から 1 つのデバイスタイプ/ACS の組み合わせをすべて削除する場合は、すべての VTV が完全に移行されていることもまず確認してください。上記のように、VTSS の変更された移行機能を反映するために、ほかのパラメータを変更することを検討してください (たとえば、ACS と媒体を指定するストレージクラスを指しているマネージメントクラスなど)。
VTSS を休止状態にします。
オフラインになったら、手順 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 属性の変更について説明します。
注記:
SET VOLPARM または CONFIG MVCVOL 処理の結果として VTV が構成から削除される場合:volser を MVC として構成に再度挿入することはできません。
volsers をネイティブ HSC テープに使用しないでください。
メッセージ SLS6944I は、削除された VTV の数を示します。
スクラッチ VTV の削除には 2 つの方法があります。
ポリシーを使用して、VTV のマネージメントクラスで DELSCR(YES) を指定し、HSC または LCM スクラッチ同期を使用して実際のスクラッチを実行します。
特定のタスクでは、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 パラメータで指定)。
VTVMAINT も使いやすいツールで、次のような VTV の保守に使用します。
VOLSER (範囲、リスト、個々の VOLSER) で VTV を選択します。
「VTV マネージメントクラスの変更および MVC からの VTV のリンクの切断」で説明するように、VTV のマネージメントクラスを変更するため、VTV を MVC からリンク切断します。
VTV のマネージメントクラスを変更します。これは、VTV の管理方法を変更する場合に行います。ほかの方法もありますが、「VTV マネージメントクラスの変更および MVC からの VTV のリンクの切断」で説明するように、最適なツールは明らかに VTVMAINT です。
オフライン VTSS 内の指定された VTV を論理的にマウント解除します。これについては、「オフラインの VTSS における VTV の論理マウント解除」で詳しく説明しています。
注記:
VTVMAINT を実行すると、VTVMAINT ジョブの影響を受けるボリュームの VTV レポートも生成されます。VTVMAINT を使用すると VTV のマネージメントクラスを変更できます。新しいマネージメントクラスが別のストレージクラスを指定している場合、MVC 上の VTV の現在の場所が不適切になります。VTVMAINT を使用し、VTV のマネージメントクラスおよびストレージクラスを変更する方法を次に示します。
VTV のマネージメントクラスを変更し、そのリンクを解除するには:
VTV をリコールします。
手順 2 でリンク解除が成功するには、VTV が VTSS 常駐である必要があります。
VTVMAINT ULINKMVC を使用し、それが配置されている MVC と VTV のリンクを解除します。
VTVMAINT MGMTclas を使用し、新しいマネージメントクラスを割り当てます。
VTV を再移行して正しい MVC に配置します。または VTV を MVC に適宜移動する手順については、RECONcil による 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 にアクセスするには次のようにします。
次のコマンドを実行して、VTCS に対して VTSS をオフラインにします。
VT VARY VTSS(name) OFFLINE
I/O がアクティブ状態で VTSS に障害が発生した場合、MVS は VTD を BOX し、マウントされた VTV を MVS 的にマウント解除します。ただし、VTSS がマウントされている VTV を実際にマウント解除する前に VTSS との通信が失敗した場合は、引き続き VTCS に対しオンラインの場合があります。したがって、最初に VTCS に対し VTSS をオフラインに変更する必要があります。
MVS が VTD を隔離し、マウント済みの VTV をマウント解除した場合は、手順 3 に進みます。それ以外の場合は、手順 2 に進みます。
VTV を MVS 的にマウント解除します。
VTV がオフラインの VTSS にマウントされていると MVS が認識している場合には、別の VTSS の VTD に VTV を再マウントすることはできません。次のいずれかを実行します。
MVS UNLOAD コマンドで VTV をマウント解除します。
VARY OFFLINE コマンドを実行して、VTV がマウントされている VTD をオフラインにします。これにより、VTV もマウント解除されます。
オフラインの 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" ステータスをクリアするようにしてください。VTVMAINT を使用すると、CTR によって複製された VTV のステータスを変更できます。
VTV の所有 TapePlex を変更するには、VTVMAINT OWNRPLEX を使用します。
VTV を参照する TapePlex の名前を削除するには、VTVMAINT DELEXpot を使用します。
VTV を参照する TapePlex の名前を追加するには、VTVMAINT ADDEXpot を使用します。
詳細は、『ELS 障害回復およびオフサイトデータ管理ガイド』を参照してください。
「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 を使用して VTV の ACS/メディアを変更するには、次の手順に従います。
再統合が必要かどうかを検証する 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 が表示されます。
RECONcil をはじめて実行するときは、デフォルトを受け入れます。このときはレポートのみが生成されます。データの移動は行われず、再統合の候補となる VTV が報告されるだけです。
注意:
VTV を再統合すると、リソースを大量に消費する可能性があるため、最初は MOVEVTV を指定せずに RECONcil を実行し、MOVEVTV を指定する前に必要に応じてジョブを調整することを強くお勧めします。必要に応じて、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 がアクティブである必要があります。必要な事前確認、調整、およびピーク時を避けたスケジュールをすべて行いました。
ここで、それを実現させましょう。次に、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 レポートには実行結果が表示され、必要に応じて処理を再調整して再実行できます。
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 それぞれのサマリー情報も出力されます。
| 代替 VTV コピーのカテゴリ | 回復処理 |
|---|---|
|
カテゴリ 1: 現在、VTSS が常駐している。 |
回復は常駐コピーから行います。回復コマンドを要求すると、失われた MVC または破損した MVC から VTV をリンク解除するために |
|
カテゴリ 2: 現在、1 つまたは複数の代替 MVC コピーにリンクされている。 |
回復は、次の 4 つの項目に基づいて最適な代替 MVC から行います。
回復コマンドを要求すると、 |
|
カテゴリ 3: Cross TapePlex Replication で複製されている。 |
VTV のコピーを含む、最初に見つかったリモート TapePlex を使用して、VTV を回復します。 回復コマンドを要求すると、 |
|
カテゴリ 4: VTV データをまだ含んでいる可能性がある 1 つまたは複数の MVC コピーに以前リンクされていた。 |
以前リンクされていた MVC の 1 つが、回復 MVC として選択されます。これらの MVC コピーはログファイルで検索され、まだ VTV のコピーを含んでいる可能性があります。選択した回復 MVC を監査する必要があります。リンクされていた MVC コピーのうち回復に使用できる最適なコピーは、代替 MVC と同じ条件に基づいて選択します。 回復コマンドを要求すると、
|
|
カテゴリ 5: 回復不能。 |
コピーは失われた MVC または破損した MVC のみに存在し、回復することができません。 |
注記:
回復コマンドを要求すると、カテゴリ 1、2、3、および 4 ではMVCMAINT コマンドも生成されます。これらの文は、失われた MVC または破損した MVC を読み取り専用および破損としてマーク付けし、それらがリコールまたは移行の対象として選択されないようにします。注記:
この手順の JCL 例では、CDS コピーに対する DD 文を示していません。HSC がアクティブで、LOGUTIL を実行しているシステムでアクティブな CDS を使用する場合は、このままで有効です。それ以外の場合は、CDS コピーに対する DD 文を指定する必要があります。FOR_LOSTMVC を使用して VTV を回復するには:
まず、失われた 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)
手順 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 に進みます。
指定した VTV を回復するには、手順 2 で指定した回復データセット内のコマンドを実行します。
注記:
回復データセット内のコマンドは、FOR_LOSTMVC の実行後にできるだけすみやかに (標準の SLUADMIN JCL を使用して) 実行し、正確さを保証する必要があります。
Oracle では、回復コマンドを COMMANDS ファイル内で、次の順序で実行することをお勧めしています。
すべての EEXPORT ULINKMVC コマンド。
すべての MVCMAINT READONLY(ON) コマンド。
すべての AUDIT コマンド。
EEXPORT ULINKMVC または AUDIT コマンドがあった場合は、FOR_LOSTMVC を再実行します。新規の実行では、新しく生成された COMMANDS ファイルに EEXPORT または AUDIT コマンドがないようにします。ある場合は、手順 a に戻ります。
すべての MVCMAINT READONLY(ON) ERROR(ON) コマンド。
すべての ULINKMVC コマンド。
すべての RECALL コマンド。
RECONcil ユーティリティー
指定したすべての失われた MVC または破損した MVC で、CDS に存在し候補となる VTV が少なくとも 1 つあるものに対して、MVCMAINT コマンドが生成されます。MVCMAINT コマンドは、失われた MVC または破損した MVC に読み取り専用ビットとエラー/破損ビットを設定して、これらがリコールまたは移行で割り振られないようにします。各 MVCMAINT コマンドには、最大で約 3000 の MVC が含まれます。
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)