mainframe - Java/OOP/SQL の背景を持つメインフレームと JCL の学習

Question

キャリア全体で、Java および ASP.Net アプリケーションとサーバーのコーディングと管理を行ってきました。現在、私は z/OS や JCL などのメインフレームに関与するよう指示されていますが、理解するのが難しいと感じています (彼らはまだパンチ カードについて話しているのです!)。現代のぜいたく品に完全に甘やかされてしまった後で、これらすべてを学ぶための最善の方法は何でしょうか?

Answer 1

最新のメインフレームにはパンチ カードはありません。

「古い」方法で行われていることがまだたくさんあるので、苦労するでしょう。

• データ セットには、fixed-block-80、variable-block-255 などのプロパティが引き続き割り当てられます。ファイルの内容を計画します。
• ディレクトリがありません。階層レベルがあり、それぞれ 8 文字に制限されています。
• ユーザー インターフェイスは ISPF です。これは、慣れていない人向けの地獄の 7 番目の円からのグリーン スクリーン テキスト モード ユーザー インターフェイスです。
• ほとんどのジョブは引き続きバッチ ジョブとしてサブミットされるため、SDSF (一種のタスク マネージャー) で進行状況を監視する必要があります。

これは悪いニュースの一部ですが、良いニュースは次のとおりです。

USS サブシステム (UNIX) があるため、これらのツールを使用できます。これは、z/OS と非常によく統合されています。Java を実行し、Websphere を実行し、DB2 (適切な DB2 であり、それほど小さな Linux/UNIX/Windows ではありません) を実行し、MQ などを実行します。多くのショップでは、ハイパーバイザーである z/VM も実行します。 z/OS 自体 (場合によっては複数のコピー) や zLinux (SLES/RHEL) を含む、多くの LPAR (論理区画) を実行します。

メインフレームがすぐに消滅する危険はありません。世界中のさまざまな IBM ラボでまだ多くの作業が行われており、64 ビット OS (z/OS、MVS、OS/390 など) は長い道のりを歩んできました。実際、それを知っているすべてのオールディーズは55歳以上であるため、キャリアの機会が少しあります.

これは、大企業のトランザクションで信頼できる唯一のものであるため、依然として大企業で使用されています。System z の z は、ダウンタイムがゼロであることを意味します。これは単なるマーケティングの誇大広告ではありません。メインフレームのパワーは、その CPU のうなり声にあるのではなく (個々のプロセッサはそれほど強力ではありませんが、ホット バックアップを備えた 54 個の CPU のブックで提供され、単一の System z ボックスで多くのブックを実行できます)、実際には、 CPU が行うのは命令の処理だけです。

それ以外はすべて、専用プロセッサー、DB2 用の zIIP、Java ワークロード用の zAAP、I/O 用のその他のデバイスにオフロードされます (I/O は、光ファイバーと非常に大規模なディスク アレイを使用して、メインフレームが他のすべてのシステムを停止する場所です)。タンパク質の折り畳みやゲノム配列決定には使用しませんが、対象となる非常に異常なレベルのトランザクション処理には理想的です。

前述したように、z/OS には UNIX サブシステムがあり、z/VM は z/OS およびその他のオペレーティング システムの複数のコピーを実行できます。私は、RHEL の数万のインスタンスを同時に実行する単一の z800 ボックスを見てきました。これは、すべての PC メーカーの「環境に配慮した」主張を恥ずかしく思います。インスタンス間の通信は、HyperSockets (TCP/IP ですが、低速のネットワーク ケーブルではなく共有メモリを使用します) を使用すると驚くほど高速です (はい、HyperSockets と比較してギガビット イーサネットでさえクロールします (申し訳ありません)ネストされた括弧 :-)))。

Unix スペースで Websphere Application Server と Java を非常にうまく実行しながら、すべてのレガシー (遺産?) も同様に実行できます。実際、メインフレーム ショップは PC ベースのサーバーを購入する必要はまったくありません。いくつかの zLinux VM を導入し、すべてを 1 つのボックスで実行するだけです。

そして最近、IBM がメインフレーム用の xSeries (つまり PC) プラグイン デバイスも提供している可能性があるという話があります。ほとんどのメインフレームのユーザーは、美しいボックスの横にあるいぼだと考えるでしょうが、サードパーティ ベンダーには多くの可能性が開かれています。彼らが 50,000 の Windows インスタンスを実行できるようになるかどうかはわかりませんが、それは彼らが目指しているようなものです (1 つのリングですべてを支配する?)。

興味があれば、Hercules という System z エミュレーターがあり、これは Windows ボックスで 23 MIPS で動作し、合法的に使用できる最新の MVS 3.8j を感じるのに十分な速さで動作します。CP/M が Windows XP に対するものであるように、MVS 3.8j は z/OS 1.10 に対するものであることに注意してください。

職場の友人の 1 人が書いた本の恥知らずなプラグインを提供するには、What On Earth is a Mainframe?をチェックしてください。David Stephens (ISBN-13 = 978-1409225355) 著。私は PC/UNIX のバックグラウンドを持っていたので、これは非常に貴重であり、かなりのパラダイム シフトであることがわかりました。この本はあなたの特定の質問に最適だと思います。グーグルブックスでかなりの量が入手できると思うので、購入する前に試してみてください。

JCL に関しては、JCL ファイルは 1 つしか作成されておらず、他のすべてのファイルはカット アンド ペーストで作成されたものであるという考え方があります。それらの内容を見て、私はそれを理解することができます。IEBGENER や IEFBR14 のようなプログラムは、冗長ではないにしても、Unix を少なくとも理解できるようにします。

Answer 2

最初の誤解は、JCLの「L」を信じていることです。JCLはプログラミング言語ではなく、プログラムの実行方法や使用するファイルなどの静的な宣言です。

このように、これは、spring、hebernate、antなどの「最新の」ソフトウェアを制御するために使用されるxml config spahettiによく似ています（ただし、優れています）。

これらの用語で考えると、すべてが明らかになります。

メインフレームの文化は、2つの一見相容れない強迫観念によって推進されています。

1. 後方互換性。1970年に作成およびコンパイルされた実行可能ファイルを引き続き実行できます。40年前のJCLおよびスクリプトは引き続き実行され、機能します。
2. ブリーディングエッジのパフォーマンス。2つのデータセンターの4台のマシンで128個のCPUを使用して、単一のDB2クエリを処理できます。最新のJ2EE（Websphere）アプリケーションを他のどのマシンよりも高速に実行します。

Answer 3

Z/OS 上のCICS (メインフレーム トランザクション サーバー) に関わることがあれば、 「CICS アプリケーションの設計とプログラミング」という本をお勧めします。
とても便利です。
代替テキスト http://img18.imageshack.us/img18/7031/designingandprogramming.gif

Answer 4

従来のレガシー アプリケーションの開発に携わる場合は、Steve Eckols の本を読んでください。彼らはかなり良いです。学習時間を短縮するために、オープン システムからメインフレームまでの用語を比較する必要があります。いくつかの例 ファイルはメインフレームではデータセットと呼ばれます JCL はシェルスクリプトのサブプログラム/ルーチンまたは一般的な関数のようなものです...頑張ってください...

Answer 5

最初に手を握るほど良いです。私はインターンとしてメインフレームの仕事をしたことがありますが、UNIX のバックグラウンドはかなり豊富でしたが、簡単ではありませんでした。メインフレーム部門で働いている人に、1 日か 2 日かけて基本を教えてもらうことをお勧めします。IBM のトレーニングも役立つかもしれませんが、私はその経験がないため、役立つとは限りません。メインフレームの使用方法の学習に関する私のストーリーを、いくつかのコンテキストのために以下に記載しました。すべてのインターンは、メインフレームの使用方法を夏のプロジェクトとして学習することになり、その時間の 20% を費やすことが決定されました。すべてのインターンは、私がメインフレーム以外の領域で働いていて、立方体の壁を越えて助けを求めることができる人がいなかったことを受け入れたので、それは完全な惨事でした. ISPF および JCL 環境は、彼らがすぐに習熟するには異質なものでした。USS は基本的に UNIX であり、大学ではこれに慣れていたので、彼らが唯一成功したのは USS での基本的なプログラミングでした。運がよかったのには 2 つの理由があります。1 つ目は、約 20 人のメインフレーム プログラマーのグループで働いていたので、誰かが定期的に私と一緒に座って、JCL の理解やジョブの送信などを手伝ってくれました。Rational Developer for System zそれが WebSphere Developer for System z と名付けられたとき。これにより、ジョブのサブミット、データセットの編集、データセットの割り当て、プログラムのデバッグなど、ほとんどのタスクを実行できるほぼ使いやすい GUI が得られました。洗練されていませんでしたが、十分に使用可能であり、ISPF を学ぶ必要はありませんでした。基本的なメインフレーム タスクを実行するために Eclipsed ベースの IDE を使用していたという事実は、学習曲線を大幅に短縮し、完全に新しい環境ではなく、JCL などの新しいテクノロジを学ぶだけでよいことを意味しました。さらに、Rational をメインフレームで実行するために必要なソフトウェアが、私が使用したプロダクション システムのいずれにもインストールされていなかったため、ISPF を使用するようになりました。ISPF は Rational Developer よりも高速であり、より効率的であることがわかりました。これは、Rational を使用した JCL や ISPF インターフェースなどの基盤となるテクノロジーを後日学習できたからにすぎません。一度に両方を学ばなければならなかったとしたら、それはもっと難しく、一対一の指導が必要だったでしょう。