OPコマンドを待ち合わせるECBをECBLISTでWAITする時の注意

By kamii - Last updated: 金曜日, 9月 10, 2010

オペレーター・コマンド待ち合わせのECBをECBLISTに含める場合の注意

MODIFY/STOPコマンドによってオペレーター・コマンドを受け取るには、EXTRACTマクロでCOMエリアのアドレスを求め、そこからポイントされているMODIFY/STOPコマンドECBを求めます。その後QEDITマクロによってコマンド・キューを初期設定してから、MODIFY/STOPコマンドECBでWAITします。コンソールからMODIFY/STOPコマンドが投入されるとECBがPOSTされます。COMエリアからCIBをたどり、入力されたコマンド文字列を得る、という流れになります。
MSPでもVOS3でもこの流れに関しては同じです。しかしMODIFY/STOPコマンドECBによって単独でWAITするのではなく、自分自身のプログラム・イベントのECBと共にマルチイベントでWAITする場合は注意が必要です。MODIFY/STOPコマンドECBを含めたマルチイベントでのWAITを行う場合、MODIFY/STOPコマンドECB領域の記憶保護キーが0になっていることが理由です。


※MSP/VOS3におけるこのような現象は、1990年代前半頃に調査した結果です。データベース製品を担当してた先輩から「昔、お客さんからソフトを立ち上げてるだけで使ってないのに何でこんなにCPUが上がってるの?って聞かれたことがある、そしたらさ...」という話が発端でした。同じようにECBLISTでマルチイベントのWAITしている自分の担当製品では同じMSPでそんなことは起きてないのに何で?ということから自分でもいろいろ調べてみたわけです。その後機会があって2001年にもテストしましたが変わっていませんでした。しかしそれから10年近く経ってますので、もしかしたらOSの動きも変わっているかも知れません。

Filed in API、インターナルの違い, システムプログラマーのための手引きいろいろ

07.2複数の非同期事象をFIFOで処理する(EVENTS)-2

By kamii - Last updated: 木曜日, 9月 9, 2010

EVENTSマクロによって複数のECBをFIFOで処理できることは解説しました。複数のECBにPOSTがなされている状態でも、WAIT=YES指定のEVENTSマクロ発行毎に完了済みのECBが順番に通知されます。しかし同時に多くの非同期事象が完了するような場合は、1つのECB毎にEVENTS SVCを呼び出していてはオーバーヘッドが大きいです。そこで通知済みのECBをまとめてプログラムで認識できれば、より少ないオーバーヘッドで複数のECBを完了順に知ることができます。


完了済みECBのピックアップ処理の例

Filed in 中級編

07.2複数の非同期事象をFIFOで処理する(EVENTS)-1

By kamii - Last updated: 木曜日, 9月 9, 2010

非同期事象(「いつ来るかわからない」「いつ終わるかわからない」と言った事象)の待ち合わせを行うAPIとして基礎編では WAIT マクロを解説しました。1つ、あるいは数個のイベントを待ち合わせる場合はWAITマクロが利用できます。
しかしWAITマクロで複数のイベントを待ち合わせる場合、どのECBに対応したイベントが最初に終了したかはわかりません。ECBLISTにはイベントが完了したことを示すPOSTビットは立ちますが、複数のイベントが完了していても、イベントが完了した(POSTされた)順番はわかりません。そのためオンライン・システムのTPモニターやTCP/IPによるサービスを提供するサーバープログラムなど、接続された端末やクライアントのデータ受信などに対応してECBを用意しデータ受信が完了した順にトランザクション・サービスを提供するようなプログラムなどでは、受信データが到着した順番がわからないので正確なFIFOでの処理ができません。
マルチイベントの待ち合わせ処理では、イベントに優先度がある場合を除けば事象が完了した順に対応した処理を行うのが一般的です。先着順にFIFOで処理をすることで均一のサービスを提供できます。しかしWAITマクロのECBLISTではどのイベントが完了したかはわかりますがその順番はわかりません。たいていはECBLISTの先頭から完了したECBを探したりしますので、複数の端末やクライアントからデータ受信が集中しても、実際の先着順ではなくECBLISTの順番で処理することになったりします。そこで前回POSTビットの立っていたECBの次のECBから探索を行う、などの工夫が考えられます。それでも不公平さ(LISTの先頭にいるほど見つけてもらいやすい)が少しは解消されますがFIFOになるわけではありません。

WAITマクロの代わりにEVENTSマクロを使うと、事象の完了した順番でECBを通知してもらえるので、オンラインやサーバーなどのプログラムでは、トランザクションが到着した順に処理をして、公平なサービスを提供することが容易になります。使用するECBの数が処理に応じて増減するような場合もEVENTSマクロは向いています。
また待ち合わせの対象となるECBが多い場合(数個ではなく数十、数百)、EVENTSマクロの方が少ないオーバーヘッドで処理されます。VOS3のマニュアルではEVENTSマクロを”高速多重ウェイト機能”と解説しています。


EVENTSテーブルの作成(初期設定処理)


ECBの初期化(ECBの登録)


完了事象の待ち合わせ


EVENTSテーブルの削除


EVENTSマクロではWAITマクロよりやらねばならない手続きが増えます。しかしEVENTSテーブルの作成と削除はタスクの開始時と終了時に行えばいいので、実際にプログラム内で都度都度必要なのはECBの初期化です。WAITマクロでもECB内のWAIT/POSTビットのクリアーはプログラム自身で行うことになりますから、その代わりにECB指定のEVENTSマクロを発行する、と考えればいいでしょう。WAITに比べると一見面倒そうですが、一回書いてしまえばどうということはありません。
POSTする側の処理は、待っている側がWAITを使おうがEVENTSを使おうが違いを意識する必要はありません。

Filed in 中級編

FIBGET

By kamii - Last updated: 水曜日, 9月 8, 2010

FIBGET:AIFからサブミットしたジョブのSOUTファイルを取り出すコマンド(XSP専用)


富士通のXSPシステムにおいても、MSP同様にジョブの出力をシステムが管理する特殊なデータセットとして書き出すことができます。しかしOSが違うためその方法は異なります。MSPではJESと呼ばれるスプーリングサブシステムが、スプールと呼ばれるDASD上の特殊なデータセット内にSYSOUTと呼ばれる仮想データセットとして書き出して管理します。
XSPにはJESに相当するものはなく、XSP自身のジョブ管理機能がジョブのスケジューリングやジョブ入力と出力を管理します。MSPのSYSOUTデータセットに相当するのがSOUTファイルで、XSPでもJCLによってSOUTへの書き出しを指定します。SOUTもクラス(AからTの1文字)や出力部数、フォーム(用紙コード)、文字セット、オーバーレイなどMSPと似たような属性を持っています。

\ JOB BACKUP1,LIST=(A,JS)
\ EX  LIBE
\ FD  LIST=DA,SOUT=A  ← ファイル名LISTをSOUTへ出力する指定
\ FD  SYSUT1=DA,FILE=UAP1.MASTER
\ FD  SYSUT2=DA,FILE=UAP1.MASTER.UNLOAD,
      CYL=(1,1),VOL=000002,DISP=CAT
\ FD  COIN=*
/ BACKUP +,IN=SYSUT1,OUT=SYSUT2
/ FIN
\ JEND

XSPにはMSPのJESのようなスプールデータセットはなく、SOUTファイルの出力先はJCLによってディスクやテープなどのデバイスが指定されます。デバイス種別に加えボリュームを特定することもできます。指定しなければOSが適切なボリュームを割り振ります。MSPではSYSOUTデータセットにはJESが識別するための名前(DSN)が付けられますが、XSPでもOSがSYSOUTにファイル名を付け直接DASDボリュームなどに書き出します。

XSPにはジョブスタックファイルというものがあるが、そこで管理されるのは解釈されたJCLとジョブスケジューリングのためのジョブ入出力待ち行列で、SOUTファイルそのものの内容は含まれない。

書き出されたSOUTファイルはクラスに対応したプリンターやテープなどに出力されますが、印刷が不要なものはディスプレイ端末で内容を確認して消去することもできます。これを行うのがAIFのFIBGETコマンドです。AIFはMSPのTSSと同じものです。PFDなどのエディターからSUBMITしたジョブ(FIBジョブ:Foreground Initiated Backgroundジョブ)の実行結果はわざわざ印刷せずにディスプレイ端末でその内容を確認できれば十分なことが多いです。MSPではPFDのOUTLISTユーティリティー(オプション3.8)を利用すればスプール内のSYSOUTデータセットの内容を直接参照できますが、XSPではSOUTファイルの内容を直接PFDブラウザーなどで参照できません。そこでAIFのコマンドプロンプトから「FIBGET」というコマンドを使って、SOUTファイルの内容を一旦順次編成ファイルへ移してから、その順次編成ファイルをPFDのブラウザーなどで参照します。


FIBGETコマンド

FIBGET jobname [CLASS(class)] DATASET(filename)

例:
AIFログオン・ユーザーID=USER01、ジョブ名=MYJOB01、である時、
FIBGET MYJOB01 DATASET(JOBOUT)
とすれば、
ジョブMYJOB01のSOUT内容が、USER01.JOBOUT.LIST というファイルに書き出される。

ピックアップしたいジョブ名、出力先ファイル名を指定します。クラスを省略した場合は、AからTの順番で探され見つかったジョブのSYSOUTが選択されます。出力先の順次編成ファイルはRECFM=VB、LRECL=136の属性を持ちます。FIBGET実行後、書き出されたSYSOUTは消去されますのでSYSOUTから順次編成ファイルへの移動コマンド、と考えていいでしょう。
ファイル名を完全修飾名で指定する場合は、ファイル名をクォーテーション記号’で囲みます。例えばDATASET(‘MY.SOUT’)のようにです。コマンドの詳細は「AIFコマンド文法書」に記載されています。

出力先順次編成ファイルの形式は、AIFそのもののオプションパラメーターでVBかVBAかを選択することもできる。

次のようなコマンドプロシージャを作成して実行すれば、ジョブ名を指定するだけでSYSOUTの内容をPFDブラウザーで表示できます。

          PROC 1 JOBNAME
          CONTROL MSG
          FIBGET &JOBNAME DATASET('MY.SYSOUT')
LOOP:     READ
          IF &LENGTH(&SYSDVAL) NE 0 THEN GOTO CALLPDF
          GOTO LOOP
CALLPDF:  PFDEXEC BROWSE DATASET('MY.SYSOUT')

FIBGETコマンドの要求によって、AIFWTRというシステムプログラムがSYSOUTを順次編成ファイルに書き出します。AIFWTRはあらかじめSTARTコマンドによって起動されている必要がありますが、多くのセンターではIPL後にAIFと共に起動されているようです。

Filed in キーワードから(何が知りたいですか)

06.3タスクの生成(ATTACH/DETACHとIDENTIFY)-2

By kamii - Last updated: 火曜日, 9月 7, 2010

ATTACHマクロのEPまたはEPLOCキーワードで指定できるのはロードモジュール・メンバーの名前です。したがってこの点だけで考えるとATTACHできるのはLINKやXCTLのように独立したロードモジュールになっているプログラムになってしまいます。しかしながらタスクを分けるが故にプログラムも分割しなければならないのは不便です。タスク構造とプログラム構造が一対一になっていなければならない決まりはありません。自由度はもっと高いのです。
では静的リンクされた単純構造プログラム(06.1プログラムのローディングと実行(LOAD,LINKとXCTL)を参照)内の別CSECTのプログラムをサブタスクとしてATTACHしたい場合はどうすればいいのでしょうか?
そのためには2つの方法があります。

ATTACHしたいプログラムがCSECTで定義されていれば、バインダーのモジュールをリンクする際にCSECT名メンバーの別名として追加することができます。割り当てた別名をEPあるいはEPLOCキーワードで指定すればATTACHすることができます。

もう1つはIDENTIFYマクロを使い、メインプログラム内で動的に入口点を追加する方法です。LOADマクロなどによって既にメモリー内にローディングされたモジュール内(EXEC文のPGMパラメーターで指定されたメインプログラムも含む)であれば任意のアドレスを入口点として追加できます。


入口点の追加(IDENTIFY)


バッチ・ユーティリティーの呼び出しにATTACHを使う

Filed in 中級編

06.3タスクの生成(ATTACH/DETACHとIDENTIFY)-1

By kamii - Last updated: 火曜日, 9月 7, 2010

MVS(z/OS)はマルチタスクのオペレーティング・システムです。一般のアプリケーションでも複数のタスクに処理を振り分けることで、より実行効率のよいプログラム構造を持つこともできます。同時に複数のイベント(処理要求)が発生したり、非同期に発生するイベントを処理するプログラムではタスクを分割するプログラムデザインは珍しいものではありません。しかしバッチ処理でのマルチタスク構造のプログラムはまれで、通常はオンライン処理プログラムなど、サーバー的な機能を持つプログラムにおいて主に採用されます。


どういう時にマルチタスクを使うか


タスクの生成と実行(ATTACH)および消去(DETACH)

ATTACHされたタスク(子タスク)のプログラムとATTACHしたタスク(親タスク)のプログラムは非同期に動きます。異なるタスクのプログラム間でデータの受け渡したり、処理の整合性を正しく取るためには、タイミング合わせや排他制御などのコントロールが必要になります。これらはWAIT/POST、ENQ/DEQ(あるいはCS/CDSなどの逐次化命令)などを利用することで可能です。

Filed in 中級編

お手軽バッチ・パフォーマンス改善 – IX

By kamii - Last updated: 水曜日, 9月 1, 2010

データセットのI/O効率を上げる(続き)


以上、数回にわたり「バッチ処理のパフォーマンスを改善する」ということでまとめてみました。チューニングに関しては、いろいろな方法があるのですが、既存のリソースの中で行う、お金も掛けない、むずかしいチューニングの知識もいらない、運用への悪影響もほとんどない、大がかりな作業をせずに実現できる(PARMLIBを直すのもできれば避けたい)、という観点で紹介しました。他にもいい方法があればぜひご意見をお寄せ下さい。

Filed in オペレーション・運用

お手軽バッチ・パフォーマンス改善 – VIII

By kamii - Last updated: 月曜日, 8月 23, 2010

データセットのI/O効率を上げる(続き)


Filed in オペレーション・運用

お手軽バッチ・パフォーマンス改善 – VII

By kamii - Last updated: 火曜日, 8月 17, 2010

データセットのI/O効率を上げる(続き)


Filed in オペレーション・運用

DFSMSの保証スペース

By kamii - Last updated: 火曜日, 8月 17, 2010

数千シリンダーを超えるような大きなデータセットを作成する場合、複数のボリュームに分散して割り当てることができます。マルチボリューム・データセットなどと呼ばれ、古くから利用されてきました。

データセットを最大3つのボリュームに分散して作成します。最初に割り振られるスペースはボリュームDATA01に3000シリンダーです。DATA01に3000シリンダーを満たす空きスペースがなければ、最初の割り振りに失敗します。最初の割り振りに成功した後、3000シリンダーを使い切ると、OSは同じボリュームに1000シリンダー分の2次量で追加の割り振りを試みます。ボリュームに空きがなければDATA02、そこも空きがなければDATA03と順に最大3ボリュームにまたがってスペースが割り振られていきます。

これが基本的なデータセット・スペースの拡張メカニズムですが、使う側から見ると問題がないわけではありません。確実にスペースが割り振られるのは最初の3000シリンダーだけです。たとえ2次量を指定して、複数のボリュームにまたがってもかまわないことを指定していても、2次スペース量の拡張時に指定されたボリュームに空きがなければ追加の割り振りはできません。その結果スペース不足でジョブはABENDしてしまいます。

このような問題を回避するためDFSMSには保証スペース(Guaranteed Space)という機能があります。SMSのストレージクラスにGuaranteed Space=Yesの属性を与えれば、指定されたすべてのボリュームに1次量を割り振ります。

データセットは指定されたすべてのボリューム(DATA01,DATA02,DATA03)に1次量である3000シリンダーが割り振られ、最初に作成した時点で3000シリンダー×3ボリュームで9000シリンダーのスペース量が確保されます。2次量が指定されていれば最初のボリュームの1次スペースが一杯になると同じボリューム内で可能なだけの2次スペース量拡張が行われ、それをすべて使い切ってから、2番目のボリュームのすでに割り振り済みの1次スペースが使われます。絶対に必要としたいスペース量を事前に割り振ることができるため、運用中にスペース不足でジョブがABENDすることを防げます。保証スペースは、指定した1次量を複数のボリュームに分散するのではありません(例えば1000cylを250cylずつ4ボリュームに割り振る)、また指定した1次量が最初のボリュームでまかないきれず不足分を次のボリュームに割り当てるものでもありません(例えば1000cylのうち、最初のボリュームに800cyl、2番目のボリュームに200cylを割り振る)。VOLパラメーターで指定されたすべてのボリュームにSPACEパラメーターで指定された1次量を割り振ります。したがってその仕組みを考慮して1次量を指定します。例えば全部で5000シリンダーが必要で、5つのボリュームが使えるなら1次量は1000cylとします。指定されたボリュームのうち、1つでも1次量を満たす空きスペースがなければデータセットは作成されません。



なおラージ・データセットを作成し、かつそのスペース割り振りを保証するには、保証スペース機能の他にも3390-9型以上の大容量ボリュームに単一エクステントのデータセットとして作成する方法もあります。一般のデータセットでは1つのボリュームに割り当てることができるエクステント(ボリューム内でデータセットに割り当てられる連続した領域)は最大65535トラックに制限されますが、拡張形式の順次データセットやVSAMデータセットはこれを超える容量のデータセット・エクステントを割り当てることができます。拡張形式のPSデータセットなら、30000シリンダーという巨大なデータセットでも単一エクステントで割り振ることができます。


保証スペースやラージ・エクステントに関する詳細はマニュアル「z/OS DFSMS データ・セットの使用法」に解説されています。

Filed in アドミニストレーター編