デバッグのためにコンソールにMSGを出さない

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

少しアセンブラーに慣れてくると作ったプログラムのデバッグが気になってくる。思うような結果が出ない、ABENDしてしまう、など上手く動かないことはわかるが、どうしてそうなるかがわからない。この部分は通ったか、あそこはどうか、と書いたプログラムがどう流れているのかが知りたくなる。そんな時コンソールにメッセージを出すWTOと言うOSマクロの存在なんぞを知ってしまうと、プログラム内の至る所にそれを入れて、どこをどう通ったかコンソールにメッセージを出してプログラムの流れを掴もうとしたくなる。
だがこの方法はできればやらない方がいい。正直言ってみっともないし(腕前のなさを宣伝してるようなもの)、他人のデバッグMSGほどうっとおしいものはない。それにもし誤ってループした場合、そのループの中にWTOマクロが入っていると悲惨である。コンソールに大量のMSGが出され、かつシステムのコンソールバッファも滞留する。それが捌けるまでシステムは足を引っ張られ他のジョブも止まってしまう場合がある。MVSはとにかくMSGをさばくことに必死となる。もしそのプログラムのJCLをTSOからサブミットしたならば大騒ぎにならないうちに自分で始末しようとしてもキャンセルすることすらむずかしいであろう。そんな状況になると優先度が比較的低く設定されるTSOユーザー空間などはちっともディスパッチされない。とにかくコンソールからコマンドでジョブをキャンセルしてもらわねばならない。コンソールが一杯でディスプレイコマンドも使えないからオペレーターにもうっとおしがられるし、ビビッて放っておいて大騒ぎになったりすると厳格な運用をしているセンターでは始末書を書かされるかも知れない。協力会社のエンジニアならあなたが怒られるだけでなく、責任者も呼び出されるかも知れない。いずれにしても嫌な思いをすることになる。私はさすがに始末書を書かされたことはないが、駆け出しの頃は何度もやってしまいバツの悪い思いをしたことが何度もある。
プログラムの流れを追うのに要所要所でメッセージを出す方法自体は悪いことではない。基本的なデバッグの方法でもある。問題は出力先なのである。コンソールに出すから問題にもなるし、かっこ悪い。WTOは1行マクロ命令を書くだけで済みお手軽だから使いたくなるのだが、どうせMSGを出すならSYSOUTの方がいい。WTOに比べればDCBを用意してOPENとCLOSEが必要になるが大した手間ではないし、MSGを出すのにはWTOの代わりにPUTマクロを使えばいい。MSGテキストはリテラルで書けばWTO同様に1メッセージ1行で済む。簡単なサンプルを紹介するので参考にして見て欲しい。

プログラムの実行JCLには以下のDD文を追加する。OUTLIMパラメーターは必ず付ける。この例では1000メッセージ出したらジョブの実行を打ち切る。これが無いとPUTを出しながらループしたら場合によってはJES2スプールを一杯にしてしまう。これも起こしてしまうと大騒ぎになる。それでもスプールが一杯になるにはある程度時間が掛かるし、ログオン済みTSO端末の応答がなくなることはないので自分でそのジョブをキャンセルしてからパージできる。

VOS3の場合は2秒間に38回連続して同一テキストのMSGが出るとWTOを出しながらループしていると判定されABENDさせられる。(確かS722だったと記憶している、また監視時間はPARMLIBの設定で変更できる)MVSやMSPには同様のガードはない。JCLのTIMEパラメーターで一定時間CPUを使ったらABENDさせてしまう方法もあるが、数秒であっても相当な数のメッセージが滞留してしまうからコンソールへMSGを出してデバッグするやり方はやはり勧められない。MVSにおけるコンソールは本来センターオペレーターにシステムの異常な状態を通知したり、業務アプリケーションでオペレーターに判断を求めたり、と言ったシステムやプログラムがオペレーターと通信するためのもの。プログラマーがデバッグに使うのは必要最小限にとどめたい。代替の出力先が使えるならそちらを利用すべき。

Filed in S/370アセンブラー講座

TASID(z/OSシステム動作状況モニターツール)

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

TASIDはIBM社が提供するMVS(z/OS)のシステム動作状況をTSO端末上でモニターすることができる無料のプログラムです。
SDSFのDAパネルを拡張したようなもので、ジョブやアドレス空間の状況だけでなく、ENQ競合、仮想ストレージ内容の表示、アクティブデバイスの一覧、DASDの空きスペース状況、仮想ストレージ・マップなどなどかなりディープな情報を知ることができます。使いこなすにはMVSの内部構造や機能に関する知識をそれなりに必要としますが、システムプログラマーや運用担当者であればインストールしておくと便利なツールです。

ISPFパネルモジュールがTASID本体に組み込まれたものと、プログラムとパネルがセパレートされているものと2種類ありますが、パネル組み込み版がインストールが簡単です。

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

07.データセットの種類とアクセス法

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

DASDやTAPEなどのデバイス・ボリューム内に格納されるデータセットが、どのような形式でどのように構成されるかの概要について紹介します。

レコードとブロック、レコード形式

MVSではデータセットを構成する最小の単位をレコードと呼びます。すべてのデータセットはこのレコードによって構造化されると言う特徴を持っています。またレコードはプログラムから見たI/Oの最小単位でもあって、通常はレコード単位にファイルを読み書きします。レコードはさらにフィールドに細分化されますが、これにはMVSは一切関与しません。あくまでもプログラム側の処理によって行われます。

MVSのファイルシステムがレコードを基本にデータを構成するのは歴史的な背景によります。コンピュータ以前のPCS(パンチカード・システム)では紙カードを媒体にしたデータ処理を行っており、1枚のカード上のデータが処理の単位になっていました。やがてコンピュータが生まれ、さまざまな記憶装置が使われるようになり、紙の代わりにこれらの装置上にデータをカードのイメージで保存したことに始まります。

複数のレコードをまとめたものをブロックと呼びます。ブロックはデータセットがディスクやテープなどの記憶装置に記録されるときの単位であり、物理レコードとも呼ばれます。これに対してブロック内の各レコードは論理レコードとなります。ブロックの中にいくつのレコードが格納できるかを示す数値をブロック化因数(Blocking Factor)と言います。複数の論理レコードをブロックにまとめることをブロッキングと呼び、逆にブロックから論理レコードにばらすことをデブロッキングと呼びます。ブロッキングとデブロッキングは通常のアクセスであればMVSによって行われます。

なぜレコードをブロック化するかと言うと、記憶装置のスペースを節約するためと、データの転送効率を高めるためです。ディスクでもテープでも装置内に物理レコードを記録する時、レコードとレコードの間にギャップ(GAP)またはインターレコードギャップ(IRG)と呼ばれる隙間が置かれます。ギャップはデバイス上でのレコードの区切りでもあってハードウェアによって自動的に書き込まれます。またギャップは高速で回転する磁気媒体から正確にデータを読み取るためにも必要なものです。ギャップも記録媒体上のスペースを占めるため、小さなレコードを数多く書くと無駄なスペースが増え、実際のデータを書き込める量が少なくなってしまいます。
したがってデバイスの使用効率を上げるためには物理レコードを可能な限り(デバイスが許す限り)長くする必要があります。またデバイスは物理レコード単位にデータを読み書きしますので、物理レコードが長ければI/O回数を減らすことができます。I/O回数が減ればMVS側の入出力処理のオーバーヘッドも減りますから転送効率は上がります。反面ブロック(物理レコード)が大きくなると、それだけ転送用のメモリー領域は増えることになります。初期のMVSではメモリーは貴重な資源でしたからやたら大きくすればよいわけではなく、処理内容と資源量のバランスを考えちょうどよい頃合いを見つける必要がありました。現在のMVSでは実記憶もGB単位になり、また仮想メモリーもふんだんに使えるので、そのような気を使う必要はなく、どちらかと言えば大きければ大きい方がよいと言う考え方に変っています。

MVSで扱うレコードにはいくつかの形式が用意されています。また扱える長さにも取り決めがあります。レコード形式はRECFM、ブロック長はBLKSIZE、レコード長はLRECLで示されます。MVSのデータ管理機能ではレコード長、ブロック長いずれも最大32760バイトまでの長さを扱うことができます。物理レコード長の最大値はハードウェアであるDASDの特性に依存し実際にはもっと長いレコードも可能です。例えば3390型DASDであれば56664バイトです。しかしこのような長さをプログラムで直接扱うにはアセンブラー言語で直接デバイスのI/Oを行う必要があります。一般的には32Kが最大値と覚えていいでしょう。

レコードとブロック

レコードとブロック


ブロック化因数の違いによる比較

ブロック化因数の違いによる比較




データセットの種類とアクセスメソッド

MVSのデータセットにはレコードの配列方法によって複数の種類があり、編成(DSORG:Dataset Organization)と呼ばれます。アクセスメソッド(AM:Access Method:アクセス法)はプログラムでデータセットの読み書きを行うためのMVSのプログラミング・インタフェースで、データセット編成に応じたアクセス法がデータ管理によって提供されています。これはアセンブラー言語で使用するためのAPIで、COBOLやPL/Iではファイル定義やファイルアクセス・ステートメントを介して間接的に使用されます。どのような言語でプログラムを作成するにせよ、あるいはプログラム作成には直接携わらないにせよ、データセット編成とアクセス法(の概要)を理解することは、MVSでデータセットを作成し、編集し、操作する上で必要かつ重要です。複数のデータセット編成がありますが、現在でもよく使われる代表的なものに限定して紹介します。

アクセスメソッドはOSのデータ管理に属する機能(API)です。MVSでデータ管理の機能を提供するのが「DFP」(Data Facility Product )と呼ばれるコンポーネントでした。現在ではDFSMSdfpとしてDFSMSに統合されています。MSPとVOS3では「データ管理」です。


Filed in ..基礎編

MVSパフォーマンスチューニング入門

By takao - Last updated: 火曜日, 10月 21, 2008

思想

パフォーマンスチューニングというと、「とにかく早くなるんだろーな」と素人は考えがちです。自宅のパソコンなら早くするためになんでもやれます。オーバークロック、高価なグラフィックカード、早いディスク、等等。
が、仕事でやるパフォーマンスチューニングは違います。まず、「どこまでチューニングすることがゴールなのですか?」をはっきりさせることです。チューニングはボトルネックを発見し、解消に努めます。しかし、ひとつのボトルネックを解消すると次のボトルネックは必ず起きます。それゆえゴールがひつようなのです。
以上を踏まえて、以下の個別要素でボトルネックが起きているかを検討してください。

スケジューリング

汎用機はその名のとおり、汎用ではあります。古(いにしえ)の昔はひとつのプロセッサーで、バッチもオンラインもTSOも動かしており、それらにリソースを絶妙に配分するためにSRMのパラメータをいじるのが偉い、とされていました。プログラミングでもいかにメモリを使わないかでずいぶんトリッキーなことをやっていました。
しかし時代は変わりました。CPU資源は潤沢にあり、メモリーはディスク並みの容量を誇ります。こういう時にスケジューリングとは何を考えるべきでしょうか?基本的な「CPUバウンダリー(いっぱい使う、くらいの意味)」なジョブなのか「I/Oバウンダリー」のジョブなのかの考慮くらいかなぁ、と思います。そのMVSシステムで動かすのは主にどちらだろ?くらいは把握しましょう。
これは大事なことで、I/Oバウンダリーは後述する、I/Oのチューニングで解決しますが、CPUバウンダリーでCPUが100%を振り切るとそれ以上リソースがない、ことは考慮すべきです。
あちこちをチューニングして、100%CPUが使われるようになってしまったら、これ以上の負荷はかけられない、ということです。大きな意味でのジョブのスケジューリングをするしかなくなります。
また、最近、VM,LPARの使用が多いと思いますが、魔法の杖ではありません。システム全体として負荷を考慮するべきであることはいうまでもありません。

DASD I/O

友人のDisk屋がいっていたことですが、「CPU(ナノ単位)を1秒とすれば、Disk(ミリ単位)の返事は1日」それゆえ効果がもっとも出やすいです。しかも汎用機はオープン系と違いチャネルの力により相当なI/Oをこなせます。
とはいえ、ページングと一般のI/Oについてはよく考えたほうがいいです。

ページングはページデータセットの置かれたボリュームにほかのデータへのI/Oがないのであれば、通常のI/Oとは異なる方法がとられます。MVSはCCW(チャネルコマンド)を作りチャネルに実行させますが、必要な処理を行わせた時点でチャネルにストップをかけます。そしてさらにページングが必要な場合、CCWを作りチャネルをスタートします。つまりチャネルからすると無限に続くCCWを実行しているようなイメージになります。しかもページデータセットは4K単位のスロットから構成されているため、データをもってくる場所を計算で割り出せます。それゆえページングは抜群に早いI/Oなのです。10年以上前、私が現役でチューニングをやっていた時ですらVMテストシステムでは一秒間に200ページングしていてもゲストOSユーザーはまったく不満を感じていませんでした。ページングはディスクの場所さえ慎重に考えれば恐れることはないのです。VSAMリニアデータセットなどは、まさにこの動きを利用したファイルシステムです。
ページングの回数よりも、レスポンスタイムを監視しましょう。

通常のI/Oはそこまではいきません。例外なのはDBMSのライトアヘッドログ(トランザクションコミットの度に一時的に書かれるデータセット)で、これらはたいていヘッドの動きを最小限にし、独自のCCWで読み書きするようになっています。ヘッドが動かない分、ミリ秒単位での猛烈な速度で動きます。RAIDであれば、キャッシュをオーバーフローしない範囲でしょうか。

さて、通常のI/Oについて考えるのであれば、レコードフォーマットがどうであれ、転送の単位はブロックですからブロックはできるだけ大きくとったほうが、一度の転送でのデータ量は増えます。昔はトラック上にブロックがどうレイアウトされるかも考えていましたが、RAIDになってから無意味なので気にしなくていいと思います。
ただし、データセットのエクステンションがめちゃくちゃに多く、実はディスクのヘッドが飛び回っているということもありますので、エクステントが多いデータセットは時々「Defrag」じゃなく、アロケーションサイズを見直し、コピーしてあげましょう。(除くDB)

その他のI/O

RMFでI/Oキューの長さは調べておいてください。たとえばコンソールは遅いデバイスです。にもかかわらずコンソールのメッセージがはけないと、MVSは新しい作業を開始しません。めちゃくちゃにメッセージが出力されていて足をひっぱっていることはあります。対策は、EXITやMPFLSTなどによりメッセージを削減することです。

メモリ

これはチューニングするというよりも、現状を把握しておいてください。安直にページ固定していないかを調べておきましょう。ページングは恐れることはないですが、ページ固定をバンバンかけられるとページングが不必要に増えることは、簡単に予測できるでしょう。ボトルネックは以外にこういうところにあります。
なお、一時的に大量にページが要求される状態(フリーのページスロットが極端に減ってしまう場合)に陥った場合、なんとかジョブのスケジュールを変更してください。いくらMVSといえども、リアルメモリーがなくなってしまうとどうしようもありません。

CPU

CPUのチューニングというものは、バッチ処理以外には、あまり意味がないように思います。シスプレックス構成をとって、システム全体でディスパッチを考える場合にはいるときでしょうが、それはすでにこういうチューニング入門を超えた議論になるかと思います。
バッチの場合、長くかかりそうなものはパフォーマンスグループを分けてディスパッチのプライオリティをあらかじめ下げます。理由はターンアラウンドタイムを早くしたいからです。ターンアラウンドタイムというのは、「一定時間に何件処理したか」という考え方です。対する考え方は「スループット」です。これは「とあるジョブがどれくらいの時間で終わったか」です。一般的に長いジョブであればあるほど、1秒はどうでもよくなります。それゆえ、長いジョブには率先してCPUを割り当てる必要はないのです。TSOでもバッチをサブミットするのであれば、パフォーマンスグループは下げておきましょう。

CPUのチューニングについては、むしろ毎月の平均とピークの使用率を監視しましょう。キャパシティの管理をすることはきわめて重要です。

なんとなく、通常時で30%程度、ピークで80%なんていうオープン系ののりで見ていてもいいのではないでしょうか。

サブシステム(IMSとか)

あらかじめいっておきますが、サブシステムのトランザクション処理が遅い場合、OS側でできることは限られます。というのも、各々自分の中でトランザクションのスケジュールを行っているからです。(SUSPEND,RESUMEマクロなんてもんを使いまくってます)用件をまとめてもらわないと、なかなか対処しずらいところです。

これらのことは、RMFがあればできることで、高価な測定ツールは管理職には受けるでしょうが、チューニングにはあまりいらないように思います。
Filed in オペレーション・運用

08.システム管理

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

SMF(System Management Facilities)

MVSの運用においてシステムとジョブに関連するさまざまな情報を収集する機能です。VOS3ではSMSと呼ばれます。システムの運用担当部門は直接のオペレーション業務だけでなく、システムの状況を正しく把握・分析して、より最適なシステムになるよう改良し、ジョブの特性に合わせた運用を行う必要があります。またシステムの利用者に、使用した資源に応じた課金を行うこともあります。これらの仕事をシステム側から支援するのがSMFです。
SMFは主にジョブ及びジョブ・ステップ単位のスケジューリングに関する情報、課金情報、システム資源の利用状況、どのようなデータセットが利用されたかなどの情報も収集されます。

SMFが収集したデータは、SMFデータセットに書き込まれます。データセットに書き込まれるデータをSMFレコードと呼びます。通常SMFデータセットは複数個用意され、1つのデータセットが一杯になると残りの予備データセットに切り替わります。


RMF(Resource Measurement Facility)

SMFはジョブ運用の観点からの情報が中心ですが、システムのチューニングに直結する情報はRMFによって収集されます。MSPではPDL/PDA、VOS3ではSAR/D/ESが相当する機能です。RMFは必要に応じて起動され、システム全体またはジョブ空間毎の、CPU使用量、メモリー使用量、ページング状況、チャネルやデバイスの使用率(BUSY度)やパフォーマンス、資源の競合など、さまざまなシステム資源の活動状況を記録しレポートとして出力します。RMFレポートを分析することによって、パフォーマンスの阻害要因や資源を独占しているジョブを見つけ出すことができます。
しかしながらこれを正確に行うには、MVSも含めメインフレーム・システム全般に関する十分な知識と経験が必要で、運用部門の業務の中でも難易度の高い部類に入ります。

MVSパフォーマンスチューニング入門

SRM(System Resources Manager)

SRMはMVSシステムのパフォーマンス制御を行う機能です。主としてCPU、メモリー(実記憶)、I/Oの3つの資源を、システム内の各ジョブに適切に配分して、各プログラムの応答性を保ちつつ、資源の使用効率を高め全体のスループットを向上させる役割を持ちます。MSPではSDM(System Decision Manager)、VOS3ではRCM(Resource Centralized Manager)と呼ばれ、細かな制御方法に違いはありますがSRM同等の機能です。

SRMの目標は大きく2つです。

しかしこの2つは相反する関係にあります。 1つのジョブを優先すれば他は動けず資源に遊びが生まれ、すべてを平等に扱えば資源を取り合い競合するのでみんなで遅くなります。そこでSRMはお互いに大きな支障にならない程度にバランス良く対処する「妥協点」を見いだします。元々はオペレーターの作業分野ですが、この種の作業は「勘と経験」を頼りにした高度な技能を必要とします。SRMはこれをOS自身で肩代わりするものです。

SRMでは管理の対象を以下のように分けます。

MVSではユーザーの仕事の単位はジョブですが、SRMではこれを「トランザクション」と呼びます。バッチやSTCタスクではジョブ、TSOでは1回のコマンド入力がトランザクションに対応します。IMSやCICSなどオンライン・リアルタイム処理を行うシステムでは、ジョブ全体のサービス制御に加えて、DCシステムのトランザクションをSRMのトランザクションに対応させることもできます。

SRMの活動状況をレポートするのがRMFになります。オペレーターやシステム管理者はRMFのレポートに基づきSRMのパラメーターやWLMのポリシーを調整します。これがMVSのシステム・チューニング作業です。

Filed in ..基礎編

割り込み可能な命令

By takao - Last updated: 日曜日, 10月 19, 2008
なんとなくインストラクションって実行中は割り込みなんか受け付けない気がしてませんか。
それって大間違い。一番いい例がMVC(MoVe Charactor)。とあるメモリからとあるメモリへ転送する命令。
指定するアドレスは当然ながら仮想アドレス。もし、そのアドレスがリアルメモリーになかったらどうなるでしょうか?

はい。もちろんページフォールトという割り込みが起きます。そしてページング処理がガチャガチャっと動いてメモリのアドレスに対応するリアルメモリが用意されてから、命令の残りを続行するぜ、となるわけです。命令の解説をよく見ると乗ってるんですけどね。

一方、この命令の途中で割り込まれたらマルチタスク、マルチスレッドは無理というのがCS(Compare and Swap)。とあるメモリを参照し、その値が自分の期待した内容と同じならば、というふたつの動作が整合性をもつことを保障した命令です。ロック、セマフォ、なんでもいいのですが共有資源を矛盾なく更新するためには必須の命令です。どんなプロセッサアーキテクチャを組んだところでマルチスレッドをやりたいのであれば、必ず同様の命令が必要となります。

普段はどーでもいい話ですが、OSの一部として動くプログラムを書く場合には頭の隅にチラチラしているべき話です。
Filed in MVS実践アセンブラー・プログラミング

09.ネットワーク

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

SNA(Systems Network Architecture )ネットワーク

初期のネットワークシステムにおいてはコンピュータ同様にハードウェアもソフトウェアも個々のシステム毎に設計・開発されていました。IBM社は複雑化する通信処理システムを容易に構築し効率的に運用するために、この分野にもシステムとしての構成や機能に統一した基準を当てはめました。これがSNAです。MSPではFNA、VOS3ではHNAと呼ばれ細かな実装点には違いがありますが、基本的にはSNAと互換があります。
SNAでは通信手順としてのプロトコルだけでなく、ネットワークシステムがどのような要素で構成され、それぞれがどのような役割を果たすかと言ったことまでも含めて体系化されています。SNAではネットワーク内の通信(データリンク層)のプロトコルには主にSDLCが使われます。SDLCはIBM社が開発したもので、後にISO(国際標準化機構)によってHDLCとして標準化されました。FNAやVOS3で使う場合はHDLCになります。

システム内でのVTAMの位置づけ

システム内でのVTAMの位置づけ



TCP/IPネットワーク

SNA(FNA,HNA)による独自のネットワークを構築してきたメインフレームですが、現在ではTCP/IPも標準で実装され幅広く使われています。FTPによるファイル転送、TELNET(TN3270)によるオンライン端末の接続も一般的になりました。メインフレームにおけるTCP/IPのプロトコル・スタックは、リンク層以下はLAN用の通信制御装置*1によって行われ、ネットワーク層以上がMVS内のソフトウェアによって行われます。
*1 MVSではLCS(LAN Channel Station)、OSA(Open System Adapter)、MSPではLANC(LAN Controller)、SURE、VOS3ではLIC(LAN Interface Controller)、ILA(Inter LAN Adapter)が使用される。

メインフレームでのTCPネットワーク

メインフレームでのTCPネットワーク


MVSではCommunications ServerのIP機能によって制御され、IPおよびTCP/UDPプロトコル制御、FTPやTELNETなどのアプリケーションまでも含めて提供されます。(VTAMは同じくCommunications ServerのSNA機能とされているがプログラムはTCPIP,VTAMとしてそれぞれ別のアドレス空間で起動する)MSPではVTAM-G TISP、VOS3ではXNF/TCPが提供されています。いずれもアプリケーション層であるFTPやTELNETまで含まれますが、TISPではFTPサーバーの利用はDTSと言う別製品を必要とします。

TCP/IPに関してはVTAMと異なりAPIも含めMVS,MSP,VOS3の3つには全く互換はありません。もちろんプロトコルは同じですからSNAと異なり相互に接続することは可能です。ただしネットワーク・ソフトウェアとしての実装方法は全く異なっています。特にAPIの互換性は皆無です。
MVSのTCP/IPのAPIは非常にわかりやすく、UNIXのバークレーソケット(BSDソケット)に準拠しています。非ブロッキングI/Oに関しても同様ですが、MVS独自のWAIT/POSTや非同期割込み出口などもサポートされ柔軟で効率の良いプログラミングが可能です。IPv6やRAWソケットなどもサポートされます。そのため他のプラットフォームでのTCP/IPプログラミングの経験があれば、その知識や技法をダイレクトに生かすことができます。
一方TISPはC言語であればSOCKET準拠の関数が利用できますが、COBOLやアセンブラー用のAPIとVOS3のXNF/TCPは全く独自のAPIを持ちます。
また日本特有のことですが、メインフレームでTCP/IPを使う場合の大きな問題の1つが文字コードの違いです。同じMVS同士、MSP同士、VOS3同士であれば問題はありませんが、メインフレームでも異なるメーカー同士や、WindowsやUNIXなど異なるプラットフォーム間との接続では、データ転送時の文字コードは異なります。したがってこのことをよく理解した上でデータの交換を行う必要があります。(FTPのテキスト転送ではメインフレーム側でコード変換を行うのが一般的です)

TCP/IPに関してはIBM社のサイトからわかりやすい解説書が提供されています。特にMVSに特化したものではなく一般的に利用できますから、改めてTCP/IPとはなんだ?と言ったレベルから知りたい方にもお薦めできます。
日本語Redbooksその他:TCP/IP チュートリアルおよび技術解説書(GG88-4005-00)


Filed in ..基礎編

アドレスモードによる分岐命令の動きの違い

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


Filed in システムプログラマーのための手引きいろいろ

10.セキュリティ

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

昨今は非常に重要視されるセキュリティ機能はMVSにも備わっています。MVSではソフトウェアだけで行うもの、ハードウェアの機能も利用して行うものに分かれます。前者はデータの機密保持や情報漏洩およびデータ破壊などの防止、後者はシステム運用の保全性を高める目的で使われます。

ソフトウェアによるセキュリティ

以降はOS自身やメモリー、デバイス資源などをプログラムの誤った動きから破壊されることを防ぐ保全性に関するMVSの機能です。これも一種のセキュリティです。

ハードウェアまたはハードウェア機能を使用したOSによるセキュリティ

Filed in ..基礎編

11.TSOとISPF

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

TSO(Time Sharing Option)

MVSシステムで対話型処理を行うための機能がTSOです。コマンド型のプロセッサーでWindowsにおけるコマンドプロンプト(cmd.exe)と同等の働きをします。もちろんコマンドに互換などありませんが操作方法や機能には共通点が非常に多く、コマンドプロンプトを使える人ならTSOはすぐに使えるようになります。
MSPとVOS3ではTSS(Time Sharing System)と呼ばれますがJCL同様、仕組みも機能も同じです。コマンドも基本的なものはほぼ同じと言ってよく、いずれかのOSでTSOが使えれば相互に応用が利きます。

TSOコマンドプロンプト

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はその前身である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データストリームの詳細などを知る必要はありませんが、端末エミュレーターの開発者やミドルウェアを使わない独自のオンライン・プログラムを作る場合には必要となります。


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)やユーザー作成のダイアログが動きます。

ISPFプライマリーメニュー・パネル

ISPFプライマリーメニュー・パネル


MSPではISPF相当の機能はPFD(Programming Facility for Display users)になります。ISPFのミニセット版のような感じです。VOS3ではプログラム開発機能の部分だけがASPEN(Advanced editor System for Programming ENvironment)として提供されていますが、ISPFやPFDと異なり純粋なプログラム開発ツールで、ユーザーが独自のパネル・プログラムなどを作成することはできません。

パネル方式の利点はWindowsのGUI同様に直感での操作ができる点にあります。面倒なコマンドを覚える必要が減り、メニューをたどって行けば容易に目的の操作を行うことができます。またTMPでは1つのコマンド(プログラム)しか実行できませんが、ISPFはマルチタスクでコマンド・セッションを制御しており、同時に複数のコマンド(プログラム)を実行できます。
そのためプログラムをパネルで編集しながら、コンパイルしてロードモジュールを作成し、それを実行させ出力結果を確認できます。それに基づき直ちにプログラムの誤りを直し、また繰り返すと言ったように関連する処理を並行して行うことができます。このパネルによるデータセットやジョブの操作と、複数の機能やサービスを並行して行えるマルチタスク処理によって、プログラム開発の生産性を大きく向上させています。

Filed in ..基礎編