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は、こちら「TSOバッチ・セッション」を参照してください。

コマンドとユーザープログラム

コマンドもプログラムも、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コマンド・プロセッサーが行ってくれます。

基本的なTSOコマンド

• LOGON/LOGOFF

LOGONはTSOに再ログオン、LOGOFFはTSOからログオフします。最初のLOGONコマンドは、端末をTSOに接続した際に自動的に実行されます。LOGONコマンドを使うのは、ユーザーIDを変えてログオンする、デバッグ作業などで一旦空間メモリーをリセットする、などの場合です。

• ALLOCATE/FREE

このコマンドはJCLのDD文に相当します。ALLOCATEで、コマンドやプログラムで使用するデータセットを割り当てます。FREEは、逆に解放します。バッチ・ジョブと違ってプログラムが終わっても自動的に解放されません。複数のプログラムを実行するなら、必要に応じてFREEコマンドを使います。いちいち手で打つのは面倒なので、CALLコマンドと組み合わせてCLISTにすることがよく行われます。

• CALL/EXEC

CALLコマンドはロードモジュールの実行、EXECはCLISTの実行を行います（MVSではREXXも実行できます）。CLISTは、定義済みのコマンドプロシージャー・ライブラリーに入っていれば、メンバー名だけを指定して実行できます。ロードモジュールも、リンク・ライブラリーまたはTSOログオン・プロシージャーのSTEPLIBライブラリーに入っていればメンバー名だけでも実行できますが、この場合は、コマンド・プロセッサーとして実行されてしまいます。バッチ用に作ったプログラムでは、CALLコマンドを使う必要があります。CALLコマンドは、JCLのEXEC文に相当します。プログラムで使用できるメモリーの大きさは、TSOにログオンする際のリージョン・サイズで決まります。プログラム毎に異なるリージョンサイズを与えるようなことはできません。

• RENAME/DELETE

それぞれデータセットをリネーム、削除するコマンドです。TSOで操作するデータセットは、カタログされている必要があります。一部にボリューム名を指定できるコマンドや機能もありますが、基本的にTSOではデータセットのカタログは必須です。

• LISTALC/LISTCAT/LISTDS/AMSコマンド

LISTALCはTSOセッションに割り当てられているデータセット、LISTCATはカタログされているデータセットの一覧を表示します。LISTDSは、非VSAMデータセットに関する属性情報を表示します。AMSコマンドは、IDCAMSユーティリティです。TSOではAMSユーティリティのコマンドを、ダイレクトに実行することができます。

• SUBMIT

JCLをサブミットします。

• STATUS/CANCEL/OUTPUT

SUBMITコマンドなどで実行したジョブの実行状態を表示したり、実行をキャンセルします。OUTPUTコマンドは、実行したジョブのSYSOUT内容を画面に表示します。端末が80桁でリストがそれ以上の長さを持つ場合、はみ出たデータは次の行へ折れ曲がって表示されます。

MVSはバッチ処理指向のオペレーティング・システム

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がなければシステムの生成も運用もできません。

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と異なり、純粋なプログラム開発ツールで、ユーザーが独自のパネル・プログラムなどを作成することはできません。

パネル方式のUI（ユーザー・インターフェース）の利点は、WindowsのGUI同様に直感での操作ができる点にあります。面倒なコマンドを覚える必要が減り、メニューをたどって行けば容易に目的の操作を行うことができます。また、TMPでは1つのコマンド（プログラム）しか実行できませんが、ISPFはマルチタスクでコマンド・セッションを制御しており、同時に複数のコマンド（プログラム）を実行できます。複数のプログラム（ダイアログ）の実行中は、それぞれのプログラム（ダイアログ）が表示している画面を切り替えることで、複数のプログラムを並行して操作できるようになっています。

そのため、プログラムをパネルで編集しながら、コンパイルしてロードモジュールを作成し、それを実行させ出力結果を確認できます。コンパイラーの出力リストなどを見て、直ちにプログラムの誤りを直し、また繰り返すと言ったように、関連する処理を並行して行うことができます。パネルによるデータセットやジョブの操作と、複数の機能やサービスを並行して行えるマルチタスク処理によって、プログラム開発作業などの生産性を大きく向上させています。