ジョブの解剖
皆さんが、サインオンをしてプログラムを作成して、サインオフをする。この簡単な環境が如何に生まれているか、ご存知ですか？ここでは、「対話型」のジョブの生成に関して、細かく見ていきましょう。
さて、本来、サインオンから始まり、と言いたいところですが、システムから見ると、まず、サインオン画面を出す、と言うところから考えてみると、対話型のジョブの生成は、大きく3つに分かれると思います。
| 1 |
端末装置の電源オンとバリーオン（オンに構成変更） |
1.端末とAS/400の通信環境の確立 |
| 2 |
サブシステムの装置獲得 |
2.サブシステムの装置獲得、サインオン画面の表示 |
| 3 |
装置を獲得したサブシステムからサインオン画面の表示 |
| 4 |
ユーザーのサインオン |
3.サブシステム上で、ユーザー対話型ジョブの開始と終了 |
| 5 |
ユーザーのサインオフ |
ここでは、サブシステム以降を考えます。装置のバリーオンと言った部分は、日進月歩進化？する技術でどんどん変わる分野に関わるので、取り上げません（というより、最新の情報を知りませんので...）。PC5250のバージョンアップで変わる内容やら、通信設定やら、サインオン画面が出るとか出ないとか、など、今のところ追いかけていく気持ちはありません。むしろ、今目指すのは、AS/400側のジョブの生成過程をしっかり解明していきたいのです。「実行管理の解体新書」を目指しています。
これから見てゆく、実行管理の基本的部分は、System38のころから変わっていないようです。（ご存知の方は、ご存知でしょうが、マニュアルの挿し絵も変わっていないですよね。S38の「プログラマーの手引き」に出ていたのではなかったっけ？）これは、IBMの怠慢ではなくて、それほど、しっかり出来ている部分なのです。W95、W98、WNTがアプリがあるから生き延びているOSに対して、このAS/400のOSは、本当に安定していて、叩けば、「コンコン」と音がしそうなくらい、堅牢です。実際、サブシステムという、たくさんの団地にジョブという住人が、様々に暮らしている様子が、目に見えるようなのです。しっかりしたコンセプトと、それに添ったコマンド（WRKACTJOB,
WRKSYSSTS,etc.)がうまく調和して、自由にシステムの中を覗き、どのようなジョブが、そのようなステータスで、どんなファイルを参照して実行しているか、等、ジョブの管理やサブシステムの管理が、とても楽に出来ます。もし、コマンドWRKACTJOBがAS/400に無かったら、皆さんはジョブの状況をここまで赤裸々に覗けたでしょうか？
対話型ジョブの始まりと終わり
さて、これは定義の問題かもしれません。対話型のジョブは「サインオン」から「サインオフ」までです。このジョブ（サインオンからサインオフ）には、識別子がつけられます。「ジョブ名」＋「ユーザー名」＋「ジョブ番号」です。一応この3っつそろって、ユニークにはなるのですが、この最後のジョブ番号が6桁しか無く、000000から999999までなので、事によれば、重複するかもしれません。つまりDSP01/KAKEFUDA/000010が、数年後に（同じジョブ番号を同じ端末で同じユーザー名で引き当てるのは、確率的に低いとは思うのですが...）同じ、DSP01/KAKEFUDA/000010が現れるかもしれません。したがって、アプリなどで利用したい、完全な識別子を設けるのなら、「ジョブ名」＋「ユーザー名」＋「ジョブ番号」を使わずに、もっと大きな桁の数字の桁を準備すると良いと思います。
さて、図式的にサインオンからサインオフを見てみましょう。
| 一つのジョブとして、システム内で活動 |
サイン・オン |
ユーザーがユーザー名を使用してサイン・オン。対話型ジョブの始まり |
|
INLPGM
|
ユーザー・プロファイルに初期プログラムがある場合、それが呼び出されます |
| INLMNU |
ユーザー・プロファイルの初期メニューが呼び出されます。省略時値はメイン・メニューです。 |
| サイン・オフ |
対話型ジョブの終了 |
ここで、ジョブの生成に関わる、オブジェクトを洗い出してみましょう。（前提要素の、エミュレーションやら、装置記述やら制御装置記述など、は省きますよ。きりがないので。）
サブシステム記述
ユーザープロファイル
ジョブ記述
クラス
これらは、頭にたたき込んで下さい。後で掲載予定のバッチジョブでも、ほとんど共通です。
マニュアルを参考に見てみましょう。
AS/400 実行管理の手引き 6.1.2
対話式ジョブの開始方法 より
| ユーザーがシステムにサイン・オンすると、サブシステムは複数のシステム・オブジェクトから情報を収集し、それから対話式ジョブが実行可能になります。 1.
サブシステムは対話式ジョブの属性を入手するために、ワークステーション項目を調べてジョブ記述を見つけます。ワークステーション項目にジョブ記述として
*USRPRF の指定がある場合、該当のジョブは、ユーザー・プロファイルの情報を使用します。
注:
このような柔軟性により、ジョブの属性をワークステーションまたは個々のユーザーのどちらに結びつけるかを指定することができます。
2.
サブシステムがどのジョブ記述を使用すればよいかを判別できても、すべてのジョブ属性がそのジョブ記述から入手できるとはかぎりません。属性によっては、ユーザー・プロファイルに入っていることもあります。ユーザー・プロファイルに必要な情報が入っていない場合は、サブシステムはシステム値を調べます。
注: ユーザー・プロファイルに入っているジョブ属性は、ユーザー単位で調整したい事項を指定するための属性です。
3.
サブシステムは、すべてのジョブ属性を収集すると、ジョブ記述中の経路指定データを調べます。サブシステムは、その経路指定データを使用して、サブシステム記述から経路指定項目を見つけます。経路指定項目から、そのジョブで使用するプール、使用される経路指定プログラム、および実行時属性入手するクラスなどの情報が得られます。
4.
これらのすべての情報が得られると、経路指定プログラムが実行されます。IBM
では、QCMD
と呼ばれる経路指定プログラムを用意しており、これはすべてのタイプの処理に使用することができます。QCMD
は、ジョブが対話式ジョブであるか否かを把握し、ユーザー・プロファイルを調べて実行すべき初期プログラムを判別します。初期プログラムの実行が終わると、QCMD
は初期メニューを表示します。
| 対話式ジョブの開始時に起こる事柄 |
システムの情報の収集源 |
| 表示画面でサイン・オンする。 |
|
| 該当対話式ジョブのジョブ記述を入手する。 |
サブシステム・ワークステーション項目、ユーザー・プロファイル |
| ジョブ属性を入手する。 |
ジョブ記述
、ユーザー・プロファイル、ワークステーション装置記述、システム値 |
| 経路指定データおよび経路指定項目を入手する。 |
ジョブ記述、サブシステムの経路指定項目のクラス |
| 実行するプログラムを入手する。 |
| クラス (実行時情報) を入手する。 |
| プール番号を入手する。 |
| 経路指定項目の経路指定プログラムを実行する。 |
サブシステム経路指定項目 |
| 初期プログラムを呼び出すか、初期メニューを表示する。あるいはその両方を行う。 |
ユーザー・プロファイルまたは 「サイン・オン」画面 |
| 対話式ジョブが実行可能になる。 |
|
|
さて、下図は、マニュアルを参考にしながら作った、ジョブの生成の概略図です。
前提
- 装置はオンに構成変更されていること。
- サブシステムが立ち上がっていること。
ポイント
- ワークステーション項目で該当する端末を獲得する。装置記述名などでヒモ付けの場合が多い。
- サインオン画面から、ユーザープロファイルの名とパスワードを入力する。
- ワークステーション項目にジョブ記述として *USRPRF
の指定がある場合、該当のジョブは、ユーザー・プロファイルの情報を取りだす
- 同じく、ユーザー・プロファイルのジョブ記述を参照する。
- サインオン画面を出していたサブシステムの経路指定項目（テーブル）にアクセスして、その経路を使うか判定する。（これはあたかも、CMPVALをキーとするファイルに、RTGDTAでCHAINしてゆくのに似ている）
- 要求処理プログラムQCMDを呼び出す。（経路指定内のプログラムを呼び出している。）QCMDはIBMの作った、汎用の要求処理プログラムです。
- クラスの指定内容を取り出す。優先順位やパージの情報が出ています。バッチ処理では、このクラスが大きく異なります。
- プール番号の取りだし。メモリの管理単位の指定の事です。実行効率に関与します。
図には入れませんでしたが、この後、ジョブは、
- ユーザー・プロファイルに初期プログラムがある場合、それが呼び出されます
- ユーザー・プロファイルの初期メニューが呼び出されます。省略時値はメイン・メニューです。
をします。
上図は、概説ではあるものの、関連するオブジェクトや、内部パラメータ（経路指定など）を網羅しているので、まずは、しっかりこれを頭に入れて下さい。この他は、この応用と考えていくことが出来ます。これは、また、後で、見ていきましょう。
QCMD
このプログラムを考えてみましょう。「要求処理プログラム」と言いましたよね。System38の時は、QCLという名前でした。そうです。経路指定にQCLが有るのは、38属性のプログラムを流す目的の為でした。上図で、QCLを呼び出したいのならば、JOBDのRTGDTAに「QCMD38」を指定しておけばいいのでね。もしここが、QCMDIならば、QCMDが使用されます。
CL（制御言語）プログラミング 8.2.7.1 要求メッセージ より
※プログラマーの方は、必ず「CL（制御言語）プログラミング」は全て（特にメッセージの部分）は読んだ方がいいでしょう。とても重要です。
- CL 処理プログラム QCMD が、*EXT
から要求メッセージを受け取ります。
- *EXT
上に要求メッセージがない場合には、コマンド入力画面が表示されます。表示装置のユーザーが、この画面にコマンドを入力します。入力したコマンドは、要求メッセージとして
*EXT に入れられます。
- 次に、そのコマンドは、QCMD
の呼出しメッセージ待ち行列の終わりに移され、そこから QCMD
に渡されます。
- コマンドが分析され、そのコマンド処理プログラム (CPP)
が呼び出されます。
- コマンド処理プログラムは、QCMD
の呼出しメッセージ待ち行列に診断メッセージを送ります。
- 次に、コマンド処理プログラムは、QCMD
の呼出しメッセージ待ち行列にエスケープ・メッセージを送ります。このエスケープ・メッセージは、待ち行列上に診断メッセージがあること、および
QCMD が CPP の処理を打ち切らなければならないことを QCMD
に伝えます。
- QCMD は、要求チェックのエスケープ・メッセージ (CPF9901)
または機能チェックのエスケープ・メッセージ (CPF9999)
の着信を監視します。次に、QCMDは次の要求メッセージの受信を試みます。要求処理プログラムがメッセージCPF9901
またはCPF9999 を受け取った場合には、そのプログラムは資源再利用(RCLRSC)
コマンドを実行しなければなりません。また、要求処理プログラムは、メッセージ
CPF1907（要求終了）および CPF2415（コマンド入力画面でユーザーが F3
または F12
キーを押したことを示すメッセージ）の監視も行う必要があります。
- 要求メッセージの処理が行われたので、QCMD
の呼出しメッセージ待ち行列上のすべてのメッセージがコマンド入力画面に表示され、表示装置のユーザーに対してさらに別のコマンドの入力を求めるプロンプトがその画面に表示されます。
- 前の要求メッセージ（コマンド）とそれに関連したメッセージが、このジョブについて指定されているメッセージ・ロギング・レベルに従ってジョブ・ログに入れられます。詳細については、トピック8.7の『メッセージのロギング』の項を参照してください。
QCMDは、メッセージ待ち行列をモニターしているのですね。いつでも要求を受けられるように、大きく口を開けて、待っているのです。このQCMDがジョブの中核に入り込み、我々プログラマーの要求を、どんどんとこなしているのですね。
但し、このQCMDが無くてもジョブの開始は出来ますが、これは応用になるでしょう。
1999/7/20 | 
