06.3タスクの生成(ATTACH/DETACHとIDENTIFY)-2

By kamii - Last updated: 火曜日, 9月 7, 2010

ATTACHマクロのEPまたはEPLOCキーワードで指定できるのはロードモジュール・メンバーの名前です。したがってこの点だけで考えるとATTACHできるのはLINKやXCTLのように独立したロードモジュールになっているプログラムになってしまいます。しかしながらタスクを分けるが故にプログラムも分割しなければならないのは不便です。タスク構造とプログラム構造が一対一になっていなければならない決まりはありません。自由度はもっと高いのです。
では静的リンクされた単純構造プログラム(06.1プログラムのローディングと実行(LOAD,LINKとXCTL)を参照)内の別CSECTのプログラムをサブタスクとしてATTACHしたい場合はどうすればいいのでしょうか?
そのためには2つの方法があります。

ATTACHしたいプログラムがCSECTで定義されていれば、バインダーのモジュールをリンクする際にCSECT名メンバーの別名として追加することができます。割り当てた別名をEPあるいはEPLOCキーワードで指定すればATTACHすることができます。

もう1つはIDENTIFYマクロを使い、メインプログラム内で動的に入口点を追加する方法です。LOADマクロなどによって既にメモリー内にローディングされたモジュール内(EXEC文のPGMパラメーターで指定されたメインプログラムも含む)であれば任意のアドレスを入口点として追加できます。


入口点の追加(IDENTIFY)


バッチ・ユーティリティーの呼び出しにATTACHを使う

Filed in 中級編

06.3タスクの生成(ATTACH/DETACHとIDENTIFY)-1

By kamii - Last updated: 火曜日, 9月 7, 2010

MVS(z/OS)はマルチタスクのオペレーティング・システムです。一般のアプリケーションでも複数のタスクに処理を振り分けることで、より実行効率のよいプログラム構造を持つこともできます。同時に複数のイベント(処理要求)が発生したり、非同期に発生するイベントを処理するプログラムではタスクを分割するプログラムデザインは珍しいものではありません。しかしバッチ処理でのマルチタスク構造のプログラムはまれで、通常はオンライン処理プログラムなど、サーバー的な機能を持つプログラムにおいて主に採用されます。


どういう時にマルチタスクを使うか


タスクの生成と実行(ATTACH)および消去(DETACH)

ATTACHされたタスク(子タスク)のプログラムとATTACHしたタスク(親タスク)のプログラムは非同期に動きます。異なるタスクのプログラム間でデータの受け渡したり、処理の整合性を正しく取るためには、タイミング合わせや排他制御などのコントロールが必要になります。これらはWAIT/POST、ENQ/DEQ(あるいはCS/CDSなどの逐次化命令)などを利用することで可能です。

Filed in 中級編

お手軽バッチ・パフォーマンス改善 – IX

By kamii - Last updated: 水曜日, 9月 1, 2010

データセットのI/O効率を上げる(続き)


以上、数回にわたり「バッチ処理のパフォーマンスを改善する」ということでまとめてみました。チューニングに関しては、いろいろな方法があるのですが、既存のリソースの中で行う、お金も掛けない、むずかしいチューニングの知識もいらない、運用への悪影響もほとんどない、大がかりな作業をせずに実現できる(PARMLIBを直すのもできれば避けたい)、という観点で紹介しました。他にもいい方法があればぜひご意見をお寄せ下さい。

Filed in オペレーション・運用

お手軽バッチ・パフォーマンス改善 – VIII

By kamii - Last updated: 月曜日, 8月 23, 2010

データセットのI/O効率を上げる(続き)


Filed in オペレーション・運用

お手軽バッチ・パフォーマンス改善 – VII

By kamii - Last updated: 火曜日, 8月 17, 2010

データセットのI/O効率を上げる(続き)


Filed in オペレーション・運用

DFSMSの保証スペース

By kamii - Last updated: 火曜日, 8月 17, 2010

数千シリンダーを超えるような大きなデータセットを作成する場合、複数のボリュームに分散して割り当てることができます。マルチボリューム・データセットなどと呼ばれ、古くから利用されてきました。

データセットを最大3つのボリュームに分散して作成します。最初に割り振られるスペースはボリュームDATA01に3000シリンダーです。DATA01に3000シリンダーを満たす空きスペースがなければ、最初の割り振りに失敗します。最初の割り振りに成功した後、3000シリンダーを使い切ると、OSは同じボリュームに1000シリンダー分の2次量で追加の割り振りを試みます。ボリュームに空きがなければDATA02、そこも空きがなければDATA03と順に最大3ボリュームにまたがってスペースが割り振られていきます。

これが基本的なデータセット・スペースの拡張メカニズムですが、使う側から見ると問題がないわけではありません。確実にスペースが割り振られるのは最初の3000シリンダーだけです。たとえ2次量を指定して、複数のボリュームにまたがってもかまわないことを指定していても、2次スペース量の拡張時に指定されたボリュームに空きがなければ追加の割り振りはできません。その結果スペース不足でジョブはABENDしてしまいます。

このような問題を回避するためDFSMSには保証スペース(Guaranteed Space)という機能があります。SMSのストレージクラスにGuaranteed Space=Yesの属性を与えれば、指定されたすべてのボリュームに1次量を割り振ります。

データセットは指定されたすべてのボリューム(DATA01,DATA02,DATA03)に1次量である3000シリンダーが割り振られ、最初に作成した時点で3000シリンダー×3ボリュームで9000シリンダーのスペース量が確保されます。2次量が指定されていれば最初のボリュームの1次スペースが一杯になると同じボリューム内で可能なだけの2次スペース量拡張が行われ、それをすべて使い切ってから、2番目のボリュームのすでに割り振り済みの1次スペースが使われます。絶対に必要としたいスペース量を事前に割り振ることができるため、運用中にスペース不足でジョブがABENDすることを防げます。保証スペースは、指定した1次量を複数のボリュームに分散するのではありません(例えば1000cylを250cylずつ4ボリュームに割り振る)、また指定した1次量が最初のボリュームでまかないきれず不足分を次のボリュームに割り当てるものでもありません(例えば1000cylのうち、最初のボリュームに800cyl、2番目のボリュームに200cylを割り振る)。VOLパラメーターで指定されたすべてのボリュームにSPACEパラメーターで指定された1次量を割り振ります。したがってその仕組みを考慮して1次量を指定します。例えば全部で5000シリンダーが必要で、5つのボリュームが使えるなら1次量は1000cylとします。指定されたボリュームのうち、1つでも1次量を満たす空きスペースがなければデータセットは作成されません。



なおラージ・データセットを作成し、かつそのスペース割り振りを保証するには、保証スペース機能の他にも3390-9型以上の大容量ボリュームに単一エクステントのデータセットとして作成する方法もあります。一般のデータセットでは1つのボリュームに割り当てることができるエクステント(ボリューム内でデータセットに割り当てられる連続した領域)は最大65535トラックに制限されますが、拡張形式の順次データセットやVSAMデータセットはこれを超える容量のデータセット・エクステントを割り当てることができます。拡張形式のPSデータセットなら、30000シリンダーという巨大なデータセットでも単一エクステントで割り振ることができます。


保証スペースやラージ・エクステントに関する詳細はマニュアル「z/OS DFSMS データ・セットの使用法」に解説されています。

Filed in アドミニストレーター編

FTP

By kamii - Last updated: 月曜日, 8月 16, 2010

FTP:ファイル転送プログラム(File Transfer Program)


FTPそのものが何であるかを解説する必要はないでしょう。メインフレームでもTCP/IPがサポートされてから、FTPもTCPアプリケーション(ユーティリティー)として利用できるようになっています。以前はFTPの利用を嫌うユーザーも多く「TCPは使えますがFTPは禁止です」というところもありました。最近ではどうなのでしょうか?以前ほどFTPは使わせない、というところは少ないように思います。


FTPにはクライアントとサーバーの2種類がありますが、いずれも利用できます。ただしMSPではFTPサーバーの利用にはDTSというPPが別に導入されている必要がありました(もしかしたら今ではTISP単独で利用可能になっているかも知れません)。
メインフレームと言えばサーバー・コンピューターでもありますから、FTPもサーバーで使うもの、と思われがちですが決してそんなことはありません。むしろFTPはクライアントで使う方がバッチジョブのステップに組み込めますから、自動的なデータ転送処理を行いたいときなどに便利です。


FTPサーバーは、PC上のファイル(例えばJCLやソースプログラム、業務処理用のデータ制御ファイルなど)を区分データセットのメンバーや順次データセットとして送りたい場合によく使われます。基本的には利用者が使いたいときに起動するものではなく、システムのIPL後に常駐タスク(アドレス空間)として起動されます。z/OSではTCPIPサービスの起動時に、FTPデーモンプロセスがUSS(Unix System Service)を使ってアクティブになります。いずれにせよFTPサーバーに関しては利用者の好みに合わせて機能を選択したり設定を変えたりはできません。システム管理者がセンター環境に合わせて設定した範囲での利用になります。
メインフレームのFTPサーバーを利用するクライアントは同じメインフレームに限らず、Unix、WindowsなどTCPをサポートしたプラットフォームであればかまいません。


データセットとファイルパス

z/OSのHFSでなければ、MVSではUnixやWindowsのような階層ファイルシステムではありません。しかしFTPにおけるファイル名は階層を意識したファイルパスでの指定になっています。例えばMVS(z/OS)のTCPIPのFTPでは、D:/folder1/subfolder2/JCLCOPY.txt のようなファイルパスとファイル名は、UAP1/JCLLIB/JCLCOPY のようにデータセットの修飾子で区切られたファイルパスとして表現されます。データセット名は修飾子で区切られた階層によって構成されているので、それを階層ファイルシステムのパス名のように割り当てます。データセット名の各修飾子をフォルダー名のように扱うわけです。そのためデータセットはカタログされていることが前提です。ディレクトリパスUAP1/JCLLIB、ファイル名JCLCOPY は UAP1.JCLLIB.JCLCOPY という順次データセットか、UAP1.JCLLIB という区分データセットのメンバーJCLCOPY を示します。
このようにDSNの修飾子をディレクトリに置き換えて対応させるマッピング方法を知ることは、LSコマンドなどディレクトリ内のファイル一覧を表示させたい場合に役立ちます。初期ディレクトリはFTPサーバーにログインした際のアカウント名(TSOユーザーID)です。USERID=RTJ6638でログインした場合、ログイン後に LS コマンドを入れると修飾子 RTJ6638 で始まるDSNがリストされます。その状態で CD TEST と入力すればカレントディレクトリは RTJ6638.TEST に変わり、LSコマンドを入れると修飾子 RTJ6638.TEST で始まるDSNがリストされます。先頭修飾子を UAP1 に変えたければ CD ‘UAP1’ と入力します。
しかしGETやPUTで転送の対象となるデータセットが予めわかっているなら、最終修飾子やメンバー名がファイル名になるよう階層を掘り下げなくても、’RTJ6638.TEST.DATA1′ や ‘RTJ6638.JCL(IEBCOPY)’ のようにDSNをアポストロフィで囲めば、メインフレームのデータセット名の形式で指定することもできます。各メーカーが提供するFTPソフトウェアの仕様によって細かな点は異なるので必要に応じてマニュアルなどを参照して下さい。


FTPによっては、DD名をサポートしている場合もあります。例えばz/OSでは、メインフレーム側のファイル名として、//DD:ddname が指定できます。これはJCLにDD名ddnameで定義されているDDステートメントに定義されたデータセットを示します。この場合、ターゲットのデータセットはカタログされていなくてもかまいません。UNITとVOL=SERパラメーターでデータセットの場所を特定することができます。VOS3のXTCPでは、DD(ddname) と指定します。また INTRDR はJESのリーダーを示し、転送したファイルをJCLとしてサブミットする場合に使われます(z/OSでは事前にSITEコマンドが必要)。なおDD名指定のファイル転送はFTPクライアントで使用されます。


文字コードの変換

異なる文字コードを持つプラットフォーム間の転送では、文字コードの変換が必要です。送り手、受けてどちらが変換するかは考え方がいろいろあります。「受け手が自分と違うコードなら変換する」という仕様なら同じ文字コードであれば変換が不要なのですっきりするとか、サーバーとクライアントならサーバー側でやるべき、とかです。しかし現実メインフレームの場合は、送り手だろうが受け手だろうが、メインフレームが他と異なる特有の世界のコードを使っているのが実情なので、クライアントであってもメインフレーム側のFTPで文字コードを変換するのが一般的です。メインフレームのFTPでは単にECBDICとASCIIの変換だけでなく、日本語コードをShiftJISやEUCなど相手側ホストの文字コードに合わせて変換できます。z/OSのFTPであれば、シフトコードの位置に擬似コード(文字→や←)を入れてそこにシフトコードがあることを示したり、バイナリー転送時に可変長レコードのデータセットのRDWを付加して元のレコードが何バイトなのかを識別できるようにしたり、などきめ細かなコード変換機能を持っています。


FTPの使用サンプルはこちらのページに記載しています。


Filed in キーワードから(何が知りたいですか)

お手軽バッチ・パフォーマンス改善 – VI

By kamii - Last updated: 木曜日, 8月 12, 2010

データセットのI/O効率を上げる(続き)

Filed in オペレーション・運用

お手軽バッチ・パフォーマンス改善 – V

By kamii - Last updated: 木曜日, 8月 5, 2010

データセットのI/O効率を上げる(続き)

Filed in オペレーション・運用

米国IBMの公式入門書?

By kamii - Last updated: 木曜日, 8月 5, 2010

USのIBM WebサイトからはRedbookという解説書を得ることができます。その中からメジャーな製品の入門書的なものを以下に紹介します。このサイト(IBM Redbooks)には数千冊ものredbookが登録されています。タイトルの一部をキーワードで検索することもできますから必要とするものが見つかるかも知れません。すべて英文になりますが、どれも有益な資料です。






Introduction to the New Mainframe:
z/OS Basics
z/OSおよびOSと共に利用されている代表的なミドルウェアについての概説書。
Introduction to the New Mainframe:
z/VM Basics
z/VMについての概説書。
IMS PrimerIMS入門書。
MQSeries PrimerMQ入門書。
DFSMShsm PrimerDFSMShsm入門書(DFSMSの階層ストレージ管理:データセットのマイグレート/リコール)。
DFSMSrmm PrimerDFSMSrmm入門書(DFSMSのリムーバブルメディア管理:テープや仮想テープボリュームの管理)。
VSAM DemystifiedVSAMの内部構造や仕組みを解説したもの。入門書の域を超えているがアプリケーションプログラマーにとってもVSAMのファイル設計などにも役立つ内容が載っている。

 




Filed in メインフレーム情報