ICKDSF

By kamii - Last updated: 火曜日, 6月 23, 2009

ICKDSF:DASDの初期化などを行うユーティリティ・プログラム(DSFはDevice Support Facilitiesの略)

ICKDSFユーティリティを検索している人は比較的多いようです。特に「マニュアル」「manual」のキーワードを組み合わせられることがほとんどです。何故かICKDSFのマニュアルは日本語化されていません。そんなにしょっちゅう使うものではないからでしょうか...
英語だけどマニュアルを見てくれ、では記事にならないので、3つの基本パターンのサンプルを紹介します。サンプル以上に詳しいことや、別の使い方については、やはりマニュアルを見てください。
また、ICKDSFは別のカテゴリーでもサンプルを載せているので併せてご覧下さい。==>ここ



ボリュームだけいじっても、カタログは連動して変わらないことは知っておく必要があります。大量のデータセットを消すのに、楽そうだから、なんて安易な理由でボリュームのイニシャライズをやると泣きを見ます。
しかしDASDがハード障害になったのでワークをつぶしてバックアップから戻す、普段はオフラインになっている予備のボリュームを臨時に使う、などボリュームのイニシャライズは、そうしょっちゅうではなくとも必要になる場合がありますから、運用担当者なら1番目のサンプルぐらいは持ってるといいと思います。

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

.検索上位キーワード

By kamii - Last updated: 火曜日, 6月 23, 2009
一昨年の8月からこのサイトを始めて2年近くが経ちました。おかげさまで最近では平日は500から600名ほどの方々が訪れてくれています。それぞれの方々はプログラムの設計や開発、システムの運用、保守管理などなど、さまざまな仕事についておられることと思います。当初はこれほどメインフレーム・コンピュータ・システムに関する技術情報を求める人々が多いとは思ってもいませんでした。また意外なほどベーシックな情報が探されていることもわかりました。何だかんだ言われても、新しくメインフレームに携わらねばならない人々は、世間が言うほど少なくないのでしょう。

このカテゴリーでは、「メインフレーム・コンピュータ」で遊ぼう、に訪れた人々がどのようなキーワードによって検索した結果、ここにたどりついたのかを、検索に使われたキーワードからピックアップして行きます。
みなさんが知りたいこと、調べたいことについて答えて行ければいいのですが、私たちもすべてのことを知っているわけではありません。何について載せるかは検索件数の多い、上位のキーワードから選びますが、答えをほどほどの量で一回でまとめられるものに限定します。なので、いつまで経ってもここに載らない場合は、
ということでご容赦下さい。
Filed in キーワードから(何が知りたいですか)

バッチでSDSFを実行する

By kamii - Last updated: 木曜日, 5月 21, 2009

ISPF同様、SDSFもバッチで利用することができます。
DAパネルで表示されるジョブ一覧は、簡易版としてRMFモニターⅡの代わりにすることもできますし、特定のジョブのSYSOUT内容をバックグラウンドでコピーしたりできます。XWTRではSYSOUTはスプールからパージされてしまうので、MOVEではなくCOPYで処理したい時などは役に立ちます。


バッチSDSFの基本的なJCL


ジョブのSYSOUTを順次編成データセットにコピーする


しかし同じことがあなたのユーザーIDで、TSO/ISPFではできても、バッチでは上手く行かないかも知れません。もしPRE *コマンドがNOT AUTHORIZEDになったり、自ユーザーIDで始まるジョブしか選択できないなら、ISFPARMSをバッチ用にカスタマイズしてトライしてみます。


バッチSDSF用ISFPARMSを作る





カスタマイズしたISFPARMSモジュールを使ったバッチSDSFのJCL

Filed in ISPFとSDSFのちょっと得する使い方

MVSパフォーマンスチューニング概略

By takao - Last updated: 火曜日, 4月 21, 2009
オープン系がポピュラーになる以前の汎用機では、開発、バッチ、オンラインなどを一台で処理していました。

それゆえ、違う特性のジョブを「うまく組み合わせる」といったことが重要な技術でした。メインフレームのとても細かいディスパッチのプライオリティなどに、その名残りを見ることができます。しかし、現在のメインフレームにおいて、パフォーマンスチューニングは考え方はオープン系と、そう変わりません。

チューニングのゴール

さてチューニングは、なぜ行うのでしょうか?そこには必ず不満があるはずです。多くの場合「どうも遅い」という感覚的な議論からスタートします。この感覚を数値化することがチューニングの最初にするべきことです。
個人所有のパソコンと比較すると理由がわかると思います。新しいグラフィックボードが出たから、即購入してどれくらいの速度になるか確認する、その速度がパフォーマンス、というようなことは個人だからできることです。企業では必ず「投資と効果」というものを問われます。「早ければいい」と数十億円をつっこんでいいという恵まれた環境は通常は夢だと考えていいでしょう。
そうすると、「どこまで早ければいいのか?」というゴールが必要です。このゴールを設定しない限り、チューニング作業にはかかれない、ということを理解しましょう。具体的にはバッチ群が4時間以内に終わること、とか、IMSトランザクションの端末レスポンスタイムが2秒以内であること、などになるかと思います。

データ収集

これはいきなり、メモリーだ、CPUだ、というのではなく、作業システム全体から考えることが必須です。例えば他社からのテープが午後5時に到着し、それから6時間で終わればいいジョブなのに、いつも8時にならないと届かない、それゆえジョブスケジュールが狂っている、といったこともあり得ます。担当の人から、ボトルネックが自明のことであっても説明がなされていなければ、後々、予算化の段階で説得力をもたないのです。「システム」とは、作業をふくめたビジネスサイクルのことをいいます。
メインフレームの場合、コンピュータシステムのデータの収集は比較的ラクです。ログ、統計データを出力しないソフトウェアのほうが稀です。基本的には、RMF、Tivoli Decision SupportやOMEGAMONなどを使うことでしょう。

分析

次に原因調査にかかるわけですが、最初に見つけるべきことは「クリティカルなリソースはどこだ?」ということです。通常、ボトルネックの発見といわれています。ボトルネックとは、ハードウェアまたはソフトウェアの一部が能力の限界に近づき、システム全体の「足をひっぱっている」状態です。
たとえばボトルネックは多くの場合、非常に使用率が高いはずです。ただ、注意しなくてはいけないことは、「使用率が高いからボトルネックである」は真ではないことです。当たり前の例ですが、キャッシュのヒット率が高い、ということはボトルネックではありませんね。因果関係を意識しながらデータの収集が必要となります。
それゆえデータ収集したレポートは、OS,IMS,DB2などの専門家が見ないと意味を見誤ることがありますし、話し合いによりシステムの動作を把握できていることを理解することが必要です。

ひとつ注意点があります。オープン系の常識をメインフレームに持ち込まないことです。例えば、オープン系ではページングはあまり起きないように設定します。(ページスペースもせいぜい、リアルメモリの2倍くらいしか用意しないでしょう。)しかし、メインフレームはI/Oが強力であるため、秒100件程度のページングでかまわない場合もあります。

対処

一般的なコンピュータシステムの場合、最終的なボトルネックはCPUとなることが多いです。なぜならば、すべてのスケジュールもI/Oも問題ない場合、最終的には処理能力の問題となるからです。

あいにくCPU処理の大半はOSとDBMS(データベースマネージメントシステム)が消費します。そのため、一般的には 最大CPU使用率:90%以上が限界、といった一般的指標を目安とします。

とはいえ、各サブコンポーネント毎に対処が取られることもあるでしょうし、メモリー不足からリアルメモリーの購入が必要になることもあるかも知れません。
忘れてはいけないのは、リソースを追加することで、ゴールに近づけるか、達成できるか、といった観点からレビューすることです。技術的にはついつい、「こうしたら、もっと早くなるんじゃないの?」と思いがちですが、変更点をいくつも作ってしまうと、後のレビューサイクルがやりにくくなります。
一番わかりやすいのは、構成変更を一度にひとつだけにすることです。これだと評価しやすいです。

テスト/評価

構成を変更した以上、サイドエフェクト(影響)がないか調べること、思ったとおりの効果をあげているか監視することが大事です。
期待したゴールにパフォーマンスが向上すれば、チューニングサイクルは一段落です。しない場合は、次の可能性をテストすることになります。

チューニングサイクルはこれで終わりではありません。「システムは生き物」とよく言います。少しずつ変化していきます。パフォーマンスデータを定期的に集計しておき、トレンドを見ることがもっとも有効なチューニング、キャパシティプランニングに繋がる道です。
Filed in オペレーション・運用

ヘラクレス(Hercules)導入について

By takao - Last updated: 火曜日, 4月 14, 2009
導入について、使うリソースや速度についての参考のために、以下のFAQの一部を訳してみました。英語を読むのが面倒な人のための利便のために訳してあるので、訳が信用できない人、細かい点が気になる人は原文を参照されることを強くお勧めします。

http://www.hercules-390.eu/hercfaq.html#3.01

3.01 Herculesを走らせるために必要なPCハードウェアはなんですか?

伝統的なIBMオペレーティングシステム(OS/360,MVS3.8,VM/370)は現在の標準的なハードウェアからすれば、非常に軽いものです。32MB RAMと300MHzのペンティアムでも十分な速度がでます。

現在のもの、例えばLinux/390,OS/390などはより多くのプロセッサーパワーが必要です。
ヘラクレスはCPUを多く使います。それゆえ快適にしたいのであれば、速いプロセッサーが入手できればそのほうがいいのです。できればハイパースレッディングのついた、2GHzのペンティアムは、軽い負荷ならば許容できるパフォーマンスで動くでしょう。もし、マルチプロセッサーシステムをお持ちならば、より速く動きます。ヘラクレスはマルチスレッディングを積極的に使い、CPUとI/Oをオーバーラップさせ、平行してCPUのディスパッチをエミュレートしようとします。

最新のzLinuxやz/OSなど64ビットオペレーティングシステムを、ペンティアムのような32ビットプロセッサでz/アーキテクチャマシンでエミュレートしようとした時は、パフォーマンスは下がります。64ビットを走らせるためのパフォーマンス低下が深刻な問題であるならば、64ビットプロセッサー用、例えばAlpha,AMD64,IA64など、でビルドすることです。同様なものは64ビットバージョンLinuxやOSXでのPowerPCにもいえます。

ヘラクレスはペンティアムのアーキテクチャに依存していません。私はAlpha 21164 500MHzでビルドし、走らせることに成功しています。同様に、SPARC上でS/390 Linuxを走らせたこともあります。とある人はVM/ESA下のLinux/390下のヘラクレスの下のLinux/390の下のヘラクレスの下でOS/360を走らせたこともあります。Ivan Warrenはもっとも小さいメインフレーマーの称号をもつでしょうけれども、PDA iPAQ5450上でヘラクレスを走らせVM/370を動かしました。

S/390リアルストレージ(メインストレージ+拡張ストレージ)のために十分なRAMを与える必要があります。あと、普通のPCのOSのためにも必要です。スループットを最大化するには、S/390のページングが起きないくらいの十分なメインストレージ、拡張ストレージをアサインするべきです。

もし、DASDをエミュレートするならば十分なディスクスペースが必要です。仮想”3330- model 1″は100MB必要です。(3330-11ならば約200MB)。3380″単密”モデルならば650MB、3390-model2ならば2GB。3390 model 3ならば、約3GBです。もし、”CKD DASD 圧縮機能”を使うのであれば、サイズは劇的に小さくなります。オリジナルの20~30%だと思えばいいでしょう。

3.02 MIPS(Million Instructions Per Second)をどれくらい期待できますか?
多くのプログラマー(名称略)のおかげで、5年前よりもヘラクレスは、はるかに速くなりました。
Celeron 3001,2Mipsの速度で実行できるでしょう。この速度はOS/360(MFT,MVT)やMVS3.8において1970年代の3033プロセッサーよりはいいパフォーマンスが期待できます。VSE/ESAでも十分な速度を得られます。より新しい2GHzのペンティアムならば30MIPS程度は期待できます。これはLinux/390やz/OSに軽い負荷をかけた状態ならば十分な速度です。

サーバークラスのマシンのパフォーマンスは素晴らしいものです。3.46GHz デュアルコアのIntel Xeon ハイパースレディング付(4CPU)ならば、40から60MIPSが期待できます。デュアルプロセッサー クアッドコアのMac Pro(8コア、3GHz)なら150MIPSを超えるでしょう。ある人がIntel Core i7を3.75GHz、4コアプラスハイパースレッディング(8 CPU)で300MIPS以上を記録したそうです。

典型的なI/Oは秒当たり50EXCP/秒くらいです。ハードウェアRAIDの場合は、500/秒くらいまで出せた例もあるようです。

3.03 ヘラクレスを動かすために必要なPCソフト

Windows 98, Windows NT, Windows 2000, or Windows XP with Cygwin
Windows 98, Windows NT, Windows 2000, or Windows XP (without Cygwin)
Mac OS X 10.3 or later
Solaris 2.9 or later (Sparc or Intel)
FreeBSD

仮想3270コンソールのために3270クライアントソフトゥエアが必要です。3270ターミナルはヘラクレスと同じマシン上で問題ありません。もしくは、UnixやWindowsからTCP/IPでヘラクレスマシンと接続します。

ヘラクレスでお勧めしている3270ターミナルは

x3270 for Unix
x3270はほとんどのLinuxのディストリビューションに入ってます。
http://x3270.bgp.nu/

Vista tn3270 for Windows
http://www.tombrennansoftware.com. にあります。機能の割りに安い3270エミュレータです。

Brown University tn3270 for Macintosh
Brown University tn3270はフリーです。
http://www.brown.edu/Facilities/CIS/tn3270/.
MVS3.8とつなぐ時は設定を変える必要があります。ヘラクレスとの接続を啓き、システムをIPLする前に、Session->Featuresメニューで”Change embedded nulls to blanks”をNoに変更してください。 そして、File -> Save default Settingします。

他にもQWS3270, IBM Personal Communications, Attahemte Extra, Dynamcomm Eliteなども動作が確認されています。ただ、ものによってはバグがあり、OS/360のmvsコンソールではうまく動かないものもあります。
Filed in メインフレーム・エミュレーター

04.3複数行メッセージの出力

By kamii - Last updated: 水曜日, 4月 8, 2009

コンソールにメッセージを出すために、WTOマクロを使うことはすでに説明しました。一般には1つのメッセージが1つのWTOマクロによって出力されますが、オペレータ・コマンドの処理結果など、プログラムの処理結果を複数のメッセージで構成して出力したいこともよくあります。出したいメッセージが10行分あるなら、テキスト内容を変えてWTOマクロを10回出せば実現できます。しかしこの方法では、コンソール上の個々のメッセージの間に他のジョブのメッセージが割り込んで表示されてしまう場合もあります。これを防ぐためには1つのWTOで複数のメッセージを出すか、メッセージ毎にWTOを発行するものの、連続したメッセージ群であることをOSに示すことで、間に他のジョブのメッセージを割り込ませないようにします。
OSのディスプレイコマンドの表示結果のようなメッセージ出力を行う場合は複数行メッセージのためのWTO機能を利用します。予め出力するメッセージ行数が決まっているなら前者、処理の内容によって行数が可変になるような場合は後者の方法を使うといいでしょう。ただしコネクティングWTOと呼ばれる後者の方法ではプログラムはAPF許可されていなければなりません(VOS3の場合はさらにスーパーバイザーモードでなければなりません)。


一度に複数のメッセージをコンソールに出力する

最初の例は複数行WTOマクロの古典的なコーディングです。MSPとVOS3もこの書き方になります。1つのWTOで複数のメッセージをコンソールに出力できます。リスト形式のWTOマクロを組み合わせてますので、メッセージテキストはプログラムで修正することができます。長さは増やせないので、予め空白を埋めるなりして必要な最大長で定義しておきます。2番目はMVS(z/OS)で利用可能なメッセージ・テキストをマクロの外に記述する方法です。

※わかりにくいバグの例:
最初の例で、リスト形式のWTOマクロを以下のように書くとWTOは失敗することがあります。

実行形式のWTOマクロではラベル名CMDRESLTを指定しますが、CMDRESLTはDS 0Hによってハーフワード境界に調整されます。しかし続くMF=L指定のWTOマクロの展開内でパラメーターリストの先頭がフルワード境界に調整されるため、ラベル名の位置と実際のWTOパラメーターが場合によっては2バイトずれてしまいます。ずれた場合は正しいパラメーターリストを指さなくなるので、実行形式のWTOマクロは失敗します。マクロそのものの使い方は誤っていないため、デバッグしてもなかなか原因が掴めません。実際の復帰コードは4となりますが、マニュアルでは行数が0あるいはメッセージ長が0などと説明されており、実際のコーディングと合わないため、「なんで??」となってしまいます。
一般に機械命令はDS 0Hで境界調整するのでついこのようなラベルをコーディングしがちですが、マクロ命令の多く(特にリスト形式)はフルワード境界に調整されますから、知っておくといいでしょう。わかってしまえばつまらない原因のバグですが、わかりにくい例でもあります。


複数のメッセージを連結してコンソールに出力する(OS/390,z/OS)

通常のWTO同様に1つのWTOで1つのメッセージを出力するものの、各々のメッセージはひとまとまりの複数行メッセージとして扱われる、コネクティングWTOです。AREAIDパラメーターでコンソール上の表示域を指定できます。サンプルでは一般メッセージが表示されるスクロール領域を出力するため、’Z’を指定していますが、OSのディスプレイコマンド同様に表示域(K Aコマンドで設定するAREA域)に出力する場合は’A’を指定し、DESCコードに最低でも(8,9)を指定します。表示域(AREA=A)に出力すればメッセージのスクロールはK D,Fコマンドで制御できるようになります。制御行(C)およびラベル行(L)はスクロールされないので、固定表示させたいタイトルや見出しに利用できます。なおAPF許可されていないプログラムでコネクティングWTOを使うと、2回目以降の連結されたWTOはSD23でABENDします。
サンプルのコーディングはMVS(z/OS)でのみ有効です。


複数のメッセージを連結してコンソールに出力する(MSP,VOS3)

コネクティングWTOの古典的コーディング方法です。MSPおよびVOS3でも利用できます。サンプルでは省略していますが、行タイプがCであれば35文字、LまたはDであれば71文字が行あたりの最大文字数になりますので、それを超えたテキストは35ないしは71文字までしかパラメーター・リスト内にMOVEしないようなチェックを入れて、後続の制御フィールドを壊さないようにしなければなりません。

システム・プログラムの場合であれば、コネクティングWTOの方が応用範囲が広いので便利です。行数が固定された場合でも、処理内容やデータによって行数が変わる場合でも、どちらでも対応できます。なおコネクティングWTOを使う場合、出力する上限の行数を決めて、それを超えたらデータ行の出力を打ち切るべきです。例えば多くても100行しか出さないなど。ひとつのプログラムで大量のコネクティングWTOを使うと、コンソール資源を占有してしまいますし、万一WTO出力を伴うループを起こしてしまったら、コンソールバッファは、あっという間に枯渇してしまいます。要所要所にフェイルセーフとなるようなチェック処理を入れるのはシステム・プログラミングの基本でもあります。なお実際の処理結果が大量にあるような場合は、コンソール出力は途中で打ち切るが、SYSOUTなどのログリスト上には全データを出力するようなデザインをすればよいでしょう。

Filed in 中級編

データセンターの移設

By takao - Last updated: 火曜日, 4月 7, 2009
データセンターの移設については、次の3とおりが考えられるか、と思います。

A. 物理的に引っ越す
B. ディザスターリカバリーの拠点とする
C. 役割をかえる

順々に議論を加えてみたいと思います。

A. 物理的な引越し

いつサイトを閉じて、いつ再開するか、が鍵となります。メインフレームの場合、結線をはずして梱包し、移設して、開梱し、再結線するのは、ほとんど専門業者の担当になるかと思います。
が、ストレージ・システムだけはベンダーと意見があわないことがあります。3380,3390といった古いタイプのディスクの場合、ヘッドを固定すればよいでしょう。
それ以降のモデルは内部的には、3.5inch HDDが使われていることがほとんどかと思います。ところが電源がオフになった状態でヘッドがきちんとシッピング・ゾーンに格納されるのが現在のディスクですが、古いモデルは必ずしもそうではありません。
そのため、ベンダーとしてはRAIDシステムから全部のHDD(通称:玉)を取り外し、梱包し、開梱して全部乗せる、というプロセスを主張します。これは、内部データはどうなるかわからないため、バックアップを全部取り、リストアすることになります。手間も莫大にかかります。

もちろん移設するのですから、バックアップは必須です。しかし、完全解体はどうしてもしなければならないのか、よくよくベンダーさんと相談したほうがいいでしょう。やる、やらないで工数(費用)は大幅に変わります。

なお、最近のストレージシステムは非常に重たいです。データセンターの電力のみならず、床荷重は必ず確認してください。機種によっては1tを要求するものもあります。

B. ディザスターリカバリーサイトとする

これは、費用はかかりますが、技術的にはむつかしいことではありません。ストレージシステムそのものは、メインフレームにしろオープン系にしろ同じ技術でできています。ここ数年でスナップショット、データ転送についての技術は確立していますから、難易度が高いとも思えません。新しいセンターにシステムを新たに設置し、回線を引きレプリケーションを行います。
ただ、注意しなければならないのは、100キロを超えると同期型のレプリケーションは実用的な速度ではなくなってきます。(デバイスのレスポンスタイムが倍以上になる) これは回線速度ではなく、回線のレイテンシー(遅延)からの制限です。どんなメディアでも光速を超えることはできません。詳細な説明は省きますが、DRを行う場合、距離、データ量がフィージビリティを大きく左右します。
DRで本当に困難なのは、システム継続手順とオペレーションをする人の移動と訓練です。手順はシンプルであるほどいいのです。ある外資系の銀行はA4二枚でした。そして、運用システムが陳腐化しないように、訓練はかかせません。

C. 役割を変える

よくあるのが、センターを分割する場合です。そのため、移設期間中は、データの一部を移転するために回線を使うか、テープを使うか、といった議論が起きます。
すなわち、回線を利用し、ftp,データベースのレプリケーション、DR同様ディスクのレプリケーションを使い、新しい拠点のデータを更新するか、テープにバックアップを取りリストアをするか、です。
これはコストとデータの鮮度のトレードオフになります。データの鮮度が高いほどコストはかかります。なぜならば、常時、十分なデータ帯域を確保するためには、太い帯域の回線が必要となります。一応、回線の値段特性は帯域が大きいほど、ビット当たりコストは安いようにできています。(センター間で回線を使うのであれば、できるだけまとめるべきです。)
しかし、絶対金額としてはバカになりません。あまり鮮度を必要としないのであれば、テープを送ったほうが安いということはよくあります。

以上、簡単に概観してもおわかりいただけるかと思いますが、データの移動と鮮度と人の動きが引越しの鍵といえるでしょう。
Filed in メインフレーム情報, 知っておくと便利なテクニックなど

05.3プログラム割込みのトラップ(SPIE,ESPIE)

By kamii - Last updated: 月曜日, 4月 6, 2009

業務用アプリケーションでは、誤ったデータによる演算の結果、プログラムが異常終了することがしばしば起こります。プログラムロジックには問題がないのにデータが原因でプログラム割り込みが引き起こされるためです。このようなことを防止するため、入力されたデータや、データセットから読み込んだデータの妥当性をチェックすることは、よく行われるプログラミング手法です。他の方法として、結果として誤りであったら、その誤りをなかったことにする方法もあります。読み込んだデータが悪いため、演算命令がエラーになったら、プログラムをそこで終了するのではなく、そのデータを捨てて、次のデータを処理できるようにできます。例外処理とも呼ばれ、コンパイラー言語などではON ERROR、TRY?CATCHなどの記述で行われます。MVSではSPIE,ESPIE APIによって例外処理を設定することができます。
SPIEはプログラム割り込みが発生した時、プログラムをABENDさせずに、予め指定されたルーチン(SPIE出口ルーチン)を実行してエラーが発生したことをプログラムに通知します。


0による除算をトラップしてメッセージを出力する

このようにSPIEを使うと、指定したプログラム割り込みであれば、発生してもABENDせずに、指定のSPIE出口ルーチンが実行されることでプログラムに通知されます。トラップルーチンにはPIEと言うパラメータ・リストが渡され、それを見ることでABENDの内容、発生したアドレスを知ることができます。このサンプルのようにPIE内容を変更しなければ、ABENDした次の命令からメインラインの実行を再開させることができます。


指定可能なすべてのプログラム割り込みをトラップして、独自のABENDメッセージを出す。
データ例外であれば、その入力データを捨てる。

サンプルなので無理して全部のプログラム割り込みをトラップしていますが、実際には必要なものだけに絞って行う方がよいでしょう。一般のアプリケーションであれば、0C7や0C9で十分かと思います。

ABENDしたアドレスや割り込みコードは出口ルーチンに渡される、PIE(Program Interruption Element)を参照すれば知ることができます。PIE内のPSWアドレスフィールドを書き換えれば、任意の場所からプログラムを再開させることができます。この例ではS0C7ABENDの場合にそれを行っています。
なおSPIEは24ビットモードのプログラムでなければ使用できません。31ビットモード・プログラムの場合は次に示す、ESPIEを利用します。


31ビットモード・プログラムにおけるSPIE(ESPIE)

2番目のサンプルと同じものを、31ビットモード・プログラム用のESPIEで置き換えた例です。
ESPIEでは出口ルーチンに渡されるPIEはESPIE(Extend PIE)に変わり、そのフォーマットは異なります。そのためSPIEを使っている24ビットモード・プログラムを31ビットモードに書き換える場合、単にマクロをSPIEからESPIEに交換するだけでは済みません。対応するフィールドのオフセットをESPIE用に変更しなければなりません。3番目のサンプルでは直接オフセット値を指定せずに、EPIEのマッピングマクロを使用してフィールドを名前で参照するようにしました。
MVSはPIE用にIHAPIE、EPIE用にIHAEPIEマクロを提供しています。MSPではそれぞれKAAPIEとKAAEPIE、VOS3ではMVSと同じIHAPIEが利用できます。なおVOS3では31ビットモード・プログラム用のSPIE機能は存在しますが公開されていないため、ここでは紹介しません。

大量の入力データを処理するようなプログラムでは、その中にいくつかの誤りデータが入っていても、途中で処理をやめずにエラーデータだけをはずして、正常なデータについてはすべて処理しきってしまいたい、という仕様もあります。処理前にチェックしてはじくか、エラーになったものをはじくか、いずれの方法もありますが、後者であればSPIE/ESPIEを利用すれば、プログラムチェック割り込みによるABENDは回避できます。どちらの場合であってもどのデータをはずしたか、きちんとログを取って、完了コードも0ではなく4にするなど、運用面でも誤りに気づきやすい設計にすることが大切です。

Filed in 中級編

メインフレームとキャリアパス

By takao - Last updated: 日曜日, 4月 5, 2009
しばしば判で押したように「メインフレームをやっていると、将来がない」という言葉を聞きます。だから、「若い者にやらせられない」「成り手がいない」などなど。

本当にそうなのか?私事になるが若い人の参考になれば、と私の経験の一部を書きます。

エンジニアとして新入社員当時は、メインフレームをやることになりました。当時はそれしかなかったのです。おそらく2009年現在で、46歳以上の人はほとんどメインフレームにかかわった経験をもっているはずです。

1990年代、クライアント・サーバーやLANといったものが進歩しはじめた時、それを担当したリーダーは当然ながらメインフレームをやっていた人々でした。それでも、エンジニアである以上、新しいことを勉強し進んでいったのです。LANをフロア中に這わせてルーターとにらめっこしていたシニアなエンジニアの方を覚えています。
私も30歳代後半に「このままメインフレームをやっていたら、自分の技術のキャリアは終わりになってしまいそうだ」と相当にあせりを感じていました。しかし、どっぷりつかった仕事から会社は簡単には転進させてくれません。なにより若い人間が新しい技術をやっており、中堅の私たちは日銭を稼げる存在でしたから。

それを転進させてくれたのはSIでした。パソコンにつながないシステムなんてありません。データ移行などを行えば一時的に大量にパソコンが必要となります。このころにOS/2やWindowsでのプログラミングをPMをしながら、始めました。オブジェクト指向とイベントドリブンにはずいぶん悩みましたが、なんとかなったようです。

そうしてWindowsサーバー, UNIXと進んできました。じゃあ、メインフレームでの仕事はムダだったのか?いまだに役立っていると思うことをリストしてみます。
ほとんどはオープン系のエンジニアでも限られた人しか知らないことのように感じています。(ちょっと偉そうかも知れません。すいません)
メインフレームの世界は基幹業務であるため、オープン系よりも体験するチャンスが多いと思います。
大規模案件をやれるエンジニア、プロジェクトマネージャを目指すのであれば、メインフレームの道というのは、「急がばまわれ」で、そんなに「将来がない」と決め付けることもないように思うのです。こういうメタ知識の話を書くと、私の嫌いな精神論になりかねないので、誤解を招くとイヤなのですが。

覚えた知識がムダになることを恐れていてはIT系のエンジニアは務まらないように思います。少なくともメインフレームの世界でもTCP/IPとJavaは、オープン系と共通の重要な技術として使われています。
新しい知識とは仕事で与えられるものというよりも、長年通勤している道すがら、漫画とスポーツ新聞しか読まずにCOBOLしか覚えようとしなかったか、日経ソリューションを読んでいろいろ試す、違いではないでしょうか。
Filed in つぶやき・雑感

ソフトウェアの導入(1)

By takao - Last updated: 水曜日, 4月 1, 2009
すべてではありませんが、IBM系のソフトウェアはSMP/Eを使って導入するのが普通でしょう。これがまたわかりにくいソフトウェアなので習熟には時間がかかります。

それではどうしてメインフレームは導入にSMP/Eなんていうわけのわからんものを使っているのでしょうか?単純にコピーではいけないのでしょうか。理由は大別してふたつあります。

修正情報の履歴を明らかにすること

通常、モジュールをメンテナンスしていると複雑なモジュール関係が生じます。次の図で考え方を説明します。

smp_preプログラムのソースコードを何度か修正したとします。最初の修正がA(黄色)だったとします。次にB(赤)は、黄色の修正を前提として行われています。次に三度目にC部分(緑)を修正しました。この場合、赤は関係しているかも知れないし、していないかもしれません。機械的には決められません。
つまり、
どちらかが緑の修正情報の前提となります。このように、履歴がはっきりしていないと的確に修正情報を反映できません。Windowsなどではモジュールごと、ばさりと置き換えてしまうことが多いので、このような考慮は少ないかも知れません。このような管理をしている理由は、SMP/Eのもうひとつの目標に関係します。

修正情報をお客の環境にあわせて確実に適用する

モジュールをきちんとリンクエディット(連携編集、バインド)するのは、むつかしい作業です。モジュールの順序、与えるパラメータで再入可能とか、オーソライズドにするかなどが決まります。
さらに、ユーザーが出口ルーチンなどを利用している場合もあります。そのため、モジュールを単純に新しいものと置き換えると、カスタマイズした機能が消失する可能性があります。この多くのカストマイズを許しているところが、メインフレームの特徴のひとつでもあります。
それゆえ、修正情報を適用する場合には単純な置き換えでなく、システム部分のモジュールを置き換えて適切にリンクエディットしてロードモジュールを作り出します。

このふたつが大きな機能であるといえます。逆に、導入されていないプロダクトに関する修正情報を適用しようとしても、「ないよ」とはじかれることもSMP/Eの特徴です。
Filed in メインフレーム・ソフトウェア

10.REXX 他のOSでも動かす

By takao - Last updated: 火曜日, 3月 24, 2009
REXXの優れている点に、日本では知られていませんが、あらゆるOS上にポーティングされているという事実があります。(一昔前ですが、PC-DOSにまで搭載されていました。)しばらくWindows版が有償だったことは、普及の足かせだったと思います。
今はオープンソースでREXXの処理系はあります。まず、このOpen Object Rexxのサイトにアクセスしてください。左のメニューからDownloadを選んでいただくと、各プラットフォームごとのパッケージがあります。

Windows版をインストールすると、RXAPIというサービスが起動します。これのおかげでREXXを動かすことが、ずいぶん簡単になります。以下のようなファイルを作ってみます。

/* REXX */
SAY "Hello, World!";

適当なフォルダーにhelloworld.rexという名前で保管しましょう。
コマンドコンソールをあげて、適当なフォルダーをカレントフォルダーとして、helloworld.rexといきなりタイプインしてみてください。
Hello, World!
と表示されたはずです。上のサービスがサフィックス.rexを監視しているようです。

取り合えず動作を確認したところで、日本語マニュアルは以下にあります。
Object REXX for Windows リファレンス

Object REXX for Windowsプログラミングガイド
IBMのマニュアルは、リファレンスは辞書的に引くもの、ガイドは「?するには」的なものです。それゆえ、プログラミングガイドから見始めたほうがいいでしょう。

オブジェクト指向のREXXとはいえ、従来のREXXの機能(クラシックREXXなどといいます)はそのままです。オブジェクト指向を楽しみたくなってから始めてもいいでしょう。
なお、オープンソースとはいえ、このREXXはIBM REXXと100%コンパチだ、とウェブサイトには書いてありますので、プログラム自体はMVSにもっていっても動作するでしょう。同じ言語でプラットフォームを問わないというのは、Javaの普及を見てもわかるとおり便利なのです。もちろん、Windows固有の機能、MVS固有の機能を使う場合は無理ですけれども。

calcurator MVSのREXXと違って、GUIを作ることができます。サンプルは導入したパッケージ内のC:\Program Files\ooRexx\samples\oodialogなどにあります。calcurator.rexなどを動作させると、このように電卓のウィンドウが表示されます。

Filed in REXX入門

PCの中にメインフレーム?

By takao - Last updated: 金曜日, 3月 6, 2009
以下は、読まれている方からの貴重な投稿を加筆したものです。Kさん、ありがとうございます。
メインフレームはそのメインストリートとは別に奇異な機種をいくつか生み出しています。
ここで話題にするP/390は、まさにそのひとつであります。これは、OS/2(これももう死語ですが、IBM謹製のPC用OS)の動くパソコンにメインフレームのプロセッサーチップ(初期G4、後期G5用)を搭載したカードを乗っけたもので,1997年に発表されました。

当時は、I/O用のバス速度も現在と比べると鬼のように遅く、インストラクションの処理速度にI/Oがついていけない上に、SCSI系のトラブルも非常に多く、大変な苦労をしましたが、今となっては非常に懐かしく、かつ、貴重な思い出&経験でした。
その後、IBMが正規のサポート製品MP3000を1999年9月に発表するに至って、P/390の存在価値はどんどん薄れていきました。(P/390はエニコムなどが中心となりENI390といった名称で販売していた。MP3000は、100Vで動作し、中小企業のオフィスに置くことを想定した、「メインフレーム」でした)
しかし、あの頃、今のCPU、BUS、メモリー能力を持った、大容量HDDのPCがあったら、「ミニ・メインフレーム」はもっと脚光を浴びせられただろうなぁ、と今でも思っております。
廃棄処分となったPC390システムの390ボードを、現在のPCにさして動かしてみようかと計画中です。(発表当時はマイクロチャネル用だったが、後期にはPCI用があった)
もっとも、当時でもマザーボードのBIOSで相当苦労をしましたので、さしても認識すらされないかもしれませんが。
実験結果が出たら、またメールしますね。
どうか、サイトに訪れた、隠れMFオタクたちが、どんどんこのサイトを進化させて言ってくれる事を祈りつつ!今後とも宜しくお願い致します。



ここからはサイト主宰者追加です
某ISVにいたときに、ENI390使ってました。VMでVSEとOS/390の両方を動かしてました。開発部門で限られた人数でしか使わなかったせいもあるけど、会社のメインマシン(確かMultiprise 2000だったか)のOS/390より、はるかにさくさく動きました。Y2Kなんかもあって、結構な数の企業が導入したとも聞いてます。
ハードスペックだけ比べれば、現在のPCとHERCULESの組み合わせの方が格段に速い(?)のでしょうね。
Filed in メインフレーム・ハードウェア, メインフレーム情報

メインフレームはなぜなくならないか?

By takao - Last updated: 月曜日, 3月 2, 2009
多くの若者がこの疑問をもつ。
完全な答えじゃないけれども、オープン系も見てきた私から、理由をいくつかあげておく。

乗り換えコスト

2007年問題に代表されるように、初期のプログラムを設計、開発した人がほとんどいない。メインフレームシステムを移行しようとすると、その初期の設計からを完全に理解しないと、新しいアプリケーションを作るわけにはいかない。この莫大なコストをいまさら負担するだけの潤沢なキャッシュフローを持つ会社は少ないと思われる。

技術の素直さ

メインフレームの前身は、カード処理システムだったことをご存知の方もいるだろう。膨大なデータをプログラムで処理して出力する。「コンピュータ」出現前夜はすべてが手作業と算盤だった。それを素直に機械化したのが、現在のメインフレームである。基本の考えにはオブジェクト指向もなければ、RDBもない。なにより莫大にコードを費やすGUIはなかった。それゆえシンプルで圧倒的な速度を持つ。いまだにテープ搬送や大量印刷は性能、コスト面でオープン系は勝てない。
また、大規模プロジェクトにおいてプログラムの品質をそろえようとすると、相当に技術レベルとしては低めになる。大規模開発の場合は、オブジェクト指向にすぐれた人材をかき集めてテストするより、そこそこの人間を集めたほうが確実という面がある。

台数

オープン系サーバーがここ数年、大きく方針を変えたのが台数である。ブレード、VM、すべては筐体をひたすら減らしている。エネルギー問題もあるが、台数を減らすと確実に運用コストは減る。もともとメインフレームは一台でさまざまなプログラムを流すか、LPAR,VMなどでシステムをいくつももつ、といういずれのパターンにも対応できる。目先の導入コストが安くても、運用を考えメインフレームに戻したお客も少なくはない、と聞く。

運用の細やかさ

シンプルな動きであっても集積していくと、運用は煩雑になる。そのため、メインフレームは運用管理ソフトのレベルが非常に高い。都銀で多いところは一晩に1000本近いバッチジョブが走ることがあるが、それらをエラーをふくめて、きちんとコントロールできる。なんでもオンラインで済ませるという考え方もあるが、いろんな会社と仕事をしていく上でチェックポイントを儲けてデータを受け渡しし、バッチで処理していく、というほうがビジネス上は合理的な場合もよくあるのだ。

ハードとソフトの密接なかかわり

オープン系の人は実感しないだろうが、メインフレームのI/O処理にはCPUがほとんど介在しないため、ターンアラウンドタイムが早い。しかも接続されているデバイスの数は数百なんてのは当たり前にある。
intelが長年i/o専用プロセッサーの研究を続けていて、いまだに出せないのは、オープン系での適用は、それなりに困難さがあるのだと思われる。

また、初期のMVSからESAに変わった時、チャネルの設計は大きく変更され、OSのI/O関係のルーチンも書き直された。このようにハードとソフトを一体で作ることで、堅牢なシステムを作るという目的に焦点をあてることができる。

問題解決の確実さ

ブラックボックス、ホワイトボックスにも書いた問題である。オープン系は、専門家の集まり、水平分業の典型である。プロセッサはintel,メモリーはkingstone,HDDはHDS,ネットワークカードはどことも知れない。OSはオープンソース、言語環境はJavaでIBM,ミドルウェアはWebSphere, データベースはOracle。開発にはEclipseを使いました、なんてのは珍しくもなんともない。これらはお互いが接続点で規約を守る、というルールに基づいてできている。しかし、必ずしもそのルールどおりにならないこともある。JVMの微妙な動きはIBMのバージョンによってもSun Microによっても違うなんてこともある。

一方、メインフレームは基本が「純正」でできている。ハードウェアもOSもミドルウェアもすべて同じ会社が提供する垂直統合型である。そのため責任はきわめて明確である。問題を切り分けるところから、メインフレームベンダーに渡したって構わない。
サードパーティのハードウェアは、すべて純正のふりをしているから、動きも明確である。

ミッションクリティカルなシステムな場合、仕事の精度は常人じゃ驚くほどの精度で行われる。問題が起きて「わかりません」とか「相性の問題です」なんていうベスト・エフォートを根底とした発言はあり得ない。すべてのハードとコードに責任をもつ世界の重さというのは、オープン系の人間にはわからないと思う。

あらためて書いてみると、すべてではないけれども、メインフレームが頼りにされる場所があるのは当然か、という気がしている。
Filed in つぶやき・雑感

メインフレームの解説本、やっと出ます

By kamii - Last updated: 金曜日, 2月 27, 2009

このサイトを始めたばかりの昨年10月に、日本では久しぶりのメインフレーム・コンピュータに関する和書の発刊について紹介させてもらいました。一緒にこのサイトをやってくれている相方が「本が出ます」のページで宣伝してくれてますが、やっと発刊の運びとなりました。

「メインフレーム実践ハンドブック
(z/OS,MSP,VOS3のしくみと使い方)」
B5版、約580ページ、税込み価格9240円


3月下旬にリックテレコム社から刊行されます。メインフレームOS(z/OS、MSP、VOS3)の仕組みや機能に関しては文章だけでなく、図表も交えて解説してあるので、ビギナーの方にも理解しやすい内容で書き下ろしました。このサイトを訪れる方の多くが「JCL」「入門」と言ったキーワードで探し当てられているようです。JCLはMVSを使う上で、はずすことのできないものの一つですが、本の方でももちろん取り上げており、JCLだけで一つの章を割いています。書店に置いてあったらぜひ一度ご覧になってみてください。もちろんアマゾンでも取り扱われます。上に記した本のタイトルをクリックすると出版社からのパンフレットが開きます。本の目次が載ってますので、何について書いてあるかはご覧いただくことができます。

Filed in つぶやき・雑感

どうやって覚えればいいのか、何から始めればいいのか? -2-

By kamii - Last updated: 火曜日, 1月 13, 2009

前回はTSO/ISPFなどの対話型ツール、JCLとユーティリティから覚え始めるとよいのでは、と書きました。しかしユーティリティを使う上で避けて通れないものがあります。ユーティリティに限らずメインフレームを使う上で避けて通れないものでもあります。それがメインフレームにおけるファイル(データセット)の種類や構造に関する知識です。一般には「ファイルシステム」などと呼ばれているものです。


ファイルシステム

メインフレームでは一般に呼ばれる「ファイル」のことを「データセット」と呼びます。単に呼び方が違うだけではなく、使い分けられるものですが、ここでは説明しません。
データセットにはいくつかの種類と構造があり、用途によって使い分けられます。順次データセットや区分データセット、固定長レコードや可変長レコード、ブロックとレコードなどが関連するものです。これらはメインフレームのファイルシステムに特有のもので、他のプラットフォームを先に経験した人には、メインフレームをわかりにくくしている一つの要因かも知れません。しかしメインフレームでプログラムを作るだけでなく、使う上でも避けて通れないことです。
簡単な解説は「データセットの種類とアクセス法」に書いてあります。


OSの機能

メインフレームのOSは広範囲に渡る機能を持ちます。詳細を知る必要に迫られたときに頼りになるマニュアルなどもだいたい機能ごとに分類されています。どのような機能があって、それぞれの機能が何を行っているかの概要ぐらいはわかっていないと、なかなか先に進めません。代表的なOSであるz/OS(MSP,VOS3)に関して主な機能を取り上げ、概要を説明してみましたので参考にしてください。

記事一覧のページから、カテゴリー「 z/OS(MVS),MSP,VOS3のしくみ」をご覧下さい。

Filed in つぶやき・雑感

ホワイトボックスとブラックボックス

By takao - Last updated: 木曜日, 1月 8, 2009
オープン系とメインフレーム系で大きく違う文化が、これだと思います。
メインフレーム系は基本的に一社でハードウェア、オペレーティングシステム、ミドルウェアを提供し、システムとします。これはメーカーに相談すれば、わからないことはない、という文化を育成してきました。非常に高価な投資であったこともあり、ビジネスとしてみてもメーカー側も期待に答えざるを得ない面がありました。メインフレーム系の障害対応報告会などで、ミドルウェアの内部エラーの克明な説明をお聞きになられた方も多いでしょう。

一方、オープン系はその名のとおり、規格を基準として様々な会社が提供するパーツを組み合わせてシステムとします。それゆえ、中身がどうだという議論には至りにくく、規格どおりか、固有の動きから内部を類推する以上の議論には進めません。「相性」という言葉で済ませることもよくあります。
しかも、メインフレームに比べるとトレース、ログ機能が大幅に落ちることも障害分析を困難にしています。障害でも原因がはっきりしないままで終わらせるしかないものが少なくありません。

メインフレームの文化で育ってきたお客さんの中には、オープン系のアプローチがルーズに見える方もおられるようです。しかし、システムの金額や経済性などを考えると「そういうブラックボックスなのだ」と考えるしかないと思われます。汎用機やミニコンの時代はメーカーがハードウェアからOSまですべてを提供する方式でした。オープン系はおのおのの専業メーカーが競い合って出した製品を組み合わせることで提供されます。
過大な期待をオープン系システムに求めることは、たとえインテグレータが大丈夫と言ったとしても、無理なところがあります。

だからといって、最初から障害を解決する努力をほとんどせずに、なんでも「わからない、仕方ない」で済ませることも極端です。設定ミス、運用ミスであることもあるのですから。

筆者のようにオープン系、メインフレーム系の保守を経験してきた人間からすると、障害の解決(ソリューション)についてはオープン系のほうが、より大人の判断を求められることが多いように感じています。
Filed in つぶやき・雑感

メインフレーム技術者がなぜ育たないか?

By takao - Last updated: 火曜日, 12月 16, 2008
タイトルの記事を書くのですが、最初に理由から。オープン系に比べメインフレーム系の技術者が育つ(ここでは、より技術的に高度な仕事ができることを意味している)時間は遅いです。
その理由を明らかにすることで、メインフレームにたずさわっている人の将来と、穴に落ちてなかなか進まない状況を避けたい、さらにこのサイトでどうフォローすればいいのかも、できれば考えてみたいからです。

覚えることが多い
端的にいえばマニュアルの分厚さです。最近はDVDやWEBになったせいで、物量の把握が難しくなりました。推測ですが紙にすると、5メートル幅くらいのキャビネをドンと3段は占領するのではないでしょうか。
データセットで今使われているものにしても数種類、レコード形式の違いがそれぞれあり、扱うユーティリティも違います。さらにデータベースもやるとなるとIMSで数種類+DB2。
セキュリティのRACFもリソースごとに扱いが違い、言葉を覚えるだけでも一苦労。なんでもOSでやろうとするため、範囲が広い。Z/OSについてなんでも知っている、という無理をしないことが大事だと思います。基準はやはりLinuxエンジニアのような感じになるのでしょうか?そう絞っても覚えることは多いですが。
その場限りがむしろ例外
UNIXなどではコマンドをたたいて仕事して、その仕事のログと結果を保存しろなどとはいわれないと思います。メインフレームではTSOでいろんな仕事を済ませると「記録に残らない」とJCLでの仕事をうるさくいわれている人が多いと思います。少し大掛かりになると夜間バッチに回せ、といわれたりすらすることでしょう。対話的に仕事をするのと、定型的に仕事をするのでは「行動-フィードバック」のサイクルに大きな差が開き、それが学習効果にもたらす影響は大きいでしょう。
妙な徒弟制度
これは日本特有かも知れません。もともとメインフレームは研究所で最新の技術成果を投下した、いわゆるハイテク製品でした。そのころは扱う人もエンジニアだったのですが、自動化が進むにつれ、「定常業務については」誰もがコントロール可能なものになりました。このころから「どうしてこうするか?」ではなく、「こうしなくてはイケナイのだ。理由は聞くな。」という運用、オペレータの文化が育成されてきました。新人の「どうして?」という疑問に答えることもなく、形式主義となり長年勤めた人がエライ、という当初のコンピュータ運用とはかけ離れたものとなってしまいました。しかし、コンピュータはハイテク製品であるため、ある日突然、新技術により豹変します。形式主義では対応できないのです。また、「試す」という行為ができない現場では人は学習のしようがありません。
プログラミングの難しさ
このポータルでもプログラミングの解説を多く行っていますが、システムを触ろうとすると圧倒的にアセンブラーをつかわねばなりません。高水準言語でシステムと協調して動くプログラムを作ることのハードルがとても高いのです。これは、エンジニアに長時間の学習を強います。
コミュニティの乏しさ
メインフレームの世界には不思議なことにフリーウェアのポータルがありません。はっきりしませんが、アメリカではUS IBMが難癖をつけて潰す、と聞いたことがあります。ユーザーのスキルの低いことがビジネスチャンスであったことは間違いないのですが、今の時点でそれは正解でしょうか?
以上くらいを考えてみました。他にもあるかもしれません。ここから導き出されることは「自分用の環境をもち、すばやくテストする」「わからないことを人に聞ける、例がある」という点がLinuxなどと大きく違い、エンジニアが育たない原因かもしれません。
手前ミソになりますが、アルテシードでは前者をherculesで、後者をこのサイトでカバーしエンジニアの成長に貢献できたら、と思っています。
Filed in つぶやき・雑感

04.2オペレーター応答とコマンドを受け取る(WTORとQEDIT)

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

プログラムがコンソール・オペレーターと通信(会話)を行うには2つの方法があります。1つはメッセージを出力して、そのメッセージに対する応答を受け取る方法です。もう1つはメッセージとは無関係にオペレーターがMODIFYコマンドやSTOPコマンドによってプログラムに指示を与える方法です。
前者はプログラムでオペレーターの判断を必要とする何らかの事態が起きたときに利用されます。例えばデータセットを初期化することがパラメーターで指定された時に、本当にクリアーしてもいいのかを再確認するような機能を持たせる場合や、誤った入力データを見つけたような時に、処理不能で異常終了するのか、誤ったデータを無視して処理を続けるのか、などを選択させるような場合に、その旨のメッセージをコンソールに出して、この後どう動くかをオペレーターに判断してもらうようなプログラムを作ることができます。
後者はオペレーターの都合によってプログラムに特定の動作を行わせたり、動きを変える場合などに利用されます。バッチ処理のように入力データが終わったらプログラムの処理も終わるのではなく、一定時間あるいはオペレーターが指示するまで動き続ける常駐型のプログラムを作る際に必要となる機能です。MODIFYコマンドでプログラムの動作や機能を変更し、STOPコマンドでプログラムを終了させるのが一般的です。


メッセージに対するオペレーター応答を受け取る

WTORマクロはコンソールにメッセージを表示して、オペレーターからの応答を受け取ります。出力するメッセージの指定方法はWTOマクロと同じですが、オペレーターからの応答を受け取る領域とその長さ、および待ち受けのためのECBアドレスを追加で指定します。
WTORマクロの完了はオペレーターが応答を入力したときではありません。コンソールへのメッセージ出力がスケジュールされたら完了してプログラムに戻ってきます。この時返答領域にオペレーターからの応答が入力されているかはわかりません。WTORマクロで指定したECBでWAITマクロを発行して応答入力を待ち受けなければなりません。オペレーターが応答すればWAITマクロが完了します。
バッチ処理のプログラムではあまり必要ありませんが、WTORマクロの後ですぐにWAITを出さず、オペレーターが入力するまでの間も止まることなく別の処理を行うこともできます。またWTORもマクロ完了時にGR1にメッセージ識別番号が返ります。必要なら応答を待たずにメッセージを取り消すことも可能です。

最初の例は古典的なWTORマクロのコーディングです。MSPとVOS3もこの書き方になります。2番目はMVS(z/OS)で利用可能なメッセージ・テキストをマクロの外に記述する方法です。


オペレーター・コマンドを受け取る

アドレス空間に常駐してオペレーターが指示するまで一定の処理を行い続けるサーバー型のプログラムでは、「次に何を行うか?」と言ったことをオペレーターからのコマンドによって判定したい場合があります。このような場合にOSのMODIFYコマンドやSTOPコマンドでオペレーターの指示を受け取ることができます。このプログラムはMODIFYおよびSTOPコマンドを処理するサンプルです。WTORに比べるとロジックはやや複雑になりますが、STCタスクとして動かす常駐型のサーバープログラムでは必須となる機能です。

プログラムは起動時の初期設定として、EXTRACTマクロをサンプルのように発行してMVSのコマンドスケジューラーリスト(COMMAREA)のアドレスを得ます。STARTコマンドで起動されたSTCタスクの場合は、STARTコマンド用CIBがチェインされているのでそのアドレスを求めます。これはCOMMAREA内のCOMCIBPTフィールドにあります。バッチジョブなどSTARTコマンド以外の方法で起動された場合はチェインされていません。このアドレスを調べればSTARTコマンドで起動されたSTCタスクかそうでないかを判定できます。STC起動の場合はSTARTコマンド用CIBをBLOCK指定のQEDITマクロを発行してクリアーしておきます。(サンプルでは内部サブルーチンFREECIBで行っています)STARTコマンドでパラメーターを指定していなくてもCIBは作成されることを知っておいて下さい。

STARTコマンドでパラメーターを指定する場合はこのようにコマンドを入力します。例えば S MYSTC1,,,MODE=DEBUG とすれば MODE=DEBUG の文字列がSTARTコマンド用CIBで渡されます。CIBDATLNはパラメーターの長さ、CIBDATAがパラメーター文字列です。
次にMODIFYコマンド用のコマンドキューを作るため、CIBCTR指定のQEDITマクロを発行します。CIBCTRには同時に入力可能なコマンド数(最大255)を指定します。入力されたコマンドはいっぺんにプログラムに渡ってくるわけではありません。1つずつ順番に取り出し、1つずつ処理することができます。そのためCIBCTRは1でもかまいませんが、コマンド処理に時間が掛かるとオペレーターは次のコマンドを入力してもMVSにリジェクトされてしまいます。極端に多くする必要なありませんが、10個程度はあってもいいでしょう。CIBCTR=10は未処理のコマンドを10個分OS内でキューイングできることになります。ORIGINパラメーターにはCOMMAREAのCOMCIBPTフィールドを指定します。これでオペレーターコマンドを受け取る準備ができました。
EXTRACTを出した後QEDITも含めてOSのコントロールブロック(制御表)をプログラムで直接参照します。このためコントロールブロックをフィールド名でアクセスするためにコントロールブロックのマッピングマクロを使います。参照するコントロールブロックはCOMMAREAとCIBです。それぞれIEZCOMマクロとIEZCIBマクロでマッピングします。DSECT展開マクロでないためサンプルのように自分でDSECTを定義します。MSPではKDJCOMマクロとKDECIBマクロ、VOS3ではJDJCOMマクロとJDECOMIBマクロになります。このサンプルで参照しているものであればフィールド名は同じです。

プログラムはコマンドを受け取るタイミングになったら、COMMAREA内のCOMECBPTフィールドでポイントされているコマンド入力待ち合わせ用のECBを指定してWAITします。COMECBPTフィールドはECBそのものではなく、ECBアドレスが格納されたポインターフィールドです。
すでに何らかのコマンドが入力されていたり、新たなコマンドが入力された時点でWAITは解除されます。COMMAREA内のCOMCIBPTフィールドには次の処理すべきコマンドのCIBアドレスが入っています。ここが0ならすべてのCIBは処理済みなので再びWAITを発行してオペレーターコマンド入力待ちになります。CIBアドレスが入っていればそのCIBを調べることで入力されたコマンド文字列を求めることができます。CIBのCIBVERBフィールドは入力されたコマンド種類を示します。x44ならMODIFY、x40ならSTOPコマンドですが、サンプルのように必ずラベル名で参照します。CIBSTOPはSTOPコマンドを示すEQUラベルです。通常STOPコマンドはプログラムの終了を意味しますから、サンプルのように終了処理へ移ってしまってかまいません。MODIFYコマンドの場合は入力されたコマンド文字列と長さが必要なのでCIBから求めます。CIBDATLNはコマンド文字列の長さ、CIBDATAがコマンド文字列です。コマンドを入力したコンソールIDもわかります。MSPとVOS3ではCIBCONIDフィールド、z/OSではCIBX内のCIBXCNIDまたはCIBXCNNMフィールドを利用します。CIBXはCIBに連続して配置されている拡張CIBで、先頭アドレスはCIBアドレスにCIBXOFFフィールドの値を加えることで求められます。これによって特定のコンソールからのコマンド入力かどうかをチェックしたり、コマンド発行元コンソールを記録することなどもできます。
コマンド文字列が求められたら、対応するコマンド処理を行い、その後処理済みコマンドのCIBを解放します。(サンプルでは内部サブルーチンFREECIBで行っています)先にCIBを解放してもかまいませんが、その場合は入力されたコマンド文字列をプログラム側の領域に適宜コピーしておく必要があります。解放したCIB領域を後から参照してはなりません。このサンプルは入力されたコマンド文字列と長さを先頭の32バイト分コンソールにエコーしています。

コマンド処理が終わりCIBを解放したら、次のコマンドをチェックします。再びCOMCIBPTフィールドを参照して次のCIBがセットされているかを調べます。COMCIBPTはCIBを解放するためのBLOCK指定のQEDITマクロによって内容が更新されます。次のCIBがなければWAITへ回ります。このようなサイクルでオペレーターコマンドの処理を行っていきます。MODIFYコマンドで独自のコマンド処理をする場合であってもプログラムはSTCタスクである必要はありません。バッチで起動されても同じロジックで処理できます。異なる点は初期設定時にSTARTコマンド用CIBがあるかないかです。もしSTARTコマンドではパラメーターを受け取らないなら、少し乱暴ですが初期設定時にSTCかどうかを判定せずにSTARTコマンド用CIBをQEDITで無条件にクリアーしてもかまいません。バッチの場合はQEDITがエラーになるだけでABENDするようなことにはなりません。


Filed in 中級編

どうやって覚えればいいのか、何から始めればいいのか? -1-

By kamii - Last updated: 木曜日, 12月 11, 2008

サイトに併設している掲示板に「1週間で覚えられることは?」という質問がありました。1週間という期間はともかくとしても、全く始めてメインフレーム・コンピューターの仕事に携わることになった人達には切実なことでしょう。コンピューターがまったく初めてなのか、他のプラットフォームは経験があるのか、などベースの知識や技術に違いがあってもメインフレーム・コンピューターそのものに携わったことがないのに、即戦力でないと困る、勉強は自分でやってね、みたいなツラい状況に置かれている人達に何かのアドバイスになればと考えます。


基本の対話ツールを使えるようにしましょう


JCLを書けるようにしましょう


ユーティリティ・プログラムを使ってみましょう


メインフレームは範囲が広い

マニュアルの数だけを見ても扱う範囲が広く、これさえ覚えれば後はどうとでもなる、と言う万能的なものもありません。やる仕事が決まっているのならターゲットを絞ることはできますが、それは中級レベル以上の知識でしょう。何をやるにせよ基本の部分をあまりに端折ると、結局中途半端なことになってあとで苦労します。とは言え基本の部分の範囲が広いのと、セルフスタディの材料が少ないのが最大のネックです。ここに挙げた3つで済むわけではありません。また昔は基本知識と言えば、OSコマンドがありましたが今はセキュリティの意味からも誰もがコンソールを使うことができません。こんなことも含めて基本知識や技術の習得に関してステップバイステップで考えてみようと思います。

この話題に関してはこれからメインフレームに携わる人達には切実です。ベテランの方々の幅広いご意見やお知恵があればぜひお聞かせ下さい。

Filed in つぶやき・雑感

IBMオフィシャルz/OS解説サイト

By kamii - Last updated: 月曜日, 12月 8, 2008
米国IBM社のWebサイトに、z/OSの基本スキルについて解説されているページを見つけました。

英文ではありますが、OSのしくみ、IMS、CICSとは何だ?プログラミング言語の紹介、JCLの解説からサンプルJCLなどなど広範囲に渡って、z/OSと関連する分野の基本スキルについて解説されています。
こういうのを見ると、やっぱIBM社はメインフレームに力入ってるじゃん!と改めて思います。メーカー自らの基本スキルの解説は、これからメインフレームに携わる人への大きな福音になります(残念ながら日本語版はありませんでした)。MSP,VOS3の利用者であってもOSとしての基本部分は同じですから参考になります。

「z/OS basic skills information center」


Filed in .z/OS(MVS),MSP,VOS3のしくみ, メインフレーム情報