オンライン端末の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 知っておくと便利なテクニックなど

秀丸エディター用JCLサブミットマクロ

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

メインフレームのソフトウェアではないですが、関連するので紹介します。

今はWindowsでメインフレームのプログラムやJCLを作ったりしている方も多いと思います。実際使ってみるとWindowsのテキストエディターはISPFやPFD、ASPENに比べれば使い勝手が全然違います。慣れると戻れなくなるぐらい。でも作った後は結局メインフレーム側へアップロードしなきゃならないんで、それを考えるとちょっとしたJCLなんかはわざわざPCで作っても返って面倒です。
そこでWindowsのテキストエディターから直接ホストにサブミットできたら絶対便利!と思って作ったがこのマクロです。「秀丸エディター」専用なので秀丸を使ってない方には役に立ちません。WindowsでJCLを書いたらそのままマクロを実行すればダイレクトにサブミットできます。しょっちゅう使うならマクロをファンクションキーに登録しておくといいです。

MVS3.8とz/OS(OS/390)をサポートしてます。MVS3.8ではHercrdrと言う仮想のカードリーダー機能で、z/OSではFTPでJCLをJES2リーダーに飛ばします。MVS3.8のHercrdrはファイルがディスクにセーブされていないと使えませんし、エディターとコマンドプロンプトのウィンドウを切り替えなければなりませんが、このマクロを使えば編集中のテキストをセーブしなくても直接サブミットできます。

秀丸エディターからJCLをサブミットするところ

秀丸エディターからJCLをサブミットするところ


ダウンロードはこちらからどうぞ。
秀丸エディター用JCLサブミットマクロ.lzh

Submit.mac,Submit.jcl,Submit.ftp1の3ファイルがあります。全部を秀丸がインストールされているフォルダーに(C:\Program Files\Hidemaru)にコピーします。Submit.macの中でSUBMIT先選択ウインドウを定義してますので、ご自分の環境などに合わせて適宜修正してください。
MVS3.8を使う場合は変数$HRDRに設定するMVSR38フォルダーのドライブ文字を確認して修正してください。このサイトでダウンロードしたMVSR38をインストールした環境に合わせてあります。別サイトからダウンロードしたMVS3.8システムをご自身でSYSGENした場合は環境に合わせてフォルダー名なども修正してください。
見てもらえればわかりますが大したことはやっていません。お好みに合わせてカスタマイズする場合は秀丸のマクロヘルプを参照ください。
z/OSまたはOS/390ではSubmit.ftp1がftpクライアントのパラメーターです。先頭のopenコマンドでMVSのIPアドレスを指定して下さい。2行目と3行目はユーザーIDとパスワードです。後はそのままでかまいません。日立のVOS3でも使えます。その場合は4行目のquoteを削除してください。なおTSSにログオン中のユーザーIDは使用できませんので注意してください。MSPやXSPではFTPサーバーにJCL入力機能がないので利用できません。

Filed in 関連ソフト、フリーウェア, 知っておくと便利なテクニックなど

03.ジョブ入力サブシステム

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

JES2(JES,JSS3)

JES2はMVSのジョブ管理を補完するもので、ジョブ入力サブシステム(Job Entry Subsystem)と呼ばれます。OSであるMVSと連携してジョブ管理機能を構成しています。JES2に相当するものはMSPではJES、VOS3ではJSS3となります。主な役割はジョブのスケジューリングとスプーリングです。MVSのジョブ管理は大きく3つの機能で構成されています。

JES2はそれぞれの機能の間にキュー(待ち行列)とスプールを設け、「読み取り・実行・書き出し」の3つのサイクルにおいて人間(オペレーター)の介入を極力排除して、ジョブ処理が連続して流れるように制御します。特にスプーリングは超高速なCPUによるプログラム処理と、低速なカードリーダー(ジョブの入力に使われた)やプリンター(ジョブの出力に使われる)の速度差を埋め、システム全体が低速なI/O装置に足を引っ張られないようにするための重要な仕組みです。


ジョブの入力とリーダー

JCLによって記述されたジョブはリーダー装置を通してJES2に入力されます(サブミットされる)。今ではINTRDRと呼ばれるプログラムによる論理的なリーダーが使用されますが、以前はカードやテープなどの物理的な装置もよく使われました。INTRDRはプログラムではあるものの呼び出して使うサブルーチン的なものではなく、JCLのDD文に定義して使用するか、対話処理のコマンドによって間接的に使用します。

入力されたジョブにはジョブIDと呼ばれる識別子が付けられ、「実行待ち行列(ジョブ・キュー)」に入れられます。実行待ち行列は実行クラスと優先順位によって管理されるもので、後から入力されたジョブが先に取り出されることがあります。実行クラスはジョブをグループ化するための識別子でAからZおよび0から9の36種類が使用でき、クラス毎に実行時の優先度や利用できる最大CPU時間やメモリーサイズなどのジョブの特性を定義することができます。これらはユーザーが自社の業務特性に合わせ自由に設定することができます。


ジョブの実行とイニシエーター

ジョブはイニシエーターによって実行されます。イニシエーターにも実行するジョブのクラスが割り当てられ、ジョブは同じクラスに対応した空きイニシエーター(何のジョブも実行していない実行待ち状態のイニシエーター)があれば、優先順位によってキューから取り出され、そのイニシエーターによって実行が開始されます。

MVSでは1つ1つのイニシエーターは独立したアドレス空間を持つプロセスとして動きますが、他にもメモリーを分割した区画(パーティション)として制御するOSもあります。複数のイニシエーターを利用することで、その分だけジョブを同時に実行することができ、このようなOSの制御を多重プログラミングと呼びます。プログラムはチャネルが入出力処理を実行している間はCPUを使わないので、この空き時間を利用して動かすプログラムを次々と切り替えて行くことであたかも同時に動いているかのように制御する方式です。

イニシエーターの主な役割は以下の通りです。


ジョブの出力とライター

ジョブ内のすべてのステップが終了すると、ジョブの実行結果がジョブ・ログとして出力され、ジョブは出力待ち行列(アウトプット:キュー)に入れられます。ジョブ・ログはJES2が作成したジョブの実行ログです。プログラム自身が出力する処理結果があればそれらも含まれます。これらは一般的に印刷用データとして作成されますが、直接印刷装置に出力されるのではなく、一旦JES2のスプールに入れられます。
スプール内の出力データはDD文の指定などによって区分され仮想のデータセットとして格納されます。これがSYSOUTで、スプール内の個々のSYSOUTをSYSOUTデータセットと呼びます。入力用のデータをスプール内に格納することも出来、こちらはSYSIN(データセット)と呼ばれます。
実際のSYSOUTデータセットはジョブ終了時に作成されるのではなく、ジョブの入力時やステップの開始時にスプール内に割り振られ、JES2およびプログラムによってデータの出力が行われると、バッファリングされ必要に応じてスプール内に書き出されます。ジョブの終了によってこれらのSYSOUTはデータとして完成し書き出しが可能になります。

書き出しが可能になったSYSOUTを実際の出力装置に送り出すのがライター(Writer)です。標準的な出力装置として使われるのがプリンター(印刷装置)とカードパンチ(穿孔装置)ですが、カードパンチはカードリーダー同様に現在ではほとんど使われることがありません。その他にスプール内のSYSOUTをテープやDASDにデータセットとして書き出すこともでき、これを行うプログラムをXWTR(External Writer:外部書き出しプログラム)と呼びます。MVSの標準機能として提供されていますが、ユーザー独自のプログラムとして作成することもできます。

スプーリングによるSYSOUTとライターの利点は、パフォーマンスとスループットの向上とユーザープログラムの簡易化にあります。低速なデバイスであるプリンターやカードパンチにユーザープログラムから直接書き出していては、処理速度は装置の速度に引っ張られます。その間他のジョブも装置を利用できないので実行自体を待たねばなりません。スプール内にSYSOUTデータセットとして書き出せば、高速なディスク装置の速度で処理を行うことができますし、DASDであれば同時に複数のジョブでも共用使用ができます。またプリンターの制御を行うにはハードウェアに依存したI/O処理が必要になりますが、これはユーザープログラムにとっては業務処理とは直接関係ありません。ライターを介せばこれらの面倒なハードウェア制御の処理はJES2が一手に引き受けますから、ユーザープログラムはSYSOUTと言う仮想のプリンターに単にデータを書き出せば良いのです。

Filed in ..基礎編

WindowsとTCP/IPでどんなに仕事が楽になったことか…

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

私は1980年代後半からメインフレームのシステム系パッケージソフトを扱う仕事をしてきました。
当時担当してた製品はトラブルが多く毎日のようにいろんなユーザーから「また落ちたぞ、ダンプ出てるから取りにきて!」って言う嬉しくないコールがバンバン入る。ダンプって言うのはメモリー上に展開されてるプログラムやデータをはき出した物。これが16進数と対応したキャラクター文字で編集された診断用のリストとして出力される。ダンプリストのサンプル

アプリケーションの場合は自分のプログラムだけがわかればよかったり、使うメモリーも少なかったりするのでそんなに量がでない。でもサーバー系のソフトなんかだとメモリーは沢山使うは、さらに機能がシステム系だったりすると自分のプログラムやデータだけじゃ済まなくて、OS全体の共通エリアやOS自身のモジュール域なんかも必要だったりして、その出力量が半端じゃない。10万行、20万行とかはありがちで時には50万行なんてとてつもない量が出たりする。

それを1ページ66行133桁の用紙に出すんですが、すごい紙の量になる。ストックフォームって言ってましたが印刷用紙が入った箱が高さ30から40cmぐらいあって、まぁ普通で1箱、多いと2箱、3箱分ぐらい出ちゃったりする。当時でもメインフレームのプリンター、特にレーザープリンター、それも高性能のはもの凄いスピードで印刷できるからストックフォーム1箱分程度の印刷ならさして時間は掛からない。これだけの量になるとスプールに残しておいてもかなりのスペースを占めるからお客さんとしてはさっさか掃き出したい。なので「こっち来る間に出しとくからね」となる。あまりに頻繁だとトラブルこと自体もさることながら「今度は本当に紙代請求するよ!」なんて言われたりもした。(実際取られたことはなかったな)

さて前置きが長くなってしまった。まず最初にツライのはこの大量の紙が入った箱を会社に持って帰ること。さすがに2箱以上になると電車は無理なのでタクシー、でも若い身分でしょっちゅうタクシー使うとそれはそれでにらまれたりする。1箱程度だと2つに分けて紙袋に突っ込む。でも指がちぎれそうに痛い。真冬で雪が降った日に京葉線の何とかって駅まで延々とそれを持って歩いた時、本当につらくて本気で捨てようかと思った。

会社に戻ってからは、そのダンプリストを調べてデバッグが始まるんですが何せ紙なんで作業効率悪いことこの上ない。どのモジュールで落ちたか?何のエラーで落ちたか?ぐらいはすぐわかる。問題はその げ・ん・い・ん。まずは何でそんなことが起きたのかって言う原因を調べなければならないがこれがまた大変。紙だから検索なんて気の利いたことができない。アドレスで場所を探す場合はまだいいけど、ある特定の文字列を見つけるとか、バイナリー値を探したいなんて時は、リストの量が多いとたまらない。でもその頃はそうするしかなかったからね。調べるスピードが追っつかないからそのうち調査待ちのダンプの箱が何十個って積み上がってたりしたもんです。本当にやばくて緊急なものは徹夜してでもやったけど、そうでないとバカらしくてやってらんないってことになり、割とさっさか帰っちゃったりしてました。「いや?徹夜して調べたんですど、むずかしくてまだわかんないんですよ。すいませんもうしばらく時間下さい」なんてしれっとして中間報告。自分が作ったプログラムならいざ知らず、外国のそれも会ったこともない奴が作ったプログラムのバグで何で俺がこんな思いしなきゃなんないのって思いの方が強いからふてくされちゃうんですね、私は。それでもさすがに量がたまるとそれはそれでまずくなってくるので徹夜したり、休みをつぶしたりはしょっちゅうでした。ごめんなさいまだ前置き長いですね。

昔からメインフレームやってた人なら「何でTSOとか使わないの?」と思ったかも知れません。小さい会社だったんでそんなに端末なかったんですよ。事務所に数台って感じ。まだ新参者だったし先輩連中が端末の前にドカって座ってるとそうそう簡単に使わせてもらえません。周りも忙しいからなかなか帰ってくれないんで端末空かないし…
やがて部署に数台ってぐらいに増設されてからは使いましたよ。ダンプを紙じゃなくテープに入れてもらって、マシン室のある別の事務所に行ってテープからディスクに落として、自分の事務所に戻ってから机の上で調べられました。でもね、やっぱりこれはこれで不便なんですよ。と言うのは端末って言ってもMS-DOSベース(実際はIBM製なんでPC-DOS、PS/55とか言ったかなぁ…)のPCでの3270エミュレーターですが画面サイズが80桁*24行なんですよ。ダンプって121桁あるんで画面からはみ出るんです。画面をいちいち左右にスクロールしないとだめなんです。これが実にうっとおしくてやってられません。132桁*27行表示できる3270モデル5のハードウェア端末(型番は忘れた)が事務所に2台だか3台だかあったんで空いてればそれを使いましたが昼間だと結構取り合いになるんです。これが使えると検索はできるわ、リストの横幅一杯に表示できるわで紙を見るより作業効率はぐんと良くなりました。もっとも調査待ちで積み上がるのが紙の代わりにテープになっただけだったかも知れない。この頃が1990年過ぎぐらいですよ、確か。

それからしばらくして自分で買いました。DOS/Vノートパソコン。Dynabookだったかな。でもメインフレームには繋げられなかったんで単なる高級文房具としてこちょこちょやってたけど、仕事では何の役にたったかあまり覚えてない。あの頃はまだインターネットはやってなくて、代わりにハマッてたのがNifty-Serveって言うパソコン通信。ダイヤルアップって言ってモデムで電話回線と繋げて通信してたんですよ。なつかしいね。実はこのブログを一緒にやってる相棒とはここの何かのフォーラムで知り合ったんですよ。彼は当時外資系メーカーにいたんですけどいろいろ助けてもらいました。ISVでシステムソフトをやってた身としてはメーカーのエンジニアの友人は強い味方でしたねぇ。ちなみに僕は○○○BASなんてソフトを扱ってたとこにいましたが、僕はまったく違う製品をやってました。日本では超マイナーな製品でしたけど…



すいませんねぇ思い出話に浸ってしまい。ここからがタイトルに関しての本題。

その後に出たんですよ。ウ・イ・ン・ド・ウ・ズってものが。飛びつきました。自分で買いましたよ仕事用に。確かPS/VISIONってやつ。さすがに3270エミュレーターとホストに繋げるためのCOAXボードって言うインタフェース・カードはあまりにも高いんで会社で買ってもらった。まだ大らかな時代でした。個人持込みPCだって使い放題。そもそも個人用PCなんてお偉いさんから割り当てられるんでまだぺーぺーだった僕なんかいつになることやらって頃でしたから。

まだTCP/IPは普及してなくて、仮にWindows側で使えるようにしたとしてもホスト側のTCP/IPなんてまだまだ使えなかったらあくまでもSNA接続です。それでもWindowsになって自分のPCで3270エミュレーターを動かせたのは大きかったな。ソフトウェアでのエミュレーションだからお気に入りの132桁表示も出来たし、エミュレーターのファイル転送でホスト側のデータセットを自分のPCに持って来られたから紙のリストで苦労したダンプやら製品のアセンブルリストやら何やら仕事で使うホスト上にあったデータをみ?んな自分の道具の中に入れました。Windowsのテキストエディターはいいよねぇ。ISPFエディターだのISPFブラウザーなんて使ってられないですよ、PCの世界に浸ると。このあたりでついに紙の資料から解放されたって感じです。ダンプやトレースリストもそうだけどアセンブルリストやソースコードがPCの中に入ってくると出来るんですよ、け・ん・さ・く。それも複数のファイルにまたがって。このメッセージってどのモジュールが出すんだ?このフィールドに値を設定してるのはどのモジュールだ?ってことなんかを調べるのにそりゃあ便利になりましたよ。フリーウェアだのシェアウェアだのもこの頃はもう盛んでしたからいろいろ落としまくりました。まだインターネットではなく入手元はニフティサーブ(今の@niftyの前身)から役立ちそうなものはないかって。この頃会社の汎用機はIBM,FACOM,HITACってひと揃いあって、VM,MVS/ESA,VSE/ESA,AVM,MSP/EX,XSP,VMS,VOS3/ES1,VOS1が自由に使いまくれていい時代でした。メインフレーム全盛期の終盤あたりでしょうかね。

それから数年で出ましたねWindows95。TCP/IPが標準になってインターネットが普及し始めました。でもメインフレームの仕事関係でTCP/IPの恩恵を受けるようになったのは会社の汎用機にLANコントローラーが導入された後です。確かIBM機が最初だったと思う。型番はわかりません。まだ直接自分の仕事では関係なかったから。仕事でTCP/IPやったきっかけは1997年に仕事でアイルランドに行った時。アイルランドのある会社で作ったMVS(OS/390のバージョン2が出始めた頃かな)版ソフトを富士通にMSPに移してみないかって話で。そこの社長は当時いた会社で僕がやってた製品の開発元にいたエンジニアで仕事上ではあるものの元々付き合いがあった人。そんな縁で話がきたんですね。どんなソフトかをひとことで言うとメインフレームで動かすPOSIX環境。応用オプションで用意したのがWebサーバー。一応やりましたよMSPへの移植。このソフトはわりと壮大な構想で、MVSの中にPOSIXのAPIを実装して、C言語で書かれたプログラムはこの製品のライブラリーを使ってコンパイルすればUNIXベースのソフトを汎用機で動かせるってシロモノ。バッチ・プログラムでもいいし、専用のオンライン処理用サーバー内で動かしてもいい。C言語だけでなく、アセンブラー用のマクロやCOBOL用のAPIルーチンも用意してた。もっとも最初から全部のAPIを用意したわけでなく、Webサーバーで使うのに必要なものに絞ってたと思う。エンハンスを重ねて実装API数を増やすって計画でした。オプションで用意したWebサーバー自体はアセンブラーで書かれたがファイルのI/OやTCPソケット通信はそのPOSIX APIを使用してました。ちゃんと動きましたよ。MVSやMSPのコンソール・イメージをWebブラウザーで表示するなんて言うCGIルーチンを作った記憶がある。あくまでもテスト用で実用品ではありませんけど。技術的には完動品として完成したんですけど、まぁその後いろいろあって日の目を見るには至りませんでした。もっとも私は日本では売れるとは思いませんでした。すでにIBMさんはWebSphereを出してたし、その頃はみんなが思ってたんですよ「近いうちにメインフレームはなくなる」って。だったらWebサーバーなんてUNIXでApacheでしょ。メインフレームはなくなるんだから代わりになるものはUNIXしかないじゃんってね。じゃあなんでそんな開発できたのって思うかも知れませんね。わりと融通が効く会社だったんですよ。しかもベースのMVS版は出来ていてただMSP用に直すだけだし、外注するわけでなく全部自分達でやるし。まぁこの製品はいろいろ学べたものも多かったです。ちなみにTCP/IPを扱うソフトをやったのはこれが最初でした。

また話が脱線しました。すみません。で話を戻すとそのアイルランドに行った時に見たんですよ。WS_FTPってソフトを使ってるのを。このソフトはWindows用のFTPクライアントですが、何とサーバーとしてMVSをサポートしてるんです。区分データセットのメンバーが一覧で出てきてPC側のフォルダーにまとめてダウンロードしたり、アップロードしたり、GUIで操作できるんです。それって便利!ってことから使い始めました。FTPを使うと3270エミュレーターのファイル転送機能には戻れません。スピードは全然違うし、簡単だし。そもそも自分の仕事ではプログラム内に日本語を書くことはないから海外のソフトでも関係ないんですね。それからもメインフレームの仕事をしてはいましたが、WindowsとTCP/IPによって使えるツールによって、ダム端末しかなかった頃に比べれば作業の効率は格段に上がりました。それこそ紙や磁気テープでもらってたトラブルシューティングの資料なんかもその後はCD-ROMに焼いてもらったり、直接会社のWebサイトにアップロードしてもらったり、などなど便利な時代になりました。こんなブログを書いているのもネットのおかげですしね。

メインフレームだけやってる人であっても、今はWindowsやTCP/IP抜きでは仕事ができないって時代になりました。でも逆はないんですよね。Windowsとかオープン系だけやってる人はメインフレームなくっても(Windowsやオープン系の)仕事はできますよね。メインフレームでWindows用のクロスコンパイラーを動かすなんて聞いたことないし。

こんなことを書くのにだらだらと思い出話なぞを綴ってしまいました。最後まで読んでくれてありがとうございます。

Filed in つぶやき・雑感

04.メモリー管理

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

仮想記憶

コンピュータのプログラムは命令にせよデータにせよ、必ずメモリー上に置かれていなければCPUが処理することができません。プログラムが大きくなりデータ量も増えてくればそれに応じたサイズのメモリーが必要です。ところがすべてのプログラムが同じ大きさで同じ量のデータを扱うわけではありませんから、小さなプログラムでは使われないメモリーは無駄になってしまいます。昔はメインフレームに限らずハードウェア部品としてのメモリーは非常に高価であったため大きな問題でした。そこで登場したのが仮想記憶と言う考え方の仕組みです。
仮想記憶方式では主記憶装置はハードウェア部品としての実記憶装置とDASD上の補助記憶装置によって構成される論理的な装置として扱われます。MVS上のジョブは一部の例外を除けば実記憶(リアルストレージまたはリアルメモリー)を直接アクセスすることはありません。よってMVSでは単にメモリー、記憶域と言った場合は基本的に仮想記憶(バーチャルストレージまたはバーチャルメモリー)のことを指します。

仮想記憶によって得られるメリットとして大きく以下の2つがあります。


ページングとスワッピング

CPUは実記憶装置しかアクセスできませんから、実際に命令を実行したり演算処理やデータの移動を行うためには命令と対象となるデータは必ず実メモリー上に置かれなければなりません。仮想記憶は一般に実記憶より大きなサイズを持ちます。そのため溢れた内容をどこかにしまっておく必要があります。これが補助記憶でメインフレームではDASD内に作成されているページ・データセットに入れられます。
S/370アーキテクチャーではCPUはDATと呼ばれるハードウェア機構によって仮想アドレスのまま命令やデータの場所をアクセスできるようになっています。この時仮想アドレスで示されたメモリー領域が実際の実記憶上に存在しない場合、CPUはOSに割込みを起こして通知します。MVSはこの割込みを受けて、そのアドレスが示す領域が仮想記憶域として存在するかを調べます。正しい仮想アドレスであればページ・データセットにその内容が退避されているので、DASDからそれを実記憶上に読み込みます。これがページインです。逆に当面CPUが使わない領域はページ・データセットに退避されます。これがページアウトです。

このページインとページアウトによって実記憶と補助記憶間でのメモリー領域を、CPUがその都度必要とする部分に対応させ頻繁にやり取りを行って制御しています。これがページングと呼ばれる仕組みです。MVSではやり取りされるメモリー領域を4KBずつの大きさに区切って管理します。この4KBで区切られた領域をページと呼びます。ページングではページ単位に実記憶から補助記憶に書き出され、また逆に補助記憶から実記憶に読み込まれます。

頻繁にアクセスされるページがその都度DASDから読み込まれるのでは、効率が悪いので優先度が低いジョブが使用している実記憶上のページの集まり(ワーキングセットと呼ばれます)はCPUの割込みに依らずMVSが自らまとめてページ・データセットに書き出します。このようにページ単位ではなくワーキングセット単位に行われるのがスワッピングです。スワッピングは仮想記憶そのもののメカニズムではなく、パフォーマンス制御のために行われるMVSのOSとしての機能になります。
またMVSのページング制御や割込み制御などを行うモジュールはページアウトされてしまうとOSとしての制御ができなくなってしまいます。このようなOSとしての核になる部分はページアウトされないようになっていて、ページ固定と呼ばれます。


アドレス空間

MVSでは1つのジョブは1つのアドレス空間の中で動きます。実行するジョブが2つあるとそれぞれが独立したアドレス空間を持ちます。アドレス空間はプログラムに与えられる一定の大きさを持つ連続したメモリー領域です。メモリーと言ってもあくまでも仮想です。
またMVSと言う名前はMultiple Virtual Storageの略で、複数の仮想空間を並べて制御するためにMVSと名付けられたのです。ここで言うVirtual Storageが仮想アドレス空間となります。これが複数だからMVSとなったのです。ちなみにMVSの前にはSVSと呼ばれるものもありました。Single、つまり単一の仮想空間では、複数のプログラム(ジョブ)はパーティションと呼ばれる空間内を区分けした区画内で動きます。ジョブ管理とJES2で出てきたイニシエーターは、この区画の考え方の名残でもあります。
アドレス空間はメモリー空間と言い換えて考えてもいいです。Windowsなどではそう呼ばれます。「1つのプロセスには1つの独立したメモリー空間が与えられる」なんて解説されたりします。独立しているのがポイントです。ジョブAのプログラムでもジョブBのプログラムでも8000番地は同じ8000番地ですが、お互いの領域がかぶらないのは、それぞれの空間が独立しているからです。これによって、誤りがあっても他のプログラムのメモリー領域を壊すことがありません。ソフトウェア面におけるシステムの信頼性は大きく向上しました。「行儀の悪いプログラムのおかげでみんなが迷惑する」と言うことは、メインフレームの世界ではすでに1970年代初期には解決していたわけです。

アドレス空間の大きさは初期のMVSでは16MB(24ビット)、次のMVS/XAでは2GB(31ビット)となりました。何で32ビット使って4GBにしないのか?とお思いでしょうがこれにも理由があります。
先頭の1ビットはプログラムが16MBまでのメモリーをアクセスできる24ビット・プログラムなのか、それを超えてアクセスできる31ビット・プログラムなのか、を識別するための標識に使われます。そのため仮想アドレスは残りの31ビットで表現するため最大2GBとなったのです。これは古い24ビット・プログラムも、新しい31ビット・プログラムも、どちらも修正なしでそのまま動かせる互換性のためです。現在のz/OSでも同じです。MVSを始めとするメインフレームOSや、ハードウェアは、この互換性を非常に重要視してきました。故に今でも昔のプログラムが現役で動いているわけです。
現在のz/OSでは16ExaB(64ビット)となっていますが、2GBを超える領域はデータ用に使われプログラム自身は動きません。64ビットの空間をフルに利用するプログラムは、データベース系の製品など、これから少しずつ出てくるでしょうが、一般のプログラムではそこまでの広大なメモリーはあまり必要とされないと思います。またアドレス空間の数ですが最大で32767空間となっていますが、z/OSのデフォルト値では255とされています。

アドレス空間が2GBの大きさを持っていてもプログラムですべて自由に使える訳ではありません。MVSは空間をOS自身を置く領域、OSがシステムやプログラムを制御するために使う領域、複数のプログラムで共通に使える領域、ユーザー・プログラムを置く領域など、いくつかに区分けして管理します。それぞれの領域の大きさはシステムのパラメーター設定によっても変わってきます。
ユーザー・プログラムが利用できる領域が「リージョン(REGION)」です。PVTとも呼ばれます。リージョンは16MBより低い24ビット領域と、16MBより高い31ビット領域の2つに分かれ、それぞれ基本リージョン・拡張リージョンとなります。基本リージョンはユーザーのシステム設定によって幅があります(6MB?10MB)が、一般的なユーザーでは8MB程度の大きさを持ちます。拡張リージョンはGBの大きさを持つものの利用できるのは標準では32MBです。MVSとMSPでは暗黙で利用できますが、VOS3ではJCLに明示的に利用する大きさを定義する必要があります。

MVSアドレス空間構成図

MVSアドレス空間構成図



アドレスモード

MVSではプログラムはアドレスモード(またはアドレッシングモード)と呼ばれる空間をアクセスできる範囲があります。16MBまでのメモリー域にアクセスできる24ビット・アドレッシングモード、2GBまでのメモリー域にアクセスできる31ビット・アドレッシングモード、さらに16ExaBまでのメモリー域にアクセスできる64ビット・アドレッシングモードです。24ビットモードを基本モード、31ビットモードを拡張モードと呼ぶこともあります。
最初のMVSの仮想アドレス空間の大きさは16MBでした。その後MVS/XAになって、これが2GBに拡張された時に、旧24ビットプログラムの互換を保ち、新31ビットプログラムも同時に動かすためにアドレッシングモードの考え方が採用されたのです。
Windowsなどのように、32ビットを使用して4GBにしなかったのは、アドレス・ワードの先頭ビットをアドレスモードの識別に使用したためです。CPUは元々32ビット、PSWなどもアドレス部は32ビットを持っていたため、それらをそのまま生かして仮想アドレス空間を拡張しました。zアーキテクチャではPSWや命令も新たに64ビット対応に変更されたり、追加されたりしたので、MVS/XAの時のように63ビットではなく64ビットをすべて使用してアドレス表現できるようになっています。

Filed in ..基礎編