Xmit Manager(XMITファイルビュワー)

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

Xmit ManagerはMVSではなくWindowsで動作するツール・プログラムです。MVSのTSOコマンドであるXMIT(TRANSMIT)コマンドによって転送可能形式にパッキングされたデータセットの内容を、Windows側で直接表示したり、解凍してPCファイルに変換できます。ホスト上のソースプログラムやJCLなどをまとめてダウンロードしたりする際に便利に使えます。(ただし日本語には対応されていません)
作成されたXMITデータセットをFTPなどでPC側へ転送すれば簡単なバックアップとしても利用できます。その際にデータセットやメンバーの内容をいちいちホストへアップロードし直して解凍することなく、Windows上で見ることができます。

スクリーン・サンプルはこちら。

XMITされたソース(テキスト)データセットのメンバー内容の表示

XMITされたソース(テキスト)データセットの
メンバー内容の表示


XMITされたロードモジュール・データセットのメンバーリスト

XMITされたロードモジュール・データセットのメンバーリスト


ダウンロードはこちらからできます。XmitManager v3

Xmit Manager is a Windows based tool that allows for the manipulation of IBM Mainframe created Xmit format files. With Xmit Manager you can open Xmit files and view or extract the data within them, whether that is binary or text based. Xmit files with Partitioned datasets or Sequential datatsets content can be dealt with similarly through the Graphical Interface.

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

DASDボリューム内にあるデータセットの一覧(VTOCリスト)を出力する(IEHLIST)

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

DASDボリューム内にあるデータセットの一覧(VTOCリスト)を出力する。

プログラム名はMSPではJSGLIST、VOS3ではJSFLISTですが、いずれもIEHLISTの別名が付いているのでMVSと同じ名前でも利用できます。
VTOCリストは3種類のタイプから選択でき、それぞれ標準(短縮)、フォーマット、ダンプの各形式で編集されます。上記SYSIN内のLISTVTOC文の順序もそう並べてあります。どのような名前のデータセットがあるかをとりあえず調べるなら標準(短縮)形式が見やすいでしょう。volumeの箇所に調べたいDASDボリュームのボリューム名を指定します。

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

デバッグのためにコンソールに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 システムプログラマーのための手引きいろいろ