04.4 MCS仮想コンソール機能

コンソールをプログラムでハンドリングしたいという要望は古くからありました。SDSFのような対話型の操作ツールに乏しかった当時、コンソールはOSを操作する上で最も基本となるデバイスでした。専門のオペレーターをコンソールに配し、ジョブのSTART/ENDを手作業で起動しながら処理したり、システムの運用状態を示すメッセージを目で追いながら適切なOSコマンドなどで対処するといった運用が行われていた時代から、人に依存するオペレーションを自動化するために多くのユーザーがコンソールに出力されるメッセージをプログラムで検知したり、コマンドの実行結果を取り込んだりといったことを考えてきました。
元々はそのためのプログラムをユーザー自身が作っていましたが、やがては自動運用ソフトウェアに代表されるメーカーやベンダーのプログラム製品に取って代わられました。今日でも、ユーザー固有の自動化処理やモニタリングのためにプログラムによるコンソールへのアクセスは必要とされています。

昔のMVSでは、OSのコンソール・バッファーは共通域に展開されていたのでプログラムで簡単に読み込むことができました。MVS/XAからコンソール・バッファーはコンソール空間へ移ってしまい簡単には見られなくなり、代替としてOSのWTO出口ルーチン(例えばIEECVXIT、現在ならIEAVMXIT)によってメッセージをロギングしたりする方法も使われました。その他、サブシステム・インタフェースによってWTOやWTLをトラップする方法も使われました。出口ルーチンやサブシステムを使えば、新しいメッセージが出たかをOSが教えてくれるので、タイマーなどでバッファーを定期的に見る必要がありません。
しかしながら、今となってはこれらも古典的な方法であって、現在のz/OS(MVS)は、コンソールをアクセスするためのAPI、MCSOPERとMCSOPMSGを提供しています。これらのAPIは、コンソール・システムがMCSコンソールとして実装されたMVS/ESAから利用できるようになりました。出口ルーチンやSSIを使う方法では、プログラムは全てのアドレス空間で動くため、誤りが起きると他の空間をABENDさせてしまうことにもなりますが、APIなら誤りが起きても影響を局所化することにも繋がり安全性の面でも有利です。とは言っても、今日ではメーカーやベンダーのソフトウェア製品経由でのコンソール・アクセスがほとんどでしょう。

拡張MCSコンソール

拡張MCSコンソールは、コンソールとしての役割を果たすプログラムです。このプログラムでは、コンソールに出力されるメッセージを受け取ったり、OSやJESコマンドを発行してその応答を受け取ることができます。代表的なものとして、SDSFのULOGパネルの機能があります。

拡張MCSコンソールの実現には、MCSOPERおよびMCSOPMSGマクロを使用します。コマンドの発行には、MGCREマクロを使用します。いずれもスーパーバイザー・モードが要求されるため、APF許可プログラムでなければなりません。また、通知されるコンソール・メッセージはデータ空間にキューイングされるため、AR(アクセス・レジスター)モードによるプログラミングが必須です。

オペレーター・コマンドを発行して、その実行結果を得る

拡張MCSコンソール機能による仮想コンソールをプログラムで作成するには、最初にMCSOPER REQUEST=ACTIVATEによって仮想コンソールをアクティブにします。このコンソールへ出力されるメッセージは、MCSOPMSG REQUEST=GETMSGによって読み込むことができます。必要なコンソール・メッセージを読み取ったら、MCSOPER REQUEST=DEACTIVATEによってコンソールを停止します。
オペレーター・コマンドの発行はMGCREマクロによって行います。このサンプルは、コマンドを発行してその実行結果メッセージを取り込むのが目的なので、発行したコマンドに対する応答メッセージだけを受け取ります。そのため、コマンドと応答を関連付けるための8バイトの応答トークンをコマンド発行時にMGCREマクロのCARTパラメーターで指定します。関連付けられた応答トークンは、MCSOPMSGマクロでも指定されて指定したトークンを持つ応答メッセージがコンソールに出力されると、メッセージ待ち合わせのECBがポストされます。
ECBがポストされたら、MCSOPMSG REQUEST=GETMSGを発行してコマンドに対する応答メッセージを受け取ります。メッセージは、拡張MCS機能によって作成されたデータ空間に展開され、MDB(Message Data Block)によってマッピングされます。1つのMDBには複数のメッセージが格納され、それぞれのメッセージはMDBT(MDB Text Object)によって区分けされています。MDB内の全てのメッセージを処理したら、MDBプレフィックスにポイントされている次のMDBを求めて続きのメッセージ・テキストを読み込みます。チェインの最後のMDBを処理したら、再びMCSOPMSG REQUEST=GETMSGを発行します。これ以上返すMDBがなくなれば、MCSOPMSGはRC=8で復帰します。それによって仮想コンソールの停止タイミングを知ることができます。

このサンプルでは、JES2コマンド「$TOJ72,Q=P,OUTDISP=WRITE」を発行してその応答メッセージを受け取ります。SDSFパネルからOSコマンドを発行すると、その応答メッセージが画面にエコーバックされますが、そのようなことを自分のプログラムで行いたい場合や、発行したコマンドの応答をプログラムで解析してから実行結果を通知したい場合などに利用できます。サンプルのプログラムでは、返された応答メッセージはプログラム内の4KB領域に1行あたり128バイトで格納しています。32行分しか格納できませんが、それを超える数のメッセージが返された場合の考慮はしていません。

コンソールへの出力メッセージを取得して、順次データセットに書き出す

コマンドに対する応答メッセージではなく、システムやジョブの状況表示など全ての出力メッセージを取り込むこともできます。最初のサンプルと異なり、仮想コンソールをアクティブにする際にMCSOPERのMSGDLVRYでFIFOを指定します。コンソールへのメッセージ出力が行われるとECBにポストされるので、続けてMCSOPMSG REQUEST=GETMSGを発行してメッセージを読み込みます。このサンプルでは、読み込んだメッセージを順次データセットに書き出す処理を行っています。このようなコンソール・モニターを作れば、ジョブの開始や終了、ステップの終了状況(SMF出口等でメッセージ出力していれば)などをリアルタイムに検知して、ユーザー独自の自動運用処理などに応用することもできます。

サンプル・プログラムは、常にコンソール・メッセージの発生を待ち合わせているため終了するタイミングがありません。CANCELコマンドでしか終了できないのは良い作りではありませんので、コンソールに’STOP MYCONS’という文字列が入力されたかをコマンド・メッセージそのものでチェックしています。しかし、このようなシステム常駐型のプログラムではQEDITマクロを使用してMODIFYやSTOPコマンドを受け入れるようするのが本来です。QEDITを使用したオペレーター・コマンドの受け入れを行う方法は、「オペレーター応答とコマンドを受け取る(WTORとQEDIT)」で解説しています。

拡張MCSコンソール機能では、プログラムはアクセス・レジスターモードにしなければなりません。MDBが実際にどのような構造になっていて、どのようにメッセージ・テキストが格納されているのかを調べるために、適当な場所でわざとABENDさせてもMDBは異なる空間に存在するのでSYSUDUMPやSYSABENDダンプでは見ることができません。データ空間の内容を確認するにはいくつかの方法がありますが、比較的簡単なのはSNAPXマクロでDSPSTORパラメーターを指定する方法です。MDBで返されたALETを入力にしたALESERV EXTRACTを発行してMDB領域のSTOKEN値を求め、そのSTOKENを指定したDSPSTORリストを作成してSNAPXマクロを発行します。

SYS1.SAMPLIBにも拡張MCSコンソールのサンプル・プログラムIEAEXMCSが格納されています。また、拡張MCSコンソールの活動状況は、D EMCS[,I|F]コマンドで確認することができます。