区分データセットのメンバーリスト出力(IEHLIST)

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

区分データセットのメンバーリストを出力する。

プログラム名はMSPではJSGLIST、VOS3ではJSFLISTとなるがいずれもIEHLISTの別名が付いているからMVSと同じ名前で利用できる。
FORMATパラメーターで、各メンバーのディレクトリ・エントリーが編集されます。ただしロードモジュール用の編集となります。ロードモジュールでなければFORMATの代わりにDUMPと指定した方が返って見やすいでしょう。volumeの箇所にリストアップするデータセットが格納されているボリューム名を指定します。

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

06.データ管理

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

データセットとファイル

MVSではファイルを「データセット」と呼びます。Windowsでは一部のソフトウェアがファイルを「ドキュメント」と呼びます。しばしば同じ意味で使われますが、この場合のファイルとドキュメントは、データの集合をより人間の操作感覚に近いものとしてドキュメントと表現し、裏付けである記録媒体上(例えばハードディスク)での集合体をファイルとして扱う、として使い分けられたものだと考えることができます。MVSにおけるファイルとデータセットもしばしば同じ意味で使われますが、本来は使い分けられるもので、それを理解することは重要です。

Windowsでマイドキュメントを開いてみてください。その中にはいくつかのファイルが入っているはずです。Wordファイル、Excelファイルあるいは画像のファイル何でもいいのですが、名前が付けられファイルの大きさや種類が示されていますね。MVSにおけるデータセットはそこで表示されている1つ1つのファイルと同じです。つまりディスク上に記録されているデータの集合としての実体です。一方ファイルは実体ではなく論理的なデータの集合体として捉えたもので、プログラムで扱うデータの集合として考えることができます。
データセットに付ける名前がデータセット名です。データセット名は1つまたは複数の修飾子(Qualify)で構成されます。修飾子はセグメントとも呼ばれます。各々の修飾子は1から8文字で、そのうち先頭は英字(AからZ)または国別文字(#@$または\)でなければなりません。残りの7文字は、英字、数字(0から9)、国別文字、またはハイフン(-)のいずれかです。修飾子はピリオド(.)によって連結し、データセット名を構成します。データセット名はすべての修飾子およびピリオドを含めて44文字までを使用することができます。ただし磁気テープ上のデータセットには17文字までの名前しか付けられません。17文字以上の名前を付けた場合は後方の17文字で認識されます。

ファイルとデータセット

ファイルとデータセット


データセット名の構成

データセット名の構成



デバイスとボリューム

データセットはディスクやテープに記録され保存されます。ハードウェアとしてのディスク装置やテープ装置がデバイスです。これらのデバイスには記録媒体が取り付けられ、実際のデータが記録されます。MVSではこの記録媒体をボリュームと呼びます。ボリュームとはデータセットを格納する入れ物(器)と言っていいでしょう。デバイスとボリュームは必ずしも1対1になりません。特にテープ装置で考えるとわかりやすいです。(PCのCD-ROMも同じです。機械の方がデバイスで、記録するメディアとしてのCD-ROMがボリュームに相当します。)

デバイスとボリューム

デバイスとボリューム



カタログ

カタログはデータセット名およびそれが作成された装置の種類とボリューム名(テープであればテープ内の順序番号も含む)を記録しておく機能です。カタログされたデータセットは、DD文にデータセット名とアクセス後の後始末方法だけを指定すればアクセスできます。ユーザーは個々のデータセットが格納されているボリューム名を覚えたり、管理したりする必要がなくなります。MVSはDD文にボリュームの指定がないとカタログを探索してデータセットの場所を求めます。
また、カタログはデータセットを名前で管理するという面も併せ持ちます。これによってデータセットをバックアップする際などに、ボリュームを意識することなく、特定の用途にグループ化されたデータセットを一度にまとめて処理することができます。例えば経理業務のマスターファイルがKEIRI.MASTER.xxxxxxxxのように命名されていれば、KEIRI.MASTERで始まるすべてのデータセットを1度の操作で容易にバックアップを行うことができます。この時バックアップの対象になるデータセットがどのボリュームに格納されているかを意識する必要はありません。またカタログを使用する場合は異なるボリュームであっても同じ名前のデータセットを作成することはできなくなります。そのため同名のデータセットが散在し、どれが最新のものか、どれが正しい内容のものかが不明になるなどと言ったことも起きません。またカタログ自体にセキュリティを掛ければ、規定の命名基準に合っていない名前のデータセットをむやみに作成することを防止することもできます。なおカタログを上手に使うためには使用するデータセット名を正しく階層化することが必要です。

カタログによるデータセットのアクセス

カタログによるデータセットのアクセス



アロケーション

ジョブ・ステップで使用するデータセットは、あらかじめJCLのDD文によって定義されます。MVSはジョブ・ステップの開始時に、定義されたデータセットを探し出し、利用できるように準備します。これがアロケーションで、データセットを資源としてジョブ・ステップに割り当てることです。プログラムから見た場合は、論理的なデータの集合であるファイルを、データの実体であるデータセットに関連付けることになります。

手順が多く面倒に見えますが、MVSではアロケーションの仕組みを採用することによってプログラマーとオペレーターの負担を減らし、スループットを向上させています。
例えば処理の結果をデータセットに出力する場合、対象のデータセットを新たに作成して書き出すのか、既存のデータセットに上書きするのか、追加するのか、同じ出力処理でも何通りもの状況が考えられます。
プログラマーは考え得るすべての状況に対応したロジックを組まねばなりません。データセットがすでに存在していたら上書きするのか最後尾に追加するかを、いずれか一方に固定した処理にするか、あるいはパラメーターなどで選択できるようにするかを考え実装しなければなりません。このようなことは本来アプリケーションとしてのビジネス・ロジックとは直接関係しません。
また運用する側から見ればプログラム側で機能が固定されてしまうと、プログラムに合わせた運用しかできず不便です。プログラムが常に既存のデータセットの先頭から上書きして書き出す仕様になっていれば、追加して書き出したいときには現在のデータセットをバックアップしておき、後でマージしなければなりません。新たなデータセットに書き出したいときには、プログラムの実行前にあらかじめ空のデータセットを作成しなければなりません。このような作業が発生すれば、その分ジョブの実行に手間取り、結果としてシステムのスループットは低下します。
プログラマーが楽をすればオペレーターの負担は増しますし、それを解決するにはプログラミングは制御的な処理で複雑になり負担も増えます。これだけのことを考えてもプログラマー、オペレーター双方に取って負担です。

MVSにおけるアロケーションは、このような問題からプログラマーとオペレーター双方の負担を減らし、柔軟な運用を可能にする仕組みなのです。
※アロケーションの機能はMVSではデータ管理ではなくジョブ管理に属します。便宜上ここで説明しましたが、実際にはデータセットの割り当ては、ジョブで使用する資源として管理されるため、ジョブ管理の仕事となっています。

Filed in ..基礎編

アンカーポインターの持ち方

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

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

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