07.1非同期事象の待ち合わせと通知(WAITとPOST)

By kamii - Last updated: 火曜日, 11月 25, 2008

システムプログラムでは「いつ来るかわからない」「いつ終わるかわからない」と言った事象(イベント)を待ち合わせることは多々あります。メインフレームでもイベントが発生・終了するまで、来たか?来たか?、終わったか?終わったか?、とループしてタイミングを合わせる方法がありますが、一般のプログラムでは使いません。OSであってもループによるタイミング合わせは本当に必要な所だけに限定して使っています。
MVSはイベントの完了の待ち合わせにWAIT、イベントの完了の通知にはPOSTと言うサービスを提供しています。プログラムはこのサービスを使うことで、ループなどしなくても、必要なイベントの発生や終了のタイミングを合わせることができます。

上に挙げたこれらの例も、いつ発生するかわからない事柄です。インターバルタイマーに関しては例えば10秒後と言う時間はわかっていても、いつが10秒後なのかわかりません。人間は時計を見ながら10秒後を知ることができますが、これはループと同じです。オペレーターコマンドや端末の受信データはわかりやすいでしょう。いつコマンドが入力されるか、いつ実行(エンター)キーが押されるかは人間様次第です。I/O動作の完了やJCLのサブミットの待ち合わせはOSに取っての待ち合わせ事象の1つです。チャネルで実行されたI/Oはいつ完了するかわかりません。JCLは人間がコマンドやパネルでサブミット操作を行いますが、OSにしてみれば、それがいつ行われるかまったく予測できません。
これらのようにいつ起きるかわからない事を非同期事象(asynchronous event)と呼びます。バッチ処理用のアプリケーション・プログラムを作るだけではなかなかわかりにくいのですが、MVSは基本的にイベント駆動型のソフトウェアです。さまざまな非同期事象の発生を待ち受け、それに応じた処理をディスパッチします。このサイクルを延々と繰り返して行くわけです。


タイマーによるインターバル時間の経過を待ち合わせる(WAIT)

WAITマクロはイベントの完了を待ち合わせます。WAITマクロではどのイベントかを識別するため、ECBと言う1ワードの領域を使用します。ECBの先頭のビット0をWAITビット、ビット1をPOSTビットと呼びます。WAITマクロを発行するためにはECBを用意し、ビット0をクリアーしておかなければなりません。サンプルではビット0のクリアーではなくMVIでバイト毎クリアーしていますが、これも一般的な方法で非同期事象の開始前であることがはっきりしている時は、その時点ではこのECBにPOSTするプログラムは存在しないためPOSTビットも含めて0クリアーしてかまいません。XC命令でワード毎クリアーしてもかまいません。
イベントの識別と言ってもややこしい規約があるわけではなく、単に待ちになる側と、完了を伝える側でどこにECBがあるかがわかっていればいいのです。複数のイベントを並行して取り扱うような場合、それぞれのイベントをどのECBを使って待ち合わせるかを取り決める、と言うことです。一般的にはWAITする前にECBのアドレスを、実際に非同期事象を実行する側のプログラム(POSTする側)に何らかの手段で伝えます。

WAITマクロを発行するとプログラム(タスク)は指定したECBにPOSTがなされるまで、スーパーバイザー(WAITルーチン)の中で待ち状態となります。ECBのWAITビットは1にされ、WAIT中プログラムを識別するトークン(RBアドレス)が下位3バイトに格納されます。

ECBをどこでクリアーするかは重要なことです。待ち合わせる事象が開始する前にクリアーするのが原則です。タイマーならSTIMER発行前、オペレータ応答の受け取りならWTOR発行前、データの受信ならRECEIVE要求の前です。イベントを開始させてしまってからクリアーするとタイミングによってはイベントをロストさせてしまいます。
イベントによってはWAITしようとする時点で既にPOSTされている場合もあり得ます。すでにPOST済みのECBを指定してWAITマクロを発行しても問題ありません。実際にWAITせずにすぐに発行元プログラムに戻ってきます。しかしWAITビットが1になっているECB(WAIT中ECB)を指定するとプログラムはABENDさせられます。

これは誤ったECBクリアーの例です。STIMETRマクロで指定する時刻や間隔時間にもよりますが、99%は正しく動くでしょう。しかし指定した時刻が15:00丁度である時、STIMETRマクロが15時に限りなく近い15時前での発行であった場合、STIMERマクロから復帰した時点でWKUPECBにはすでにPOSTがなされているかも知れません。指定した間隔時間が1/10秒などと言う極端に短い時間である時も、STIMERマクロから復帰した時点で実時間で1/10秒は過ぎてしまっているかも知れません。
ロジックでは無条件にECBをクリアーしていますから、その場合永遠にPOSTされないWAITに入ってしまいます。これがイベントのロストです。WAIT発行前にPOSTビットをテストして1であればWAITを迂回するロジックもありですが、この例に関して言えばそんなことをするよりはECBのクリアーをSTIMETRマクロの発行前に行えばよいのです。非同期事象はその名の通り非同期ですから指定したイベントがいつ完了するかは予測できませんが、この例では自分がSTIMERを出さない限り時間計測と言う非同期イベントは起き得ないのでPOSTされることもありません。そのきっかけとなるSTIMERマクロの前でECBをクリアーできます。


タイマーによるインターバル時間の経過を通知する(POST)

POSTマクロはWAITの逆でイベントの完了を通知します。指定したECBにPOSTビットを設定し、WAIT中のプログラムがあれば待ち状態を解きます。この時ECBのビット2?31に任意のPOSTコードを設定することもできます。省略すればビット2?31は0にクリアーされます。POSTする側は相手がWAITしているかどうかを考える必要はありません。
このサンプルはSTIMERマクロによるインターバル時間の経過の待ち合わせと通知の例です。STIMERマクロを出した後のWAITマクロによってプログラムのタスクは待ち状態になります。10秒経過するとTIMREXITルーチンが実行されます。タスクが止まっている状態でも割り込んで実行されます。このようなプログラムを非同期出口ルーチンと言います。MVSでは長時間掛かるサービスやいつ完了するか予測できないサービスの完了を通知するために非同期出口ルーチンが使われるものがいくつかあります。

WAIT/POSTはマルチタスクのプログラムで使うもの、と言うイメージがありますが、シングルタスクのプログラムでも使用するAPIによってはWAIT/POSTによる待ち合わせと通知の処理が必要になります。


複数のイベントを待ち合わせる(ECBLIST)

複数の非同期イベントを取り扱うプログラムでは、いずれかのイベントが完了したら通知してもらうようにすることもできます。サンプルでは複数のECBの内、どれか1つが完了したら通知してもらう例です。これはマルチイベント・シングルウェイトです。複数個のECBが完了したら通知してもらうようにすることも(マルチイベント・マルチウェイト)、すべてのECBが完了したら通知してもらうようにすることも(マルチイベント・オールウェイト)できます。ただしマルチウェイトの場合どのECBから完了したかはわかりません。シングルウェイトであってもWAITが解けた後に別のECBにもPOSTされることがあり得ます。同様にどのECBから終わったかはわかりません。どちらの場合であってもどのECBのイベントが終わったかは、プログラムが自分でPOSTビットの立っているECBを探す必要があります。
なおマルチイベントではWAITから復帰した後、POSTビットとPOSTコードはPOSTされたECBにのみ設定されています。POSTされたECBを含めすべてのECBのWAITビットは0になっていますが、POSTされなかったECBのPOSTコード部にはRBアドレスが設定されたままになっていることに注意してください。MVS側はECBにRBアドレスが設定されたままで再びWAITが出されても支障ありませんが、POSTされなかったECBはECBワード自体が0(あるいはWAIT発行時の内容)になっているものと期待してロジックを作ると正しく動きません。

Filed in .基礎編

09.REXX 組み込み関数

By takao - Last updated: 火曜日, 11月 25, 2008
REXXは大量の組み込み関数で、プログラマーの負担を減らそうとしています。関数ライブラリーはREXXでも作れますし、多くのプロダクトが提供していたりもします。
ここでは、個々の関数について、マニュアルのような解説はしません(できません)。適当に分類してみたので、「あー、こんな関数があるのね」と頭に留めておいて、必要な都度、マニュアルを調べてください。

文字列
* ABBREV (Abbreviation)
* CENTER/CENTRE
* COMPARE
* COPIES
* DBxx (Double-Byte Character Set Functions)
* DELSTR (Delete String)
* DELWORD (Delete Word)
* FORMAT
* INSERT
* LASTPOS (Last Position)
* LEFT
* LENGTH
* OVERLAY
* POS (Position)
* REVERSE
* RIGHT
* SPACE
* STRIP
* SUBSTR (Substring)
* SUBWORD
* TRANSLATE
* TRUNC (Truncate)
* WORD
* WORDINDEX
* WORDLENGTH
* WORDPOS (Word Position)
* WORDS
* VERIFY
* XRANGE (Hexadecimal Range)
制御
* ADDRESS
* ARG (Argument)
* CHARIN (Character Input)
* CHAROUT (Character Output)
* DIGITS
* LINEIN (Line Input)
* LINEOUT (Line Output)
演算
* ABS (Absolute Value)
* BITAND (Bit by Bit AND)
* BITOR (Bit by Bit OR)
* BITXOR (Bit by Bit Exclusive OR)
* B2X (Binary to Hexadecimal)
* C2D (Character to Decimal)
* C2X (Character to Hexadecimal)
* D2C (Decimal to Character)
* D2X (Decimal to Hexadecimal)
* MAX (Maximum)
* MIN (Minimum)
* RANDOM
* X2B (Hexadecimal to Binary)
* X2C (Hexadecimal to Character)
* X2D (Hexadecimal to Decimal)

検査
* CHARS (Characters Remaining)
* CONDITION
* DATATYPE
* DATE
* ERRORTEXT
* FORM
* FUZZ
* LINES (Lines Remaining)
* QUEUED
* SIGN
* SOURCELINE
* STREAM
* SYMBOL
* TIME
* TRACE
* VALUE
Filed in REXX入門

06.2CSECT名でプログラムのローディングを行う

By kamii - Last updated: 月曜日, 11月 24, 2008

LOADマクロでのローディングや、LINKマクロでの呼び出し時にEP/EPLOCで指定できる名前はロードモジュールのメンバー名です。CSECT名でのローディングや呼び出しはできません。動的構造のプログラムでCSECT名を使ってモジュールにアクセスするには少し工夫が必要です。


ロードモジュールの先頭にアドレスポインターフィールドを作る

いろいろなプログラムで使うさまざまな共通サブルーチンを1つのロードモジュールにまとめあげたライブラリーモジュールを作る場合、バインダーで連携編集されるモジュールのすべてのCSECTに先だってサンプルのようなV型アドレス定数(VCON)のフィールドを作ります。ここの部分のCSECTはなくてもかまいませんが、わかりやすくするためにもロードモジュールと同じ名前などでCSECTの定義をしておきましょう。結合したCSECT名を指定したVCONを必要なだけ並べます。最初のCSECTの前に定義してもいいですが、サブルーチンの数が多くきちんと管理するならば、VCONだけのソースメンバーを作った方がいいでしょう。

サンプルのJCLでバインドすれば、バインドされたロードモジュール名をCOMMSUBRとした場合、LOADマクロでロードされたCOMMSUBRの入口点アドレスがサンプルのCOMMVCON CSECTになります。先頭から+0番地の1ワードがSUBRTN1のアドレスが入ったポインターになり、先頭から+4番地の1ワードがSUBRTN2のアドレスが入ったポインターになります。SUBRTN2を呼ぶ場合はCOMMSUBRの先頭+4番地の内容をロードすればそれがSUBRTN2の入口点アドレスです。直接SUBRTN2の名前でLOADすることはできませんが、ロードしたモジュール内ののCSECTの位置はこのような方法で求めることができます。
このようなVまたはA型アドレス定数で他のモジュールやデータ・テーブル領域などをポイントするポインターフィールドの集合を「ベクターテーブル」と呼びます。


ロードモジュールにCSECT名のALIASを付ける

最初の方法と異なりLOADマクロで直接CSECT名を指定できるようにする方法です。バインダーのALIAS(別名)機能でロードモジュールに別名を付けます。ALIAS制御文にCSECT名を指定すれば、それがそのまま別名になります。この例ではロードモジュール・ライブラリー内にはCOMMSUBR主メンバー名の他にSUBRTN1,SUBRTN2,SUBRTN3の副メンバー名が作成されます。

プログラムがLOADマクロのEP/EPLOCでSUBRTN2を指定すれば、ロードモジュール自体はCOMMSUBRがローディングされますが、入口点アドレスにはSUBRTN2のCSECTアドレスが通知されます。特定のCSECT部分だけを抜き出してロードすることはできませんが、指定したCSECTのアドレスを通知してもらうことはできます。なおGR1で通知されるモジュール・レングスもロードモジュール全体の長さであって、CSECT部分の長さではありません。

Filed in 中級編

06.1プログラムのローディングと実行(LOAD,LINKとXCTL)

By kamii - Last updated: 月曜日, 11月 24, 2008

プログラムのローディングと実行は、一般のプログラムでも身近な機能です。規模の大きなプログラムでは複数のモジュールに分割して開発・管理・保守が行われます。複数のモジュールで構成されるプログラムの処理に関するMVSの機能を解説します。


MVSにおけるプログラムの構造


再入可能(リエントラント)プログラム

単純構造や動的構造に関係なくプログラム・デザインに関するもので、複数のタスクで同時に実行できるプログラムのことです。リエントラント(reentrant)構造プログラムとも呼ばれます。プログラムが処理に使うデータの内、更新を伴うものをプログラム内部に置いていない設計になっているものです。端的な例がレジスター保管域です。レジスター保管域をプログラム内に置いたプログラムが同時に複数のタスクで実行されると、タスク1がそのプログラムでサブルーチンAを呼び出し、そのサブルーチンが実行中に、タスク2でも同じプログラムが実行されサブルーチンAが呼び出されると、最初に呼び出されたタスク1のレジスター保管域は後から呼び出されたタスク2のサブルーチンAによって上書きされてしまいます。そうなるとタスク1で最初に呼び出されたサブルーチンAは元の呼び出し元に正しく戻れなくなってしまいます。
これは同じ領域にローディングされているプログラムを複数のタスクで共有使用する場合の問題です。同じプログラムのコピーをタスク毎に使えばこのような問題は解決しますが、メモリーの利用効率やパフォーマンスの観点で劣ってしまいます。特にあらゆるプログラムから頻繁に利用されるシステムの共通機能ルーチンのようなものでは顕著です。そこでこのような問題を解決するために、レジスター保管域など書き込みされるデータ領域をプログラムの外に置き、タスク毎にGETMAINして使用すればデータ領域は他のタスクによって壊されることがなくなります。プログラムの命令コード部分と書き込みされるデータ領域を分けた設計になっているプログラム・モジュールを再入可能プログラム、再入可能モジュールと呼びます。

なお再入可能プログラムのように複数のタスクで同時に使用することはできないものの、データ領域をプログラムの先頭で初期化するような処理を持ち、順番に1タスクずつなら同じ領域のプログラムを実行することができるものは逐次再使用可能(reusable)プログラムと呼びます。



単純構造プログラムにおけるサブルーチンの呼び出し

単純構造プログラムではサブルーチン(他のモジュール)はCPU命令で直接呼び出すことができます。リンケージ規約に則ればGR15に呼び出すモジュールの入口点アドレス、GR14に戻りアドレスを格納して、入口点アドレスへ分岐します。BASR(BALR)命令をサンプルのようにコーディングすればいいのです。サンプルではGR1にパラメーター・アドレスをセットしています。パラメーターはアドレスパラメーター・リスト形式で渡していますが、呼び出す側と呼び出される側で合意すればどんな形式で渡してもかまいません。アドレスパラメーター・リスト方式はパラメーター数が少ないときは面倒ですが汎用的な方法なので、他の言語で作成されたプログラムとリンケージを取るような場合にも適しています。

2番目のサンプルは最初のサンプルとまったく同じことを、CALLマクロ命令を使って行うものです。呼び出すモジュールの入口点アドレスフィールドやパラメーターリストなどはCALLマクロの中で自動生成されます。CALLマクロはスーパーバイザーのサービスを呼び出すAPIではなく、機能に対応するCPU命令列をプログラマーに代わり生成するものです。COBOL言語を主に使うプログラマーには比較的理解しやすい方法です。
最初に呼び出すプログラムの入口点名(CSECT名)の名前または入口点アドレスを格納したレジスター番号(15)を指定し、続いてプログラムへ渡すパラメーターが格納されている領域の名前を()括弧でくくって指定します。VLはパラメーター・リスト上の最後のパラメーターを示すエントリーの先頭ビットを1にするパラメーターです。最終パラメーターのエントリーの先頭ビットを1にする必要があるかどうかは、プログラムの呼び出しインターフェースによって決まります。

3番目は呼び出されるプログラムで利用できる関連マクロを紹介します。SAVEマクロはプログラムの先頭で呼び出し元のレジスターを保管する命令を展開します。ただし自プログラムのレジスター保管域の定義や呼び出し元プログラムのレジスター保管域とのチェインを行う命令は生成されません。サンプルでは省略していますが、必要な処理は自ら行わねばなりません。
サンプルのように,,*を追加指定すると、CSECT名をプログラム中に埋め込みます。これはプログラム・ヘッダーあるいはeye catcherとも呼ばれ複数のCSECTで構成されるプログラムのダンプを見るときに、どのモジュールかを判別しやすくするために行われるものです。規模の大きなプログラムや商用プログラムでは、さまざまな情報を持つヘッダーが作られることも多く、プログラム・デザインの1つでもあります。
RETURNはSAVEマクロの逆で呼び出し元レジスターを保管域から復元して、呼び出し元へ復帰する命令を展開します。
CALL、SAVEおよびRETURNはサブルーチンを呼び出したり、プログラムのハウスキーピング処理を行うためのアシストマクロですが、必ずしも使わなければならないものではありません。特にSAVEとRETURNマクロは自分で直接命令を書いてもさほど違いはありませんが、一般的にはよく利用されていますから、使い方を知っていれば、他の人が書いたプログラムを追う場合などで役に立ちます。


動的構造プログラムにおけるモジュールのローディング

動的構造のプログラムでは呼び出すモジュールは各々が独立したメンバーになっているため、CPU命令だけでは呼び出すことができません。呼び出す前にLOADマクロを使ってあらかじめリージョン内にローディングしておきます。ローディングされたモジュールの入口点アドレスはGR0に返されます。モジュールがローディングされた後は、単純構造のプログラム同様にBASR命令やCALLマクロで呼び出すことができます。使用し終わったローディング済みモジュールはDELETEマクロでリージョン内から消去します。(再入可能あるいは再使用可能なモジュールは呼び出しの都度でなく、これ以上呼び出す必要がなくなった時点でDELETEすればよい)
サンプルではPLISTをCALLマクロのリスト形式を使って定義しています。DC A(name)命令の代わりに利用したものです。

2番目は動的リンクの例です。この動的リンクはアプリケーション自らがやっており、MSPがアシストする動的リンク構造ではありません。どのOSにも共通に利用できる方法です。LOADマクロを出す前にサブルーチンの入口点アドレスをテストします。0でなければすでにローディング済みなのでLOADは迂回します。0ならば初回なのでLOADマクロを発行してローディングします。モジュール名は名前を直接指定するのではなく、EPLOCパラメーターで名前を格納した領域アドレスを指定する方法を使っています。ERRETパラメーターはローディングに失敗した場合に実行されるルーチンのアドレスです。失敗するとここで指定したラベル箇所(アドレス)に飛び込んできます。ERRETを指定しないとローディングに失敗した場合プログラムはAEBNDします。ERRETルーチンに飛び込んできた時のGR1にはABENDコードが入っています。


動的構造プログラムにおけるサブルーチンの実行

LINKマクロはモジュールをローディングして呼び出します。CALLマクロの動的構造プログラム版と言ってもいいでしょう。LOADマクロはロードモジュールをメモリーにローディングするだけですが、LINKマクロはローディング+呼び出し、となります。呼び出すプログラムの処理が終わるとロードモジュールはメモリーから消去されます。
PARAMパラメーターは呼び出すプログラムに渡すパラメーターを指定します。CALLマクロにおけるパラメーター渡しと同様の指定を行います。VL=1もCALLマクロのVLパラメーターと同じ意味です。

2番目の例はLOADマクロ発行後にLINKマクロを発行する例です。このLINKではその前にLOADを発行していますのでモジュールは改めてローディングされません。ロード済みモジュールが使われます。しかし3番目の例では注意が必要です。2回目のLINKマクロではモジュールが改めてローディングされてしまいます。そして呼び出したプログラムが終了し、LINKマクロの処理が終了すると改めてロードされたモジュールのみが消去されます。このような動きは呼び出すモジュールがRENT,REUSのどちらの属性も持たない場合に起きます。モジュールにRENT,REUSいずれかの属性があればローディング済みのモジュールは共用されます。またREUS属性のモジュールは複数のタスクで同時に実行できないので、複数のタスクからLINKが発行されると、先にLINKマクロを発行したタスクでのモジュールの処理が終了するまで、他のタスクのLINKはスーパーバイザー内で待たされます。この待ち合わせにはENQは使用されていませんので、REUS属性のモジュールをLINKマクロとBASR等による直接CALLを混在して呼び出すことは危険です。LINKマクロに統一する方が間違いありません。

REUSモジュールでなければLOADとCALLの組み合わせがパフォーマンスの面でも優れています。実戦では本当の意味での逐次再使用可能モジュールをプログラムとして作ることは稀です。バッチ処理のようにシングルタスクのプログラムならREUSもRENTも必要ありませんし。マルチタスクならば再入可能プログラムの方が一般的です。わざわざ同時並行での実行を目的にタスクを分けているのに排他制御されてしまうREUSモジュールを作ることは設計に矛盾が起きてしまいます。REUSモジュールはどちらかと言えば、プログラムそのものよりはプログラムで使用するテーブルデータなどを作るために使われる方が多いでしょう。名前がわかっていればLOADマクロによって入口点アドレスが求められます。REUSならば複数のタスクでLOADされても空間内での初回のLOAD時のみディスクからモジュールがロードされ、2回目以降は同じアドレスが通知されます。なお1つのロードモジュールをDELETEせずにLOADマクロを出せる上限回数は32767です。これは知っておくべき事です。


動的構造プログラムにおける他プログラムへの実行切り替え

XCTLマクロはLINKと異なり、呼び出したプログラムが終了しても自分に戻ってきません。呼び出したプログラムが終了した後は、自分ではなく自分を呼び出した親モジュールに直接戻ります。サブルーチンの処理が長く複数のモジュールに分割する場合や、機能に応じて処理モジュールを分割する場合などに利用できます。XCTLを発行するとEP/EPLOCで指定したモジュールに制御が渡った時点で自分自身のモジュールは他のタスクで使用中でなければ消去されます。(r1,r2)パラメーターで自分が呼び出されたときのレジスターを復元することができます。r1は2以上、r2は12以下で連続した範囲のレジスターがXCTLマクロ発行時点のGR13が示すレジスター保管域から復元されます。GR1は復元できないのでXCTLマクロ発行前に必要な値をセットします。GR0は引き継ぐことができません(実際に大丈夫だとしても保証されているわけではない)。GR13は自分を呼び出した親モジュール(呼び出し元)の保管域をポイントしておきます。


プログラムの終了(SVC 3:EXIT SVC)

マニュアルには載っていませんが、プログラムの終了はSVC 3によって行われます。リンケージ規約ではGR14が呼び出し元への戻りアドレスを示しますが、JCLのEXEC文のPGMパラメーターで指定され実行されたロードモジュールやLINK/XCTLマクロによって呼び出されたロードモジュールの入口点では、GR14が示す戻りアドレスはOSのコントロールブロックCVT内にあるSVC 3命令をポイントしています。なのでBR 14命令で戻る代わりにSVC 3命令を直接コーディングすることもできます。ただしBASR(BALR)命令で呼び出されたプログラムはSVC 3を使ってはなりません。呼び出し元へ戻らずにプログラムは終了してしまいます。BR14かSVC3かを考えて使い分けるのは現実的ではありませんので、基本通りBR 14でいいのですが、スーパーバイザーを経由して呼び出されたモジュールは戻る際もスーパーバイザーを経由する必要があります。戻るときはマクロではなくBR命令で戻っていますが、実際には分岐先にあるSVC 3命令が実行されてEXIT SVCが呼び出されスーパーバイザーを経由して呼び出し元へ戻っているのです。

サンプルはSVC 3命令でプログラムを終了させるものです。呼び出し元に戻った時のレジスターはSVC 3命令発行時の内容と同じです。プログラムを終了する場合はレジスターを復元しなくてもMVSがおかしくなるようなことはありませんが、LINKやXCTLマクロで呼ばれた場合、レジスターをきちんと復元しないと、戻った後で呼び出し元は正しく動くことができません。

Filed in .基礎編

05.2ダンプの書き出しとトレースの記録(SNAPとGTRACE)

By kamii - Last updated: 金曜日, 11月 21, 2008

プログラム(リージョン)のダンプを取得するにはDUMPオプション指定のABENDマクロを発行する方法があります。しかしABENDマクロではプログラムの実行はそこで終わってしまいます。プログラムを終わらせずにダンプを取るには自らストレージの内容を編集してデータセット(SYSOUT)に書き出すこともできますが、SNAPサービスを使えば簡単にダンプを取ることができます。またダンプはエラーが起きた時点でのスポットな診断情報ですが、エラーの内容によっては、プログラムの動きやデータの変化を時系列に記録したい場合があります。これはトレースと呼ばれます。トレースもGTRACEマクロで簡単に記録することができます。


プログラムの状態やストレージの内容をダンプする

SNAPマクロはストレージ・ダンプを取得します。ダンプリストはDCBパラメーターで指定したDD文で定義したデータセットに書き込まれます。サンプルではDD名SNAPDUMPとしていますが任意の名前でかまいません。SNAPマクロ発行前に出力先データセットはあらかじめOPENしておかなければなりません。ダンプの出力が終わったらCLOSEします。DCBはサンプルのように定義します。サンプルでは各マクロ命令のエラーをチェックしていませんが、必要に応じてエラー処理を組み込みます。

1番目のサンプルは自分のプログラム領域をダンプする例です。ただしGETMAINした領域はダンプされません。GETMAINした領域のダンプが必要な場合は、PDATAパラメーターにSPLSを追加します。
2番目のサンプルは自分のプログラム領域を含めリージョン全体をダンプする例です。OSのコントロールブロックはフォーマットされるだけでなく、割り当てられている領域自体も出力されます。SDATAおよびPDATAパラメーターはMVSの例です。MSPとVOS3では若干異なるのでマニュアルで確認して下さい。
3番目のサンプルは指定したストレージ領域をダンプする例です。ダンプしたい領域の開始および終了アドレスを指定しています。
4番目のサンプルも指定したストレージ領域をダンプする例です。ダンプしたい領域の開始および終了アドレスをパラメーターではなく、リストで指定しています。リストはダンプしたい領域の開始・終了アドレスのペアーを複数個並べたものです。(ラベルSTORLIST)この例では3つの領域をダンプするので開始・終了アドレス×3で6ワードを使います。SNAPルーチンが最後のエントリーを判別するため、最終エントリーの終了アドレスの先頭ビットを1に設定します。MVSではSTRHDRパラメーターでダンプする領域に対応する見出し文字列を指定することもできます。見出しは1バイトの長さ+タイトル文字列で構成されます。

OSのスーパーバイザー・ルーチンや出口ルーチンなどでダンプを取る場合は、SNAPマクロではなく、SDUMPマクロを使いSYS1.DUMPnnデータセットにSVCダンプを書き出します。システムプログラムであっても起動JCLがあればDD文が定義できますから、SNAPマクロは利用されます。しかしOS出口ルーチンのように不特定の空間で動作するものやシステム空間で動作するものはDD文を定義できませんので、SDUMPサービスによるSVCダンプが使われます。SDUMPマクロはAPF許可プログラムやスーパーバイザーモードのプログラムでなければ利用できません。


GTFにトレースレコードを書き込む

GTRACEマクロはGTFトレースデータセットに、ユーザートレースレコードを書き込みます。OPENもCLOSEもDCBも必要ありませんし、ある意味QSAMより簡単です。書き込み可能なデータの長さはOSによって異なります。(サンプルコードを見て下さい)VOS3では正式なマクロ名はETRACEですが、GTRACEでも利用できます。

トレースレコードを書き込むにはEID(EVENT ID)を決める必要があります。ユーザープログラムでは0?1023が指定できます。特に規約などがなければ1023でいいでしょう。FIDと言う、レコードを編集するときの識別番号(編集するプログラムを決める識別子)もありますが省略してかまいません。(FID=0とする)この場合IPCSやPRDMPでフォーマットする際、レコード内容はダンプ形式に編集されます。文字で構成されたレコードなら、わざわざOSのユーティリティでフォーマットしなくても、GENERでSYSOUTにコピーしても判別することができます。
正しく書き込めればGR15に復帰コード0が返ります。復帰コード4はGTFが起動されていないことを示します。8以上は基本的にパラメーターエラーです。復帰コードが32の場合、書き込むデータがページアウトされていたことを示します。これを防止するにはパラメーターPAGEIN=YESを指定します。(MVSとVOS3のみ)トレースデータ領域がページアウトされていた場合、ページインして書き込めるまでリトライします。絶対にロストしたくないレコードならPAGEIN=YESを指定します。よほどページングがヘビーなシステムでなければGTRACEを発行する前に書き込むデータを作るか触るかしておけば大丈夫でしょうが、気になる方は指定して下さい。マクロの展開形を見ればわかりますが、復帰コードが32ならデータ領域を一旦参照して(ページインされる)から書き込みをリトライします。

GTFにレコードを書くのは実は簡単です。MC命令で直接書き込むことができます。(実際はプログラム割込み:モニターイベントを起こし、割込みハンドラー経由でGTF空間にトレース書き込みを依頼する)わざわざGTRACEマクロを使わなくても直接CPU命令で行ってもかまいません。2番目のサンプルがGTRACEを使わず直接命令で行うものです。問題プログラム状態で利用できます。MVSではGTRACEマクロはAPF許可プログラム用のAPIマニュアルに記載されていますが、実際はAPF許可は不要です。
GTFの起動方法は以下にサンプルを示します。USR=3FFの3FFはEID=1023の16進数指定です。GTFに関してはマニュアルあるいはGTFトレースの採取とフォーマットを参照して下さい。

Filed in .基礎編

08.REXX自身の制御

By takao - Last updated: 金曜日, 11月 21, 2008
今回は、REXX自身への命令について書いてみます。

DROP

後ろに記述した変数を「なかったもの」にしてくれます。大きな配列などを使った後「メモリーが心配だなぁ。」と思ったらやっておきましょう。

INTERPRET

後ろに続く文字列をREXXコマンドとして処理します。

NUMERIC

NUMERIC DIGITS 式

この指定は、数値計算の桁数を指定します。とてもありがたい機能で、電卓だとすぐにべき乗表示になるところをメモリーの許す限り、整数演算してくれます。

NUMERIC FORM

これは、キーワードだけでNUMERIC FORM SCIENTIFIC,またはNUMERIC FORM ENGINEERINGを指定します。ENGINEERINGは、「10の累乗が必ず3の倍数になる」形式だそうです。

NUMERIC FUZZ 式

式の桁だけ数値比較で桁を無視します。

OPTIONS

この指定はプログラムの最初にしましょう。
OPTIONS ETMODEと指定すると、文字列やコメントがDBCSを含むという処理をします。逆にDBCS文字列かどうかを無視する場合、OPTIONS NOETMODEと指定します。
OPTONS EXMODEは、命令、演算子、関数においてDBCS文字列として処理します。OPTIONS NOEXMODEとすると、すべてをバイト単位で処理します。

TRACE

デバッグのトレースです。後ろには、
All – すべてを実行前にトレース
Commands – コマンドを実行前にトレース
Error – 実行の結果、エラーを起こしたコマンドについて表示
Failure – 障害発生したコマンドがあれば、表示
Intermediates – 式の結果、中間結果、置換された名前なども表示
Labels – 実行中、通過したラベルをトレース
Normal – 負の戻りコードだけを出力(これがデフォルト)
Results – すべての式の評価結果を表示します。トレースする際には、これが期待にこたえると思います。
Scan – 実行はせずにトレースするので、シンタックスチェックに近いです。
? – デバッグが対話式になります。

以上で、いわゆるREXXコマンドについてはひととおり説明をしました。
Filed in REXX入門

ロードモジュールの情報を得る(AMBLIST)

By kamii - Last updated: 金曜日, 11月 21, 2008

AMBLISTユーティリティはロードモジュールの属性や内容を編集して出力します。アドレスモード、入口点の位置、リエントラントなのか、APF許可を必要とするか、などのモジュール属性とどのようなモジュール(CSECT)によって構成されているかのマップとクロスリファレンス情報、いつコンパイル(アセンブル)されいつリンケージされたか、どのようなプログラム修正が適用されているか、などの識別レコード情報、さらにロードモジュール内容(命令コードとデータ)を出力することもできます。

AMBLISTユーティリティJCLサンプル

LISTLOADはロードモジュールのマップ情報とレコード内容を出力します。OUTPUTパラメーターでXREFを指定した時は、ロードモジュール属性とマップおよびクロスリファレンス情報を、OUTPUTパラメーターでMODLISTを指定した時は、ロードモジュール属性とレコード内容を編集して出力します。BOTHは両方の出力です。
LISTIDRはロードモジュールのIDRレコードを編集して出力します。モジュールの翻訳日、作成日、適用されているプログラム修正名を知ることができます。
LISTLPAはLPAに展開されているロードモジュールの名前、アドレスと大きさ、入口点をマップしたリストを出力します。

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

SMFデータセットのアンロード(IFASMFDP)

By kamii - Last updated: 金曜日, 11月 21, 2008

SMFデータセットのアンロードJCLサンプル

SMFデータセットを順次データセットにアンロードします。SMFデータセット内のすべてのレコードがアンロードされます。TYPE(0:255)
入力元SMFデータセットの内容はクリアーせずにそのまま残します。ACTIVEなSMFデータセットでもアンロードは可能です。日付や時刻でアンロードするレコードを絞り込むこともできます。日付ならMVSではDATE(2008001,2008031)、MSPではDATE(080101,080131)のように制御文に追加します。
MSPではプログラム名はKDKSMFDPとなります。なおVOS3ではまったくJCLが異なりますのでSMSのマニュアルを参照して下さい。


アンロードするレコードを、レコード・タイプで選択し出力先データセットを振り分けることもできます。その場合はOUTDD制御文を複数個定義し、レコード・タイプに対応した出力先DD名を指定します。
サンプルではレコード・タイプ30をWORK.SMFMANX.UNLOAD.REC30へ、レコード・タイプ60番台をWORK.SMFMANX.UNLOAD.REC60へアンロードします。


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

ありがたいOSコマンド集(SLIPコマンド)

By kamii - Last updated: 木曜日, 11月 20, 2008

SLIPコマンド設定状況の表示


SLIPコマンド・サンプル集


複数のメモリー範囲にSAトラップを掛ける例

Filed in システムプログラマーのための手引きいろいろ

TSO/TESTコマンドによるデバッグ

By kamii - Last updated: 木曜日, 11月 20, 2008

TSOのTESTコマンドはMVSにおける標準デバッガーです。WindowsやUnixのビジュアル開発ツールのような多機能なデバッガーではありませんが、アセンブラー言語のプログラムのちょっとしたデバッグには結構役に立ちます。レジスターやメモリー領域の表示、ブレークポイントの設定など基本的なデバッグができます。
※TESTコマンドはISPFのコマンドシェル・パネル(オプション6)では実行できません。ネイティブなTSOコマンドプロンプトから実行します。


TESTコマンドを使ってプログラムを起動する

TESTコマンドで実行したいプログラムを、’格納されているロードモジュールライブラリー(メンバー名)’で指定します。起動後、プログラムは入口点(先頭の命令)でブレークした状態になり、TESTのサブコマンド入力待ちになります。


サブコマンド(プログラムを実行する)

GOコマンドはブレークしている場所からプログラムの実行を行います。次のブレークポイントを見つけるか途中でABENDするとそこで停止します。最後の命令を実行するとプログラムは終了します。WHEREコマンドで現在どこでブレークしているかがわかります。ENDコマンドでTESTコマンドを終了します。
プログラムの中でWTOマクロを使っている場合、メッセージはコンソールだけでなくTSO端末にもエコーされます。


サブコマンド(レジスターやメモリー内容を表示する)

LISTMAPは仮想記憶の割り当て状態のサマリーを表示します。プログラム自身がGETMAINしていなくても、TSOおよびTESTコマンドが制御のために割り当てた領域も含まれます。LISTPSWは現在のPSW内容を編集して表示します。

LISTコマンドはレジスターやメモリー領域の内容を表示します。
1Rはレジスター1の内容を、0R:15Rは全てのレジスターの内容を表示します。メモリーの内容はアドレスまたはラベル名で表示できます。アドレスは16進数で指定し末尾に.(ピリオド)を付けます。LENGTHパラメーターで長さを指定できます。省略すると4バイトだけしか表示されません。XCは表示タイプで16進数(HEX)と文字(CHAR)の両方が表示されるダンプ形式です。LENGTHパラメーターに代えてアドレスとアドレスを:(コロン)で繋げば、そのアドレス範囲のメモリー内容を表示できます。メンバー名.CSECT名とすればプログラムの先頭から表示できます。+xxxxのようにプログラムの先頭からの相対アドレスで表示することもできます。この場合は末尾にピリオドは付けません。
ラベル名はソースプログラム内に書いたラベル名です。ラベル名を使う場合はアセンブルおよびバインド(リンクエディット)両方のパラメーターにTESTオプションを指定する必要があります。TESTオプションによってソースプログラム中のラベル名などのシンボル情報がオブジェクトとロードモジュールに出力されます。

アドレスは直接指定の他にレジスターを使った間接アドレスでも指定できます。12R%のようにRの後ろに%を置くと、そのレジスターの内容をアドレスとするメモリーの内容を表示します。


サブコマンド(レジスターやメモリー内容を変更する)

レジスターやメモリーの内容は表示するだけでなく、変更することもできます。もちろん変更できるのは自分のプログラムまたはGETMAINした領域です。割り当てられている領域はLISTMAPコマンドで確認できます。
nR=X’xxxxxxxx’とすれば、n番レジスターに値xxxxxxxxをロードします。+20=はプログラムの先頭からx20バイト離れたアドレス、20EF4.=はx20EF4番地のアドレスのメモリー内容を変更することになります。デバッグ中にレジスターやメモリーの内容を変えてプログラムの動きがどう変わるかを確認することができます。


ブレークポイントの設定

ブレークポイントはATで設定できます。ブレークする場所をラベル名、プログラムの先頭からの相対アドレスで指定できます。Cパラメーターは通過回数カウンター値です。3と指定すれば3回目にそこを通過する時ブレークします。ここでカウンターがリセットされるのでループが続くと、さらに3回目の通過で再びブレークします。つまり3,6,9と3の倍数回目で止まります。2であれば偶数回数目、10であれば10,20,30回目になります。Cパラメーターを使うとループの中にブレークポイントを設定する時、いちいちプログラムが止まらなくなるのでデバッグ効率が上がります。なおブレークは設定できますが、1命令ずつ止めるステップ実行はできないので、必要に応じてブレークポイントを細かく設定します。
ブレークする箇所の後ろに、ブレークと同時に実行するコマンドを指定することもできます。2番目のサンプルではブレークしたら同時にその時点のPSWとレジスター0から15の内容を表示します。

TESTコマンドはブレークする箇所にSVC 97と言う命令(x0A61)を埋め込みます。そのため命令コードやオペランドそのものをデータとして処理しているようなプログラムは正しく動かなくなりますから注意が必要です。

太字箇所が命令オペランドがデータとして参照されているものです。サンプルのようにWAITマクロを書いてアセンブルして見ればよりわかりやすいでしょう。

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