メインフレームで動く WebSphere Application Server の世界: 第 1 回 メインフレームでの Java 活用

ページオプション JavaScript を要するドキュメントオプションは表示されません

レベル: 中級

青木 京子, Advisory IT Specialist, IBM

2008年 3月 14日

この連載では、メインフレームで動く Java およびサーバー・ミドルウェアの IBM WebSphere Application Server for z/OS の世界を連載でご紹介します。第 1 回は、IBMメインフレーム OS である z/OS と、z/OS の Java をバッチ処理で活用する方法についてご紹介いたします。

はじめに

メインフレームと聞いて思い浮かべる単語は何でしょう？「レガシー」、「滅び行く恐竜」、｢化石｣。「ダウンサイジング」や「オープンシステム」という標語が盛んにもてはやされた時期、メインフレームが過去の遺物として恐竜扱いされ、主役の座を追われつつある状況もありました。しかし、あれから10年以上経った今でも、メインフレームは多数の大規模な企業・組織で使われ続けています。これは間違いなく、メインフレームに向いた用途が実際に存在し、そこではメインフレームを利用することがよい選択であったからです。規模が大きく、大量業務データを並行処理する。しかも、安定性／信頼性を重視し、とにかくダウンしないという特性を実現したのがメインフレームなのです。高い信頼性、保守運用性、拡張性、セキュリティ性を備え、トランザクション処理、バッチ処理の両方の性能に優れています。

一方、Java言語に対する世の中の評価は、高まるばかりです。技術者数が多い。移植性が高く、特定プラットフォームに依存しない。オブジェクト指向。高いセキュリティー機能。ポインタがなく、メモリー領域を気にせずにプログラムを組むことができる。Java関連の本の出版量を見ても、Java が主流であることは間違いないでしょう。オープン・スタンダードな技術であるJavaを使って基幹システムを構築したいというニーズも高まっています。

そこで、この連載では、メインフレームで動くJavaおよびサーバー・ミドルウェアの IBM WebSphere Application Server for z/OSの世界を連載でご紹介します。

メインフレームの世界でどのようにJavaアプリが活躍できるのか？　を、考えていただけたら、と、思います。

上に戻る

IBM メインフレームの歴史

最初に汎用機として登場したメインフレームは、1964年にIBMが発売したS/360です。それ以前のコンピュータは、商用計算用・科学技術計算用に設計され、機種ごとに仕様が異なり、機種が変わればユーザーが作成したアプリケーションプログラムは書き直し、周辺機器は買い直しとなり、同じメーカーでも互換性は無いのが常識でした。S/360は、科学計算にも、事務計算にも、すべてに向いている、どういった業務・目的にも全方向（360度）から使えるコンピュータとして登場しました。また、S/360は、互換性のある一連の機械を開発するという考え方を初めて実用化した点に大きな特徴があります。当時S/360向けに開発されたアプリケーションは、現在の最新のメインフレーム IBM System zでも動作可能なのです。

IBMメインフレームは、S/360 → S/370 → S/390 → zSeries → System z と進化を続けてきています。IBMメインフレームのオペレーティング・システムも、大規模用としては、OS/360 → OS/VS → MVS/SP → MVS/370 → MVS/XA → MVS/ESA → OS/390 → z/OS と進化を続けてきています。いまや、LinuxもIBMメインフレームで稼動します(Linux on IBM System z)。IBMのメインフレームのオペレーティング・システムは、上記以外にも、VM (中規模用/サーバー統合用)、VSE (中規模用)、TPF (航空会社用) などがありますが、この連載では、z/OSについてお話します。

上に戻る

z/OS で稼動する MVS と UNIX

オペレーティング・システム　z/OSは、MVS （Multiple Virtual Storage、多重仮想記憶）から発展したものです。MVSは、単語の意味のとおり、複数個の仮想記憶域空間を巧みに駆使して、システム資源の有効活用をはかるシステムです。仮想記憶方式で、実在する実記憶域の容量を超えたサイズの記憶域を利用できるようにしました。さらに、単一仮想記憶方式では、処理の多重度を増やしていくと、いずれ限界に達してしまうので、システム上で多数同時に実行される仕事ひとつひとつに仮想記憶域を割当てるという方法をとりました。仮想記憶が複数(Multiple)で、MVS(多重仮想記憶)です。MVSの後継となるOS/390は、MVSの機能に、UNIX System Services (USS) 機能やTCP/IPを取り込みながらオープンな環境に対応しました。 そして、z/OSは、OS/390の後継をなす、z/Architectureを基礎としたオペレーティング・システムです。z/Architectureは、当初ESA Modal Extensions (ESAME)と呼ばれた64ビット・アーキテクチャです。MVSはもともと、24ビットシステムをサポートしました。ハードウェアの進歩に伴って、MVS/XA、MVS/ESA、OS/390では31ビットシステムを、z/OSでは64ビットシステムをサポートします。64ビットの実記憶域アドレッシングのサポートにより、従来の31ビット・アドレッシングでは2GBに制限されていた主記憶域が大幅に広がりました。また、64ビット仮想記憶域アドレッシングのサポートにより、仮想記憶域も2GBから、論理的には2の64乗=18,446,744,073,709,551,615(Byte)=16EB(エクサバイト)にまで広がりました。

OS/390から組み込まれたUNIXシステム・サービスを見ていきましょう。UNIXになじみがある方々は、何をもってUNIXシステムと呼ぶでしょうか？UNIXと同じような、ディレクトリやファイルの構造を持っていること？他のシステムとネットワーク接続するときにTCP/IPで接続可能であること？ユーザーがシステムをインタラクティブに使用する際、Telnetログインできること？C, C++, Javaなどの言語でアプリケーションを開発できること？、、、そういう意味では、z/OSのUNIXシステムサービスは、UNIXシステムです。列記されたUNIXたる特性をz/OSのUNIXシステムサービスは全て持っているからです。もちろん、UNIXシステム・サービスは、Single UNIX Specification(SUS、唯一のUNIX仕様) に準拠しています。

z/OSの前身のMVSから持っているOSとしての機能をUNIXシステム・サービスと区別するために、ここでは、MVSサービスと呼びます。MVSサービスとAIXとUNIXシステムサービスを比較しながら、UNIXシステム・サービス(以降USSと呼びます)を理解していきましょう。

まず、実行環境ですが、AIXのカーネルに相当する部分は、USSでは、z/OSの基幹となるMVS-BCP (Base Control Program) に含まれています。UNIXシステム・サービスは、単純にz/OSのオペレーティング･システムの上に乗せているのではなく、z/OSの根幹に組み込み稼動しています。表1は、MVSとAIXとUSSのプログラム実行の観点での相違を記述したものです。図1は、z/OS UNIXシステム・サービスのコンポーネント図です。

次に、データの持ち方についてですが、MVSでは、データセットと呼ばれるファイルにデータ記録します。データセットは基本的には、事前にアロケーションしておき、カタログと呼ばれる、索引のようなものに登録しておきます。データセットは、カタログから固定ディスク（DASD、とも言います)のボリューム名を、ディスクの登録簿であるVTOCから実際のデータセットの所在を知ることがでいます。USS内でのデータの扱いはAIXなどのUNIXと同じディレクトリ構造です。MVSで、USSのファイル・システムの器としてのHFSデータセットやzFSデータセットをアロケーションしておきます。HFSやzFSの中にある階層構造を成したUnixファイルは、USSシェルやUSSアプリケーションからアクセスします。表2は、MVSとAIXとUSSのデータの持ち方の観点での相違を記述したものです。図2は、MVSデータセットとUSSファイル・システムの比較図です。

ユーザ・インターフェースは、MVSではTSO/E　(Time Sharing Option/Extensions)　を使います。z/OSへのアクセス、データ処理、アプリケーション開発など、全てTSO/Eを使い行います。USSでは、AIXと同様にrloginやTelnetで直接シェルにログインすることも可能ですし、TSO/Eのコマンド、OMVSコマンドシェルやISHELLを使い、USSへアクセスすることが可能です。OMVSコマンド(z/OSシェル)は、コマンド・インターフェースを提供し、ISHELLコマンドは、メニューベースのインターフェースを提供します。表3は、MVSとAIXとUSSのシステムへのログイン/ログオンの観点での相違を記述したものです。図3はrloginやtelnetでUSSへログインするイメージ図です。図4は、TSO/E OMVSコマンドとISHELLコマンドの比較図です。図5から図7は、z/OS USSへのアクセスの画面です。図5がTelnet、図6がTSO/E OMVSコマンド、図7がTSO/E ISHELLコマンドです。全て同じディレクトリを表示しています。

図 4. TSO/E OMVSコマンドとISHELLコマンド
出典　ABCs of z/OS System Programming Volume 9(SG24-6989-03)

図 5. z/OS USSへのアクセス：Telnet

図 6. z/OS USSへのアクセス：TSO/E OMVSコマンド

図 7. z/OS USSへのアクセス：TSO/E ISHELLコマンド

UNIXシステム・サービスに関して良くある誤解としては、「アプリケーション・プログラマーは、UNIXシステム・サービスとファイル・システムを使うUNIXプログラムか、MVSサービスとMVSデータセットを使うMVSプログラムか、どちらかを選択しなければならない｣というものです。プログラマーの選択は、MVSか、UNIXか、というものではありません。たとえば、UNIXアプリケーションでDB2データを扱いたい場合、DB2はMVSプログラムとして稼動していますが、UNIXアプリケーションからDB2を直接アクセスすることが可能です。z/OSにおいて、MVSとUNIX間で、シームレスに連携することができるのです。

上に戻る

z/OS 上の Java VM

IBMは、IBMのすべてのプラットフォームでJavaを提供しています。z/OS上のJavaは、他のすべてのIBMプラットフォームと同じJava機能を提供します。加えて、z/OS Javaは、z/OSユニークなファイル・システムにJavaからアクセスできるよう、機能拡張を加えています。また、z/OS Javaは、z/OS環境でのJNI (Java Native Interface) の実装を提供しています。現時点では、z/OS用に以下のIBM SDK (Software development Kit)が利用可能です。

IBM SDK for z/OS, Java 2 Technology Edition, V1.4 (5655-I56), SDK1.4.2
IBM 64-bit SDK for z/OS, Java 2 Technology Edition, V1.4 (5655-M30), SDK1.4.2
IBM 31-bit SDK for z/OS, Java 2 Technology Edition, V5 (5655-N98), SDK5
IBM 64-bit SDK for z/OS, Java 2 Technology Edition, V5 (5655-N99), SDK5
IBM 31-bit SDK for z/OS, Java Technology Edition, V6 (5655-R31), SDK6
IBM 64-bit SDK for z/OS, Java Technology Edition, V6 (5655-R32), SDK6

これらのすべてのSDK製品は、非SMP/EフォーマットとSMP/Eフォーマットの両方で提供されます。SDK製品は、IBMに注文することも、IBMのサイト IBM Java Standard Edition Products on z/OS から直接ダウンロードすることも、できます。

Java VMは、z/OSのUSS環境で稼動します。

上に戻る

バッチ処理を Java アプリケーションで

ほとんどのメインフレーム・ワークロードは、2つのカテゴリに分けられます。オンライン・トランザクション処理とバッチ処理です。特に、メインフレームは、バッチ処理の性能に優れています。メインフレーム・システムの1つの主要な利点が、大量のデータの高速処理にあるからです。ですから、バッチ処理もJavaを使って構築したいというニーズがあります。そこで、z/OSのバッチの要件を、z/OS上のJavaがどの程度満たしているか、検討してみます。

まず、z/OSでJavaバッチを使うメリットは、何でしょう？

• 既存のバッチで作成されたデータセットを、Javaプログラムからアクセスしたり、渡したりすることが容易
• Javaで提供されているAPIでアクセスしやすいサービス (SOAP/Webサービス、JMS, JDBC, TCP/IPソケット・サービス)を使える
• 長時間処理にSTC (Started Task)を利用できる
• Javaのプログラミング・スキルやクラス・ライブラリを再利用できる

では、z/OSでJavaバッチ処理を使う際、気になる点は、何でしょう？

• Javaでは、バッチ処理をさせるには、遅すぎるのでは
• Javaでは、CPU資源を沢山使うのでは

こういった懸念は、現在はあまり心配ではなくなってきています。Javaパフォーマンスはすばらしく良くなってきています。また、IBMはzAAP (System z Application Assist Processor) を発表し、低コストでJava処理ができる環境を提供しています。さらに、プロセッサ速度も年々速くなっています。

では、次に、バッチに必要な要件について考えて見ましょう。z/OSのレガシー・バッチが持つ機能を元に、主な要件を以下に箇条書きにしました。

1．柔軟なJVM環境設定

JVMを起動するには、環境変数とパラメータ設定が必要です。とりわけ、CLASSPATH環境変数は、クラスを含むディレクトリとJARファイルをリストアップする必要があります。こういった環境変数の設定が容易であることが必要です。

2．ジョブ出力ルーティング

MVSバッチ・ジョブでは、出力はSYSPRINTやSYSOUTに指定されたMVSデータセットへ書き出されるのが標準です。Javaバッチ・ジョブでも、出力をJCLのDDで指定したファイルへへ書き出したいという要求があります。

3．出力データのエンコーディング指定

Javaプログラムでは文字はUnicodeで扱われています。Javaアプリケーションでは、デフォルト・エンコーディングがASCII (ISO-8859-1) であることを期待してコーディングされている場合があります。しかし、z/OSでは、デフォルト・エンコーディングがEBCDIC (IBM-1047) であるため、アプリケーションが正しく稼動しない場合があります。従って、デフォルト・エンコーディングでのジョブ出力とは別に、出力データのエンコーディングを指定ができる必要があります。

4．コンディション･コード渡し

あるジョブ・ステップから次のジョブ・ステップへ推移する際、コンディション･コードを渡す必要があります。

5．DDステートメントのMVSデータセット使用

JCLのDDステートメントで設定したMVSデータセットをバッチ処理から使用したいという要求があります。

6．同アドレス空間実行

実行ジョブとJVMが別のアドレス空間として処理されると、不都合なことがいくつもあります。DD名やSYSOUTを共有できなくなりますし、SMF30のようなアカウンティング・データに本処理が課金されないという問題があります。

7．コンソール連携

MVSバッチ・ジョブは、コンソールにメッセージを出力します。また、思いがけず長時間実行されるジョブは、MVS STOPコマンドはMODIFYコマンドで処理されます。Javaバッチでもコンソール出力、コンソール処理ができることが必要です。

z/OS Javaには、バッチ処理を意識したJZOSが同梱されています。これは、z/OSで動くJavaアプリケーションのためのJZOS JVMランチャーとJZOSツールのセットです。JZOS JVMランチャーを使用すれば、USS環境の上でシェル・コマンドとしてJavaを実行するのではなく、JZOS JVMランチャーで、直接JVMをバッチ・ジョブのアドレス空間に呼び出すことができます。JZOS JVMランチャーは、MVS環境でのJVM起動を可能にしたのです。また、JZOSはz/OSと連携するための様々なツールを提供しています。JZOSツールにより、COBOL、PL/Iのようなコンパイラ型言語で書かれたz/OSバッチアプリケーションに近い機能環境を、Javaバッチで利用することができます。JZOSは、IBM SDK 1.4.2 for z/OS以降のz/OS Java製品で利用可能です。

次のジョブがJZOS JVMランチャーのJCL例です。com.foo.MyClassはスタンドアロンのJavaプログラムで、JZOSVM14（14はJavaのバージョン1.4に相当）というのがJZOSランチャーの実体です。

//JZOSBAT JOB (999,XXX),'JAVA JZOS',CLASS=A,MSGLEVEL=(1,1),
//   MSGCLASS=X,REGION=0M,NOTIFY=&SYSUID
//JAVAJVM  EXEC PGM=JZOSVM14,
//   PARM='com.foo.MyClass arg1 arg2'
//STEPLIB  DD DSN=JZOS.LIBRARY,DISP=SHR
//SYSPRINT DD SYSOUT=*          < System stdout
//SYSOUT   DD SYSOUT=*          < System stderr
//STDOUT   DD SYSOUT=*          < Java System.out
//STDERR   DD SYSOUT=*          < Java System.err
//STDENV   DD *
. /etc/profile
. ~/.profile
export CLASSPATH=~/myapp
for i in ~/myapp/lib/*.jar; do
    export CLASSPATH=$i:$CLASSPATH
    done
//

JZOSではバッチジョブを使いやすくするための以下の機能が提供されています。

1. 柔軟なJVM環境設定

   //STDENV DDでUNIXシェルを実行できます。変数置換やスクリプティングなどで、動的設定が可能です。

2. ジョブ出力ルーティング

   STDOUTとSTDERRを、直接JES SYSOUTにできます。

3. 出力データのエンコーディング指定

   z/OSでは、デフォルト出力デンコーディングは、システム・プロパティのfile.encodingの設定にかかわらず、LANG環境変数によって指定されたエンコーディングになります。JZOSでは、JZOS_OUTPUT_ENCODING環境変数により、デフォルト出力コード化を変えることができます。

4. コンディション･コード渡し

   System.exit()で、コンディション･コードを次のジョブ・ステップへ渡すことができます。

5. DDステートメントのMVSデータセット使用

   JZOS ZFileのクラスはJNIラッパーを標準のCライブラリ入出力ルーチンに提供します。
   
   MVSデータセットの入出力コーディング例 (レコード・モード)
   

   ZFile inZFile = new ZFile("//DD:INPUT", "rb,type=record,noseek"); ZFile outZFile = new ZFile("//DD:OUTPUT", "wb,type=record,noseek"); try { byte[] recBuf = new byte[inZFile.getLrecl()]; int nRead = 0; while((nRead = inZFile.read(recBuf)) > 0) { outZFile.write(recBuf, 0, nRead); } } finally { inZFile.close(); outZFile.close(); }

   
   
6. 同アドレス空間実行

   JZOSでは、元のアドレス空間の下でJVMを呼び出します。Javaプログラムは、ジョブステップのDDデータセットを使用できます。セカンダリアドレス空間が使用されていないので、JavaプログラムはオリジナルのWLMグループで実行されます。

7. コンソール連携

   ZOS ZUtilのクラスは、コンソールにメッセージを出力したり、オペレータコマンドに応じるためのメソッドを提供します。
   
   ZUtilクラス　コーディング例 (IBM SDK for z/OS 1.4.2の例)
   

   ZUtil.wto("FOO1233E processing terminated", 0x0020, // routecde 0x4000); // descriptor code

   
   

表 4 は、USS環境でシェル・コマンドとしてJavaを実行するための標準機能であるBPXBATCHやBPXBATSLユーティリティと、JZOS JVMランチャーを比較したものです。JZOSによってJavaバッチがレガシーバッチ並みに組めることがご理解いただけると思います。

上に戻る

次回について

今回は、メインフレームの歴史からはじまり、z/OS上のJavaで実行するバッチ処理まで見てきました。次回からは、 IBM WebSphere Application Server for z/OSのオンライン処理の世界をご紹介します。

参考文献

• ｢z/OS｣には、z/OSの情報が集められています。(英語)
  
  
• z/OSの技術的なトピックについて興味がある方は、｢z/OS Hot Topics newsletters｣をご覧ください。(英語)
  
  
• z/OS USSの技術的なトピックについて興味がある方は、｢ABCs of z/OS System Programming Volume 9(SG24-6989-03)｣をご覧ください。(英語)
  
  
• ｢Java on z/OS｣には、Java on z/OSの情報が集められています。(英語)
  
  
• JZOSの技術的なトピックについて興味がある方は、｢Java Launcher and Toolkit Overview｣をご覧ください。(英語)
  

著者について

		青木 京子（あおき　きょうこ）。デザイン・センターで、IBM WebSphere Application Server for z/OSを扱うプロジェクトを後方支援しています。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

上に戻る