11.TSOとISPF
TSO(Time Sharing Option)
MVSシステムで対話型処理を行うための機能がTSOです。コマンド型のプロセッサーでWindowsにおけるコマンドプロンプト(cmd.exe)と同等の働きをします。もちろんコマンドに互換などありませんが操作方法や機能には共通点が非常に多く、コマンドプロンプトを使える人ならTSOはすぐに使えるようになります。
MSPとVOS3ではTSS(Time Sharing System)と呼ばれますがJCL同様、仕組みも機能も同じです。コマンドも基本的なものはほぼ同じと言ってよく、いずれかのOSでTSOが使えれば相互に応用が利きます。
TSOでは1人のユーザーがMVS上の1つのジョブとして扱われます。ユーザーを識別するのがユーザーIDで、TSOユーザーを表すジョブ名(空間名)にもなります。TSOはジョブと異なり自由に実行することはできません。あらかじめ利用するユーザーをパスワードと共に登録しておく必要があります。この際ユーザー毎のアカウント名、利用できる最大リージョンサイズ、利用可能なコマンド種類などを登録します。コマンドは1つ1つを細かく登録するのではなく権限レベルのようなものを登録します。例えばJCLでジョブを実行する機能を利用できるか、ユーザーIDの登録や変更ができるコマンドを使う許可を与えるか、と言ったものです。
TSOでは、これらのユーザー情報(アカウント情報)をSYS1.UADSと言うデータセットで管理します。現在ではセキュリティー機能であるRACFで管理することも出来ます。RACFを利用するシステムではユーザーIDとパスワードだけはRACFで許可されなければなりませんが、追加のアカウント情報に関してはRACF、SYS1.UADSのいずれを使うかを選択できます。とは言えこれらはシステム管理者(Administrator)が行うことで一般利用者は気にする必要はありません。
ユーザーがTSOを開始する手続きがログオンで、この際にユーザー専用のアドレス空間が作られます。これはTSOユーザー空間とも呼ばれます。バッチジョブと違いイニシエーターで実行されるわけではありません。ただしTSOユーザ空間もバッチジョブ同様に起動用のJCLは必要でログオンプロシージャーと呼ばれます。ログオンプロシージャーはユーザー毎に作成することもできますが、同じログオンプロシージャーを複数のユーザーで共用することもできます。
Windowsでも1つのコマンドプロンプトは1つのウィンドウ・プロセスとなりますが、MVSでも同じ仕組みが取られます。そのためユーザーが実行したコマンドやプログラムが異常終了したり、誤った動作をしても他のジョブやユーザーに影響を与えることはありません。1人のユーザーは自分のユーザー空間の中では何をやっても自由です。仮想計算機とまでは行きませんが、自分が行いたい処理はコマンドを打てばすぐに行われますし、処理結果を見て考えている間コンピューターは止まっているように見えますが、実際はその間他のジョブやユーザーの処理が行われています。このような仕組みがTSS(Time Sharing System)です。MVSではTSS制御の仕組みはTSOユーザーの制御だけでなくすべてのアドレス空間の制御に用いられます。
TSOではあらかじめ用意されたコマンドを使うだけでなく、ユーザーが作成したアプリケーション・プログラムを動かすこともできますし、独自のTSOコマンドを追加することもできます。またWindowsのコマンドプロンプトにあるバッチファイルのように複数のコマンドを実行して定型的な処理を行わせることもできます。これがCLISTです。(MSPとVOS3ではコマンドプロシージャーと呼ばれる)CLISTはTSOコマンドを制御するスクリプトで完全なインタープリター方式で実行されます。バッチジョブに使うJCLも似ていますが、JCLはサブミット時にJES2によって中間言語のようなものに変換されてからジョブ管理によって処理されます。なのでサブミット時に構文エラーなどがはじかれますが、CLISTでは実際にそのステートメントが実行される時にエラーが検出されます。
TSOユーザー空間でもバッチジョブ空間でもできることは同じです。JCLで言うところのSYSPRINT(SYSOUT)、SYSIN(JCL内データ)はTSOでは端末画面にリダイレクトできます。特別なシステム系プログラムを除き、一般のアプリケーション・プログラムならどちらでも実行することが出来ます。基本的にバッチでできることはTSOでもできると考えていいでしょう。ただしTSOユーザーではあるプログラムを実行したら、そのプログラムが終了するまで他の操作を行うことが出来ません。そのため長時間かかるプログラムの実行には向きません。Windowsのコマンドプロンプトならいくつもウィンドウを起動すればいいのですが、MVSで同じ事をやろうとすると複数の端末エミュレーターを立ち上げて、それぞれ異なる複数のTSOユーザーIDを使う必要があります。
TSOセッションはバッチジョブとしても実行できます。同じコマンドをパラメーターを変えて何度も繰り返すような場合はバッチ・セッションが便利です。端末からログオンされたTSOユーザーをフォアグラウンドセッション、サブミットされたTSOバッチをバックグラウンドセッションと呼びます。
バッチ・セッションでは端末への出力はSYSTSPRT DDへ、端末からの入力はSYSTSIN DDから行われます。
TSOバッチ・セッションのサンプルJCLはこちらを参照してください。
コマンドとユーザープログラム
コマンドもプログラムもMVSから見るとどちらも同じプログラムですが、コマンドと言うのはTSO環境でのみ動作するTSO専用のプログラムと考えていいでしょう。コマンドは正確にはコマンド・プロセッサーと呼ばれ、端末の入出力、割込みキーのハンドリング、入力されたコマンドラインの解析処理などの実装が要求されます。これら端末ハンドリング固有の処理は専用のAPIがTSOによって提供されており、一般にコマンド・プロセッサーはアセンブラー言語で作成され、プログラムが異常終了してもセッションを異常終了させないよう十分なリカバリー処理を持つことも要求されます。TSOが標準で提供しているコマンドも同様の仕様で実装されており、ユーザーが独自のコマンド・プロセッサーを作る場合もシステム・コマンドに準じたプログラムデザインが必要です。TSOが提供する標準コマンドのプロセッサー・モジュールはSYS1.CMDLIBに格納されています。
一方JCLのEXEC文に指定して実行できるユーザープログラムの場合は、JCLに変えてCALLと言うTSOコマンドによって動かすことができます。パラメーターもEXEC文のPARMパラメーターに相当するものがCALLコマンドで指定できます。プログラムはバッチジョブとして動くつもりでデザインできます。使用できる言語に制限もなくCOBOL、PL/I、Cなど自由です。特別なシステム・インターフェースを意識する必要はありません。端末との入出力はデータセットをアクセスするつもりでコーディングすれば大丈夫です。ファイルI/Oを端末I/Oに振り替えるのはTSO側で行われます。もちろんデータセットそのものに対してアクセスすることもできます。いずれにしてもプログラムはI/Oのターゲットが端末なのかデータセットなのかを意識する必要はありません。またプログラムが異常終了してもTSOセッションに異常を来さないようにするためのリカバリー処理はCALLコマンド・プロセッサーが行ってくれます。
- LOGON/LOGOFF
- ALLOCATE/FREE
- CALL/EXEC
- RENAME/DELETE
- LISTALC/LISTCAT/LISTDS/AMSコマンド
- SUBMIT
- STATUS/CANCEL/OUTPUT
基本的なTSOコマンド
LOGONはTSOに再ログオン、LOGOFFはTSOからログオフします。最初のLOGONコマンドは端末をTSOに接続した際に自動的に実行されます。LOGONコマンドを使うのはユーザーIDを変えてログオンする、デバッグ作業などで一旦空間メモリーをリセットする、などの時があります。
このコマンドはJCLのDD文に相当します。ALLOCATEでコマンドやプログラムで使用するデータセットを割り当てます。FREEは逆に解放します。バッチと違ってプログラムが終わっても自動的に解放されません。複数のプログラムを実行するなら必要に応じてFREEコマンドを使います。いちいち手で打つのは面倒なのでCALLコマンドと組み合わせてCLISTにすることがよく行われます。
CALLコマンドはロードモジュールの実行、EXECはCLISTの実行を行います(MVSではREXXも実行できます)。CLISTは定義済みのコマンドプロシージャー・ライブラリーに入っていればメンバー名だけでも実行できます。ロードモジュールもリンクライブラリーまたはTSOログオンプロシージャーのSTEPLIBライブラリーに入っていればメンバー名だけでも実行できますが、この場合はコマンド・プロセッサーとして実行されてしまいます。バッチ用に作ったプログラムではCALLコマンドを使う必要があります。CALLコマンドはJCLのEXEC文に相当します。プログラムで使用できるメモリーの大きさはTSOにログオンする際のリージョンサイズで決まります。プログラム毎に異なるリージョンサイズを与えるようなことはできません。
それぞれデータセットをリネーム、削除するコマンドです。TSOで操作するデータセットはカタログされている必要があります。一部にボリューム名を指定できるコマンドや機能もありますが、基本的にTSOではデータセットのカタログは必須だと覚えて下さい。
LISTALCはTSOセッションに割り当てられているデータセット、LISTCATはカタログされているデータセットの一覧を表示します。LISTDSは非VSAMデータセットに関する属性情報を表示します。AMSコマンドはIDCAMSユーティリティです。TSOではAMSユーティリティのコマンドをダイレクトに実行することが出来ます。
JCLをサブミットします。
SUBMITコマンドなどで実行したジョブの実行状態を表示したり、実行をキャンセルします。OUTPUTコマンドは実行したジョブのSYSOUT内容を画面に表示します。端末が80桁でリストがそれ以上の長さを持つ場合、はみ出たデータは次の行へ折れ曲がって表示されます。
MVSはその前身であるOS/360(S/360システム用のOS群)の時代から元々はバッチ処理用OSとして発展してきました。現在のように1人1人が端末からシステムにログオンして自由な作業を行うような使い方を想定していなかったのです。メインフレーム・コンピューターの前身はPCS(パンチカードシステム)と呼ばれるもので横に80桁のやや厚紙の紙カードにデータを打ち込みをそれを読み取って処理する機械でした。コンピューターになっても紙カードは使われ、磁気テープと共にメインフレームでは主力のデータ入力手段として用いられました。初期のメインフレーム・コンピューターはこれらの手段で入力された、まとまったデータを並行して次々に処理して行くために利用されました。
同時代にこれとは別にタイムシェアリングシステム(Time Sharing System:TSS)と言う考え方もありました。当時コンピューターは高価な機械で個人が占有して自由に対話して(インタラクティブに)使うことなどは無理でしたが、これを何とか解決しようして考え出されたのがTSSです。AT&TとGEはMulticsと呼ばれるTSSシステムを開発しこれは後にUNIXへと繋がって行きました。バッチ処理系のメインフレーム、インタラクティブ系のUNIXでそれぞれ発展して行ったわけです。
バッチ処理系のメインフレームでは業務処理に使われるまとまった処理データだけでなくJCL、プログラムと言ったものもカードを使って入力しなければなりませんでした。実行結果をカードに出力するようなことも行われました。(例えばコンパイル結果のオブジェクトプログラムなど)
1枚の紙カードがJCL1行、ソースプログラム1行に対応します。例えばJCLが10行、プログラムが100行なら、ジョブをサブミットするために10枚のカードを読み取らせ、プログラムをコンパイルする際は100枚のカードを読み取らせていたのです。入力となるカードは穿孔機(カードパンチ)と呼ばれるカードに穴を開けるタイプライターのような機械で作りました。扱うジョブやプログラムの数が増えてくると、コンピューターの処理速度が速くても、JCLやプログラムを用意する人間側の作業が追いつかなくなって作業効率が上がらなくなります。そこでメインフレームでもTSSの機能が採用されました。メインフレームではタイムシェアリングシステムは独立したOSではなく汎用OSの中に機能として組み込まれました。当時のS/360ではTSSシステムがなくてもコンピューター・システムとして成り立っていましたから、必須機能ではなく追加のオプション機能として用意されました。なのでTSO(Time Sharing Option)と呼ばれているのです。名前こそオプションですが現在のMVSではTSOがなければシステムの生成も運用もできません。
3270データストリーム
TSOを利用するには端末エミュレータが必要です。端末とTSO間の通信にはSDLC、BSC、ローカルチャネルが使用されVTAMを介して接続されます。TCP/IPのTN3270接続も行われていますが、この場合は端末←→(TCP/IP)←→TN3270server←→(VTAM)←→TSOとなります。たいていはOSのTCP/IP機能が提供するTN3270serverが利用されますが、端末とホスト・コンピューター間にTN3270のゲートウェイサーバーなどを置いているユーザーもいます。この形態ではゲートウェイとホスト間はVTAMがサポートするプロトコルによって接続されます。TSOが扱う端末は3270ターミナルと呼ばれ、端末画面や印刷の制御には3270データストリームと言うIBM社が規定した標準プロトコルが使用されます。文字やフィールドを画面上のどこに置くのか、色や罫線はどうするのか、入力できる文字の種類(数字のみ、英数字、日本語など)をどうするか、などと言った画面の見た目や入力操作に関する制御方法などを細かく規定したのが3270データストリームです。TSOだけでなくCICS、IMSと言ったオンラインシステム構築用ソフトウェア製品もVTAMと3270データストリームによって接続され制御されています。
富士通では6650/6680データストリーム、日立ではT560/20データストリームが使われます。SNAとFNA/HNAは基本的に互換を持ちますが、端末制御のデータストリームは似てはいますが異なるプロトコルと考える方が無難です。もっともF6650は3270とほぼ同じなので、文字は英語、色はモノクロのモードなら3270端末をMSPやXSPに接続して使うことは可能です。しかしカラーや罫線と言った拡張属性の制御には異なる部分が多いので実際には使用できません。T560/20はさらに独自色が強いため接続することもできません。(HNAは互換なのでネットワーク・セッションは繋がるが、TSSが最初のスクリーン・データを送ったところでエラーになる)
現在ではハードウェア装置としての3270ターミナルが利用されることはほとんどなく、WindowsやUNIX(Linux)上のソフトウェアによって処理されます。これが3270エミュレーターです。3270は公開されたプロトコルなので、IBM以外にも多くのベンダーからエミュレーション・ソフトが提供されています。3270データストリームはSNAやTN3270プロトコルの1階層上に位置します。一般のTSO利用者は3270データストリームの詳細などを知る必要はありませんが、端末エミュレーターの開発者やミドルウェアを使わない独自のオンライン・プログラムを作る場合には必要となります。
3270データストリームの初歩
アウトバウンドとインバウンド
アウトバウンドはホスト→端末方向のデータを指す。基本的には画面内容を構成するデータで、コマンド・制御コード(オーダーコードと呼ばれる)+ユーザーデータ[+オーダー+ユーザーデータ+オーダー+ユーザーデータ...]の組み合わせで構成される。コマンドは画面データの書き方を示す。(現在の内容に上書きするのか、一旦消去して書くのか等)画面表示を伴わないデータのやり取り(例えば端末の特性情報を問い合わせたり、ファイル転送などで使われる)や現在の画面表示内容を吸い上げるコマンドなども存在する。オーダーにはSBAと言う画面上のどの位置に文字やフィールドを置くかを示すもの、SF,SFEと言うフィールドを定義するもの、ICと言うカーソルの設定位置を示すものなどがある。フィールドは文字列を表示・入力するための連続した領域で、入力可/不可・表示/非表示・高輝度・低輝度・点滅・反転・色・罫線などを指定できる。文字を表示するだけならフィールド定義は不要だが、コンスタント文字列や強調表示など属性を変える場合は必ずフィールドで構成することになる。
インバウンドは端末→ホスト方向のデータを指す。基本的にはオペレーターがキーボードによって入力したデータで、AID・カーソル位置・制御コード(オーダーコードと呼ばれる)+ユーザーデータ[+オーダー+ユーザーデータ+オーダー+ユーザーデータ...]の組み合わせで構成される。AIDはどのキーによってホストにデータを上げてきたかを識別するために用いられる、ENTERキーなのかPFnキーなのかがこれでわかる。その後にホストへ送信した時のカーソル位置が続く。オーダーに関しては基本的には出力時ほど複雑ではない、SBAでどのフィールドに入力されたかを示し、その後に入力されたデータが続く。
アテンション
表示された画面に入力されたデータをホストへ送信することをアテンションを上げると言う。AIDはAttention IDの略。ENTERキー、PFnnキー、CLEAR、PAnキーがある。ホストはアテンションによって上がってきたインバウンド・データを解析して必要な処理を行い、処理結果をアウトバウンドとして返す。これの繰り返しが対話型処理である。
対話型処理では一度アテンションを上げるとホスト側でアウトバウンドを返すまで次の入力は受け付けないのが基本である。応答が遅いと待ちきれなくなって再びENTERキーなどを押す人をよく見るが無駄な努力である。細かく言うといろいろあるがSNAでは基本的に送信権を持っていないとデータを相手に送ってはいけないことになっている。ENTERやPFキーを押しても意味がない。エミュレーターによってはキー先読み、なんて機能があって送信できないときでも押されたキーをバッファにどんどんため込んでいたりする。入力できたように思えても実際にホストに送られているわけではない。人間と違ってただ尻をひっぱたいても早くならない。
3270には「ATTN」と言うキーがある。これは特別なキーで例え送信権がなくても割り込んで通知をすることができる。このキーによって上げられるインバウンドをアテンション割込みと言う。TSOではATTN割込みは特殊な処理をします。たいていは実行中のコマンド処理を中断してプロンプト入力待ちになり、別のコマンド入力されたりすると割込み前に実行中だったコマンド処理を打ち切ったり出来る。同じTSOでもISPFなどは異なる動きをするので注意が必要である。マニュアルなどで確認して欲しい。NON-SNA3270端末と言われるものもあり、これはSNAではなくBSCやローカルチャネルで接続されたものである。全二重方式で通信が可能でSNAと違って送信権というものがない。そのためATTNキーは使えない。NON-SNA端末の場合はATTNキーではなく、RESETキーでキーボードロックを解除してからENTERキーなどを押せばよい。これでホストはアテンション割込みの処理を行う。なおSNA端末ではアウトバウンド待ちの状態ではRESETキーでキーボードロックを解除することはできない。
ブラケットと送信権
この項目は3270データストリームではなくSNAプロトコルの規定に関することですが関連するので紹介します。
対話型処理ではインバウンドとアウトバウンドのやり取りで処理が進みます。オンラインシステムでは処理の単位をトランザクションと言います。TSOのようなコマンドでOSを操作したり、画面パネルを使用してデータの編集や表示を行う場合は、1つのインバウンド=1つのコマンド=トランザクションとして扱うことができ比較的単純です。しかしながら業務処理系のオンラインシステムでは、トランザクションが必ずしも一対のインバウンド/アウトバウンドで構成されるとは限りません。複数の画面の入出力によって構成されるトランザクションもあり得ます。この場合複数のインバウンド/アウトバウンドでトランザクションが成り立つのですが、どこからどこまでが1つのトランザクションなのかの区切りを明確にしなければなりません。これを行うのがブラケットです。
ブラケットはデータストリーム中ではなくSNAプロトコルのヘッダー内にブラケットの開始や終了を示すフラグを立てることで相手側に示します。ブラケットでは双方が同時にトランザクションを開始しようとすると衝突が発生します。そこで片側は無条件にブラケットを開始できますが、もう反対側はブラケットの開始には相手側の許可を必要とするようにして衝突を制御します。端末←→ホスト間の標準的な取り決めではブラケットを無条件に開始できるのは端末側で1st Speakerとなります。他方ホスト側は自らブラケットを開始するには常に端末側の許可を必要とするBidderとなります。基本的にトランザクションの開始は端末からのサービス要求によりますから理にかなった取り決めです。
ビッダーからからトランザクションを開始したいときは、これから「ブラケットでトランザクションを始めるぞ」と言う意思表示を相手に示します。相手はそれ受けて異論がなければ「いいよ」の応答を返します。すでにその前に自分からデータを送ってしまっていれば「しばらく待ってて」と返します。相手からのトランザクションを受け入れられる状態になったら「送ってもいいよ」と通知します。ブラケットを使うと1つのトランザクションの範囲がアプリケーション・データとは関係なく明確にできるため、通信中に障害が発生したときなどのトランザクション・リカバリーやデータベース・コントロールなどの処理をアプリケーションから切り離してオンラインの制御側プログラムで行うこともできます。
単純な会話のキャッチボールで構成される対話処理や、データベースのコミットやロールバックなどを必要としないトランザクション処理ではブラケットに代えて送信権のみによって制御する方法も行われます。送信権はCD(Change Direction)とも呼ばれデータを送信する権利を片側が持つことで衝突が発生しないようにする制御方法です。データを相手に送る際にSNAプロトコルのヘッダー内にCDI(Change Direction Indicator)と呼ばれるフラグを立てると送信権は相手に渡ります。それを交互に行うことで、基本的には常に片側からしか送信しないようにする方式を半二重フリップフロップと言います。相手に送信権を渡してしまった後、送信権が無い状態で緊急にデータを送りたい場合は送信権を返してもらうよう要求することもできます。ブラケットが複数のインバウンド/アウトバウンドの組み合わせで構成される場合、相手側に送信権を渡します。ブラケットが終了する場合は送信権は渡さなくてもかまいません。
ブラケットと送信権をどう使って制御するかはオンラインシステムの制御プログラムの設計で決めます。実際は両方の制御を組み合わせて行われますがトランザクションの範囲を明確にする必要がなければ、最初のメッセージでブラケットを開始して以降セッションが切れるまでブラケット中の状態を継続させて、送信権のみをインバウンド/アウトバウンドでやり取りする方法が単純です。
ISPF(Interactive System Productivity Facility)
ISPFはTSOの画面パネルによる対話型処理プログラムの実行プラットフォームです。TSOコマンドのコマンド・シェル(TMP)のようにコマンドとメッセージによる対話方式ではなく、パネル(端末に表示される画面)を使用して、パネル内のメニューやガイダンス・テキストに従い、用意された入力フィールドにデータを入力して行くことで処理を進める対話方式です。
ISPFはデータセット操作とプログラム開発用のツールと言う側面が強いですが、それらはISPF内の1つのコンポーネントです。ISPFは単なるプログラム開発ツールではなく、パネルを使用した対話方式のアプリケーション・プログラムを開発し実行するための環境を提供します。ISPFではこれらのアプリケーションをダイアログと呼びます。データセットのビュワーやエディターなどのプログラム開発ツールも、1つのISPFダイアログ・プログラムなのです。ISPFではISPFパネルの作成やテスト、パネルを使用したダイアログ・アプリケーションに対する各種のプログラミング・サービス(パネルのI/O、変数サービスなど)を提供するDM(Dialog Manager)と呼ばれるコンポーネントの上で、データセット操作とプログラム開発用のツールであるPDF(Program Development Facility)、JES2スプール内のSYSOUT操作などを行えるSDSF(System Display and Search Facility)やユーザー作成のダイアログが動きます。
MSPではISPF相当の機能はPFD(Programming Facility for Display users)になります。ISPFのミニセット版のような感じです。VOS3ではプログラム開発機能の部分だけがASPEN(Advanced editor System for Programming ENvironment)として提供されていますが、ISPFやPFDと異なり純粋なプログラム開発ツールで、ユーザーが独自のパネル・プログラムなどを作成することはできません。
パネル方式の利点はWindowsのGUI同様に直感での操作ができる点にあります。面倒なコマンドを覚える必要が減り、メニューをたどって行けば容易に目的の操作を行うことができます。またTMPでは1つのコマンド(プログラム)しか実行できませんが、ISPFはマルチタスクでコマンド・セッションを制御しており、同時に複数のコマンド(プログラム)を実行できます。
そのためプログラムをパネルで編集しながら、コンパイルしてロードモジュールを作成し、それを実行させ出力結果を確認できます。それに基づき直ちにプログラムの誤りを直し、また繰り返すと言ったように関連する処理を並行して行うことができます。このパネルによるデータセットやジョブの操作と、複数の機能やサービスを並行して行えるマルチタスク処理によって、プログラム開発の生産性を大きく向上させています。