ISPFとISPFコマンド

By kamii - Last updated: 水曜日, 1月 5, 2011

ISPF(Interactive System Productivity Facility)とISPFコマンド

ISPFはエディターやデータセット・リストなど、z/OSにおけるJCLやプログラムの開発ツールとして知られています。しかしそれらはISPFの機能の一部にすぎません。ISPFはコマンドベースのTSOにおいて、画面パネルを利用した対話型プログラムの実行プラットフォームとして動作します。エディターもDSLISTもISPFを利用して作られた1つのISPFアプリケーションプログラムです。
ISPFの概要はこちら(z/OSのしくみ:基礎編:TSOとISPF)にも解説があります。

ISPFは画面パネルに表示されたガイダンスに従って、画面内に用意されているフィールドに必要なパラメーターをセットして実行すれば、細かなコマンドなどを覚えなくても大抵の操作ができるようになっています。WindowsのGUIほどではないにせよ、現在のISPFにはポップアップ・ウィンドウやプルダウン・メニューを実装する機能もあります。予めマニュアルなどを読まなくても直感で使えるアプリケーションを作れるように出来ています。
そのためプログラム開発ツールでもあるISPF/PDFも、マニュアルを読んだりコマンドを覚えなくてもパネルを見れば直感ですぐ使えるようになります。しかしISPFにもさまざまなコマンドがあって、それらを覚えることでより便利に、より多機能に、よりスマートにISPFを利用することができるようになります。ここではそれらのコマンドのうちのいくつかを紹介します。


ISPFシステム・コマンド

ISPFコマンドは、パネル内のOptionあるいはCommandフィールドに入力できます。ISPFダイアログであれば基本的にどのパネルでも入力できます。コマンド入力によってパネルが切り替わっても、そのパネルの終了後は元のパネルに戻ります。


他にも多くのコマンドがあります。ISPFコマンドの詳細は「ISPFユーザーズ・ガイド第1巻」に解説されています。ISRDDNユーティリティーの詳細は同マニュアルの付録G. ISRDDN 診断ユーティリティーに解説されています。

Filed in ISPFとSDSFのちょっと得する使い方, キーワードから(何が知りたいですか)

文字コード変換テーブルの参照

By kamii - Last updated: 水曜日, 1月 5, 2011

今ではTCP/IP(FTP等)によるメインフレームとWindowsやUnix間でのファイル転送は一般的に行われています。漢字などの日本語データは文字コードの違いから意図しない文字に変換されたり、独自の変換を行いたい場合があります。TCP/IPの通信システムが使用する漢字コードの変換テーブルは公開されていて、カスタマイズも可能です。


DBCS変換テーブルの参照


DBCS変換テーブルの変更

Filed in 知っておくと便利なテクニックなど

画面スクロール量の計算(加算命令で引き算)

By kamii - Last updated: 水曜日, 1月 5, 2011

同じ値を±の符号を入れ替えて計算したい場合があります。例えば画面のスクロール量を計算するようなことがあります。押されたキーがPF8キーなら表示中データを前方へスクロールさせ、PF7キーなら同じ量を後方へスクロールさせるような場合です。
そのような場合、すぐに思いつくのがADD命令とSUBTRACT命令の使い分けです。

         LH    R0,SCRAMONT              LOAD SCREEN SCROLL AMOUNT
         CLC   0(3,R1),=CL3'UP.'        BACKWARD SCROLL ?
         BE    UPSCROLL                 YES,
         A     R0,NEXTROW               NO, ADD SCROLL AMOUNT          +
                                            FOR FORWARD SCROLLING
         B     SETROWNO
UPSCROLL DS    0H
         S     R0,NEXTROW               SUBTRACT SCROLL AMOUNT         +
                                        FOR BACKWARD SCROLLING
SETROWNO DS    0H
         ST    R0,NEXTROW               SAVE THE 1ST ROW OF SCROLLING

プログラムとしては正しいですが、符号だけが異なる同じ値の加減算であれば、±の符号を入れ替える方が少しスマートになります。引き算は補数の加算で実現できます。

         LH    R0,SCRAMONT              LOAD SCREEN SCROLL AMOUNT
         CLC   0(3,R1),=CL3'UP.'        BACKWARD SCROLL ?
         BNE   *+4+2                    NO,
         LCR   R0,R0                    YES, SET NEGATIVE VALUE
         A     R0,NEXTROW               ADD SCROLL AMOUNT              +
                                            FOR NEXT SCROLLING
         ST    R0,NEXTROW               SAVE THE 1ST ROW OF SCROLLING

2の補数はLCR命令で求めます。GR0に入っているのが正の整数と決まっていればLNR命令でも同じことですが、補数と言うことでLCRを使ってます。
アセンブラーに限らず、引き算は負の数の足し算と同じ、というようにいろいろ視点を変える発想ができると柔軟なプログラミングに繋がります。

Filed in MVS実践アセンブラー・プログラミング

11.2DASD空きスペースの取得(LSPACE)

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

ボリュームにどのくらいの空きスペースがあるかを知りたい場合は、OBTAINマクロで空きスペース情報を管理するDSCBや、CVAFでVTOCインデックスデータセットの空きスペースマップを読み込み、それを解析することもできます。ボリューム内の各空きトラックの位置やサイズを詳細に抽出して、より細かな空きスペース状況を知る必要があれば、DSCB5やVTOCインデックスデータセットへのアクセスは避けられませんが、ISPF3.4のVオプションのように、空きスペースの総量や空きエクステント数などの要約情報でよければもっと簡単な方法で入手できます。


ボリュームの空きスペース量の要約を求める

LSPACEマクロを使用するには求めるボリュームのUCBアドレスもしくはUCBのコピーが必要です。これはUCBLOOKもしくはUCBSCANマクロで入手・作成ができます。LSPACEマクロはAPF許可不要ですが、UCBLOOKマクロおよびUCBSCANでのUCBアドレスの取得はAPF許可プログラムでなければなりません。非APFである一般プログラムの場合は、UCBSCANマクロでシステムのUCBのコピーを自プログラム内に作成して、そのアドレスを指定することができます。
LSPACEは空きスペースの要約をメッセージテキストの形で返します。内容は次の通りです。

先頭から、空きシリンダー総数、追加の空きトラック数、空きエクステント数、最大の空きエクステントのシリンダー数、最大の空きエクステントの追加のトラック数、の順に5つの情報が返ります。これはISPF3.4のVオプション(VTOC Summary Information)に示される、Free Space情報と同じです。

標準形式では空き容量は9999までしか表示できません。3390-9型以上の大容量ボリュームでは4桁では足りないので拡張形式のメッセージで返答させる必要があります。もちろん3390-3などの9999シリンダー以下の容量のボリュームでも利用できます。返答される項目は標準形式と同じで、数値の桁数が4から6桁に増えているだけです。
その他、DATAパラメーターを使用して、空き情報をメッセージではなくバイナリーのデータで返答させることもできます。返答域は36バイトでLSPACEマクロのMF=(D,DATA)でマッピングできます。メッセージテキストによる返答よりも追加の情報(VTOCの空きDSCB数やフラグメント化指標値など)が返ります。空きスペース量を計算処理するような場合はDATAでの返答が便利でしょう。
サンプルでは単一のボリュームに対しての空きスペース情報を求めていますが、UCBSCANはシステム内のデバイスのUCBを順次に戻すことができるので、複数のDASDボリュームの空きスペースをリストアップするようなプログラムに応用できます。

MSPとVOS3でも標準形式の返答であればLSPACEはサポートされています。ただしマクロ命令は提供されていないので、SVC命令を直接コーディングすることになります。

このコードはMVSでも有効ですが、MVSの場合はLSPACEマクロを使うべきです。なおMVSのLSPACEマクロの展開コードは後年になって新たにサポートされたもので、MSPやVOS3では使えません。

関連マニュアル:

  • MVS:z/OS DFSMSdfp 拡張サービス(LSPACEマクロ)
  • z/OS MVS プログラミング: アセンブラー・サービスガイド(UCBSCANマクロ)
  • z/OS MVS プログラミング: アセンブラー・サービス解説書 第2巻(UCBSCANマクロ)
  • Filed in 中級編

    11.1カタログの探索とデータセット情報の取得(LOCATEとOBTAIN)

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

    一般のデータセットへのアクセスだけでなく、カタログやDASDボリュームのVTOC(索引)にアクセスするためのサービスも提供されています。現在ではわざわざプログラムなどを作らなくても、ISPFやユーティリティ、ISVソフトウェア製品などを使えば事足りることが多いですが、どのようなサービスによって実現できるかを知っておくだけでもいいでしょう。


    データセット名からカタログされているボリューム名を求める

    データセット名からカタログされているボリューム名を求めるにはLOCATEマクロを使用します。LOCATEマクロはカタログ項目を読み取るためのサービスで、いくつかの機能がありますが、ここではDSNを入力にして、カタログされているボリューム名を求めています。ボリューム名は1つとは限らず、データセットは複数のボリュームに分散して作成されることもあるので、ボリューム・リストの形式で戻されます。HSMによってマイグレートされたデータセットの場合は、元のボリューム名ではなく「MIGRAT」という名前が返ります。
    CAMLSTはLOCATEマクロの入力パラメーター・リストです。

    カタログされているすべてのデータセットをリストアップするような場合は、CSI(カタログ検索インターフェース)を利用すればAMSのLISTCATのようなプログラムを作ることができます。MSPとVOS3にはありませんが、代わりにGENERIC LOCATEやカタログレコードを順次に読むためのインターフェースがあります。それらはMVSでも同じですが、現在ではCSIを使用する方がいいでしょう。MSPもVOS3もGENERIC LOCATEやカタログレコードの順次アクセスはマニュアルで公開していないため、必要ならメーカーに問い合わせて下さい。


    データセット名とボリューム名からデータセットの属性情報を求める(非VSAMデータセット)

    データセット名とボリューム名がすでにわかっている場合(あるいはLOCATEによってボリューム名を得た場合)、そのデータセットの各種の属性情報、例えば編成種別、レコード形式、レコード長、ブロック長、スペース量、作成日やアクセス日などを読み取ることができます。これらの情報はVTOC内のDSCBレコードに格納されており、OBTAINマクロによってDSCBレコードを読み取ることができます。編成種別やレコード形式、長さなどは、データセットをOPENすればDCBに返されますが、DSCBを読み取ればわざわざOPENしなくてもそれらを得ることができます。
    OBTAINもLOCATE同様にCAMLSTマクロによって入力パラメーター・リストを作ります。ここではデータセット名を入力にして、対応するDSCBレコード(DSCB1)を読み取っています。返されるのはDSCBのデータ部(96バイト)とDSCBレコードのCCHHR(5バイトのボリューム内ディスクアドレス)です。
    なお指定したDSNがVSAMのクラスター名の場合、返答域には最低限のフィールドが設定されたダミーのDSCBが作成され、DSCBのCCHHRには0が設定されます。


    ボリューム内に格納されているデータセットをリストアップする

    OBTAINマクロを使い、VTOC内のDSCBを順次に読み取ることによって、DASDボリューム内のデータセットの一覧を作ることができます。ここではDSCBのCCHHR(ボリューム内ディスクアドレス)を入力にして、対応するDSCBレコード(DSCB1)を読み取っています。返されるのはDSCBのキー部(44バイト)とデータ部(96バイト)です。
    VTOCの先頭にはDSCB4というVTOC自身を示すレコードがあります。このレコードのキーには44バイトのx04が設定されており、DSNに44バイトのx04を指定することで、DSCB4を読み取ることができます。返されたDSCB4のCCHHRを利用してDSCB4に続く残りのDSCBレコードを順次に読み取ることができます。
    サンプルではDSCB4の読み取りにはOBTAIN/SEARCHを、以降のDSCBレコードの読み取りにはOBTAIN/SEEKを使っています。VTOCの終端はDSCB4に設定されているので、そこに示されたトラック内のDSCB4を全部読んだところで処理終了としています。読み込むべきDSCBのCCHHRは1トラック内に格納されるDSCBレコード数に基づいて計算します。この値もDSCB4に格納されています。1トラック分のDSCBを読んだら、トラックアドレスを1つ増やしてレコード番号は1に戻します。トラックアドレスが14になったら次は15ではなく、シリンダーアドレスを1つ増やしトラックアドレスは0に戻します。現在のディスク(3390など)は1シリンダー15トラック(0から14)なので、シリンダーあたりのトラック数を15と決めて処理していますが、本来はデバイスの特性に応じて変動してもいいようにロジックを作るべきです。例えばDEVTYPEマクロを使用すればシリンダーあたりのトラック数を求めることができます。
    データセットを示すDSCB1以外はすべて読み捨てていますが、データセットが占めるスペース量などを正しく知る場合には、関連するDSCBも読む必要があります。またDSN以外はプリントしていませんが、実際には編成種別、レコード形式、レコード長その他の情報を編集して出力しなければ実用にはなりません。それらもDSCB1に格納されています。VTOCやDSCBレコードの詳細についてはマニュアル「z/OS DFSMSdfp 拡張サービス」に記載されています。

    実践のプログラミングにおいて、VTOC内の複数のDSCBを読み取るような処理では、OBTAINで1つずつDSCBを読む代わりにCVAFという別のVTOCアクセスサービスを使うことが多いです。OBTAINはインデックスVTOCがサポートされるより前のMVSからある古典的なAPIですが、インデックスVTOCの場合はボリューム内の空きスペースを管理するDSCB5は事実上使われないので、OBTAINでは空きスペース量と場所などを知ることができませんが、CVAFを使うことでインデックスVTOCであってもそうでなくても処理することができます。しかしCVAFはOBTAINに比べると複雑なAPIなので、まずはOBTAINを使ってDSCBを読み取り、DSCBやVTOCの構造を理解してからCVAFを使う方がわかりやすいと思います。
    なおOBTAINやLOCATEに関しては基本的な機能はMSPとVOS3でも互換があります。MSPではCVAFも一部を除き同様のAPIがサポートされています。


    関連マニュアル:

  • MVS:z/OS DFSMSdfp 拡張サービス
  • z/OS DFSMS: カタログの管理
  • MSP:システムプログラミング手引書 データ管理編
  • DM/DSE運用手引書
  • Filed in .基礎編

    10.3定義されているDD文の取得(TIOTの探索)

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

    JCLにどのようなDD文が定義されているかを知りたい場合は、TIOTをスキャンします。TIOT(Task Input/Output Table)は、JCLに定義されたDD文に基づいて作成される制御表で、ステップ開始時のデバイス・アロケーション処理の過程で作成されます。TIOTはジョブ名やステップ名が格納されているヘッダー部分の後に、定義されたDD文に対応したDDエントリーが続きます。DDエントリーにはDD名、JFCBへのポインタートークン、関連デバイスのUCBアドレス、制御用のフラグ・フィールドなどが格納されています。


    JCLに定義されているDD文のリストを作る(TIOTを直接たどる)

    TIOTのアドレスを得たら、先頭のDDエントリーに位置付けます。DDエントリーの先頭にはそのエントリーの長さが入っているので、それを元に順次たどって行くことができます。DD名だけでなく、DD文に定義されたパラメーター情報を得るためにJFCBを求めることもできますが、JES2のJOBCLASS定義によってJFCBが拡張SWA領域に置かれていると、TIOTにはJFCBアドレスではなくSWAREQマクロで使用するトークン値が入り、JFCBを求めるにはSWAREQマクロを使用しなければなりません。JFCBを得るなら代わりにRDJFCBマクロを発行してもかまいません。


    EXTRACTマクロの代わりに、TCBから直接TIOTをたどっても同じことができます。


    MSPはMVSと同じ方法でTIOTを求められますが、VOS3の場合はTCBあるいはEXTRACTで求めたTIOT(ヘッダ)アドレスからDDエントリーを求める場合、GETTIOTマクロを使います。このマクロを使えばTIOTのDDエントリー部が16MB以上の領域に展開されている場合でも正しい探索が可能になります。


    JCLに定義されているDD文のリストを作る(DSABからTIOTを求める)

    MVSにおいて、TIOTが16MBより上のSWA領域に作られているXTIOTの場合は、従来のTIOT探索では求めることができません。JCLに定義されたDD文に関しては16MB未満の領域に作られますが、動的割り振りによって割り振られたデータセットやデバイスにおいてXTIOT要求の指定があると、その割り当てに関するDDエントリーは16MBより上の領域に作成され、16MBより下の領域にあるTIOTとは切り離されて管理されます。プログラム内でXTIOTを使用するダイナミック・アロケーションを行っていない限り、XTIOTを意識する必要はありませんが、もしXTIOTも含めてDDエントリーをたどる場合は、DSAB(Data Set Association Block)のチェインをたどり、DSABから対応するTIOTを求める方法があります。
    XTIOTはDB2など、一部のシステムプロダクトで使用されています。

    Filed in 中級編

    DASD

    By kamii - Last updated: 金曜日, 11月 26, 2010

    DASD(Direct Access Storage Device):直接アクセス記憶装置

    メインフレームの世界ではハードディスクのことを「DASD」とも言います。ダスドと読まれますが、英語圏の人にはダズディと言わないと通じないです。同じようなハードディスクを使っているのにPCの世界ではDASDという言葉はほとんど使われません。これには歴史的な経緯もあります。

    かつて、直接アクセスができる記憶装置にはディスク装置の他にもいくつかの種類がありました。例えば磁気ドラム装置というのがあり、1960年代から70年代ぐらいまで使われていました。ドラムというのはその名の通り、バスドラ(大太鼓)みたいな記憶メディアがグルグルとぶん回り、回りに読み書きのための磁気ヘッドがついているものです。ディスクでは記録部分は円盤状でそれが回転するということでは似てましたが、大きく違うのがヘッドが動かずに固定されていることです。トラックの数だけヘッドがあると考えて下さい。ディスクの場合は目的のトラックをアクセスするためにヘッドが動きますが、ドラムではそれがないのでFixed Headとも言います。ディスクと違いアクセスアームが動かないので、同じ回転速度なら構造的には早いのですが、やがては半導体メモリーなどに置き換わりなくなっていきました。
    そんなわけで、当時は直接アクセスできるデバイスはディスクだけとは限らなかったので、ディスク、ドラム、その他を総称してDASD(直接アクセス記憶装置)としたわけです。

    IBM 2305 fixed head storage

    IBM 2305 fixed head storage


    IBM 2305 fixed head storage(US IBM, IBM Archivesより)











    現在では、直接アクセス記憶装置=ハードディスク装置となっているので、DASDはディスクの同義の意味で使われてます。しかしPCなどでは日常的に使われることはなく、メインフレーム特有の用語となってしまっています。

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

    SYSINデータセットとは

    By kamii - Last updated: 金曜日, 11月 26, 2010

    SYSIN[データセット]

    出力のSYSOUTに対して、入力データセットとなるのがSYSINです。正確には「(JCL)ストリーム内データセット」と言い、SYSOUTのOUTに対するINであることや、OSのユーティリティーの多くがそのDD名にSYSINを使用することから、SYSINデータセットと呼ばれます。JCLのDDステートメントにDSNパラメーターの代わりに「*」を指定することで、次の行からJCLステートメントではなく、プログラムへ渡す入力データを記述することができます。
    SYSINデータはユーティリティーやアプリケーションプログラムの機能コマンドや制御パラメーターとして非常によく利用されています。

    SYSINデータ(ストリーム内データセット)は、「*」を定義したDDステートメントの次の行から書き始めます。書き出し位置(開始桁)や構文、内容はまったくの自由で、入力するプログラムの仕様で決まります。この例ではAMSユーティリティーのDEFINE CLUSTERコマンドを記述しています。
    SYSINデータはJCLと同じ80バイトの固定長レコードのデータです。80を超える長いレコード長も取り扱えますが、あまり一般的ではないと思われます。

    SYSINデータの終わりは、/*ステートメントまたは別のJCLステートメント(//)によって示します。

    別のジョブのJCLそのものを、SYSINデータとして記述したい場合があります。この場合は、DDステートメントに「*」ではなく「DATA」パラメーターを定義します。

    /*ステートメントそのものも、SYSINデータとして記述したい場合は、DLMパラメーターで区切り文字を指定できます。


    SYSINからのデータ入力

    COBOLにせよアセンブラーにせよ、SYSIN(ストリーム内データセット)を読み込むには、固定長レコードの順次データセットとして読み込みを行えばいいのです。SYSOUT同様にプログラム自身ではSYSINから読むとかDISKのデータセットから読むとかの意識は基本的にしません。
    実際のデータセットから読むか、JES2のスプールから読むかはJCLで決まります。JCLの定義を変えれば、プログラムをいじらなくても運用でデータの読み込み元を自由に変えることができます。
    COBOLプログラムの場合、DD名をSYSINと決めてあるなら、ファイルアクセスよりも簡単にACCEPT文を書くだけで読み込み処理ができます。「COBOLプログラムでSYSINにアクセスする」


    プロシージャーでのストリーム内データセット定義

    プログラムの実行にとても便利なストリーム内データセットの機能ですが、残念ながらプロシージャー内には定義できません。ただしMVSの場合は、STARTコマンドで起動するプロシージャーのJCLを、MSTRJCLのIEFJOBS DD文に定義されたデータセットにJOB文を持つジョブのJCLとして登録すれば、そのジョブをSTCタスクとして起動することもできます。この場合のJCLはカタログ・プロシージャーではなく、ジョブ用JCLになるのでストリーム内データセットを使用できます。この場合はそのJCLをサブミットすればJOBとして実行され、STARTコマンドで起動すればSTCタスクとして実行されます。
    あくまでもプロシージャー内でSYSINを使用するなら、プロシージャー内には定義できないので、そのプロシージャーを呼び出す時に、DD文の追加または置き換えの形で定義します。

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

    SYSOUTデータセットとは

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

    SYSOUT[データセット]

    多くのメインフレーム・システムでは、プログラムの実行結果は出力ファイルとして書き出されます。MVS(MSPやVOS3も含む)の場合は、JES2サブシステムと組み合わせて、JES2スプール内に特別な出力ファイルとして書き出されます。
    スプール内の出力データはDD文の指定などによって区分され、仮想のデータセットとして格納されます。これがSYSOUTで、スプール内の個々のSYSOUTをSYSOUTデータセットと呼びます。入力用のデータをスプール内に格納することもでき、こちらはSYSINデータセットと呼ばれます(正確にはJCLストリーム内データセットですが、SYSOUTに対しての意味で一般的にはSYSINデータと呼ばれます)。
    SYSOUTを含めスプール内の仮想データセットにはJES2によって内部DSN(userid.jobname.jobid.idnumber.addname)が割り当てられますが、利用者がそれを意識する必要はありません。SDSFを使えばそのDSNを知ることもできますが、一般的なSYSOUT操作でDSNを使うことはないでしょう。

    SYSOUTデータセットとJES2スプール


    一般にSYSOUTに書き出されるプログラムの実行結果は、処理内容の要約メッセージや、どのようなデータを入力し、どのような処理を行い、どこへ出力したか、といった実行ログリストという形に編集されたものです。例えば各種のユーティリティーやコンパイラーなどはSYSPRINTというDD文に定義されたデータセットに対して、実行サマリーやコンパイルリストといった形で実行結果を出力します。
    元々これらのリストは最終的にはプリンターから印刷してその内容を確認していました。プログラムが直接プリンターに印刷・出力するのではさまざまな問題が生じます。プリンターというデバイスは非常に遅い機械です。そのためプログラムの実行速度は遅い機械であるプリンターの印刷速度に引っ張られてしまいます。また1つのプログラムがプリンターを使っていると、他のジョブ(プログラム)はその間、デバイスが空くまで待たなければなりません。用紙がなくなったり、ジャムったりした場合もその復旧時間の間、実行中のプログラムも待っていなければなりません。他にも行送りや改ページなど、プリンターの制御を行うにはハードウェアに依存したI/O処理が必要ですが、これはユーザープログラムにとっては業務処理とは直接関係ありません。それらのようなことからパフォーマンスとスループットの向上、ユーザープログラムの簡易化などの観点から、出力データをスプーリングという方式で制御しています。スプーリングはMVS(JES2)のみならずほとんどすべてのメインフレームOS(ジョブ入力サブシステム)で採用していますし、メインフレームOS以外の多くのオペレーティング・システムでも使われています。


    SYSOUTへのデータ出力

    実はプログラム自身ではSYSOUTに出力するとかDISKのデータセットに書き出すとかの意識は基本的にしません。特にCOBOLなどで作成されるアプリケーションプログラムやアセンブラー言語であっても一般のプログラムであれば、順次データセットとして書き出す、という処理さえ行えばよいようになっています。
    ディスクやテープのデータセットに書き出すか、JES2のスプールに書き出すかはJCLで決まります。言い換えればJCLの定義を変えれば、プログラムをいじらなくても運用でデータの書き出し先を自由に変えることができるようになっています。

    出力データをJES2スプールにデータを書き出すのであれば、DD文でSYSOUTパラメーターを定義します。SYSOUTにはクラスと呼ばれる区分けの識別子があり、JES2ではAからZ、0から9の36種類があります。どのクラスにどのような意味を持たせるかはセンターによって違います。例えばAクラスは高速なレーザープリンター、Bクラスはラインインパクトプリンター、Hクラスはスプール内に留め置かれるホールドクラス、Wクラスはリモート印刷処理を行うためのソフトウェアで処理される、などです。開発作業で作成したCOBOLプログラムのコンパイルジョブの実行結果を、むやみに業務用帳票の印刷を行うプリンターから出力してしまうなどは決してよいことではありません。SYSOUTパラメーターにどのクラスを指定するかは、必ずセンター規約を参照するかシステム管理者に確認することが大切です。なお実行結果(SYSOUT)をTSO端末での表示だけで行い、印刷せずに消去してもかまわない場合は、ホールドクラスを指定することが一般的です。MVSのSDSFなどでは必ずしもホールドクラスである必要はありませんが、ホールドクラスであればSDSF以外のTSO OUTPUTコマンドなどでも処理が可能になります。いずれにせよ利用するセンターの規約で定められていますからそれに従います。


    SYSOUTの取り出し

    スプール内に書き出されたSYSOUTデータセットは、ジョブが終了すれば自動的にプリンターから印刷されます。これはJES2のライターと呼ばれる機能によって行われます。実際にプリンターから印刷されるかどうかはSYSOUTに指定したクラスによって決まります。プリンターにもクラスが割り当てられており、SYSOUTは同じクラスのプリンターから出力されます。
    プリンターに割り当てられていないクラスやホールドクラスのSYSOUTの場合は、そのままスプール内に留め置かれます。JES2コマンドでジョブ単位に消去するか、スプールをクリアーするまでスプールに残ります。

    スプール内にあるSYSOUTデータセットは、いくつかの方法で取り出すことができます。最も簡単なのはSDSF(MSPの場合はPFD3.8、VOS3の場合はASPENやSOEDIT機能)を使用して、SYSOUT内容をTSO画面に表示するものです。業務運用に乗らないバッチジョブ(例えば、プログラムのコンパイルや臨時のデータバックアップなど)はJCLの実行者によって正しく実行できたかがその都度確認されます。この場合多くはSDSFでジョブログのSYSOUTを画面に表示して、完了コードの値や異常を示すメッセージなどが出ていないかを目視で確認しています。
    目視ではなくSYSOUT内容をデータセットにコピーして保管したい場合は、OSが提供する外部ライター(XWTR)というプログラムを利用できます。詳細はSYSOUTデータセットの取り出し(XWTR)を参照して下さい。またSDSFであれば表示中のSYSOUTを簡単にデータセットにコピーすることもできます。SYSOUTの選択パネルでNPフィールドにXDCを入力すれば、SDSF Open Print Data Set というパネルが出て、どこへ書き出すかを問い掛けてきます。SYSOUTの内容を表示中であれば、COMMAND INPUT ===>フィールドにPTコマンドを入力することでコピーできます。PTコマンドにはさまざまなパラメーターがありますので詳しくはヘルプ(HELP PTと入力)を見るかマニュアルを見て下さい。こちらのページ、SDSFで表示中のSYSOUTをデータセットに取り込むでも使い方例を解説しています。

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

    MVS3.8に関連するOSドキュメントなど

    By kamii - Last updated: 火曜日, 10月 26, 2010

    MVS3.8に関連するOSドキュメントなど

    OS/VS2 MVS 3.8はあまりにも古いOSで、現在ではIBM社のマニュアルや技術文書、トレーニング用資料などを手に入れることは無理でしょう。現在のz/OSのマニュアルでも十分参考になりますが、OSやJES2コマンド、JCLやユーティリティーなどは当時からあるものは今でもほとんど同じままですが、どれがそうなのかがわからないかも知れません。その場合は試して動かないものは、あぁ使えないのか..と割り切るしかありません。

    いろいろ探してみたところ、次の2つのドキュメントが海外のサイトにありました。

    いずれもMVS 3.8 System Documentationというページから参照、ダウンロードできます。

    その他、COBOLコンパイラーに関するドキュメントは次の場所にあります。

    COBOLコンパイラーはMVS用のものは公開されていないため、更に古いOSであるMVT(OS/360)用のものを利用することになります。VSAMファイルのI/Oはコンパイラーではサポートされていないため、VSAMアクセスルーチンを呼び出して行います。アクセスルーチンの解説は、「VSAM File Access for COBOL」というページに掲載されています。アクセスルーチンのライブラリーである「SYS2.VSAMIO.SOURCE」と「SYS2.VSAMIO.OBJECT」は、「メインフレーム・コンピュータで遊ぼう」からダウンロードしたMVS3.8にはそれぞれ「MVS.VSAMIO.SOURCE」と「MVS.VSAMIO.OBJECT」として導入済みです。


    作成したCOBOLプログラムのコンパイル用JCLに関しては、ダウンロードした「MVSR38.lzhまたはMVSR38.zip」内に入っている「実習用MVSとHerculesの操作ガイド.pdf」の「COBOLではろ?わーるど」に記載してあります。必要に応じて参照して操作して見て下さい。またISPF代わりに使用するエディターやブラウザーなどを統合したTSOユーティリティーであるRPFの使用法は、MVSR38フォルダ内に入っている「RPFユーザーガイド」(英文)を参照して下さい。基本的な操作はISPFに似ていますので、ISPFが使えれば直感での操作は可能です。

    Filed in メインフレーム・エミュレーター