アセンブラープログラムの作成(アセンブルJCL)

By 神居 - Last updated: 日曜日, 11月 2, 2008

アセンブラーはメインフレーム・コンピューターでは現在でも広く利用されています。業務アプリケーション・プログラムを作成することはなくなってきたものの、OSのEXIT(出口)ルーチンやミドルウェア製品のパラメーター生成など使う機会はまだまだあります。
アセンブルオプションなどについては使用するアセンブラーのマニュアルを参照して下さい。


MVS高水準アセンブラーJCLサンプル

REGIONパラメーターは必要に応じて指定して下さい。アセンブルされたオブジェクトモジュールはバインダーでロードモジュールにするか、ローダーで直接実行します。
アセンブラーは標準のカタログプロシージャーを提供しています(SYS1.PROCLIB)からそちらも参考にしてください。
          ASMAC,ASMACG,ASMACL,ASMACLG


MSPアセンブラーJCLサンプル

リンケージエディターはプログラム名をJQALにすればMVSと同じJCLを使えます。ローダーも同じJCLです。
アセンブラーは標準のカタログプロシージャーを提供しています(SYS1.PROCLIB)からそちらも参考にしてください。
          ASMFC,ASMFCG,ASMFCL,ASMFCLG


VOS3アセンブラーJCLサンプル

リンケージエディターはプログラム名をJSAXLNKにすればMVSと同じJCLを使えます。
アセンブラーは標準のカタログプロシージャーを提供しています(SYS1.PROCLIB)からそちらも参考にしてください。
          ASMC,ASMCG,ASMCL,ASMCLGまたはXASMC,XASMCG,XASMCL,XASMCLG
XASMCが登録されていれば拡張アセンブラー(JOAXASM)が使えます。こちらを使う方がいいでしょう。JLAASSYは24ビット・モードのプログラム用アセンブラーで、31ビット・モード用命令の一部がアセンブルできない、などがあります。

Filed in S/370アセンブラー講座, ありがたいサンプルJCL

COBOLプログラムの作成(COBOLコンパイラー)

By 神居 - Last updated: 日曜日, 11月 2, 2008

COBOLはメインフレーム・コンピューターの業務アプリケーション・プログラムでは最も多く使われているプログラミング言語です。バッチ・オンラインを問わず広く利用されています。基本的なコンパイルを行うためのサンプルJCLを示します。コンパイラーも標準のカタログプロシージャーを提供しています(SYS1.PROCLIB等)からそちらも参考にしてください。ユーザーによっては自社のプログラム開発用に標準化されたJCLを作成していたりします。業務用プログラムの場合はそれらの使用が規定されているかも知れません。
コンパイルオプションや追加のDD文などについては使用するCOBOLのマニュアルを参照して下さい。

MVS Enterprise COBOLのコンパイラーJCLサンプル

STEPLIBにコンパイラーが格納されたロードモジュール・ライブラリーを指定します。コンパイルされたオブジェクトモジュールはバインダーでロードモジュールにするか、ローダーで直接実行します。
REGIONパラメーターは必要に応じて指定して下さい。コンパイラーオプションはEXEC文のPARMパラメーターで指定します。長すぎて1行に書ききれない場合は以下のように記述して次の行へ継続できます。


富士通COBOL85のコンパイラーJCLサンプル

リンケージエディターはプログラム名をJQALにすればMVSと同じJCLを使えます。ローダーも同じJCLです。ただしSYSLIB DD文で指定するCOBOLの実行時ライブラリー名はSYS1.COBLIBとなります。


日立COBOL85のコンパイラーJCLサンプル

リンケージエディターはプログラム名をJSAXLNKにすればMVSと同じJCLを使えます。ローダーも同じJCLです。ただしSYSLIB DD文で指定するCOBOLの実行時ライブラリー名はSYS1.COBLIBとなります。

Filed in ありがたいサンプルJCL

03.アセンブラー言語の概説(コーディングの基礎)

By 神居 - Last updated: 土曜日, 11月 1, 2008

プログラムの書式

アセンブラー・プログラムは1行が80バイトです。LRECL=80の固定長レコードのデータセットを作成してそこへ書いていきます。区分データセットのメンバーとして登録するのが普通ですが、ちょっとしたプログラムや、命令の動きだけを確認したいような時は、アセンブラーJCL中にSYSINデータとして直接コーディングすることも多いです。

アセンブラーではラベル(名前)は第1桁目、命令はラベルがあればラベルの後ろに1文字以上の空白を置いてから、ラベルがなければ第2桁目以降から書けます。オペランド(命令のパラメーター)は命令の後ろに1文字以上の空白を置いてから書けます。オペランド(オペランドがない命令では命令)の後ろに1文字以上の空白を置いてからコメントが書ける。1行に書ききれないときは72桁目に空白以外の文字を置いて、パラメーターは次の行の16桁目から、コメントは17桁目以降から継続できます。アセンブラーは最低限のルールを守れば基本的に自由コーディングできます。しかし行によって命令の開始桁が違っていたり、人によってスタイルが変わると見にくいので伝統的な決まり事があります。
73桁目以降はSEQ番号ですが使わなくてもかまいません。

1?8桁目はラベル。命令は10桁目からオペランドは16桁目から書きます。OSサービスのマクロなど、命令が6文字以上ある場合は、パラメーター(オペランド)開始位置もそれに合わせてずらします。その場合でも継続行は必ず16桁目からでなければなりません。MVSのアセンブラーではロングネームが使えるので必ずしもこのルールに沿えませんが、伝統的な基本として知っておいてください。
コメントにはいろいろスタイルがありますが、第41桁目、40桁目、36桁目などから書かれることが多いでしょう。行全体をコメントにするなら1桁目に*を置きます。オペランドがない命令の文にコメントを書く場合は命令とコメントの間にカンマ記号を置く癖をつけるといいでしょう。

アセンブラー言語ではコメントは非常に重要です。命令文ごとにコメントを付けるのが良いのですが、単なる命令自体の解説のようなコメントばかり続くと、くどくなるので注意します。何をしてるのか、何のためにやるのか等を残すように心がけるといいでしょう。上のサンプルのように*記号などでコメント欄をカプセルのように囲むこともよく行われます。きちんとしたコメントは十分なドキュメントにもなります。商用プログラムではコメント・カプセルの中にドキュメント自体を書いてしまうことも少なくありません。
形を繕うための外部ドキュメントにさしたる意味はありませんが、プログラム内のきちんとしたコメントはプログラムの保守を行う上でとても役に立ちます。商用プログラムの場合、どんなに素晴らしいものでもコメントがまったく無いようなプログラムは0点と言っても過言ではありません。アセンブラー言語でプログラミングを行う場合は、学習レベルのプログラムを書くときからコメントを付ける癖をつけることを勧めます。


プログラムはCSECTで始まりENDで終わる

プログラムの開始はCSECT命令を使います。一般に最初のセクション開始がSTART、2番目以降のセクション開始がCSECTとされますが、特別な理由がない限りSTARTを使う必要はありません。セクションとはプログラムを構成する要素のことで、実行される命令やデータが展開される制御セクション、外部領域内をフィールドに分割して名前で参照できるようにする見かけセクションなどがあります。CSECTは制御セクションのことで実際に命令やデータが展開されてオブジェクト・モジュールとして出力されます。
プログラムの終了はEND命令を使います。END命令にはプログラムの実行開始位置を指定することもできます。省略すればCSECTの先頭から実行されます。実行開始位置をセクションの途中からにする手法はそれほどむずかしいものではありませんが、慣れるまではわかりにくいので素直にプログラムはセクションの先頭から実行されるものなのだ、と覚えていいでしょう。


ロケーションカウンター

ロケーションカウンターはオブジェクトモジュール内の命令やデータがCSECTの先頭からどれだけ離れているかを示すもので、オフセット、アドレス、番地などとも呼ばれます。あくまでもプログラム(CSECT)の先頭からの相対アドレスです。実際の仮想記憶域にローディングされると、そのローディング・アドレスが加算されて仮想記憶上の主記憶アドレスを形成します。ロケーションカウンターは命令やデータの長さに応じてアセンブラーが適切な番地を計算しますが、必要に応じてプログラマーが変更することもできます。これによってデータ領域の再定義(Redefine)が可能になります。


アセンブラー命令

アセンブラー言語では命令は大きく3種類あります。1つはCPU命令です。マシン命令、機械命令とも言いCPUの1つ1つの動作を指示するものです。次がマクロ命令です。複数の命令をまとめたもので、繰り返し実行する処理などをいちいち書かなくても、マクロ名を書けば対応する命令列に展開してくれるものです。OSのサービス(API)などの多くはマクロ命令を使って呼び出します。メインフレームのマクロは非常に強力な機能を持っていて、活用すれば高級言語並みのコーディングが可能になります。CPU命令とマクロ命令(1部例外を除く)は最終的にオブジェクトモジュールになります。最後が「アセンブラー命令」です。アセンブラー命令は実際にCPUで実行されるものではなく、アセンブラーに対してアセンブル時の動作を指示するものです。いろいろとありますが覚えなければいけないものはそれほど多くありません。



簡単なアセンブラー・プログラムの例

消費税を計算する簡単なプログラムです。どのアセンブラー命令が出てきたか復習してみましょう。計算結果として税込み価格をプログラムの完了コードとして出力します。(OSの仕様で4095円を超えると完了コードでは正しく表示できません)

Filed in S/370アセンブラー講座

MVSのアセンブラーサービス解説書がついに日本語化された

By 神居 - Last updated: 金曜日, 10月 31, 2008

アセンブラーでMVSのシステムサービス(GETMAINとかWTOとかいろいろ)を使う際に必要となるのが「Assembler Service Guide」と「Assembler Service Reference」。MVS/ESAまでは日本語版があったのですが、OS/390になってから何故かService ReferenceのVolume2だけが翻訳されていませんでした。最近になって日本語化されたのがわかったので紹介します。(マニュアル一覧ページも修正してあります)

いずれも非APFサービスです。APFサービスのマニュアルは英文を見るしかありません(これもESAまでは翻訳版あったのに)。必要とする人が少ないせいもあるでしょうが、せめて後DFSMS/DFPのマクロサービスとアセンブラーのマニュアルが翻訳されるとアセンブラービギナーには朗報なんですけど…

Filed in つぶやき・雑感

02.S/370における数と文字の表現

By 神居 - Last updated: 金曜日, 10月 31, 2008

メインフレームに限らずコンピューターのCPUは内部で2進数を使用して演算処理を行っていることはよく知られています。アセンブラー言語のプログラミングではCPUの機械命令を直接使用し、メモリーにも直接アクセスすることになります。COBOLやPL/Iなどのいわゆる高級言語と異なり、数や文字、データがCPUでどのように処理されメモリーにどのように格納されるのかが具体的にわかっている必要があります。そのために数や文字が内部でどのように表現されるかを理解することは大切です。


2進数と16進数

私たちは日常生活では10進数(decimal number)を使います。0から始まって1,2,3と続き7,8,9となったらそれ以上の数字がないので繰り上がって10となります。0?9までの10の数字で表現するため10進数と呼ばれます。ところがコンピューターのCPUは2進数(binary number)を使います。0から始まって1ですが次はそれ以上の数字がないので繰り上がって10となります。0と1の2つの数字で表現するため2進数と呼ばれます。0か1かの2つの状態でしかないので、電気信号のオン/オフに対応させてハードウェアとしての記憶素子に情報を蓄えることができます。この0か1かのいずれの状態によって記憶素子に蓄えられる情報を「ビット(bit)」と呼びます。0の状態がビット・オフ、1の状態がビット・オンとなります。CPUのような機械にとっては0か1かの2進数の方が自然なわけです。なおS/370アーキテクチャでは10進数も扱えますが、基本となる演算処理は内部で2進数に変換されて行われます。

CPUが2進数を使用しメモリーにもビットのON/OFFでデータが蓄えられるならば、例えば100と言う数値は2進数では1100100、379は101111011、1234は10011010010となりますがとても人間が扱える表現方法ではありません。それでもアセンブラー・プログラミングでは数の取り扱いや演算結果、命令動作の確認などでCPUが行うとおりにやってみる必要が生じます。そこでCPUにとっては自然だが人間にとってはやっかいな2進数を扱うために16進数(hexadecimal number)を用います。16進数は0から始まって1,2,3と続き7,8,9となったら次にA,B,C,D,E,Fと続きます。Fの次はそれ以上の数字がないので繰り上がって10となります。0?9、A?Fまでの16の数字で表現するため16進数と呼ばれます。AとかBは数字じゃなくて文字だろうと思うかも知れませんが、それは10進数で考えるからです。16進数ではA,B,C,D,E,Fは数字の1部だと割り切ってください。

16進数は2進数と密接な関係を持ちます。16は2の4乗なので4ビットで表現できます。したがって2進数を4ビットずつ区切れば簡単に16進数に変換できます。先ほど例示した100と言う数値は2進数では1100100なので16進数では64、379は2進数では101111011なので16進数では17B、1234は2進数では10011010010なので16進数では4D2となります。2進数←→10進数変換は計算が必要ですが、2進数←→16進数変換は対応表で簡単に変換できます。実際にプログラミングを始めればいちいち対応表など見なくても直感で変換できるようになります。

ビット操作やマスク値の設定など2進と16進の変換はアセンブラー・プログラミングでは常に必要となります。実際にはさほど長い桁数を変換することはなく、4桁の2進<->1桁の16進に、8桁の2進<->2桁の16進に変換する程度です。なお2進数と10進数の変換計算については、その計算を行うプログラムでも作らない限り必要となることはありません。16進数と10進数も変換には計算が必要でデバッグ作業ではしばしば必要になりますが、n進数計算機能を持つ関数電卓を使えば簡単です。


バイトとワード

メモリーにはデータがビット単位に記憶されます。しかし私たちは1ビット、2ビットと言った長さの数を扱うことはほとんどありません。コンピューターではメモリーを複数の記憶素子をまとめて扱い、CPUがメモリーをアクセスする際の単位とします。S/370アーキテクチャーでは8ビットを1つのグループにしてバイト(byte)を構成します。メモリーはバイト単位にアクセスされるためメモリーアドレスもバイト単位に振られます。本来は1byte=8bitと決まっているわけではありません。初期のコンピューターでは7や9ビットなども使われました。S/360システムが1byte=8bitを採用したことや80年代以降Intel社の8bitや16bitのCPUが普及したので1byte=8bitが定着してしまいました。

S/370アーキテクチャーではバイトは4つにまとめられワード(語)を構成します。演算に使われる汎用レジスターも32bitで構成されています。さらに半分の長さのハーフワード(半語)、倍の長さのダブルワード(倍語)が使われます。そのためCPU命令ではバイト、ハーフワード、ワード(フルワード)、ダブルワードのいずれかの単位でメモリーアクセスすることができます。文字列をまとめて移動できる命令などもありますが、この場合でもバイト単位で合計○○○バイトのデータをメモリーに書き込む、と言った動作になりアクセスはバイト単位に行われます。


数の表現(2進整数)

S/370アーキテクチャーでは整数は2進整数とも呼ばれ、符号を含んで16、32あるいは64ビットで表現されます。メーカーによってはマニュアルに2進固定小数点(Fixed Binary)と載っているものもありますが、実際には整数部のみが使われますので単なる整数と考えてかまいません。呼ばれ方の違いであってIBM、富士通、日立の各社アーキテクチャーに違いはありません。整数は多くのコンパイラー言語ではint型と呼ばれますが、メインフレームのアセンブラーでは integer と言う表現はあまり行われず、そのまま固定小数点とかバイナリーとか言われます。アセンブラー言語が規定した型名で呼ばれる場合もあります。(F型、H型など)

フルワード(4バイト)整数については1部の命令が符号無し32ビット整数として取り扱うこともできる。ダブルワード整数については乗算の積および除算の被除数としてのみ扱うことができる。一般にメインフレームの整数と言えばハーフワードまたはフルワードで考えればよい。C言語で言うshort(16ビット)とlong(32ビット)となる。int型でも32ビットで考えればよい。ちなみにCPUも32ビットCPUである。



符号付き32ビット整数ではマイナス値(負数)は2の補数で表現します。+1はx00000001、0はx00000000ですが、-1はxFFFFFFFFとなります。2の補数は簡単にできます。ビット補数を使えばいいのです。正の数を2進表現します。そしてすべての1を0に、0を1にひっくり返します。それに1を足せばよいのです。他の計算方法もありますがこれがいちばん簡単でしょう。

実際は自分で計算しなくても補数を取るCPU命令が使えます。ただ内部でこう表現されていることを知っているといろいろ便利なこともあります。


文字の表現(キャラクター)

S/370では文字はバイトで表現されます。1文字が1バイト(8bit)です。1バイトの2進数をどの文字に割り当てるかの対応を示すのが文字コードセットです。メインフレームではEBCDIC文字コードセットが使われ、数字文字0?9にはxF0?xF9が割り当てられます。ASCIIと異なり英文字は数字文字より小さなコード値(x81?xE9)が割り当てられます。文字をソートした時の並び順やゾーン10進数のゾーンビットのパターンが異なることは知っておく必要があります。

メモリー上のデータが数値(整数)なのか文字なのかは、そのデータを処理する命令によって決まります。演算命令を使えば整数と見なされますし、文字操作命令を使えば文字または文字列と見なされます。


数の表現(パック10進数)

S/370では2進整数の他に10進数を扱うこともできます。命令で直接数値演算ができる形式がパック10進数、表示や印刷など人間が見てわかる文字形式に変換されたものがゾーン10進数(アンパック10進数)です。

10進数で+1,234を示す例である。数値は8ビットずつに区切られ、先頭4ビットにゾーンビット(xF)、後部4ビットに0?9の値が入る。末尾バイトの先頭4ビットは符号で、+はC、-はDで示す。+はFでもかまわない。パック10進数を演算した結果は命令でゾーン10進数に変換できるが符号はそのままCまたはDで設定される。末尾桁を表示する際にはプログラムで符号ビットを変換するなどして表示可能な文字列に編集する必要がある。

これから新たに事務計算用のプログラムをアセンブラーで作ることはないでしょうが、システム系プログラムでも2進整数の演算結果を人間がわかる形に編集してメッセージなどを組み立てて出力することはよくおこなわれます。このような時はパックやゾーン10進数がデータ変換のために使われます。


数の表現(浮動小数点)

仮数部の長さによって短精度、長精度、拡張精度の3種類があり、16進数でそれぞれ6,14,28桁となる。

S/370での浮動小数点は上図のように表現され、Excess-64方式とも呼ばれる16進浮動小数点です。符号は正負を表し0が+、1が-となります。仮数部は1以下の正の数を表し、小数点が仮数部の直前(ビット8の直前)にあるものとされます。指数部は16の累乗値を表し7ビットの2進数値から64を引いた値がべき数となります。この表現方法がExcess-64です。0?127の指数値は-64?+63のべき数に対応します。浮動小数点値は仮数部に、指数部で示すべき数を使った16のべき乗の値を、掛けたものです。仮数部 * 16^指数部で示すべき数、となります。ESA/390アーキテクチャーではさらに別の方式である2進浮動小数点(インテルCPUなどで使われている)と言うものもサポートされています。
これ以上はややこしいので解説しません。浮動小数点は2^31乗で示される±約21億4700万の整数演算では処理できない大きな数や小数点以下の値の演算が必要な科学技術計算などで使用されます。しかし百分率(%)や平均値などで計算結果を小数点表示(例えば1÷3を0.33と表示)したい場合などは整数演算して表示のしかただけ工夫したり、事務計算で大きな数を扱う場合はパック10進数を使うことも多く、システム系プログラムや事務処理系のアプリケーションで浮動小数点が使われることはほとんどありません。とりあえずは浮動小数点というものがあるんだ、とだけ知っておいて下さい。将来本当に必要になる機会が来たら調べてください。(ちなみに私は1度ぐらいしか使ったことがありません)

Filed in S/370アセンブラー講座

.このカテゴリーについて

By 神居 - Last updated: 水曜日, 10月 29, 2008
このカテゴリーはメインフレーム・コンピューターの代表OSであるIBM社のMVS(z/OS)について、その機能や仕組みに関しての概要を紹介しています。特に断りがない限り富士通のMSP、日立のVOS3にも共通しています。
Filed in .z/OS(MVS),MSP,VOS3のしくみ

GTFトレースの採取とフォーマット

By 神居 - Last updated: 火曜日, 10月 28, 2008

MVSにはGTFと呼ばれる汎用トレース機能があります。MVS自身の動作やアプリケーション・プログラムなどの動きをシステムのレベルでトレースする機能です。一般のプログラムのデバッグには向きませんが、アセンブラー言語で作成されたシステム系プログラムなどの動きを追跡したりする目的で利用することもできます。GTFではトレースする項目をイベントと呼び、以下のようなものがあります。

その他ユーザープログラムでデータを書き込むこともできます。

余程のことがない限り一般のユーザーが自ら使うことはありませんが、基盤系ソフトやISV製品などに問題が考えられる時、メーカーやベンダーの依頼でトレースを採ることがありますので、使い方は知っておいた方がいいでしょう。トレースの採取やフォーマットのパラメーターについては依頼する人が必要なものを提示しますから、ユーティリティ名や基本のJCLコーディングなどがわかれば十分です。


GTF起動プロシージャ・サンプル


GTFの起動操作


GTFトレースオプションの例






関連マニュアル

MVS 「zOS MVS:診断のツールと保守援助プログラム」

MVS 「zOS MVS:対話式問題管理システム(IPCS)コマンド」

MSP 「サービスエイド 使用手引書」

VOS3 「システム支援」

Filed in ありがたいサンプルJCL, システムプログラマーのための手引きいろいろ

TSOバッチ・セッション(TSOセッションをバッチジョブで実行する)

By 神居 - Last updated: 火曜日, 10月 28, 2008

TSOコマンドは通常端末を利用するフォアグラウンドセッションで使用しますが、サブミットされたバッチジョブでも使うことができます。これがTSOのバックグラウンドセッションです。


TSOセッションをバッチで実行するJCL

Filed in ありがたいサンプルJCL

プログラムがTSOコマンド、バッチプログラムどちらとして呼ばれたかを判定する方法

By 神居 - Last updated: 火曜日, 10月 28, 2008

MVSではバッチ・プログラムはTSO環境であってもJCLであっても同じように動作させることができる。しかしTSO環境でならバッチ・モードでなくTSO固有の機能を利用したり、TSOコマンドとして動作したい場合もある。このようにTSOで実行された時はコマンド・プロセッサーとして、JCLで実行された時はバッチ・プログラムとして動作するプログラムを作成するような時、自分がどちらとして呼び出されているかを判定する方法を示す。


  • JCLのEXEC文またはTSOのCALLコマンドで呼び出された場合のGR1
  • プログラムがバッチJCLまたはCALLコマンドで実行された場合

    プログラムがバッチJCLまたはCALLコマンドで実行された場合



  • TSOのコマンド・プロセッサーとして呼び出された場合のGR1
  • プログラムがTSOコマンド・プロセッサーとして実行された場合

    プログラムがTSOコマンド・プロセッサーとして実行された場合



    呼び出された時点のGR1が示す領域の先頭ワードのビット0が1ならバッチまたはCALLコマンド、0ならTSOコマンドとして呼び出されていると判定できる。
    GR1がEXECパラメーターを指しているとき、実行中の空間がSTCやバッチ空間かTSOユーザーかを判定するにはEXTRACTマクロを使ってTJIDを求めればよい。さらに詳細を知りたければCOMM(CSCB)、PSB、TSOなども求めて参照する。

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

    ロードモジュールの修正(IMASPZAP)

    By 神居 - Last updated: 火曜日, 10月 28, 2008

    SPZAPはロードモジュールやデータセットの内容をDASD上で直接修正するためのユーティリティです。ロードモジュールに関してはアセンブラー言語で作ったプログラムのソースプログラム修正が行えないような場合に利用されます。例えばISVなど商用のパッケージソフトを提供しているソフトウェア・メーカーにおいて出荷済み製品の障害修正や機能変更を行う場合に使われます。一般のユーザーでは自らのアプリケーション・プログラムの修正に利用することはまずありませんが、ISV製品などを利用している場合、提供元の依頼でSPZAPを使用した作業を行うこともあります。修正データを作ることはなくても、ユーティリティ自体の使い方は覚えておくといいでしょう。

    ロードモジュールの修正

    プログラム名はMSPではJQPSPZAP、VOS3ではJSPPTCHですがいずれもIMASPZAPの別名が付いています。ただし制御文には一部非互換もあるから必要に応じてマニュアルを参照してください。ここで紹介した機能に関しては同じです
    SYSLIB DD文で修正するロードモジュールが格納されている区分データセットを指定します。
    SYSIN DD文で実際に修正作業を行うための制御文を指定します。NAME文で修正するロードモジュールのメンバー名とCSECT名を、VER文で現在のモジュール内容を修正箇所のCSECT先頭からのオフセット値、現在のデータの組み合わせを、REP文で修正後のデータを、オフセット値、更新後データの組み合わせで記述します。VERとREPはペアーである必要はありません。VERのみを羅列した後にREPをまとめて書いてもかまいません。IDRDATAはモジュールに修正履歴を残す場合に使用します。なくても修正はなされます。IDRDATAを使用する場合、ロードモジュール内のIDRレコードに空きエントリーがないとIDRDATAは書き込みできません。この場合SPZAPはVERデータがすべて合っていてもCC=8で終了します。JCL例のようにIGNIDRFULLパラメーターを指定すればIDRDATAは無視されモジュール内容は修正されます。この場合CC=4となります。VOS3ではIGNIDRFULLパラメーターはなく、常にIGNIDRFULLパラメーターが指定されたのと同じ動作になります。

    パッケージソフトのプログラム修正などではSPZAPの制御文は提供元ベンダーから示されるのが普通です。OS自身のモジュールはよほどの緊急事態でない限りSPZAPで修正されることはまずありません。SMP/Eと言うシステム保守機能によって行われます。


    データセット・ブロックの直接修正

    SYSLIB DD文で修正するデータセットを指定します。SYSIN DD文で実際に修正作業を行うための制御文を指定します。
    ABSDUMPとABSDUMPTはデータセットの物理レコード内容を印刷します。レコードと言ってもDASD上の物理レコードですからプログラムから見ればブロックになります。データは16進ダンプの形式で出力されます。
    データセットの場合はNAMEではなくCCHHR文で修正ブロック(物理レコード)の位置を示します。位置はシリンダ番号+トラック番号+レコード番号を16進数で繋げたDASDの先頭からの絶対トラックアドレスです。実際の値はABSDUMP(T)の出力で知ることができます。VERとREPはロードモジュール同様にデータ修正する位置と更新後の内容です。位置はブロックの先頭からのオフセット値です。通常はISPFエディターのHEXエディットモードなどでもバイナリーデータの修正ができますから、今ではSPZAPで直接修正するようなことはまず無いでしょう。

    Filed in ありがたいサンプルJCL

    01.MVSの構成

    By 神居 - Last updated: 火曜日, 10月 28, 2008

    このカテゴリーでは大型汎用機用の代表OSである、IBM社の「MVS」について、その概要やポイントなどを紹介します。その他にも関連する話題を適宜追加したりもします。
    現在ではMVSは「z/OS」の名称になっていますが、OSの基本部分は今でもMVSとしてその名が使用されています。

    MVSに限らずメインフレーム・コンピュータ用OSはRASISの指標で示される品質を踏まえた上で、

    と言う目標を達成しています。

    Reliability(信頼性)システムを間違いなく機能させること。障害の少なさ。
    Availability(利用可能度)仮に障害となってもいかにそれを回避・回復できるか。局所化できるか。
    Serviceability(保守性)障害原因の追及や修復のし易さ。
    Integrity(保全性)障害によってデータやプログラムが破壊されないこと。
    Security(機密保護性)情報の盗用や資源への不正なアクセスをいかに防げるか。

    MVSではこれらの目標を達成するためにさまざまな機能が組み込まれています。「監視プログラム」と呼ばれる、根幹となる核の部分を構成するプログラム群の上に7つの大きな機能を載せたような構造になっています。


    監視プログラム

    OSとしてのカーネルの部分です。MVSではニュークリアスと呼ばれます。CPU制御、割込み制御、入出力制御、タイマー制御、プログラム実行制御などハードウェアを直接アクセスしたり、マルチタスキングなどプログラムを実行する上で基本となる制御を司ります。


    ジョブ管理

    処理プログラムの実行を「仕事」として制御・管理します。MVSではユーザーの業務を行う処理プログラムの実行を「ジョブ」と言う単位で捉えます。初期のS/360以前の時代から、まとまったデータを一気に処理するバッチ処理と言う処理形態がメインフレーム・コンピュータでのプログラム処理の基本でした。MVSもこの流れを組んでいます。1つ1つのバッチ処理を「ジョブ」と言う単位で管理していたのです。


    ジョブエントリーサブシステム(JES)

    複数の「ジョブ」を自動的・連続的に処理させ、OS自身のジョブ管理機能を補完します。JES機能自体がMVS自身に含まれないのは、複数のJESを用途に合わせて利用できるようにするためです。MVSではOS自身にアドオンする形で機能を追加する仕組みを持っており、サブシステムと呼ばれます。JESはこのサブシステムの代表的なもので、JES2とJES3の2つがあります。日本では圧倒的にJES2が利用されています。


    メモリー管理

    仮想記憶と実記憶の制御と管理を行います。


    タスク管理

    複数のプログラムを並行して実行させる、排他制御やエラー回復などの制御・管理を行います。


    データ管理

    デバイス(ボリューム)とデータセットの制御と管理を行います。


    ファイルシステム

    データセットの構造管理、レコードへのアクセスサービスの提供を行います。MVSではファイルシステムはデータ管理のコンポーネントに含まれます。


    システム管理

    システムのモニタリングやロギングなど、OSの運用に必要なさまざまなデータの収集や解析が行われます。パフォーマンス制御などはこのシステム管理とタスク管理が密接に連動して行われることになります。


    ネットワーク

    通信デバイスの制御と管理、ネットワークへのアクセスサービスの提供。ネットワーク機能は本来OSに含まれる機能ではありませんが、現在ではネットワークなしでのメインフレーム・コンピュータ運用はまずありません。MVSではIBM社のSNAプロトコルを制御するVTAM、TCPプロトコルを制御するTCPIP/MVSがあります。現在では両方のプロトコルを処理するCommunications Serverというコンポーネントが組み込まれていますが、SNAの制御はVTAM、TCPの制御はTCPIP/MVSであることに変わりありません。VTAMやTCPIPはCommunications Serverのサブコンポーネントと考えてもいいでしょう。

    Filed in ..基礎編

    カタログの思い出

    By 高尾 - Last updated: 火曜日, 10月 28, 2008
    カタログについて、歴史的経緯と個人的思い出を書いておきます。
    もともとメインフレームでは、MVS以前のMVTのころからCVOLという考え方がありました。データセットリストを記憶しておくデータベースみたいなもので、IEHPROGM(このユーティリティは今も現役でしょうか)でコントロールしていました。
    世の中にカタログが出てきたのは、VSAMと同時だったように思います。VSAMはアクセスメソッドですが、カタログ自体がVSAMを利用しているので一緒に語るものです。当初VSAMカタログの場合、データセットの管理ということでデータセットの名前、構成はおろかスペース管理までもやろうと考えていました。今のデータベースの考えに近いです。最初にスペースを取って、データセットの大きさを決める。同時にスペースを管理するということは、そのボリュームを管理することになりますから、ボリュームオーナーシップという考え方が必須でした。ボリュームは一個でもVSAMデータセットを作ったら、いずれかのカタログに忠誠を誓うわけです。
    ところがこのアーキテクチャは結果的にいろんな問題を引き起こしました。次が代表例です。
    ・カタログが壊れると、スペース不明のボリュームが大量に出てくる。被害が甚大。
    ・VSAMに書き込むたびに、カタログへ頻繁にアクセスが起きる。パフォーマンスが低下する。
    ・カタログごとにエイリアスをもつため、ひとつのボリュームに違うカタログでつけたエイリアスをつけられない。自由にファイルを作れない。

    とくに一番目の問題は致命的でした。このころ技術的にはカタログをどうやって救うか、ということが大事なことでした。

    それを省みてでてきたのが、ICFカタログです。IDCAMSが機能を大幅に拡張してきたのも、これ以降です。
    ICFカタログは、ボリュームごとにVSAMデータセットを管理する、SYS1.VVDS.Vボリューム名 という管理データセットを作ります。それでVSAMを管理します。この考え方でSPACE管理とボリュームのオーナーシップはなくなりました。VSAMデータセットの大きさはVTOC情報と一致するのです。ただし、どえらいエクステンションを許すようになりましたが。また、カタログはボリュームへのポインターに過ぎないので,VSAMも非VSAMデータセットも同様に管理できるようになりました。カタログが壊れても再構築が簡単になりました。

    昔話はここまでです。
    さて、オープン系を見ると、フォルダーという階層型ファイル管理ばかりです。確かに書類とフォルダーというオフィスにあるメタファーを利用しているため、理解が簡単という面はあります。一方で、ファイルの名前にユーザーはものすごく無頓着です。メインフレームのユーザーはカタログのエイリアスで整理する習慣が身にそまっているので、ついつい、フォルダー名に応じたファイル名などをつけようとしてしまいます。どちらが便利なのでしょうか?
    私はオープン系はディスクの発達が急速だったため、それほどボリューム数が必要なかったことが幸いしていると思います。100個もディスクをつけているシステムなんてあるのでしょうか。ボリュームが数個であるのなら、階層型フォルダーのほうが便利なのでしょう。メインフレームのようにUCBの許す限り多くのボリュームを取り付けられる(しばしばオフライン)の場合、ボリューム名を知らなくてもファイル名のルールでアクセスできるほうが便利なのでしょう。
    Filed in OSの互換性

    VSAMデータセットの操作いろいろ(IDCAMS)

    By 神居 - Last updated: 火曜日, 10月 28, 2008

    AMS(アクセス方式サービスプログラム)はVSAMデータセットとカタログ操作用のユーティリティ・プログラムです。しかし応用範囲はVSAMだけでなくPSやPDSなどの非VSAMデータセットに関してもさまざまな操作を行うことができ、データセット操作の統合ユーティリティとなっています。AMSを使用した非VSAMデータセットの操作サンプルに関しては別の記事「非VSAMデータセット(PS,PDS)の各種操作(IDCAMS)」でアップしてますが、ここではVSAMデータセットとカタログ・データセットに関するいくつかのサンプルを紹介します。足りないものはマニュアルを見てください。



    JCLの基本形


    カタログされているデータセットをリストアップする。


    ユーザーカタログおよびALIASをリストアップする。


    VSAMデータセットの作成


    VSAMデータセットの改名と削除


    VSAMデータセットのアンロード

    Filed in ありがたいサンプルJCL

    03.REXXにおける重要な概念

    By 高尾 - Last updated: 火曜日, 10月 28, 2008
    どんな言語も「構造化プログラミング」を考慮していることは、論を待たないと思います。(構造化プログラミングがわからない人は、Wikipediaをみてください。)
    プログラミング言語は、それ以外に特有の概念が実装されていることで特色を出しています。その概念を理解することが、その言語らしいプログラミングをするために、不可欠です。REXXの場合、それはスタックと連想配列だと思います。

    スタック


    スタックそのものは別にREXX固有の話ではなく一般的にデータを扱う時に話題になる概念です。図のように2つの考え方があります。
    ひとつは地面に土管が埋まっていると思いましょう。そこにデータ(肉でもいい)を投げ込みます。次にそれを取り出すと、もっとも最近投げ込んだデータ(新しい肉)が取り出されますね。(まぜちゃいけません)こういうスタックをLast In - Fast Out(LIFO)という呼び方をします。REXXではPUSHというコマンドでスタックにデータを投げ込み、PULLというコマンドでデータを取り出します。

    もうひとつのスタックの考え方は、広場に土管がころがっていると思いましょう。そこにデータ(肉でもいい)を押し込みます。土管の反対側からデータを取り出すと、もっとも昔に押し込んだデータ(古い肉)あ取り出されますね。こういうスタックをFast In – Fast Out(FIFO)という呼び方をします。REXXでは、QUEUEというコマンドでスタックにデータを押し込み、取り出し方は同じようにPULLです。

    スタックという土管にどの順番でデータを押し込むかは、PULL,QUEUEコマンドで決まり、PULLでひたすらデータを取り出す、というのがREXXの考え方です。

    もう一点、スタックで重要な話があります。もし、スタックが空なのにPULLコマンドを出したらどうなるのでしょうか?ゼロが帰る?いやいや、これはREXXプログラムの動作環境で異なります。
    たとえば、z/OSならばSYSTSINにデータがあれば読み込みますが、それもなければ端末入力待ちになるのです。これにより、プログラムはユーザーからの入力を待つことができるようになるのです。

    連想配列

    Perl,PHP,VBなどのスクリプト言語ではよく使われていますが、なじみがない方のために連想配列の簡単な説明をしておきます。
    連想配列とは、添え字が文字列でかまわない配列をいいます。ハッシュといったりもします(個人的には違和感があるけど)。
    REXXの場合、変数に.が現れると配列だとみなします。
    たとえば、
    var.1 = “あ”
    var.2 = “い”
    i = 2
    say var.i
    では、”い”が表示されます。

    添え字が文字列でかまわない以上、次のような配列も許されます。
    a = “a”  /* 明示的に */
    var.a = “あ”
    b = “a”
    say var.a

    “あ”が示されます。

    ただし、REXXでは、他言語のように配列の添え字なしで要素を拾い出す(foreach)のような命令がないので、配列の要素を順々に取り出したい場合は、数値の添え字を使います。添え字なしで要素を順次取り出すことのほうが多いでしょうが、そういう場合には、スタックの使用が推奨されているのです。
    Filed in REXX入門

    オンライン端末のRUサイズを最適化する

    By 神居 - Last updated: 火曜日, 10月 28, 2008

    MVSパフォーマンスチューニング入門に関連して追加トピックをひとつ。

    オンライン端末のRUサイズ

    意外と忘れられているが、オンライン端末のレスポンスに影響を与える要素の1つにRUサイズがある。MAXRUとも呼ばれ、端末->ホスト、ホスト->端末方向それぞれに設定されます。TSO、CICSやIMSなどのDCMS(TPモニター)は端末にデータを送る際に画面データをRUサイズに基づいて自ら分割して送信するか、VTAMに分割を依頼します。MSPとVOS3ではVTAMに分割処理を代行する機能(LMPEO)がないのでAIMやDCCMなどは自ら行っています。1つの画面データが分割されるとき、分割された1つ1つのデータをチェインデータと呼びます。チェインにはFIC(First In Chain)、MIC(Middle…)、LIC(Last…)、OIC(Only…)の4種類があり、分割されない時はOIC、2つ以上に分割される時はFIC,MIC,LICを組み合わせて送信データを組み立てます。

    画面データの大きさは画面に表示される内容によって異なりますが、一般的な80桁24行であれば画面一杯に表示したとして文字だけで最大1920バイト、これにさまざまな制御コードが付加されます。フィールドが多い画面や、色や罫線などを多用した画面は制御コードだけでも2000バイト近くになったりもします。経験則からアプリケーション業務の画面データは2KB?4KBぐらいの大きさで構成されるものが多いです。RUサイズが小さいとホストから端末に送られる画面データ(アウトバウンド)は常に分割されてしまいます。1度で送ることができればそれだけパフォーマンスも向上します。現在では通信ネットワーク自体も早くなったり、エミュレーターによってはすべてのチェインデータを受信してから画面を組み立てたりするものあるので見た目ではわかりにくいですが、一昔前であれば体感できるほどの違いがありました。見てると画面の上からほぼ3分割されて、パカッ・パカッ・パカッ、という感じで表示されたりします。ネットワークが早くてもパッ・パッ・パッという感じです。分割されても回線やソフトのスピードが早いと人間はわかりませんが中では同じ動きをしてるでしょう。

    RUサイズはVTAMのログモードに定義されます。ただしDCMS(TPモニター)によってはDCMSの端末定義などで決定されるものもあります。ログモードと端末定義のどちらを優先するかはDCMSの仕様なので必要なら確認してください。TSOはログモードでRUサイズを決定します。
    ログモードのRUSIZEはMODEENTマクロのRUSIZESパラメーターで指定します。IBM社が提供する標準ログモードテーブルISTINCLMにはTN3270サーバーなどでも標準で使用されるSNA端末用ログモードエントリーであるSNX32702と言うのがあります。ここではRUサイズとしてx87F8が指定されています。最初の87は端末->ホスト方向のサイズを示し「8*2^7」で1024バイト、次のF8はホスト->端末方向のサイズを示し「15*2^8」で3840バイトです。3800バイトあればほとんどのケースで分割されることはなく一度で送信できるでしょう。適切なRUサイズがわからなければこのようなメーカーデフォルトを参考にするのも1つの方法です。

    昔はハードウェアの制約などで小さいRUサイズを使っていたこともあるので、昔からの伝統的なログモードを今でもそのまま使わっているユーザーでは意外と無駄な分割をしていることもあります。分割数が多ければそれだけネットワークへのI/O回数が増えますから、端末台数が多ければ決してバカには出来ません。

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

    02.REXXを実行してみる

    By 高尾 - Last updated: 月曜日, 10月 27, 2008
    REXXプログラムの最低限の形は以下のとおりです。

    /* REXX */
    say “Hello World!”

    これを、HELLOとか、適当なメンバー名で保管してください。

    REXXは最初に/* REXX */というコメントで始まらねばなりません。これはVMからの伝統なのですが、まぁ、ルールだと思ってください。次のsayは、日本語で「言え」ですよね。ダブルクオーテーションの文字列を「言います」。
    プログラムは大文字、小文字を区別しません。(内部では全部、大文字で処理します。)

    TSOで実行する時は、

    => TSO EXEC ‘hlq.your.dsn(member)’

    です。CLISTと同じようにPDSに入れておいてください。いちいちデータセット名を指定するのがイヤだったら、SYSEXECかSYSPROCのライブラリーの中にいれておけばいいです。

    バッチで走らせる場合は、PGM=IKJEFT01,PGM=IKJEFT1BもしくはPGM=IRXJCLです。IRXJCLは本当にREXXのバッチですから、TSOコマンドを利用するのが個別に呼び出さねばならず、面倒です。TSO環境下で動かすことを強く、お勧めします。
    REXXのライブラリはSYSEXECに登録します。プログラムのメンバー名は、PARM=’ ‘に記述するか、SYSTSIN の入力としてください。ここらへんがよくわからない人は、こちらのTSOとISPFの記事を参照してください。

    ぜひ、やってみてください。Hello World!が出ればREXXが動いています。
    Filed in REXX入門

    02.ジョブ管理

    By 神居 - Last updated: 月曜日, 10月 27, 2008

    ジョブとプログラム

    コンピュータで何らかの処理を行うためには、その処理の内容を1つ1つとても細かい手順としてあらかじめ記述しておかなければなりません。これがプログラムです。プログラムを動かすことによって始めてコンピュータは意味のある処理を行うようになります。MVS(メインフレーム)ではこれをコンピュータに仕事(JOB:ジョブ)をさせると言う概念で捉えます。
    そもそもコンピュータと言う機械が考えられ、開発され、発展してきた背景には人間が行ってきたさまざまな計算作業や集計処理などを少しでも早く、より大量に、そして正確に行わなければならなくなったからです。人間が仕事として行っていたことをコンピュータに行わせるのが目的ですから、コンピュータにおける処理(作業)を仕事と捉えるのは理にかなった考え方です。これがプログラムを動かすこと=ジョブ(仕事をさせる)となったわけです。
    このような考え方によってMVS(実際はMVS以前のOSやコンピュータでも)はプログラムを動かすことを、ジョブを実行すると言う考え方で扱います。ジョブは人間から見た仕事の単位で、またMVSから見た最も大きな仕事の単位でもあります。


    ジョブの構成

    1つの仕事が複数の作業によって成り立つことはよくあることです。
    例えば「会議用の資料をコピーして準備する」と言う仕事は、

    というように3つの作業に分かれます。MVSのジョブも同じで1つのジョブを複数のプログラムの実行で成り立たせることができます。この場合の1つ1つのプログラムの実行をジョブ・ステップ(JOB STEP)または単にステップと呼びます。1つのジョブは1つまたは複数のステップで構成されます。


    ステップは順番通りに実行される

    MVSのジョブでは複数のステップは順序通りに実行されます。一般に1つの仕事を構成する各々の作業には順序に基づく関連性があります。上記の例でも、資料のコピー・並べ替え・ホチキス留めは順序通りでなければ処理できず、また同時に行うこともできません。コピーされなければ並べ替えはできないし、ページがバラバラの資料をホチキスで留めるのは仕事としては不正確です。
    MVSのジョブ・ステップにも同じ考えがあてはまります。たいていの場合、先行ステップの出力データ(処理結果)を後続のステップの入力データにして、さらに別の処理を行うというようにしてデータ処理の順番にステップが並べられ、ジョブが構成されます。
    典型的な例が「プログラムの実行形式モジュールを作る」です。コンパイルしてリンカーに掛けると言う2つの手順を踏みます。コンパイラーの出力がオブジェクトで、オブジェクトはリンカーの入力になります。そしてリンカーの出力が実行形式モジュールになります。コンパイルとリンクは同時にはできませんし、順番を逆にすることもできません。コンパイル→リンクの順で処理をした結果が、出力された実行形式モジュールで、実行形式モジュールが作成されて1つの仕事が完了します。


    ジョブの種類

    MVSのジョブにはOSから見た用途に応じて3つの種類があります。


    JCL

    OS/360以前のコンピュータではジョブに対応したプログラムを実行させるのはオペレーターの仕事でした。オペレーターはプログラマーが作成したプログラムを実行指示書に基づいて、プログラムと入力データを準備し、カードリーダーやテープなどの装置にセットし、プログラムを開始させました。終了すれば使い終わったデータをはずし、片付け、そして次のジョブの実行指示書によって準備を始めるといった作業を繰り返します。実際にプログラムが動く時間よりもはるかに多くの、人間による準備と後始末作業の時間が掛かり、CPUの性能が上がるにつれ深刻な問題となりました。OSというソフトウェアは、このような無駄を少しでも減らし効率を高め生産性を上げる目的で誕生しました。
    やがて登場したOS/360においてはオペレーターを介さずにプログラマーから直接OSに「実行するプログラムと使用するデータ」を示せるように採用されたのがJCL(Job Control Language:ジョブ制御言語)です。JCLを使用してジョブにおける作業の内容と使うコンピュータ資源をOSに直接指示するわけです。言語となっていますがスクリプトの1種で、プログラマーがOSに渡す「作業指示書」です。
    JCLによってオペレーターは紙の指示書によるジョブの準備から解放され、プログラマーはOSに直接指示できることになり、運用の効率と正確性が向上したことは言うまでもありません。またOS/360で採用されたJCLの基本的な文法や機能は、現在のz/OSでもほとんど変化はなく互換性のためとは言え、当時の実装の完成度を示すものでもあります。
    JCLは大きく3つの要素(JOB文、EXEC文およびDD文)で構成され、先頭が2つの//記号で始まる80バイトの固定長レコード(カードイメージ)の集合です。このJCLをリーダーで読み取らせることで、ジョブが開始されプログラムが実行されます。リーダーを介してMVSにJCLを読み取らせる操作のことを「サブミット」と呼びます。
    JCLについては「JCL入門」にて解説してあります。


    ローディングと実行

    JCLがサブミットされジョブが開始されると、DD文で指定された資源が割り振られ、プログラムの実行が始まります。
    MVSはEXEC文で指定されたプログラムを探すことから始めます。STEPLIB DD文があればそこで指定されたデータセットからプログラムを読み込みます。STEPLIBが指定されないか、指定されてもそのライブラリーにプログラムが入っていなければOSのリンクライブラリーから探し出します。ライブラリーに入っているプログラムはMVS用の実行可能形式になっています。実行可能形式はソースプログラムがコンパイルされて出来上がったオブジェクトプログラムがさらにリンケージ・エディター(リンカー)によってロードモジュールに変換されたものです。
    ロードモジュールは命令とデータの集合であるプログラム部分(モジュール・テキスト)とプログラムの属性や大きさ、実行を始める最初の命令位置、いつどのような言語で作成されたなどの制御と管理情報の部分で構成されています。
    MVSはEXEC文で指定されたプログラム(ロードモジュール)をライブラリーに見つけるとそれをメモリー上に読み込みます。この動作をローディングと呼びます。MVSによってプログラムがローディングされ、実行の制御に必要なコントロール・ブロックが作られた後、プログラムの実行が始まります。

    Filed in ..基礎編

    不要なメッセージをコンソールに出さない方法

    By 神居 - Last updated: 日曜日, 10月 26, 2008

    コンソールと言うのは、システムやジョブの異常な状態をオペレーターに通知したり、必要な処置をオペレーターから受け入れるためにも使われます。もちろんエラーに限らず「ちゃんとシステム動いてますよ」とか「これからこんなジョブが開始します」「今この処理が終わりました」などと言う正常な状態の状況通知にも使われています。
    しかしながら、どうでもいいんじゃないかこれは?とか、どう見てもプログラマーのデバッグ用メッセージ?見たいなものも少なくありません。あまりにも多くのメッセージが頻繁に出てコンソールのスクロールが休む暇がない、と言う状況は好ましいとは言えません。
    OSは本当にクリティカルな状態を示すメッセージはスクロールされない属性でメッセージを出してはいますが、アプリケーションなどではそこまで凝った作りをしていないものが多いので、いざと言うときにオペレーターは見逃してしまうかも知れません。また何らかの対応のためOSコマンドを使った時、コマンドの実行結果が見る間もなく流れて行ってしまっては困ります。システム・パフォーマンスの面でも得はしません。MVSパフォーマンスチューニング入門

    そこでオペレーターにいちいち知らせなくてもいいだろう、と言うメッセージはコンソールへ出さないようにできます。従来はWTOのOS EXITルーチンなどが多用されましたが、単にメッセージ出力を抑止するだけなら今は出口ルーチンを書く必要はありません。MVSにはMPF(Message Processing Facility)と言う機能があり、このパラメーターを使って簡単に出力を抑止できます。

    上から3つはメッセージIDによって抑止するメッセージを個別に指定しています。4番目はUAP100番台のメッセージは一切表示しないことを指定します。5番目はIEF099メッセージは表示はさせるが、ユーザー出口ルーチンWTOEXIT1を呼び出してユーザー固有の処理させる例です。
    これをMPFLST01として作成した場合はSET MPF=01コマンドでアクティブにできます。すでに他のMPFLSTが使われているかも知れません。D MPFコマンドで確認できます。もしMPF=00が使用されていると00が取り消され01に置き換わります。既存のMPFLSTに追加する場合はSET MPF=(00,01)と指定します。
    MPFによって表示が抑止されてもそれはコンソール上だけです。SYSLOGにはきちんと書き出されますから何か問題が起きた場合にはSYSLOGをトレースすれば表示されなかったメッセージを確認することはできます。
    ※MPFはMVS固有の機能です。

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

    MSPやってる人が新たにXSPも使わないといけなくなったら

    By 神居 - Last updated: 日曜日, 10月 26, 2008

    富士通にはMSPとXSPと言う2つのOSがあります。MSPはMVSと互換を持ったOSです。MVSとMSPとVOS3は基本的に同じなので、いずれかを知っていればこの3つの中ならすぐ応用が利きます。ところがXSPとなるとだいぶ変わります。コンソール、OSコマンド、JCL、ユーティリティなどなど共通性がありません。
    ところがTSS(XSPではAIFと言う)、AIM、VTAM、TISPあたりは使い方も見た目も同じです。ジョブ管理が異なるのでPFDによるSYSOUT(XSPではSOUT)の操作なんかは若干変わりますが、PFD自体はパネルサービスもエディターもビュワーもMSPとXSPは同じです。TSSコマンド、コマンドプロシージャ(MVSで言うCLIST)も基本的には共通です。
    MSPとXSPの両方を扱うならば、TSS主体で操作すればわりとスムーズに行きます。バッチ処理やユーティリティとかは絶対必要なものに抑えて、TSSとPFDやCLISTで出来ることはそっちでやるように意識するといいと思います。

    私はずっとMVS系でやってきたので、最初XSPにはかなり違和感がありました。MVSのようにJCLでdsname(member)のつもりで、FILE=dsname,MEMBER=memberとして区分データセットのメンバーを書き込んだら、それ以前にあった既存のメンバーが全部消えてしまった!!驚きましたよ、ホントに。後で聞いたら「それってADのパラメーター指定しないとだめですよ」と言われた。「(FILE=dsname,AD)」
    プログラムがOUTPUTオープンの場合、JCLでADを指定しないとPSでは頭から上書きされる、PDSではメンバーを全部消してそのメンバーを新規に登録する動きになる。そりゃないだろうって思ったけどまぁ文化の違いかな。それで嫌になって思いついたのがTSS。いろいろ比べるとバッチでは全く違うことがTSSでなら同じなことが多い。もちろん深掘りするには避けてないでちゃんと覚えなければいけませんけど、基本はMSPだけどたまにXSPもいじるって言う方(あるいは逆)ならそんな方法もあります。

    1つだけサンプルとなるCLISTを載せます。
    SYSOUTの表示はよく行う操作ですが、XSPのPFDにはMSPのPFD3.8に相当するパネルでのビュワーがありません。いちいちFIBGETコマンド打って、PSファイルに移さなければなりません。面倒なので作ったCLISTです。ジョブのSYSOUTをPSデータセットに移してPFD1のブラウザーを呼び出します。


    CLISTをEXコマンドで実行したら、取り込み終わった頃を適当に見計らってENTERキーを押す。OUTPUTまたはFIBGETコマンドが終わっていたら、何でもいいから何か文字を入力してENTERすれば、PFDブラウザーが起ちあがり指定したジョブのSYSOUTが表示される。取り込み先のデータセットは適当な大きさで作ってください。

    Filed in OSの互換性, 知っておくと便利なテクニックなど

    STCとバッチJOBでJCLを共用する方法

    By 神居 - Last updated: 日曜日, 10月 26, 2008

    同じJCLをある時はJOBとして、またある時はSTCタスクとして起動方法を使い分けることもできます(ESA V5以降のMVSでサポートされます)。

    従来STCタスクを起動する場合は、その起動用プロシージャをシステム・プロシージャ・ライブラリーに登録しました。プロシージャ自身はSTARTコマンドで直接STCタスクとして実行するか、他のジョブJCLから呼び出して実行する必要がありました。しかし現在では、マスタースケジューラーの起動プロシージャであるMSTJCLnn(SYS1.PARMLIBに入っている)にIEFJOBS DD文を定義することで、そこで指定された区分データセット内のジョブ用JCLメンバーをSTARTコマンドで直接実行することができます。またそのメンバーをSTARTコマンドでなくJES2にサブミットすればJOBとして実行することもできます。STARTコマンドでSTCタスクとして実行した時のジョブ名もJCLのJOB文に指定されている名前になります。IEFJOBSに登録する場合JCLはJOB文を使用してあくまでも通常のJOB用に作ります。PROC文で始めてはなりません。

    JES2が起動された後、同じ名前のメンバーがIEFJOBSとJES2のPROC00の両方にあればIEFJOBS側が使用されます。この方法だとSTCタスクであってもストリーム内データ(DD *)が利用できます。STCタスクで動かすがSYSINデータをDD *で直接指定できればなぁって思ったことはありませんか?

    詳細はz/OS MVS JCL解説書の「開始済みタスクのソースJCL の決定」に載っています。

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