このセクションでは、問題発生時の対処方法について説明します。「VTCS ダッシュボードの使用」で説明された日次処理や「バックアップコピーからの CDS の復元」の要求時タスクをすでに実行したものの、問題がまだ解決されません。ここで、問題が発生したときに VTCS の動作を正常に戻す方法を判断します。まず、「一般的な問題の修正」で簡単な問題から説明します。
注記:
CDS の回復は主に HSC のタスクですが、VSM に関係する部分もあります。詳細については、「PITCOPY を使用した CDS のバックアップ」を参照してください。ここでの「一般的」は、最善の努力をしたにもかかわらず正常に動作する見込みがない状態を意味します。多くの場合、問題を見つける方法は VTCS ダッシュボードを別の角度から見ることであり、修正内容は要求時タスクの中にあります。
VTV マウントのパフォーマンスの問題を検討する前に、ほとんどの場合ユーザーが自分で診断して修復できる一般的な問題があります。妥当な範囲で努力してもうまくいかない場合、カスタマサポートに電話をかけます。また、ここではトレースなどのツールについては説明していません。これらのツールは、基本的に Oracle サービスの指示に従って使用してください。
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 がオンラインであっても、MVS VARY コマンドを実行して、VTD をオフラインにし、MVS UNLOAD コマンドを実行して、VTD をクリアしてください。次に、HSC MOUNT および DISMOUNT コマンドを使用して、操作を再試行してください。
VTV の移行処理が非常に遅い場合は、次の点を調べてください。
Display MIGrate を開始します。これにより移行タスクの動作状態が表示されます。正常に動作するように設定を調整できます (たとえば、MAXMING/MINMIG 値を大きくします)。
使用する RTD および MVC が、「仮想テープのステータスの確認 (日次)」に示すような適切な状態になっていることを確認します。詳しく調査するには、Display Queue DETail を使用して待機中のプロセスのステータスも確認します。多くのプロセスが RTD について待機中で、RTD を MVS と共有している場合は、トランスポートを MVS に対してオフラインにし、VSM に対してオンラインに変更できます。
注記:
JES3 環境では、適切なユーザー Exit 変更を作成してインストールしていない場合、VTV マウントが失敗します。移行のパフォーマンスが悪いことよりも問題となるのは、移行がまったく行われないことです。次のセクションで説明するように、VTCS では移行の障害について詳細な情報を入手できます。
移行障害の詳細な情報を示すために、メッセージ 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 パラメータによって拡張されます。出力内容は次のとおりです。
ストレージクラスの特性 (ACS、MVC プール、およびメディア)。
VTSS からストレージクラスへの移行を待機中の VTV。
移行に使用する MVC の要件。
移行 MVC への書き込みに必要な RTD のデバイスタイプ。
移行の要件を満たすにあたって発生したエラー。
繰り返しますが、VTCS では移行シナリオの重要な要素 (ストレージクラス) に関する情報が表示されます。
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 が存在することを確認するか、ストレージクラスの定義を変更するか、またはその両方を行います。
最初は、メディアまたはドライブの障害に気付いていない場合もあるでしょう。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 を除去してください。
上述の RTD に関するチェックリストをひととおり確認しても問題がない場合、また MVC スペースを増やしたり、MVC サマリーレポートと HSC ボリュームレポートの VOLSER を比較したりするなどできることはすべて行なった場合、MVC は実際に ACS 内にあります。そこにもない場合は、HSC ボリュームレポートにリストされていない MVC を再度投入するか、または取り替えます。
このような場合は、メディアに問題がある可能性があります。「仮想テープのステータスの確認 (日次)」で説明した MVC レポートと VTV レポートを使用すると、メディアの問題の種類を確認できます。そのセクションで、もっとも簡単な MVC 異常に対する修正はすでに説明しました。次に、MVC レポートと VTV レポートで表示される MVC の異常ステータスのすべてのリストと、その対処方法について説明します。
これは MVC、ドライブ、またはその組み合わせに問題があることを示す一般的なエラーステータスです。VTCS はこの状態の MVC を優先しません。一般的に、このステータスをクリアするには、次のようにします。
MVC が問題の原因である場合は、DRAIN(EJECT) コマンドを使用してサービスから MVC を除去してください。
RTD が問題の原因である場合は、MVCMAINT ユーティリティーを使用して MVC ステータスをリセットします。
BROKEN ステータスで注意が必要なのは、SLS6686、SLS6687、SLS6688、SLS6690 のメッセージが 1 つ以上発行されている場合です。これらのメッセージの詳細な回復手順については、『VTCS メッセージおよびコード』を参照してください。
データチェック状態がこの 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 に戻す方法についても説明しています。
MVC はドレイン中か、または MVCDRain に失敗しました。
MVC がマウントされている間にエラーが起こりました。
この MVC は初期化されています。
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 がすでに再入力済みの場合。
MVC は空き容量がなく、将来の移行候補になりません。
MVC は RTD 上にマウントされています。
MVC は CONFIG ユーティリティーを使用して定義されていますが、今まで使用されたことはありません。
MVC は次の要件のいずれかにより読み取り専用とマークされています。
MVC は現在処理中のエクスポートまたは統合処理の対象です。読み取り専用状態により MVC は更新処理に対して保護されています。
MVC メディアにファイル保護が設定されます。エラーを修正し、MVCMAINT ユーティリティーを使用して READONLY(OFF) を設定します。
VTCS が MVC の更新を可能とする適切な SAF ルールが MVC には設定されていません。エラーを修正し (詳細は、『ELS のインストール』の「HSC と SMC、VTCS のセキュリティーシステムのユーザー ID の定義」を参照)、MVCMAINT ユーティリティーを使用して READONLY(OFF) を設定します。
MVC は現在 AUDIT されているかまたは失敗した AUDIT の対象です。AUDIT が失敗した場合は、VTCS はこの MVC を移行に使用しません。この状態をクリアするためには、この MVC に対して AUDIT ユーティリティーを再実行します。
MVC は MVCDRain Eject の対象であるかまたは MVC は RACROUTE の呼び出しによる更新のためにイジェクトされました。移行またはリコールにこの MVC は再使用されません。この状態をクリアするためには、MVC に対して Eject オプションなしで MVCDRain を使用します。
耐用期限切れステータス。VTCS は MVC からリコールしますが、MVC に移行しません。早急に MVC を置換してください。
MVC 保障期限切れステータス。VTCS は MVC の使用を継続します。MVC が耐用期限切れステータスになった時点で置換ができるように計画してください。
VTCS が 9x40 または T10000 メディアの 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 レポートと VTV レポートで MVC データチェックエラーが表示されたときに必要となります。
データチェックの発生した MVC を回復するには、次の手順に従います。
MVC に対して MVC AUDIT を実行します。
AUDIT は、MVC から VTV メタデータをシーケンシャルに読み取ろうとします。AUDIT はデータチェックが発生すると失敗し、MVC は AUDIT 中の状態のままになります。これにより、VTCS はこの MVC を出力に選択できなくなります。
MVC に対して MVCDRain Eject コマンドを実行します。
これにより、利用できるすべての VTV がリコールされ、新しいエラーのない MVC に再移行されます。これで、論理的に MVC が MVC プールから除去されます。
注記:
MVC のエラーステータスのために、VTCS は必要に応じて代替 MVC から VTV をリコールします。
エラーになっている MVC から VTV をリコールする必要がある場合 (他にコピーがない場合)、次のようになります。
データチェック域の前にある VTV は、ブロック ID の昇順にリコールされます。
データチェック域の後にある VTV は、ブロック ID の降順にリコールされます。
MVC から回復できなかった VTV があるか確認します。
MVC に対して MVC 詳細レポートを実行します。まだ MVC 上にあると報告された VTV がある場合、これらの VTV は回復できません。データを回復するには、別の方法を使う必要があります。
次のいずれかを行い、障害のある MVC を管理します。
障害のある MVC を内部および外部ラベルが同じである初期化されたテープボリュームと交換します。
障害のある MVC に対して HSC EJECT コマンドを入力します。
代替 MVC に対して HSC ENTER コマンドを入力します。
必要に応じて、テープを初期化します。
新しい MVC に対して HSC AUDIT を入力します。
MVCDRAIN (EJECT なし) を実行して、MVC を MVC プールに戻します。
システムから MVC を除去します。
障害のある MVC に対して HSC EJECT コマンドを入力します。
MVC プール定義を編集して、障害のある MVC をプールから削除します。
すべてのアクティブなホストで VT MVCDEF を入力して、新しい MVC プール定義を有効化します。
RTV ユーティリティーは、通常 Oracle サービスからの指示を受けて使用するツールです。これは RTV が、VTCS を利用せずに VTV データを直接 MVC から読み取るように設計されているためです。たとえば、実際に CDS が失われた場合などに使用されます。
RTV はスタンドアロンユーティリティーで、MVC から VTV を読み取って圧縮解除し、単一の出力テープ (実テープボリューム) へ書き込みます。これにより、ユーザーアプリケーションがデータを読み取れるようになります。RTV ユーティリティーはスタンドアロンのユーティリティーなので、VSM がダウンしていても MVS システムが稼働していれば、RTV を実行できます。
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 バイト、または 32G バイト) が必要です。
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 許可されていなければなりません。次に、RTV ユーティリティーを使用する JCL の例を示します。
次に、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 /* //
次に、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) /* //
次に、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) /* //