MVCL命令の要約

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

命令実行前のレジスター

転送先のレングス分、転送した時点で命令は終了する。転送先が長い時、余った領域にはPADキャラクターが埋まる。転送先レングスが0の時、何も起こらない。レジスターの内容は変わらない。ただし条件コードは1が設定される。


命令実行後のレジスター


コピー先の長さ ≦ コピー元の長さ の場合


コピー先の長さ > コピー元の長さ の場合



Filed in MVS実践アセンブラー・プログラミング

DFP・31ビットモード・プロセッシング

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

MVSでは当初からQSAM、BSAM、BPAM等によるデータセットのアクセスは24ビットモード・プロセッシングが基本でした。ベーシックなI/OメカニズムはCCWも含めMVS/XAの時点で31ビット化されていましたがQSAMなどのアクセス法レベルではMVSがESAになってDFPがDFSMSに統合された時から31ビットモード・プロセッシングが可能になりました。APIのパラメーター(1部を除く)やデータセットのI/Oバッファが16MBラインの上へ配置できるようになったことはプログラムを作成する上でも恩恵が大きいです。しかしながら従来の24ビットモード・インタフェースではMVSとMSPおよびVOS3にはほぼ完全な互換がありましたが、31ビットモード・インタフェースでは各社各様の仕様になっておりAPIの互換はありません。なおMSPでは31ビットモード・インタフェースはサポートされていません。


DCBの大きさ(QSAM)


拡張DCB(DCBE)の大きさ(QSAM)


QSAMバッファプールの解放

従来はCLOSEマクロの後でFREEPOOLが必要であったが、DCBEでQSAM I/Oバッファを31ビットにする場合はCLOSEルーチン内で自動的に解放されるため不要となった。FREEPOOLマクロはエンハンスされず24ビットモードのバッファしか解放できないため。(DFSMS/MVS Macro Instructions for Data Sets SC26-4913)


サンプルコード

Filed in API、インターナルの違い

DASDレイアウト

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

レイアウト

IBMのDASDは、トラック上はCKD(カウント、キー、データ)という形式で管理されます。

その名前のとおり、Count|key|Data| gap |Count|key|Data| gap という形でデータが並んでいます。
ここでカウントには、「レコード番号、キーがあればキーの長さ、データの長さ」が書き込まれます。

オープン系で使われるディスクはFBA形式といわれ、すべてセクターという概念でトラック上に割り振られています。
CKDの場合、セクターという概念はありません。(もっとローレベルではありますが)ブロック長によりデータ長は可変です。

ディスク全体はシリンダー、ヘッド、レコード(CCHHR)でアドレスされます。



ディスクはスパターとアクチュエータからできていますから、アクチュエータが指す場所はすべて同じヘッドが並んでいます。なので、円筒形が重なったと考えるほうが合理的なのです。この単位をシリンダーといいます。そして、何番目のヘッドかでトラックが確定します。そのトラック上のレコード番号でディスクの場所は決まるのです。3次元にアドレスをもっていると考えるとわかりやすいでしょう。

VTOC

IBMディスクでもっとも重要な場所はシリンダー0、ヘッド0、レコード1です。ここには、ディスクのラベル(Volser)とVTOCの場所が指定されています。汎用機ではVTOCの場所を指定できます。

IPLボリューム

ブートをかけるプロセッサーを指定して、チャネルをリセット”System-Reset”しLoadコマンドを出すと、指定したDASDのシリンダー0、ヘッド0、レコード1からIPLブートれコートを読みます。このブートレコードはあらかじめ、ユーティリティ(ICKDSF)でIEAIPL00というファイルをコピーすることで作られます。つまり、ここにスタンドアローンのプログラムを書き込むと動作します。これを利用したのがスタンドアローンで動作するダンプやdfsmsdssです。
Filed in メインフレーム・ハードウェア

ラージDASD(3390-9型)の空きスペース管理

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

シリンダー数が4370cyl(x1112)以上になると総トラック数が65535(xFFFF)を超えてしまう。このため2バイトのトラックアドレスでは表現できなくなる。IBM 3390-9型、日立6588-9型がこれに当たる(10017cyl)。
DSCB5ではRTAは2バイトのため、このDSCBでは空きスペースを管理できない。

Device Size = 10,017cyl + 3cyl(Alternate)
MVSでOS VTOCにするとスペース管理はDSCB5でなくDSCB7となり、DSCB4のVTOC IndicatorがxA0となる。このVolumeをVOS3と共用してもVOS3からではVTOCエラーとなりアロケーションできない。

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

DASDタイプ別最適化ブロックサイズ

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

DASDにデータセットを作成する際は、トラックに無駄なくレコードを詰めて、デッドスペースがなるべくできないようにする方がよいです。データ管理の扱う最大ブロック長は32760バイトですが、3390型DISKであれば最大トラック長は56664バイトです。大きいブロックの方がよい、と言って32760バイトでブロック長を決めてしまうと、1トラックに1ブロックしか入らないので約24000バイトもの使われない無駄スペースができてしまいます。そうなると本来なら10cylの大きさで済むデータセットが、倍近い16から18cylの大きさを必要としたりすることになってしまいます。

固定長レコードの場合、論理レコード長に応じた最適なブロックサイズと言うものがあります。可変長レコードの場合はDASDの1トラックに2ブロック入れられる最も大きなサイズとなります。MVS(z/OS)の場合、現在では自分で計算しなくても、ブロック長を0としたり省略すればOS側でレコード形式とレコード長に応じた最適なブロックサイズを計算してくれるのでずいぶん便利になりました。しかしMSPとVOS3では今でも自分でサイズを指定する必要がある、ということは変わっていないのでしょう。

ユーザーデータセットではさまざまな長さの論理レコードが使われますが、ソースプログラムやJCL用データセットに使われるLRECL=80、プリントデータ用によく使われるLRECL=121および133について最適なブロックサイズを表にまとめてみました。これら以外の長さの場合、固定長レコードであれば「 27998(または23476) / レコード長 * レコード長 」で計算してみてください。要はレコード長で割り切れるブロックサイズを限りなく27998(または23476)に近づければいいのです。可変長レコードの場合は、レコード長に関係なく27998(または23476)です。なお、最適ブロックサイズを超えたとしても(最大で32760)トラック上にデッドスペースが出来るだけでI/Oエラーにはなりません。










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

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 ..基礎編