01.MVSの構成

By kamii - Last updated: 火曜日, 10月 28, 2008

このカテゴリーでは大型汎用機用の代表OSである、IBM社の「MVS」について、その概要やポイントなどを紹介します。その他にも関連する話題を適宜追加したりもします。
現在ではMVSは「z/OS」の名称になっていますが、OSの基本部分は今でもMVSとしてその名が使用されています。

MVSに限らずメインフレーム・コンピュータ用OSはRASISの指標で示される品質を踏まえた上で、

と言う目標を達成しています。

Reliability(信頼性)システムを間違いなく機能させること。障害の少なさ。
Availability(利用可能度)仮に障害となってもいかにそれを回避・回復できるか。局所化できるか。
Serviceability(保守性)障害原因の追及や修復のし易さ。
Integrity(保全性)障害によってデータやプログラムが破壊されないこと。
Security(機密保護性)情報の盗用や資源への不正なアクセスをいかに防げるか。

MVSではこれらの目標を達成するためにさまざまな機能が組み込まれています。「監視プログラム」と呼ばれる、根幹となる核の部分を構成するプログラム群の上に7つの大きな機能を載せたような構造になっています。


監視プログラム

OSとしてのカーネルの部分です。MVSではニュークリアスと呼ばれます。CPU制御、割込み制御、入出力制御、タイマー制御、プログラム実行制御などハードウェアを直接アクセスしたり、マルチタスキングなどプログラムを実行する上で基本となる制御を司ります。


ジョブ管理

処理プログラムの実行を「仕事」として制御・管理します。MVSではユーザーの業務を行う処理プログラムの実行を「ジョブ」と言う単位で捉えます。初期のS/360以前の時代から、まとまったデータを一気に処理するバッチ処理と言う処理形態がメインフレーム・コンピュータでのプログラム処理の基本でした。MVSもこの流れを組んでいます。1つ1つのバッチ処理を「ジョブ」と言う単位で管理していたのです。


ジョブエントリーサブシステム(JES)

複数の「ジョブ」を自動的・連続的に処理させ、OS自身のジョブ管理機能を補完します。JES機能自体がMVS自身に含まれないのは、複数のJESを用途に合わせて利用できるようにするためです。MVSではOS自身にアドオンする形で機能を追加する仕組みを持っており、サブシステムと呼ばれます。JESはこのサブシステムの代表的なもので、JES2とJES3の2つがあります。日本では圧倒的にJES2が利用されています。


メモリー管理

仮想記憶と実記憶の制御と管理を行います。


タスク管理

複数のプログラムを並行して実行させる、排他制御やエラー回復などの制御・管理を行います。


データ管理

デバイス(ボリューム)とデータセットの制御と管理を行います。


ファイルシステム

データセットの構造管理、レコードへのアクセスサービスの提供を行います。MVSではファイルシステムはデータ管理のコンポーネントに含まれます。


システム管理

システムのモニタリングやロギングなど、OSの運用に必要なさまざまなデータの収集や解析が行われます。パフォーマンス制御などはこのシステム管理とタスク管理が密接に連動して行われることになります。


ネットワーク

通信デバイスの制御と管理、ネットワークへのアクセスサービスの提供。ネットワーク機能は本来OSに含まれる機能ではありませんが、現在ではネットワークなしでのメインフレーム・コンピュータ運用はまずありません。MVSではIBM社のSNAプロトコルを制御するVTAM、TCPプロトコルを制御するTCPIP/MVSがあります。現在では両方のプロトコルを処理するCommunications Serverというコンポーネントが組み込まれていますが、SNAの制御はVTAM、TCPの制御はTCPIP/MVSであることに変わりありません。VTAMやTCPIPはCommunications Serverのサブコンポーネントと考えてもいいでしょう。

Filed in ..基礎編

カタログの思い出

By takao - Last updated: 火曜日, 10月 28, 2008
カタログについて、歴史的経緯と個人的思い出を書いておきます。
もともとメインフレームでは、MVS以前のMVTのころからCVOLという考え方がありました。データセットリストを記憶しておくデータベースみたいなもので、IEHPROGM(このユーティリティは今も現役でしょうか)でコントロールしていました。
世の中にカタログが出てきたのは、VSAMと同時だったように思います。VSAMはアクセスメソッドですが、カタログ自体がVSAMを利用しているので一緒に語るものです。当初VSAMカタログの場合、データセットの管理ということでデータセットの名前、構成はおろかスペース管理までもやろうと考えていました。今のデータベースの考えに近いです。最初にスペースを取って、データセットの大きさを決める。同時にスペースを管理するということは、そのボリュームを管理することになりますから、ボリュームオーナーシップという考え方が必須でした。ボリュームは一個でもVSAMデータセットを作ったら、いずれかのカタログに忠誠を誓うわけです。
ところがこのアーキテクチャは結果的にいろんな問題を引き起こしました。次が代表例です。
・カタログが壊れると、スペース不明のボリュームが大量に出てくる。被害が甚大。
・VSAMに書き込むたびに、カタログへ頻繁にアクセスが起きる。パフォーマンスが低下する。
・カタログごとにエイリアスをもつため、ひとつのボリュームに違うカタログでつけたエイリアスをつけられない。自由にファイルを作れない。

とくに一番目の問題は致命的でした。このころ技術的にはカタログをどうやって救うか、ということが大事なことでした。

それを省みてでてきたのが、ICFカタログです。IDCAMSが機能を大幅に拡張してきたのも、これ以降です。
ICFカタログは、ボリュームごとにVSAMデータセットを管理する、SYS1.VVDS.Vボリューム名 という管理データセットを作ります。それでVSAMを管理します。この考え方でSPACE管理とボリュームのオーナーシップはなくなりました。VSAMデータセットの大きさはVTOC情報と一致するのです。ただし、どえらいエクステンションを許すようになりましたが。また、カタログはボリュームへのポインターに過ぎないので,VSAMも非VSAMデータセットも同様に管理できるようになりました。カタログが壊れても再構築が簡単になりました。

昔話はここまでです。
さて、オープン系を見ると、フォルダーという階層型ファイル管理ばかりです。確かに書類とフォルダーというオフィスにあるメタファーを利用しているため、理解が簡単という面はあります。一方で、ファイルの名前にユーザーはものすごく無頓着です。メインフレームのユーザーはカタログのエイリアスで整理する習慣が身にそまっているので、ついつい、フォルダー名に応じたファイル名などをつけようとしてしまいます。どちらが便利なのでしょうか?
私はオープン系はディスクの発達が急速だったため、それほどボリューム数が必要なかったことが幸いしていると思います。100個もディスクをつけているシステムなんてあるのでしょうか。ボリュームが数個であるのなら、階層型フォルダーのほうが便利なのでしょう。メインフレームのようにUCBの許す限り多くのボリュームを取り付けられる(しばしばオフライン)の場合、ボリューム名を知らなくてもファイル名のルールでアクセスできるほうが便利なのでしょう。
Filed in OSの互換性

VSAMデータセットの操作いろいろ(IDCAMS)

By kamii - Last updated: 火曜日, 10月 28, 2008

AMS(アクセス方式サービスプログラム)はVSAMデータセットとカタログ操作用のユーティリティ・プログラムです。しかし応用範囲はVSAMだけでなくPSやPDSなどの非VSAMデータセットに関してもさまざまな操作を行うことができ、データセット操作の統合ユーティリティとなっています。AMSを使用した非VSAMデータセットの操作サンプルに関しては別の記事「非VSAMデータセット(PS,PDS)の各種操作(IDCAMS)」でアップしてますが、ここではVSAMデータセットとカタログ・データセットに関するいくつかのサンプルを紹介します。足りないものはマニュアルを見てください。



JCLの基本形


カタログされているデータセットをリストアップする。


ユーザーカタログおよびALIASをリストアップする。


VSAMデータセットの作成


VSAMデータセットの改名と削除


VSAMデータセットのアンロード

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

03.REXXにおける重要な概念

By takao - Last updated: 火曜日, 10月 28, 2008
どんな言語も「構造化プログラミング」を考慮していることは、論を待たないと思います。(構造化プログラミングがわからない人は、Wikipediaをみてください。)
プログラミング言語は、それ以外に特有の概念が実装されていることで特色を出しています。その概念を理解することが、その言語らしいプログラミングをするために、不可欠です。REXXの場合、それはスタックと連想配列だと思います。

スタック


スタックそのものは別にREXX固有の話ではなく一般的にデータを扱う時に話題になる概念です。図のように2つの考え方があります。
ひとつは地面に土管が埋まっていると思いましょう。そこにデータ(肉でもいい)を投げ込みます。次にそれを取り出すと、もっとも最近投げ込んだデータ(新しい肉)が取り出されますね。(まぜちゃいけません)こういうスタックをLast In - Fast Out(LIFO)という呼び方をします。REXXではPUSHというコマンドでスタックにデータを投げ込み、PULLというコマンドでデータを取り出します。

もうひとつのスタックの考え方は、広場に土管がころがっていると思いましょう。そこにデータ(肉でもいい)を押し込みます。土管の反対側からデータを取り出すと、もっとも昔に押し込んだデータ(古い肉)あ取り出されますね。こういうスタックをFast In – Fast Out(FIFO)という呼び方をします。REXXでは、QUEUEというコマンドでスタックにデータを押し込み、取り出し方は同じようにPULLです。

スタックという土管にどの順番でデータを押し込むかは、PULL,QUEUEコマンドで決まり、PULLでひたすらデータを取り出す、というのがREXXの考え方です。

もう一点、スタックで重要な話があります。もし、スタックが空なのにPULLコマンドを出したらどうなるのでしょうか?ゼロが帰る?いやいや、これはREXXプログラムの動作環境で異なります。
たとえば、z/OSならばSYSTSINにデータがあれば読み込みますが、それもなければ端末入力待ちになるのです。これにより、プログラムはユーザーからの入力を待つことができるようになるのです。

連想配列

Perl,PHP,VBなどのスクリプト言語ではよく使われていますが、なじみがない方のために連想配列の簡単な説明をしておきます。
連想配列とは、添え字が文字列でかまわない配列をいいます。ハッシュといったりもします(個人的には違和感があるけど)。
REXXの場合、変数に.が現れると配列だとみなします。
たとえば、
var.1 = “あ”
var.2 = “い”
i = 2
say var.i
では、”い”が表示されます。

添え字が文字列でかまわない以上、次のような配列も許されます。
a = “a”  /* 明示的に */
var.a = “あ”
b = “a”
say var.a

“あ”が示されます。

ただし、REXXでは、他言語のように配列の添え字なしで要素を拾い出す(foreach)のような命令がないので、配列の要素を順々に取り出したい場合は、数値の添え字を使います。添え字なしで要素を順次取り出すことのほうが多いでしょうが、そういう場合には、スタックの使用が推奨されているのです。
Filed in REXX入門

オンライン端末のRUサイズを最適化する

By kamii - Last updated: 火曜日, 10月 28, 2008

MVSパフォーマンスチューニング入門に関連して追加トピックをひとつ。

オンライン端末のRUサイズ

意外と忘れられているが、オンライン端末のレスポンスに影響を与える要素の1つにRUサイズがある。MAXRUとも呼ばれ、端末->ホスト、ホスト->端末方向それぞれに設定されます。TSO、CICSやIMSなどのDCMS(TPモニター)は端末にデータを送る際に画面データをRUサイズに基づいて自ら分割して送信するか、VTAMに分割を依頼します。MSPとVOS3ではVTAMに分割処理を代行する機能(LMPEO)がないのでAIMやDCCMなどは自ら行っています。1つの画面データが分割されるとき、分割された1つ1つのデータをチェインデータと呼びます。チェインにはFIC(First In Chain)、MIC(Middle…)、LIC(Last…)、OIC(Only…)の4種類があり、分割されない時はOIC、2つ以上に分割される時はFIC,MIC,LICを組み合わせて送信データを組み立てます。

画面データの大きさは画面に表示される内容によって異なりますが、一般的な80桁24行であれば画面一杯に表示したとして文字だけで最大1920バイト、これにさまざまな制御コードが付加されます。フィールドが多い画面や、色や罫線などを多用した画面は制御コードだけでも2000バイト近くになったりもします。経験則からアプリケーション業務の画面データは2KB?4KBぐらいの大きさで構成されるものが多いです。RUサイズが小さいとホストから端末に送られる画面データ(アウトバウンド)は常に分割されてしまいます。1度で送ることができればそれだけパフォーマンスも向上します。現在では通信ネットワーク自体も早くなったり、エミュレーターによってはすべてのチェインデータを受信してから画面を組み立てたりするものあるので見た目ではわかりにくいですが、一昔前であれば体感できるほどの違いがありました。見てると画面の上からほぼ3分割されて、パカッ・パカッ・パカッ、という感じで表示されたりします。ネットワークが早くてもパッ・パッ・パッという感じです。分割されても回線やソフトのスピードが早いと人間はわかりませんが中では同じ動きをしてるでしょう。

RUサイズはVTAMのログモードに定義されます。ただしDCMS(TPモニター)によってはDCMSの端末定義などで決定されるものもあります。ログモードと端末定義のどちらを優先するかはDCMSの仕様なので必要なら確認してください。TSOはログモードでRUサイズを決定します。
ログモードのRUSIZEはMODEENTマクロのRUSIZESパラメーターで指定します。IBM社が提供する標準ログモードテーブルISTINCLMにはTN3270サーバーなどでも標準で使用されるSNA端末用ログモードエントリーであるSNX32702と言うのがあります。ここではRUサイズとしてx87F8が指定されています。最初の87は端末->ホスト方向のサイズを示し「8*2^7」で1024バイト、次のF8はホスト->端末方向のサイズを示し「15*2^8」で3840バイトです。3800バイトあればほとんどのケースで分割されることはなく一度で送信できるでしょう。適切なRUサイズがわからなければこのようなメーカーデフォルトを参考にするのも1つの方法です。

昔はハードウェアの制約などで小さいRUサイズを使っていたこともあるので、昔からの伝統的なログモードを今でもそのまま使わっているユーザーでは意外と無駄な分割をしていることもあります。分割数が多ければそれだけネットワークへのI/O回数が増えますから、端末台数が多ければ決してバカには出来ません。

Filed in オペレーション・運用

02.REXXを実行してみる

By takao - Last updated: 月曜日, 10月 27, 2008
REXXプログラムの最低限の形は以下のとおりです。

/* REXX */
say “Hello World!”

これを、HELLOとか、適当なメンバー名で保管してください。

REXXは最初に/* REXX */というコメントで始まらねばなりません。これはVMからの伝統なのですが、まぁ、ルールだと思ってください。次のsayは、日本語で「言え」ですよね。ダブルクオーテーションの文字列を「言います」。
プログラムは大文字、小文字を区別しません。(内部では全部、大文字で処理します。)

TSOで実行する時は、

=> TSO EXEC ‘hlq.your.dsn(member)’

です。CLISTと同じようにPDSに入れておいてください。いちいちデータセット名を指定するのがイヤだったら、SYSEXECかSYSPROCのライブラリーの中にいれておけばいいです。

バッチで走らせる場合は、PGM=IKJEFT01,PGM=IKJEFT1BもしくはPGM=IRXJCLです。IRXJCLは本当にREXXのバッチですから、TSOコマンドを利用するのが個別に呼び出さねばならず、面倒です。TSO環境下で動かすことを強く、お勧めします。
REXXのライブラリはSYSEXECに登録します。プログラムのメンバー名は、PARM=’ ‘に記述するか、SYSTSIN の入力としてください。ここらへんがよくわからない人は、こちらのTSOとISPFの記事を参照してください。

ぜひ、やってみてください。Hello World!が出ればREXXが動いています。
Filed in REXX入門

02.ジョブ管理

By kamii - Last updated: 月曜日, 10月 27, 2008

ジョブとプログラム

コンピュータで何らかの処理を行うためには、その処理の内容を1つ1つとても細かい手順としてあらかじめ記述しておかなければなりません。これがプログラムです。プログラムを動かすことによって始めてコンピュータは意味のある処理を行うようになります。MVS(メインフレーム)ではこれをコンピュータに仕事(JOB:ジョブ)をさせると言う概念で捉えます。
そもそもコンピュータと言う機械が考えられ、開発され、発展してきた背景には人間が行ってきたさまざまな計算作業や集計処理などを少しでも早く、より大量に、そして正確に行わなければならなくなったからです。人間が仕事として行っていたことをコンピュータに行わせるのが目的ですから、コンピュータにおける処理(作業)を仕事と捉えるのは理にかなった考え方です。これがプログラムを動かすこと=ジョブ(仕事をさせる)となったわけです。
このような考え方によってMVS(実際はMVS以前のOSやコンピュータでも)はプログラムを動かすことを、ジョブを実行すると言う考え方で扱います。ジョブは人間から見た仕事の単位で、またMVSから見た最も大きな仕事の単位でもあります。


ジョブの構成

1つの仕事が複数の作業によって成り立つことはよくあることです。
例えば「会議用の資料をコピーして準備する」と言う仕事は、

というように3つの作業に分かれます。MVSのジョブも同じで1つのジョブを複数のプログラムの実行で成り立たせることができます。この場合の1つ1つのプログラムの実行をジョブ・ステップ(JOB STEP)または単にステップと呼びます。1つのジョブは1つまたは複数のステップで構成されます。


ステップは順番通りに実行される

MVSのジョブでは複数のステップは順序通りに実行されます。一般に1つの仕事を構成する各々の作業には順序に基づく関連性があります。上記の例でも、資料のコピー・並べ替え・ホチキス留めは順序通りでなければ処理できず、また同時に行うこともできません。コピーされなければ並べ替えはできないし、ページがバラバラの資料をホチキスで留めるのは仕事としては不正確です。
MVSのジョブ・ステップにも同じ考えがあてはまります。たいていの場合、先行ステップの出力データ(処理結果)を後続のステップの入力データにして、さらに別の処理を行うというようにしてデータ処理の順番にステップが並べられ、ジョブが構成されます。
典型的な例が「プログラムの実行形式モジュールを作る」です。コンパイルしてリンカーに掛けると言う2つの手順を踏みます。コンパイラーの出力がオブジェクトで、オブジェクトはリンカーの入力になります。そしてリンカーの出力が実行形式モジュールになります。コンパイルとリンクは同時にはできませんし、順番を逆にすることもできません。コンパイル→リンクの順で処理をした結果が、出力された実行形式モジュールで、実行形式モジュールが作成されて1つの仕事が完了します。


ジョブの種類

MVSのジョブにはOSから見た用途に応じて3つの種類があります。


JCL

OS/360以前のコンピュータではジョブに対応したプログラムを実行させるのはオペレーターの仕事でした。オペレーターはプログラマーが作成したプログラムを実行指示書に基づいて、プログラムと入力データを準備し、カードリーダーやテープなどの装置にセットし、プログラムを開始させました。終了すれば使い終わったデータをはずし、片付け、そして次のジョブの実行指示書によって準備を始めるといった作業を繰り返します。実際にプログラムが動く時間よりもはるかに多くの、人間による準備と後始末作業の時間が掛かり、CPUの性能が上がるにつれ深刻な問題となりました。OSというソフトウェアは、このような無駄を少しでも減らし効率を高め生産性を上げる目的で誕生しました。
やがて登場したOS/360においてはオペレーターを介さずにプログラマーから直接OSに「実行するプログラムと使用するデータ」を示せるように採用されたのがJCL(Job Control Language:ジョブ制御言語)です。JCLを使用してジョブにおける作業の内容と使うコンピュータ資源をOSに直接指示するわけです。言語となっていますがスクリプトの1種で、プログラマーがOSに渡す「作業指示書」です。
JCLによってオペレーターは紙の指示書によるジョブの準備から解放され、プログラマーはOSに直接指示できることになり、運用の効率と正確性が向上したことは言うまでもありません。またOS/360で採用されたJCLの基本的な文法や機能は、現在のz/OSでもほとんど変化はなく互換性のためとは言え、当時の実装の完成度を示すものでもあります。
JCLは大きく3つの要素(JOB文、EXEC文およびDD文)で構成され、先頭が2つの//記号で始まる80バイトの固定長レコード(カードイメージ)の集合です。このJCLをリーダーで読み取らせることで、ジョブが開始されプログラムが実行されます。リーダーを介してMVSにJCLを読み取らせる操作のことを「サブミット」と呼びます。
JCLについては「JCL入門」にて解説してあります。


ローディングと実行

JCLがサブミットされジョブが開始されると、DD文で指定された資源が割り振られ、プログラムの実行が始まります。
MVSはEXEC文で指定されたプログラムを探すことから始めます。STEPLIB DD文があればそこで指定されたデータセットからプログラムを読み込みます。STEPLIBが指定されないか、指定されてもそのライブラリーにプログラムが入っていなければOSのリンクライブラリーから探し出します。ライブラリーに入っているプログラムはMVS用の実行可能形式になっています。実行可能形式はソースプログラムがコンパイルされて出来上がったオブジェクトプログラムがさらにリンケージ・エディター(リンカー)によってロードモジュールに変換されたものです。
ロードモジュールは命令とデータの集合であるプログラム部分(モジュール・テキスト)とプログラムの属性や大きさ、実行を始める最初の命令位置、いつどのような言語で作成されたなどの制御と管理情報の部分で構成されています。
MVSはEXEC文で指定されたプログラム(ロードモジュール)をライブラリーに見つけるとそれをメモリー上に読み込みます。この動作をローディングと呼びます。MVSによってプログラムがローディングされ、実行の制御に必要なコントロール・ブロックが作られた後、プログラムの実行が始まります。

Filed in ..基礎編

不要なメッセージをコンソールに出さない方法

By kamii - Last updated: 日曜日, 10月 26, 2008

コンソールと言うのは、システムやジョブの異常な状態をオペレーターに通知したり、必要な処置をオペレーターから受け入れるためにも使われます。もちろんエラーに限らず「ちゃんとシステム動いてますよ」とか「これからこんなジョブが開始します」「今この処理が終わりました」などと言う正常な状態の状況通知にも使われています。
しかしながら、どうでもいいんじゃないかこれは?とか、どう見てもプログラマーのデバッグ用メッセージ?見たいなものも少なくありません。あまりにも多くのメッセージが頻繁に出てコンソールのスクロールが休む暇がない、と言う状況は好ましいとは言えません。
OSは本当にクリティカルな状態を示すメッセージはスクロールされない属性でメッセージを出してはいますが、アプリケーションなどではそこまで凝った作りをしていないものが多いので、いざと言うときにオペレーターは見逃してしまうかも知れません。また何らかの対応のためOSコマンドを使った時、コマンドの実行結果が見る間もなく流れて行ってしまっては困ります。システム・パフォーマンスの面でも得はしません。MVSパフォーマンスチューニング入門

そこでオペレーターにいちいち知らせなくてもいいだろう、と言うメッセージはコンソールへ出さないようにできます。従来はWTOのOS EXITルーチンなどが多用されましたが、単にメッセージ出力を抑止するだけなら今は出口ルーチンを書く必要はありません。MVSにはMPF(Message Processing Facility)と言う機能があり、このパラメーターを使って簡単に出力を抑止できます。

上から3つはメッセージIDによって抑止するメッセージを個別に指定しています。4番目はUAP100番台のメッセージは一切表示しないことを指定します。5番目はIEF099メッセージは表示はさせるが、ユーザー出口ルーチンWTOEXIT1を呼び出してユーザー固有の処理させる例です。
これをMPFLST01として作成した場合はSET MPF=01コマンドでアクティブにできます。すでに他のMPFLSTが使われているかも知れません。D MPFコマンドで確認できます。もしMPF=00が使用されていると00が取り消され01に置き換わります。既存のMPFLSTに追加する場合はSET MPF=(00,01)と指定します。
MPFによって表示が抑止されてもそれはコンソール上だけです。SYSLOGにはきちんと書き出されますから何か問題が起きた場合にはSYSLOGをトレースすれば表示されなかったメッセージを確認することはできます。
※MPFはMVS固有の機能です。

Filed in 知っておくと便利なテクニックなど

MSPやってる人が新たにXSPも使わないといけなくなったら

By kamii - Last updated: 日曜日, 10月 26, 2008

富士通にはMSPとXSPと言う2つのOSがあります。MSPはMVSと互換を持ったOSです。MVSとMSPとVOS3は基本的に同じなので、いずれかを知っていればこの3つの中ならすぐ応用が利きます。ところがXSPとなるとだいぶ変わります。コンソール、OSコマンド、JCL、ユーティリティなどなど共通性がありません。
ところがTSS(XSPではAIFと言う)、AIM、VTAM、TISPあたりは使い方も見た目も同じです。ジョブ管理が異なるのでPFDによるSYSOUT(XSPではSOUT)の操作なんかは若干変わりますが、PFD自体はパネルサービスもエディターもビュワーもMSPとXSPは同じです。TSSコマンド、コマンドプロシージャ(MVSで言うCLIST)も基本的には共通です。
MSPとXSPの両方を扱うならば、TSS主体で操作すればわりとスムーズに行きます。バッチ処理やユーティリティとかは絶対必要なものに抑えて、TSSとPFDやCLISTで出来ることはそっちでやるように意識するといいと思います。

私はずっとMVS系でやってきたので、最初XSPにはかなり違和感がありました。MVSのようにJCLでdsname(member)のつもりで、FILE=dsname,MEMBER=memberとして区分データセットのメンバーを書き込んだら、それ以前にあった既存のメンバーが全部消えてしまった!!驚きましたよ、ホントに。後で聞いたら「それってADのパラメーター指定しないとだめですよ」と言われた。「(FILE=dsname,AD)」
プログラムがOUTPUTオープンの場合、JCLでADを指定しないとPSでは頭から上書きされる、PDSではメンバーを全部消してそのメンバーを新規に登録する動きになる。そりゃないだろうって思ったけどまぁ文化の違いかな。それで嫌になって思いついたのがTSS。いろいろ比べるとバッチでは全く違うことがTSSでなら同じなことが多い。もちろん深掘りするには避けてないでちゃんと覚えなければいけませんけど、基本はMSPだけどたまにXSPもいじるって言う方(あるいは逆)ならそんな方法もあります。

1つだけサンプルとなるCLISTを載せます。
SYSOUTの表示はよく行う操作ですが、XSPのPFDにはMSPのPFD3.8に相当するパネルでのビュワーがありません。いちいちFIBGETコマンド打って、PSファイルに移さなければなりません。面倒なので作ったCLISTです。ジョブのSYSOUTをPSデータセットに移してPFD1のブラウザーを呼び出します。


CLISTをEXコマンドで実行したら、取り込み終わった頃を適当に見計らってENTERキーを押す。OUTPUTまたはFIBGETコマンドが終わっていたら、何でもいいから何か文字を入力してENTERすれば、PFDブラウザーが起ちあがり指定したジョブのSYSOUTが表示される。取り込み先のデータセットは適当な大きさで作ってください。

Filed in OSの互換性, 知っておくと便利なテクニックなど

STCとバッチJOBでJCLを共用する方法

By kamii - Last updated: 日曜日, 10月 26, 2008

同じJCLをある時はJOBとして、またある時はSTCタスクとして起動方法を使い分けることもできます(ESA V5以降のMVSでサポートされます)。

従来STCタスクを起動する場合は、その起動用プロシージャをシステム・プロシージャ・ライブラリーに登録しました。プロシージャ自身はSTARTコマンドで直接STCタスクとして実行するか、他のジョブJCLから呼び出して実行する必要がありました。しかし現在では、マスタースケジューラーの起動プロシージャであるMSTJCLnn(SYS1.PARMLIBに入っている)にIEFJOBS DD文を定義することで、そこで指定された区分データセット内のジョブ用JCLメンバーをSTARTコマンドで直接実行することができます。またそのメンバーをSTARTコマンドでなくJES2にサブミットすればJOBとして実行することもできます。STARTコマンドでSTCタスクとして実行した時のジョブ名もJCLのJOB文に指定されている名前になります。IEFJOBSに登録する場合JCLはJOB文を使用してあくまでも通常のJOB用に作ります。PROC文で始めてはなりません。

JES2が起動された後、同じ名前のメンバーがIEFJOBSとJES2のPROC00の両方にあればIEFJOBS側が使用されます。この方法だとSTCタスクであってもストリーム内データ(DD *)が利用できます。STCタスクで動かすがSYSINデータをDD *で直接指定できればなぁって思ったことはありませんか?

詳細はz/OS MVS JCL解説書の「開始済みタスクのソースJCL の決定」に載っています。

Filed in 知っておくと便利なテクニックなど