2017-05-09 5 views
2

私のサイトのプラクティスの1つは、バッチサイクルが始まるときです。プログラムを実行する前に、実行全体で使用されるすべてのGDGの新しい世代を割り当てます。数百GDGを一度に適切に定義する適切な方法

これは、処理が開始される前に500個を超えるファイルが割り当てられているシナリオがあることを意味します。私は、この大規模なサイクルをより効率的にする方法を模索することを任されてきました。

  • ラン1つの巨大なIDCAMSステップと一度(現在の機能)
  • のみ割り当てる複数のIDCAMSステップにダウンの割り当てを解除で新しいバージョンのすべてを作る:私はこれらの割り当てのために取るべき道不思議でしたファイルの一部

IDCAMSを複数回連続して呼び出す際に頭がずっとありますか?

これらを小さなステップに分割すると、全体的なパフォーマンスが向上する可能性がありますが、実際にテストするための明確な方法はありません。私たちのテスト環境は実際にはメトリックを実行するのにはあまり適していません。なぜなら私たちの仕事は通常、JESでは優先順位が低いため終了します。そのため、実際に何が行われたのか、これらはIDCAMSの割り当てであり、CPUの統計値は常に低くなります。

TLDR;誰がより効率的であるか、どれがより効率的であるかを知ることができますか?

+0

すべてのファイルの+1バージョンを割り当てる単一のジョブ(またはステップ)を実行し、その後のジョブが現在の(0)世代を参照しているとしますか?また、「より効率的な」ということは、より少ない経過時間で実行し、より少ないシステムリソースを使用し、カタログの競合などを減らすことを意味しますか? –

+0

@ValerieRはい1つのジョブは、+1と他のすべてのジョブ参照0を行います。コメントの2番目の部分については、私はそれが何よりもシステムリソースの最小量を使用して実行することを望みますが、可能であれば、カタログの競合や経過時間の短縮も良いでしょう。 – SaggingRufus

+0

これは悪い質問ではありませんが、これを自分でテストすることも非常に簡単です。 1つのIEFBR14またはIDCAMSスタップに500の新しいGDSを割り当てるテスト・ジョブと、それぞれ5つのGDSを割り振る100ステップで同じテストを実行するテスト・ジョブの2つを作成してください。 –

答えて

6

真実は、何百ものデータセットを定義することは、現代のz/OSシステムが適切に実行されれば、それを強調するものではありません。各割当は、予測可能な一連のシステム・サービス(カタログ機能、割当て機能、セキュリティ、SMFロギングなど)を順番に実行しますが、微妙な違いがありますが、どのようにしても時間はかなり似ています。

平均的に調整された最新のメインフレームでは、典型的な新しいファイル割り当ては100ミリ秒を超えるべきではありません。 500個のデータセットを割り当てるのに1分以上かかる場合は、IDCAMSの使用に関係しない何かが間違っている可能性があります。

例として、あなたの仕事はリソースを枯渇させる優先度の低いクラスに入る可能性があります。一定の量を消費すると、リソースが枯渇します。この場合、ディスパッチされるのではなく待っているだけかもしれませんCPU時間を経過時間で割ったものが、これが問題であるかどうかを示します)。これが問題であれば、一般的な方法はIDCAMS経由ではなく、JCLでGDGを定義することです。JCL割り当ては、バッチイニシエータの優先順位で実行されます。これは通常、ジョブステップ自体。ただし、エラーが発生すると、IDCAMSのエラーから返されるゼロ以外の戻りコードではなく、JCLエラーが発生します。

GDGの基本定義を確認することもできます。世代数が膨大なので、世代が遅くなる傾向があります。おそらく、世代数が少なくて済むような優れたスキームを考え出すことができます。

あなたのシステムプログラマーが、特にカタログ環境をうまく調整する良い仕事をしていることを確認することです。キャッシング、バッファリングなどを制御する多くのパラメータがあり、適切に調整されていますあなたが良いパフォーマンスを望むなら、カタログは不可欠です。 this IBM document.多くのタスクには特別な権限が必要なので、これはおそらく自分では処理できないものです。

実際に新しいデータセットのディスク領域を割り当てる場合は、割り当てパラメータが適切であることを確認することも必要です。たとえば、同じディスクボリュームにたくさんのデータセットを置いている場合、これは悪いことです。割り当てはボリュームレベルで多くのシリアル化を行います。つまり、複数のディスクボリュームにデータセットを分散するほど、競合の可能性は低くなります。エンキュー遅延などを監視するために、RMF(またはサイトに含まれているベンダー製品)のようなツールを使用することができます。これは、しばしば割り当てのパフォーマンスが低下する原因となります。

それは反復的なプロセスだし、あなたが本当にそれについて系統的になりたい場合は、あなたのGDGファイルの束を割り当て、テストジョブを作成し、その上でパフォーマンス統計情報を収集します。割り当てパラメータやシステム設定が異なると、スループットが異なることがあります。推測ではなく、最良の組み合わせを採用したいと考えています。あなたの経過時間に関係なく、CPUとI/Oのサービスユニット数を得ることができます。これは、何が最も効果的かを理解するための最良のガイドです。

システムが適切に調整され、不必要な遅延が発生していないことを確信したら、次の選択肢は並列処理のような技術によってCPU使用率を交換するかどうかです。あなたがやっている作業はほとんどI/Oバウンド作業なので、あなたのシステムがうまく調整されていると仮定すると、ファイルのサブセットを持つ複数のジョブに1つのジョブを分割すると、プロセッサリソースはわずかに多くなりますが、視点。最良のケースは、プロセッサエンジンが不足している場合、またはカタログやディスクを高い稼働率で使用する場合です。ただ、複数のジョブにあなたの割り当てを分割

は、あなたのサイトは彼らが(つまり、など十分なバッチイニシエータを持っていると)並行して実行することができますと仮定すると、並列処理へのシンプルなパスです。あなたがこれをして、経過時間が大きな仕事を1つ実行するよりもうまくいかない場合は、上で説明したように、競争がどこにあるのかを調べて調べる時です。

ちょっとした冒険をしているなら、並行して多くの割り当てを行う気の利いた方法は、IDCAMSではなくBPXWDYNのようなUNIXサービスシェルを使うことです(GDGNTフラグをBPXWDYNに指定してください)。正しく実行すると、あなたは割り当てのサブセットをそれぞれ行ういくつかのサブプロセスを起動するシェルスクリプトを書くことができます。正しく構成されていれば、並列性を達成するために複数のアドレス空間を必要とするバッチジョブではなく、1つの大きなアドレス空間で実行する利点があります。

+0

サブプロセスを使用したシェルスクリプトに関する警告:_BPX_SHAREAS = YES環境変数を設定しないと、それぞれのサブプロセスが別のアドレス空間(BPXAS)で実行されます。 z/OSでの生成プロセスは、他のシステムではかなり高価です。 –

関連する問題