「メインフレーム・コンピュータ」で遊ぼう

FIBGET

kamii — Wed, 08 Sep 2010 04:33:30 +0000

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と共に起動されているようです。

06.3タスクの生成（ATTACH／DETACHとIDENTIFY）-2

kamii — Tue, 07 Sep 2010 06:40:22 +0000

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

リンケージ・エディターでメンバー名に別名（ALIAS）を付ける
IDENTIFYマクロで入口点を追加する

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

----+----1----+----2----+----3----+----4----+----5----+----6----+----7--
//LKD      EXEC PGM=IEWL,PARM=('LIST,LET,MAP,XREF')
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD UNIT=SYSALLDA,SPACE=(TRK,(80,20))
//SYSLIB   DD DISP=SHR,DSN=MY.LOAD
//SYSLMOD  DD DISP=SHR,DSN=MY.LOAD
//SYSLIN   DD DSN=*.ASM.SYSLIN,DISP=(OLD,DELETE)
//         DD *
  ALIAS SUBTASK3   ← ALIAS制御文で別名を付ける(ATTACHしたいCSECT名)
  NAME MAINTASK(R) ← 主となるメインプログラム名
//

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

入口点の追加（IDENTIFY）

----+----1----+----2----+----3----+----4----+----5----+----6----+----7--
メインプログラム
         :
         L     R1,=A(SUBTASK1)          LOAD SUB PROGRAM ENTRY
         IDENTIFY EP=SUBTASK1,ENTRY=(1) ASSIGN ALIAS NAME
         MVI   EOTECB,0                 CLEAR SYNCHRONOUS ECB
         ATTACH EP=SUBTASK1,            EXECUTE MOD=SUBTASK1 UNDER     +
               PARAM=PARM1,                    NEW TASK WITH PARM=PARM1+
               ETXR=EOTEXIT
         :
         :

IDENTIFYを使用する場合は、対象となる入口点アドレスは必ずしもCSECTやENTRYで定義した外部参照可能なラベル名である必要はありません。同じ入口点に複数の名前を付けることもできます。同じプログラムを複数のタスクで共用するような場合、IDENTIFYによって各タスクにタスク名を割り当てるような使い方もできます。
IDENTIFYを使えば、複数のCSECTを結合した単一のプログラム・モジュールで提供あるいは運用されるプログラムにおいて、モジュール内の任意のCSECTや場所をプログラム・モジュールとしてLINKやATTACHすることができます。

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

多くのバッチ・ユーティリティーはプログラムから呼び出すこともできます。しかし同じユーティリティーをデータを変えて、繰り返し何度も続けて呼び出す場合は、LINKではなくATTACHを使う方がよい場合があります。これはユーティリティーの中には使用した作業域を解放しないまま終了してしまうものもあるからです。バッチのジョブ・ステップとしてJCLで直接実行する場合では問題になりませんが、プログラムから呼び出す場合はユーティリティーが終了しても呼び出したプログラムは終了しないため、リージョン内の解放されない領域はデッドエリアとして残ってしまいます。これは同じタスクでユーザープログラムとユーティリティーを実行する事になるからです。
LINKに変えてATTACHによってユーティリティーを実行し、かつATTACH時にサブプール0を共用しない指定をすれば、ユーティリティー・タスクの終了時に未解放の作業域があってもOSがクリーンアップし解放してくれます。

----+----1----+----2----+----3----+----4----+----5----+----6----+----7--
FTPクライアントの呼び出し例
         :
         MVI   FTPECB,0                 CLEAR EOT ECB
         LA    R1,FTPPLIST              GR1 --> EXEC PLIST
         ATTACH EPLOC=FTPNAME,          ATTACH FTP UTILITY TASK M002   +
               ECB=FTPECB,                                             +
               SZERO=NO,JSTCB=YES       NEED JSTCB=YES UNDER Z/OS TO   +
                                        AVOID RETAIN SP252 FOR SUBTASK +
                                        USE.(EG. QSAM BUFFER POOL...)
         ST    R1,FTPTCB                SAVE TCB ADDRESS
         :
         :
         WAIT  ECB=FTPECB               SYNCHRONIZE FTP TASK END
         L     RF,FTPECB                GET COMPLETION CODE
         N     RF,=A(X'3FFFFFFF')       DROP CONTROL BITS
         :
         DETACH FTPTCB                  PURGE FTP TASK TCB
         :
         :
         :
FTPNAME  DC    CL8'FTP'                 FTP PROGRAM NAME
FTPTCB   DC    A(0)                     FTP SUBTASK TCB
FTPECB   DC    F'0'                     FTP SUBTASK EOT ECB
FTPPLIST DC    A(FTPPARM+X'80000000')   PLIST FOR FTP CALL
FTPPARM  DC    H'5',CL100'(EXIT'        FTP EXEC PARAMETER

サンプルはFTPクライアントの呼び出し例です。タスク終了の待ち合わせには非同期出口ルーチンではなくECBを使用しています。このサンプルではATTACHの目的は、処理の効率化ではなく、リソースの独立性を保つためなのでATTACH後に実行されるユーティリティーと非同期に処理を行う必要はありません。そのためATTACH後は単純にユーティリティーの終了を待ち合わせればよいのです。
ユーティリティーの中にはリエントラントに設計されたものがあります。例えばIDCAMSです。AMSユーティリティーの場合は、ATTACHではなくLINKでもAMSが使用したリソースが残ってしまうような問題を経験したことがありません。しかしAMS以外のユーティリティーをLINKマクロなどで連続して呼び出した場合に、やがてストレージ不足に陥ったり、異様に大量のメモリーを使ったことになっているような場合は、ATTACHを利用してサブタスクとして実行する方法も考えてみて下さい。

06.3タスクの生成（ATTACH／DETACHとIDENTIFY）-1

kamii — Tue, 07 Sep 2010 06:38:35 +0000

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

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

実現したい処理がオンラインだから、サーバーのサービスだから、ということで何でもかんでもマルチタスクにするわけではありません。I/O待ち（通信処理のI/Oも含む）の間に他の処理ができるから、ということでタスクを分けることは決して間違いではありませんが、トランザクション量が増えても集中しても、誤りなく正確にマルチタスクのプログラムを制御することは決して簡単ではありません。まずは本当に単一のタスクで制御できないのかを十分に検討して、その上で必要ならマルチタスクでのデザインを考える方がいいでしょう。

ファンクションでタスクを分ける
トランザクション量でタスクを分ける

大まかなプログラムの設計として、機能か量かでタスクを分ける考え方があります。ファンクションで分ける、というのは、オンライン処理などでは端末（クライアント）の接続／切断、送信、受信、ファイルやデータベースのアクセスや更新など、一連の処理をいくつかのパートに分けて、それぞれの処理を担うプログラムをタスクとして独立させる方法です。このようなデザインは一見わかりやすく各タスクに与えられた機能そのものを実現するプログラムも作りやすいのですが、全体を誤りなく正確に動かすための、タスク間の同期を取ったり、データを受け渡す制御処理が複雑になります。この部分を甘くしたり、抜かしてしまうと、信頼性を大きく落とすことになりかねません。
筆者の経験ではファンクションでタスクを分けるぐらいなら、単一タスクのままWAITやEVENTSでマルチウェイトを行い、イベント（非同期待ち合わせのI/Oなど）の完了した順に必要な処理を行い、待ち合わせの必要な処理は要求だけ投げて、その後は他のイベントの処理へ回る、という構造（イベント駆動型）の方がすっきりすると考えています。むろんこれは私自身の考え方で、実際に機能でタスクを分ける考え方を採用している例も多いです。私もプログラムを覚えたての頃は、ファンクションでタスクを分けることは自然なことと考えていました。随分と前のことですが富士通のOS開発部門の方と話す機会があったときに、「VTAMはシングルタスクでやってるよ」ということを聞いてから、あれだけの大量のデータをあんなに速い速度で処理するシステムがシングルタスクのプログラム構造で作れるのか、と感心してから、いろいろ私なりに考えてみたものです。
しかし”一連の処理は単一のタスクで処理をする”という設計を行っても、1つのタスクでは大量のトランザクションが集中すれば処理が追いつかなくことも考えられます。サービスを提供するタスクが1つなので、サービスを受けるための待ち行列は長くなってしまいます。このような場合は”一連の処理”を完結できる単一のタスクを、トランザクション集中量などに応じて増やすことでマルチタスク化する方法があります。この方法なら1つのトランザクションの処理は完結するまで同じタスクが処理しますが、そのタスクを10個用意すれば、同時に10のトランザクションを並行して処理できます。現在ではプロセッサーに4つ、8つといった複数のCPUが実装されていることが多いので、OSによるCPUディスパッチの切り替えによる多重処理に加えCPU数に応じての同時実行も可能になります。

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

----+----1----+----2----+----3----+----4----+----5----+----6----+----7--
メインプログラム
         :
         MVI   EOTECB,0                 CLEAR SYNCHRONOUS ECB
         ATTACH EP=SUBTASK1,            EXECUTE MOD=SUBTASK1 UNDER     +
               PARAM=PARM1,                    NEW TASK WITH PARM=PARM1+
               ETXR=EOTEXIT

               サブタスクへ渡すパラメーターはPARAMキーワードで指定する。
               CALLマクロと同じで、アドレスパラメーターリストが生成される。
               特定の値をパラメーターとして渡すような場合は、GR1に直接その
               値を設定して、PARAMパラメーターを省略すればよい。

         ST    R1,TCBADDR               SAVE ATTACHED TASK TCB ADDRESS

               ATTACH後、GR1には生成されたサブタスクのTCBアドレスが返る。

         WAIT  ECB=EOTECB               WAIT UNTIL ATTACHED TASK DONE

               サブタスクの完了を待ち合わせるためのWAITマクロの発行。
               ECBにPOSTするのは、ETXRパラメーターで指定したサブタスク
               終了出口ルーチンになる。
               もちろん非同期処理を行うためにタスクを分けているのだから、
               WAITする前に他の処理を行ってかまわない。そのようにして
               処理を並行させなければタスクを分ける意味がない。
         :
         :
EOTECB   DC    F'0'                     ATTACHED TASK COMPLETION ECB
PARM1    DC    CL50'THIS IS SUBTASK PARAMETER STRING'
         :
         :
サブタスク終了出口ルーチン
EOTEXIT  DS    0H
         USING *,RF                     DEFINE TEMP BASE
         STM   RE,RC,12(RD)             SAVE CALLER REGISTERS
         L     RC,=A(MAINENTR)          ESTABLISH OUR BASE ADDRESS
         DROP  RF                       FORGET TEMP BASE
         SPACE ,
         ST    R1,TCBADDR               SAVE TCB ADDRESS FOR DETACH
         L     R0,TCBCMP-TCB(,R1)       LOAD TCB COMPLETION CODE
         POST  EOTECB,(0)               POST IT TO MAIN TASK
               終了したタスクの完了コードはTCBCMPフィールドを調べればわかる。
               このサンプルでは完了コードをPOSTマクロのPOSTコードとして
               使用している。

         DETACH TCBADDR                 DETACH ENDED TASK
               終了したサブタスクのTCBをパージするためにDETACHマクロを
               発行する。DETACHではTCBアドレスそのものをパラメーターとして
               指定できない。TCBアドレスが格納されたポインターフィールドの
               アドレスを渡すことになる。
               このサンプルではサブタスク終了出口ルーチンでDETACHを
               発行しているが、メインルーチンで発行してもかまわない。
               DETACHを発行するまではTCBは存在しているので、メインルーチンでも
               参照可能である。

         SPACE ,
         LM    RE,RC,12(RD)             LOAD CALLER REGISTERS
         BR    RE                       RETURN TO CALLER(DISPATCHER)
         SPACE ,
TCBADDR  DC    A(0)                     TCB ADDRESS FIELD
         :
         :
制御ブロック（TCB）マッピング
         IKJTCB ,                       TCB

----+----1----+----2----+----3----+----4----+----5----+----6----+----7--
ATTACHされるサブタスクプログラム
SUBTASK1 CSECT ,                        DEFINE CODE SECTION
         USING *,RC                     DEFINE BASE REGISTER
         STM   14,12,12(13)             SAVE CALLER REGISTERS
         LA    12,0(,15)                GR12 -> OUR 1ST BASE ADDRESS
         LR    15,13                    SAVE CALLER SAVEAREA
         CNOP  0,4                      INSURE FULL WORD BOUNDARY
         BAL   13,*+4+72                AROUND OUR SAVEAREA
         DC    18F'-1'                  OUR GPR SAVEAREA
         ST    15,4(,13)                SAVE CALLER SAVEAREA POINTER
         ST    13,8(,15)                SET BACK CHAIN FOR LINK TRACE
         :
         :     必要な処理を実装し、ごく普通に作ればよい。
         :     GR1にはATTACHマクロのPARAMキーワードで指定された
         :     パラメーターのアドレスが入る。
         :     パラメーターはアドレスリストの形式になっている。
         :     このサンプルの場合、以下のように渡される。
         :     GR1 → +---------------------------+
         :         +0 I メインプログラムの        I
         :            I PARM1フィールドのアドレス I
         :            +---------------------------+
         :
         :     プログラムが最後の命令を実行して（BR 14等）OSに
         :     制御を戻すと、メインプログラム側のタスク終了出口ルーチン
         :     が実行される。
         :

マルチタスク・プログラミングのサンプルというよりは、新たなタスクを生成し、実行が終わったタスクを消去するAPIの使用サンプルです。
タスクを生成して実行するにはATTACHマクロを使います。ATTACHも基本的にはLINKマクロによるプログラムの呼び出しと同様の手順です。ただし実行単位であるタスクが変わるので、呼び出したプログラムが終了する前に呼び出し元であるATTACH発行元に制御が戻ってきます。ATTACH後は呼び出したプログラムと呼び出されたプログラムは異なるタスクによって同時に実行されることになる点がLINKと大きく異なります。
キーワードEP（あるいはEPLOC）は呼び出すプログラムのロードモジュール・メンバー名、PARAMは呼び出すプログラムへ渡すパラメーターの指定です。さらに呼び出したプログラムが終了した際の通知方法を指定します。通知方法には非同期出口ルーチンの起動とECBへのPOSTの2種類があります。どちらを選択するかはプログラムデザインで決まります。このサンプルでは非同期出口ルーチンの起動を指定しています。実行したプログラムが終了すると、OSはETXRキーワードで指定したプログラムルーチンをメインプログラムとは非同期に起動します。ATTACHされたタスクが終了したタイミングでOSはETXRキーワードで指定されたプログラムを呼び出して実行します。ATTACHを発行したプログラムの実行とは無関係に、メインプログラムの実行を一時停止してメインプログラムのタスクに割り込んで実行するので「非同期出口ルーチン」と呼ばれます。その他にも細かなパラメーターがありますが一般のアプリケーションプログラムであれば省略値でも十分です。
ATTACHから制御が戻るとGR1には生成されたサブタスクのTCBアドレス（OSがタスクを制御するためのコントロールブロック）が返ります。ATTACHマクロを使用しないで直接ATTACH SVCをする際に誤ったパラメーター・リストを指定するなどを除けば、ATTACH処理自体が失敗することはほとんどありません。EPまたはEPLOCで指定したプログラム名が誤っているなどの場合は、ATTACHが失敗するのではなく、生成されたサブタスクがS806等でABENDします。サブタスク起動時のABENDをトラップしてリカバリー処理を行う場合は、ESTAIキーワードを使用してESTAE同様のエラーリカバリールーチンを用意することもできます。しかしS806ABENDをトラップするだけならわざわざESTAIを使わなくとも、ATTACH前にLOADやCSVQUERYマクロを利用することでモジュールが存在するかどうかのエラーは事前にチェックできます。サブタスク起動後であればサブタスク側でESTAEマクロを使ってリカバリー環境を構築できます。

ATTACHされたタスクが終了したら、DETACHマクロによってタスクを消去します。タスクの消去とはTCBの消去でもあります。タスクの終了が非同期出口ルーチンまたはECBにPOSTされてもTCBはまだ残っており、メインプログラム側ではそのTCBを参照してタスクの終了状態を調べることができます。必要な情報を収集したり、リソースをクリーンアップした後、DETACHマクロによって終了タスクのTCBを消去することを行います。

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

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

kamii — Wed, 01 Sep 2010 06:18:43 +0000

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

VSAMデータセットのバッファリング方法を変更する（その2）

VSAMデータセットを拡張形式に変更して、SMBを使用すればVSAMデータセットのアクセス・パフォーマンスはかなり向上します。特にKSDSのランダム・アクセスにおいては顕著に向上します。しかしいろいろな理由で既存のデータセットを変換するのはためらいがあるかも知れません。そのような場合はSMBほどではないにしろ、同様の効果を期待できる別の方法があります。順次アクセスであればBUFNDでバッファー数を増やすだけでもかなりの効果がありますので、ここではランダム・アクセスを前提に解説します。

Batch LSRを使う（z/OSのみ）

Batch LSR（以下BLSRとする）は、VSAMのLSR（ローカル共用リソース）をプログラムによらずに行うMVSの機能です。BLSRを使うことで、COBOLなどでI/Oのコントロールを細かく行うことができない言語で作られたプログラムでも、アクセス頻度が高いINDEXコンポーネントをメモリー常駐させたり、DATAレコードに対する大容量のソフトウェア・キャッシュを用意したりすることができます。
SMBを利用するにはVSAMデータセットを拡張フォーマットで作り直す必要がありますが、BLSRの場合はJCLのDDステートメントを変更するだけで済みます。

VSAM/KSDSデータセットBUFNI別100,000レコード検索処理時間（バッチLSR併用時）

グラフは従来からある基本フォーマットのデータセットであるVSAM/KSDSのランダム・アクセスにおける実行時間および発行されたI/O回数を示しています。左側はCIサイズをAMSデフォルトにしたもの、右側はINDEXは2KB、DATAは4KBのCIサイズにしたもので、INDEXコンポーネントのバッファー数を変更したものの実行結果です。バッファー数0はVSAMのデフォルト値を示します。バッファー数5はAMPパラメーターでBUFNI値を変更したもの、10以上はBLSRを併用したものです。AMPのBUFNIパラメーターだけでは10を超えたバッファー数を指定しても頭打ちでしたが、BLSRの場合はバッファー数80でガクンとI/O回数が減っています。これはバッファー数80になるとINDEXコンポーネントのレコードがすべてバッファーに展開されI/Oがでなくなったことを示します。
SMBほどではないものの、INDEXをメモリー常駐させるだけでも十分な効果があることがわかります。なおこのサンプルではBLSR使用時のメモリー増加量は約6MBでした。

VSAM/KSDSデータセットBUFNI別100,000レコード検索処理時間
（バッチLSR併用しDATA用バッファ数も増やした場合）

BLSRを使用する際、DATAバッファーの数も思い切って増やせばSMB並みに効果を上げることもできます。グラフの左側はCIサイズが18KBの時にDATAバッファーを500個、右側はCIサイズが4KBの時にDATAバッファーを2500個にしたものです。メモリー増加量もSMB並みの約10MB程度に増えますが、実行時間もI/O発行回数もSMB並みのパフォーマンスを出せます。

BLSRもJCLのDDステートメントの変更で簡単に利用できます。ただし予めBLSRがMVSのIPLパラメーターでサブシステム登録されていなければ、それを行わねばなりません。サブシステム登録されていない場合はオペレーター・コマンドでも追加できます。

■SYS1.PARMLIBのIEFSSNxxパラメーター：
********************************* Top of Data **********************************
SUBSYS SUBNAME(BLSR)          /* BATCH LSR                 */
       INITRTN(CSRBISUB)
******************************** Bottom of Data ********************************

■オペレーター・コマンドで追加の場合：
SETSSI ADD,SUBNAME=BLSR,INITRTN=CSRBISUB

VSAMデータセットがDD名SYSUT1でDDステートメントに定義されている場合、BLSRを利用したアクセスを行うには次のように変更します。

//SYSUT1   DD DISP=SHR,DSN=UAP5.GRK7200.MASTER
           ↓
           ↓
//SYSUT1   DD SUBSYS=(BLSR,'DDNAME=LSRUT1,BUFNI=100,BUFND=500')
//LSRUT1   DD DISP=SHR,DSN=UAP5.GRK7200.MASTER

プログラムがアクセスするDD文をBLSRの定義に変えます。元のDD文はDD名を変更し、BLSRのSUBSYSパラメーターでそのDD名を指定します。プログラムとVSAMの間にBLSRを介在させるわけです。BUFNIやBUFNDはAMPパラメーターではなく、BLSRのSUBSYSパラメーターで指定します。BUFNIはINDEXコンポーネントのレコードがすべて入るぐらいの大きさが効果的です。INDEXコンポーネントがどのくらいのレコードを抱えているかはAMSのLISTCATを取ればわかります。ランダム・アクセスの場合、索引さえメモリー常駐させれば十分なので、DATAコンポーネントのCIをキャッシュするBUFNDは指定しなくてもいいと思いますが、メモリーをいっぱい使ってでもかまわないから、減らせるI/Oは少しでも減らしたいのならば思い切った数を指定します。CIサイズ18KでBUFND=500、CIサイズ4KでBUFND=2500の時、メモリーは約4から5MB増えた記録が残っていました。

Batch LSRはMVS固有の機能なのでMSPとVOS3では使えません。なおVOS3には似たような機能としてHAF（VSAM高速アクセス機能）というのがあります。ただし展開先は空間固有のリージョンではなく、CSAもしくはデータ空間となっています。MSPにも同等の機能があるかも知れませんので、必要ならMSPのマニュアルなどで探してみてください。
なお昔はINDEXのアクセス速度を向上させるために、KSDSデータセットを作成する際に、IMBEDあるいはREPLICATEというオプションがありました。IMBEDは索引コンポーネントの一部であるシーケンスセットという部分をDATAコンポーネントの中に書いてしまうもの、REPLICATEは1つのトラック内に同じ索引レコードをいくつも書いてしまうもので、索引が10レコードあるとそれだけで10トラック使ってしまうものです。スペース量を犠牲にしてでもこんなことをしていたのは、ディスクの回転待ち時間やアクセスアームの移動時間を少しでも減らして索引のI/O効率を上げるためでした。トリッキーですがハードウェアの構造的な特性を利用した苦肉の策でもありました。しかし現在のz/OSではもはやこのようなオプションはサポートされていません。大きな理由は現在のハードディスクには十分な量のキャッシュメモリーが積まれているため、このような工夫をしてもパフォーマンス上のメリットがなくなったからです。そうなると余計なスペース量を使うなどのデメリットだけが残ってしまいオプション機能として残す意味はなくなります。MSPやVOS3ではまだ残っているオプション機能かも知れませんが、使うメリットはほとんどないかと思います。

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

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

kamii — Mon, 23 Aug 2010 08:07:08 +0000

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

VSAMデータセットのバッファリング方法を変更する

KSDSのランダム・アクセスにおいては単にBUFNIでINDEXバッファー数を増やしても、INDEXコンポーネント自体へのI/Oは避けられません。同じランダム・アクセスでもRRDSと違い直接DATAコンポーネントをアクセスするのではなく、キーに対応したレコードを探すためにINDEXコンポーネントをアクセスする必要があり、どうしてもI/Oそのものが増えてしまいます。
そこでINDEXコンポーネントをメモリーに上げてしまい、メモリー内で索引を探すことでパフォーマンスを上げる方法がいくつかあります。INDEXはDATAコンポーネントに比べれば格納データ量が小さいため、メモリーに上げてしまっても数十から数百KB程度で収まることが多いので、極端にページングが増えることもありません。細かなI/Oを小刻みに出し続けるよりはるかにオーバーヘッドは少ないです。

拡張フォーマットのVSAMに変換する（z/OSのみ）

VSAMデータセットを拡張フォーマットVSAM データ・セットとして作成することができます。拡張フォーマットにすることでデータの圧縮やストライピング、4GBを超える大容量サイズなどのオプションも利用可能になりますが、必ずしもそれらの機能を必須で使う必要はありません。ここではその目的をSMBによるデータセット・アクセスを行うためとします。
SMB（システム管理バッファリング）はDFSMSdfpの機能でより効率のよいバッファリング制御によってI/Oパフォーマンスを向上させます。特にランダム・アクセスにおいては、CIアクセスのバッファー管理方式をLSR（ローカル共用リソース）方式に自動的に変更します。このため複数ブロックを単にまとめて先読みなどをするのではなく、バッファをキャッシュ・メモリーのように扱うことができます。これによってINDEXコンポーネントをメモリー上に常駐させるような制御ができます。
LSRは古くからVSAMの機能として提供されていましたが、使用するにはアセンブラー言語によるプログラミングが必要でした。SMBはDFSMSによって実装された機能で、対象となるVSAMデータセットをSMS管理データセットとして作成する必要がありますが、COBOLなど言語仕様でLSRを利用できないプログラムでも、プログラムを直すことなくLSR方式でバッファリング制御ができるようになります。

拡張フォーマットVSAM-KSDSデータセットBUFNI別100,000レコード検索処理時間

グラフはSMSの拡張フォーマット・データセットとして作成したVSAM/KSDSのランダム・アクセスにおける実行時間および発行されたI/O回数を示しています。左側はCIサイズをAMSデフォルトにしたもの、右側はINDEXは2KB、DATAは4KBのCIサイズにしたもので、それぞれJCLのDDステートメントでAMPパラメーターによるバッファー数を変更したものの実行結果です。バッファー数0はVSAMのデフォルト値を示します。拡張フォーマットであっても従来通りのバッファー制御ではパフォーマンス面でもさして違いはありませんが、ランダム・アクセスに適したSMBバッファリングを指定するとI/O回数は激減し、実行時間もそれに応じて短縮されています。CIサイズやINDEXレベルでの違いはありますが、概ね実行時間で約1/3に、I/O回数で1/5から1/3に短縮されています。

SMS拡張フォーマット・データセットであっても、ランダム・アクセスであればDATAコンポーネントは小さめのCIサイズの方が、パフォーマンス面では有利ではあります。しかしSMBを使用した場合はデフォルトCIサイズ（DATAコンポーネントは大きめ）のままでも十分なパフォーマンスが得られています。こうしてみると昔のようにいろいろ考え試行錯誤しながら最適なCIサイズを見つける、などということをしなくてもシステムに任せてしまう方が得策です。z/OSに関して言えば、VSAMはSMS拡張フォーマットに移行して、適切なSMBバッファリング方法を選択する、のがVSAMアクセスのパフォーマンス・チューニングの早道となるようです。

拡張フォーマットVSAM データ・セットはAMSのDEFINE CLUSTERでDSNTYPEにEXT属性を定義したDATAクラスを指定すれば割り振ることができます。

//ALLOCATE EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  DEFINE CLUSTER -
        (NAME(dsname)        -
         DATACLAS(EXTVSM)    -
         STORCLAS(SGRP1)     -
         RECORDS(100000)     -
         RECORDSIZE(500 500) -
         KEYS(10 0)          -
         REUSE INDEXED)
//

作成後にAMSのREPROでローディングすれば、そのままVSAMデータセットとして使用できます。あるいは次のようにICEGENERユーティリティーで既存のVSAMデータセットから直接コピーして作成してもかまいません。z/OS V1R7以降であれば、DDステートメントのDATACLASに代えてDSNTYPE=EXTREQを指定して割り振ることもできます。

//GENEXTVS EXEC PGM=ICEGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DISP=SHR,DSN=UAP5.GRK7200.MASTER
//SYSUT2   DD DISP=(,CATLG),DSN=UAP5.GRK7200.MASTER.EXTEND,
//            SPACE=(TRK,(1000,100),RLSE),
//            RECORG=KS,LRECL=500,KEYOFF=0,KEYLEN=10,
//            STORCLAS=SGRP1,DATACLAS=EXTVSM
//SYSIN    DD DUMMY
//

SMBを使用するには、DDステートメントにAMPパラメーターでACCBIASを指定します。DOはランダム・アクセスを最適化することを示します。シーケンシャル・アクセスの最適化であればSOです。ACCBIASパラメーターはDATAクラスでRecord Access Bias=SYSTEMを定義していれば不要ですが、プログラムがACBのMACRFでDIRとSEQの両方を指定していると順次アクセスも考慮されたバッファリング制御となってしまいます。MACRFがDIRになっていればACCBIAS=DOと同じになります。ACBのMACRFはCOBOLであればFILE-CONTROLのACCESS ISがDYNAMICかRANDOMかの違いで決まります。ACCESS IS RANDOMでなければACCBIAS=DOを指定した方がランダム・アクセスの処理では実行速度がより向上します。

//SYSUT1   DD DISP=SHR,DSN=UAP5.GRK7200.MASTER.EXTEND,AMP='ACCBIAS=DO'

なおACCBIASがDOの場合、アクセスするデータセットの大きさにもよりますが、数MBから数十MBもの仮想メモリーを必要とします。ここに紹介したサンプルでは約10MBの拡張リージョンが追加で使われました。しかしメモリー量に見合うだけの効果はあると言えるでしょう。

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

kamii — Tue, 17 Aug 2010 03:50:55 +0000

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

VSAMデータセットのCIバッファーを増やす（ランダム・アクセス）

VSAM/KSDSデータセットBUFNI別100,000レコード検索処理時間

KSDSのキーによるランダム・アクセスにおいて、INDEXコンポーネントのアクセス・バッファー数のみを増やしてみた場合の例です。グラフはバッファー数と実行時間および発行されたI/O回数と使用されたリージョン内メモリーサイズを示しています。実行時間はVSAMがデフォルトで設定するCIサイズ（18432バイト）でデフォルトのINDEXバッファー数（1個）の実行時間を1とした場合の、相対数値です。
ランダム・アクセスではシーケンシャル・アクセスほどバッファー数増加の効果は出ません。左のグラフ（CIサイズ512バイト：INDEXレベル3）の例では、インデックス・バッファー数が4になったところで効果が頭打ちになっており、右のグラフ（CIサイズ2048バイト：INDEXレベル2）の例では、インデックス・バッファー数が2になったところで効果が頭打ちになっています。適切なインデックス・バッファーの数はINDEXレベルと大きな関係があり、INDEXレベルが大きければそれだけ索引レコードのアクセス回数が増えるので、インデックス・バッファーが多いと索引部のI/O回数は削減されます。しかしもう少し何とかできないか、という感じです。
なお、ランダム性が高いほどDATAコンポーネントのバッファーは増やさない方がいいです。一度にいくつものデータCIを繋げて読んでも、結局使われずに捨てられるだけです。しかも個々のI/O時間（データの転送時間）は長くなるので、逆に実行時間が増えてしまうことにもなります。

INDEXコンポーネントのバッファー数の変更は、JCLのDDステートメントにAMPパラメーターでBUFNIを追加することで行うことができます。

//KEYFILE  DD DISP=SHR,DSN=dsname,
//            AMP='BUFNI=4'

BUFNIあるいはBUFNDパラメーターではなく、BUFSPパラメーターでバッファー数ではなく、バッファーの大きさで指定することもできます。
ただしKSDSの場合、INDEXのバッファーが多く獲られるかDATAのバッファーが多く獲られるかは、プログラムがデータセットをOPENした際にデータセットをどのようにアクセス（シーケンシャル・アクセスなのかランダム・アクセスなのか）するかで変わります。COBOLのACCESS IS DYNAMICのようにどちらのアクセスも可能にするようなOPENをすると、シーケンシャル・アクセスに適したバッファー割り振りがされてしまうため、その状態でランダム・アクセスを行うと、逆に実行パフォーマンスが低下しかねません。ランダム・アクセスすることがわかっていてもプログラムが両刀使いできるように作られている場合はBUFNIで明示的にINDEXバッファーを増やす方が確実です。

DFSMSの保証スペース

kamii — Tue, 17 Aug 2010 03:14:02 +0000

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

//OUTDD    DD DISP=(,CATLG),DSN=UAP1.LARGEDS1,
//            UNIT=SYSDA,VOL=SER=(DATA01,DATA02,DATA03),
//            SPACE=(CYL,(3000,1000))

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

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

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

//OUTDD    DD DISP=(,CATLG),DSN=UAP1.LARGEDS1,
//            STORCLAS=GUARNTSP,VOL=SER=(DATA01,DATA02,DATA03),
//            SPACE=(CYL,(3000,1000))

データセットは指定されたすべてのボリューム（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 データ・セットの使用法」に解説されています。

FTP

kamii — Mon, 16 Aug 2010 08:11:41 +0000

FTP：ファイル転送プログラム（File Transfer Program）

FTPそのものが何であるかを解説する必要はないでしょう。メインフレームでもTCP/IPがサポートされてから、FTPもTCPアプリケーション（ユーティリティー）として利用できるようになっています。以前はFTPの利用を嫌うユーザーも多く「TCPは使えますがFTPは禁止です」というところもありました。最近ではどうなのでしょうか？以前ほどFTPは使わせない、というところは少ないように思います。

FTPにはクライアントとサーバーの2種類がありますが、いずれも利用できます。ただしMSPではFTPサーバーの利用にはDTSというPPが別に導入されている必要がありました（もしかしたら今ではTISP単独で利用可能になっているかも知れません）。
メインフレームと言えばサーバー・コンピューターでもありますから、FTPもサーバーで使うもの、と思われがちですが決してそんなことはありません。むしろFTPはクライアントで使う方がバッチジョブのステップに組み込めますから、自動的なデータ転送処理を行いたいときなどに便利です。

FTPサーバーは、PC上のファイル（例えばJCLやソースプログラム、業務処理用のデータ制御ファイルなど）を区分データセットのメンバーや順次データセットとして送りたい場合によく使われます。基本的には利用者が使いたいときに起動するものではなく、システムのIPL後に常駐タスク（アドレス空間）として起動されます。z/OSではTCPIPサービスの起動時に、FTPデーモンプロセスがUSS（Unix System Service）を使ってアクティブになります。いずれにせよFTPサーバーに関しては利用者の好みに合わせて機能を選択したり設定を変えたりはできません。システム管理者がセンター環境に合わせて設定した範囲での利用になります。
メインフレームのFTPサーバーを利用するクライアントは同じメインフレームに限らず、Unix、WindowsなどTCPをサポートしたプラットフォームであればかまいません。

データセットとファイルパス

z/OSのHFSでなければ、MVSではUnixやWindowsのような階層ファイルシステムではありません。しかしFTPにおけるファイル名は階層を意識したファイルパスでの指定になっています。例えばMVS（z/OS）のTCPIPのFTPでは、D:/folder1/subfolder2/JCLCOPY.txt のようなファイルパスとファイル名は、UAP1/JCLLIB/JCLCOPY のようにデータセットの修飾子で区切られたファイルパスとして表現されます。データセット名は修飾子で区切られた階層によって構成されているので、それを階層ファイルシステムのパス名のように割り当てます。データセット名の各修飾子をフォルダー名のように扱うわけです。そのためデータセットはカタログされていることが前提です。ディレクトリパスUAP1/JCLLIB、ファイル名JCLCOPY は UAP1.JCLLIB.JCLCOPY という順次データセットか、UAP1.JCLLIB という区分データセットのメンバーJCLCOPY を示します。
このようにDSNの修飾子をディレクトリに置き換えて対応させるマッピング方法を知ることは、LSコマンドなどディレクトリ内のファイル一覧を表示させたい場合に役立ちます。初期ディレクトリはFTPサーバーにログインした際のアカウント名（TSOユーザーID）です。USERID=RTJ6638でログインした場合、ログイン後に LS コマンドを入れると修飾子 RTJ6638 で始まるDSNがリストされます。その状態で CD TEST と入力すればカレントディレクトリは RTJ6638.TEST に変わり、LSコマンドを入れると修飾子 RTJ6638.TEST で始まるDSNがリストされます。先頭修飾子を UAP1 に変えたければ CD ‘UAP1′ と入力します。
しかしGETやPUTで転送の対象となるデータセットが予めわかっているなら、最終修飾子やメンバー名がファイル名になるよう階層を掘り下げなくても、’RTJ6638.TEST.DATA1′ や ‘RTJ6638.JCL(IEBCOPY)’ のようにDSNをアポストロフィで囲めば、メインフレームのデータセット名の形式で指定することもできます。各メーカーが提供するFTPソフトウェアの仕様によって細かな点は異なるので必要に応じてマニュアルなどを参照して下さい。

FTPによっては、DD名をサポートしている場合もあります。例えばz/OSでは、メインフレーム側のファイル名として、//DD:ddname が指定できます。これはJCLにDD名ddnameで定義されているDDステートメントに定義されたデータセットを示します。この場合、ターゲットのデータセットはカタログされていなくてもかまいません。UNITとVOL=SERパラメーターでデータセットの場所を特定することができます。VOS3のXTCPでは、DD(ddname) と指定します。また INTRDR はJESのリーダーを示し、転送したファイルをJCLとしてサブミットする場合に使われます（z/OSでは事前にSITEコマンドが必要）。なおDD名指定のファイル転送はFTPクライアントで使用されます。

文字コードの変換

異なる文字コードを持つプラットフォーム間の転送では、文字コードの変換が必要です。送り手、受けてどちらが変換するかは考え方がいろいろあります。「受け手が自分と違うコードなら変換する」という仕様なら同じ文字コードであれば変換が不要なのですっきりするとか、サーバーとクライアントならサーバー側でやるべき、とかです。しかし現実メインフレームの場合は、送り手だろうが受け手だろうが、メインフレームが他と異なる特有の世界のコードを使っているのが実情なので、クライアントであってもメインフレーム側のFTPで文字コードを変換するのが一般的です。メインフレームのFTPでは単にECBDICとASCIIの変換だけでなく、日本語コードをShiftJISやEUCなど相手側ホストの文字コードに合わせて変換できます。z/OSのFTPであれば、シフトコードの位置に擬似コード（文字→や←）を入れてそこにシフトコードがあることを示したり、バイナリー転送時に可変長レコードのデータセットのRDWを付加して元のレコードが何バイトなのかを識別できるようにしたり、などきめ細かなコード変換機能を持っています。

FTPの使用サンプルはこちらのページに記載しています。

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

kamii — Wed, 11 Aug 2010 23:37:18 +0000

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

VSAMデータセットのCIバッファーを増やす（シーケンシャル・アクセス）

VSAMデータセットでは、CIをアクセスするバッファーを増やすことで、一度にまとめてCIをアクセスできますから順次データセット同様にデバイスへのI/O回数を減らすことができます。特にESDSやKSDSのシーケンシャル処理では順次データセット同様に、その効果は大きいです。

グラフはバッファー数と実行時間および発行されたI/O回数と使用されたリージョン内メモリーサイズを示しています。実行時間はVSAMがデフォルトで設定するCIサイズ（18432バイト）でデフォルトのバッファー数の実行時間を1とした場合の、相対数値です。CIサイズを4KBに縮めるとそれだけで実行時間は2倍弱、I/O回数は4倍強に増えます。バッファー数を20個に増やせばやっと追いつく感じです。
VSAMもQSAM同様にバッファー数を単に多くすればよい、というわけではなくある程度のところで効果は頭打ちになります。VSAMではDATAコンポーネント・アクセスのデフォルト・バッファー数は2個です。VSAMでも大量のレコードが格納されたデータセットを順次アクセスするプログラムの場合、バッファー数を増やすことでデータセットのI/O処理の効率を上げることができます。CIサイズの大きなデータセットでは20から40個程度。CIサイズが小さい場合で40から80個程度。過去に試した結果では、それ以上増やしてもメモリー使用量の増加に見合うだけの実行時間短縮は望めませんでした。

デフォルトでも最小限のバッファリング制御がされていますが、性能に大きく寄与するほどではありません。しかし小さなCIサイズのデータセットほどバッファーを増やす効果は大きいので、機会があれば試してみて下さい。KSDSの場合で、主にキーによるランダム・アクセスをするが、たまにシーケンシャル・アクセスでの処理も行う、といったデータセットで小さめのCIサイズを選択しているような場合は、シーケンシャル・アクセス時にはバッファー数を増やすことで、大きなCIサイズ並のパフォーマンスを得られます。

DATAコンポーネントのバッファー数の変更は、JCLのDDステートメントにAMPパラメーターでBUFNDを追加することで行うことができます。

//SEQFILE  DD DISP=SHR,DSN=dsname,
//            AMP='BUFND=20'

AMSのREPROやICEGENERではプログラム自身で最適なI/Oを行うのでJCLでのバッファー数指定は効果がありません。VSAMとPSデータセット間のロード／アンロードであればAMSのREPROではなく、ICEGENERユーティリティーでコピーした方がパフォーマンスは格段にいいです。従来からあるIEBGENERユーティリティーではなく、DFSORTによって提供されるICEGENERです。PSとVSAM間の相互コピーも簡単なJCLで行うことができます。

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

kamii — Thu, 05 Aug 2010 05:50:42 +0000

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

順次編成データセットのブロックI/Oバッファーを増やす

順次データセットのアクセスでは、バッファー数を増やすことで一度に複数個のブロックを読み書きすることができます。ブロックサイズの大きさは一度に何レコードをまとめて読み書きするかでしたが、バッファーの数は一度に何ブロックをまとめて読み書きするかということです。バッファー数を増やすことで複数のブロックを先読み（書き戻し）することでデバイスへのI/O回数を減らすことができます。

PSデータセットBUFNO別1,000,000レコード読み込み処理時間

グラフはバッファー数と実行時間および消費されるメモリー量を示しています。読み込み処理の例ですが、書き込み処理であっても同様のカーブを描きます。バッファー数は1から255個の範囲で指定できますが、これも多くすればよい、というわけではなくある程度のところで効果は頭打ちになります。QSAMおよびCOBOLによる一般の順次データセット・アクセスではバッファー数のデフォルトは5個です。テープ上のLBIデータセットでは2個、PS/Eデータセットは2×トラックあたりのブロック数×ストライプ数で求めた個数（圧縮データセットの場合は1個）です。
大量のレコードが格納された順次データセットをアクセスするプログラムの場合、バッファー数を増やすことでデータセットのI/O処理の効率を上げることができます。ただし増やしてもせいぜい10から20個程度。ブロックサイズが小さい場合で20から40個程度。過去に試した結果では、それ以上増やしてもメモリー使用量の増加に見合うだけの実行時間短縮は望めませんでした。またSYSOUTデータセットへの書き込みに関しては、JES2が独自の処理を行っているのでアプリケーション側でのバッファー個数はスプール書き込みのパフォーマンスに影響しません。

デフォルトでもバッファリング制御がされているため、すでに適切なブロックサイズを持つデータセットであれば劇的に実行時間が減るわけではありませんが、小さなブロックサイズほどBUFNOの効果は顕著です。何らかの理由で小さいブロックサイズに固定してしまっているアプリケーション、ブロックサイズは小さいままだが昔から延々と使われていて今さら直せないアプリケーション、などでは少しの手間でそれなりの効果を期待できます。上のグラフ（右側）のLRECL=512でBLKSIZE=5120のケースでは、ELAP時間は約6割に減っています。これは1時間掛かるバッチが36分に短縮されることを意味します。実際にはさまざまなジョブが他にも実行されるため単純には行きませんが、デバイスへのI/O回数の削減はI/O時間だけでなく、I/Oの要求やI/Oの完了を処理するためのOS側のCPU使用量も減ることになるので、他のジョブも含めたシステム全体で見れば決して意味がないことではありません。

バッファー数の変更は、JCLのDDステートメントにDCBパラメーターを追加することで行うことができます。

//SYSUT2   DD DISP=SHR,DSN=dsname,
//            DCB=(BUFNO=10)

バッファー数はプログラムが使用するリージョン内のメモリー量に大きく影響を与えます。データセットのブロックサイズが大きいほど顕著です。消費されるリージョン内のメモリーはブロックサイズの倍数単位で増えることは知っておくべきです。特に複数のデータセットを同時にアクセスするプログラムが、すべての順次データセットのバッファー数を変えれば、増える量はさらに倍増します。しかし適切なバッファー数は増えたメモリー量に見合うだけの効果があります。
なおI/Oバッファーは、z/OSのCOBOLプログラムなら16MBラインより上の拡張リージョンに作られるので、通常はREGIONパラメーターの値を気にする必要はありません。ただし古くから使われているアセンブラーのプログラムで31ビットモードDFPに対応していなかったり、MSPの場合は、SAMのI/Oバッファーは16MBラインより下の基本リージョンに作られますから、REGIONサイズの調整は必要になります。