os/390 unixシステム・サービスを利用した web …図3...

　メインフレーム系の代表的なオペレーティング・システムである｢OS/390｣にUNIXシステム・サービス（UNIXのインターフェース機能）を取り込むことにより、大規模なUNIXアプリケーションをメインフレーム上で稼動する技術が可能となった。これによりWebなどのオープンな環境から直接、基幹システムデータへアクセスすることができ、これまでのような複数サーバ層を構築する煩雑さの解消やコスト低減が図ることができる。

　今回、このUNIXシステム・サービス機能を利用し、メインフレーム上でWebサーバ環境を構築・稼動することにより、メインフレームがサーバ選択肢の１つとなり得るかどうかを検証した。

OS/390 UNIXシステム・サービスを利用したWebサーバ稼動検証

鉄鋼システム事業部ＳＹＳＯＰセンター

小松太志

Futoshi Komatsu

41 exa review　No.1（2002）

TCP/IP ネットワーク

CPU ：9672-RA6

MEMORY ：512M Byte

NIC ：9672-RA6 OSA-E（10M Ether）

DASD ：2105-E20（ESS）

図１　ハードウェア構成

1. はじめに

　近年、ワークステーションおよびパーソナル・コンピュー

タの急激な性能アップや低価格化によりダウンサイジング

やクライアント／サーバコンピューティングが主流となっ

てきた。さらには、企業活動の多様化・広域化に伴いネッ

トワーク・コンピューティングが重要性を増してきており、

Webがその中心として位置付けられ、今後Webを基盤とし

たビジネスアプリケーションが数多く運用されると思われ

る。

　そのような中で、以下のような問題に直面し、多くの企業

がサーバ統合、集中処理への回帰という方向に動いている。

（１）維持管理負荷・コストの増加について

　分散型システムの特徴として、機能を分割して設計／開

発／運用を行えるが、これは、一元的な資源管理が困難で

あり、各プラットフォームの整合性維持のための負荷やコ

スト増に繋がる。

（２）メインフレームとの連携について

　ほとんどの分散型システムが、メインフレームの基幹業

2.2.ソフトウェア構成

　システム基盤のソフトウェア構成を図２、表１に示す。

また、他システムとのデータ連携を想定し、検証用システ

ムDB2（DATABASE2） for OS/390と別メインフレーム

務と連携しており、夜間処理などでデータのやり取りを

行っている場合が多い。依然として重要なデータはメイン

フレームに存在し、データの二重管理となっている。

（３）マルチベンダ環境について

　分散型システムは多種のハードウェアやソフトウェア製

品を組み合わせることから、複数のベンダ製品を採用する

ことが多く、トラブルや問題が発生した場合の原因究明に

多大な時間と労力を要する場合が多い。

　以上の問題の解決策として、IBM社が発表している『OS/

390 UNIXシステム・サービスを利用したWebサーバ機能』

について、各機能確認や利用可能度の調査、システム基盤

の構築・運用手順の確立を目的に検証を実施した。

2. システム基盤構成

2.1 ハードウェア構成

　今回、検証用に作成したシステム基盤のハードウェア構

成を図１に示す。

�

で既に稼動しているテスト専用システムDB2を分散リレー

ショナル・データベース処理用のプロトコルであるDRDA

（Distributed Relational Database Architecture）で接

続し、データのやり取りが可能な構成とした。


exa review　No.1（2002） 42

OS/390 BASE V2.9

OS/390 UNIX System Service V2.9

OS/390 Secureway Communications Server IP

(TCP/IP)

V2.9

OS/390 Security Server - RACF V2.9

IBM HTTP Server for OS/390 V5.2

WebSphere Application Server for OS/390 V3.02

関連

S/W

Database 2 V6.0

表１　使用ソフトウェア一覧

T

C

P

/

I

P

Unix System Service

HTTP IBM HTTP Server for

OS/390 V5.2

WebSphere

Application Server

for OS/390 V3.02

DB2

V6

OS/390 V1.3

DB2

V3

DRDA接続TCP/IP

OS/390 V2.9

Web BROWSER

図２　システム稼動イメージ

3. OS/390 UNIXシステム・サービス

　ソフトウェア構成（図２）で示したように、HIS（IBM

HTTP Server）は、OS/390の機能であるUNIXシステム・

サービスの下で稼動する。したがって、システム基盤の運

用管理者は、UNIXシステム・サービスに関するスキル習

得が必要になる。以下にUNIXシステム・サービスとはど

のようなものであるのかを紹介する。

3.1. UNIXシステム・サービスとは？

　UNIXシステム・サービスとは、UNIXアプリケーション

・プログラム・インターフェースの人気、およびプログラ

ミングとネットワーキングの標準に対する要求の増加に応

えるためにOS/390に組み込まれたUNIXインターフェース

である。OS/390は、XPG4（X/Open Portability Guides

4）UNIXプロファイル・ブランドを受けた最初のメインフ

レームOSである。これによりUNIXと同等のことがOS/390

上で実現可能となり、OS/390とUNIXの両方の機能と長所

を利用することが可能となった。

　さらにPOSIX（Portable Operating System UNIX）標

準をサポートしていることから、これらの標準に準拠して

いるUNIXアプリケーションをOS/390に移植することがで

きる。

3.2. UNIXシステム・サービスの稼動形態

　UNIXシステム・サービスは、OS/390上にいくつかのア

ドレス空間を立ち上げて、UNIXとしての機能を提供する。

ここでは、その各アドレス空間がどのような機能を担って

いるかを簡単に説明する。

　UNIXシステム・サービスでは、図３に示すように、ま

ずOS/390上に、OMVSというアドレス空間が立ち上がる。

これは、UNIXにおけるカーネルに相当するものであり、ファ

イルシステムに対するI/O処理なども一元的に管理する。

　さらにOMVSカーネルからBPXOINITというアドレス空

間が生成される。

　BPXOINITは、全ての生成されるプロセスの最上位の親

プロセスとなる。

　プログラムがプロセスを生成するためにforkなどを実行

した場合、BPXOINITが作業負荷管理プログラムである

ワークロード・マネージャ（以下WLMと略す）にアドレ

ス空間の生成を指示する。



図３　UNIXシステム・サービスの実装方式

BPXOINIT WLM

OS/390 Base Control Program

OMVS(ｶｰﾈﾙ)

BPXAS ﾕｰｻﾞｰﾌﾟﾛｾｽ

fork()

CICS

DB2

IMS

etc

　この指示により、WLMはBPXASというアドレス空間を

生成し、そこで新規プロセスの実行が行われる。

3.3. ファイルシステムについて

　UNIXシステム・サービスで使用されるファイルは、HFS

（Hierarchical File System）と呼ばれるファイルシステ

ムである。HFSは、TYPE=HFSで作成するMVSデータ

セットで、UNIXと同様の階層構造ファイルになってお

り、バイト指向でレコードという概念はない。構成はディ

レクトリ部分と通常ファイル部分からなっており、ディレ

クトリ部分はサブディレクトリを作成することも可能であ

る。

3.4.シェル・インターフェース

　UNIXシステム・サービスには、UNIXにおける一般的な

ASCII端末ベースのログイン・シェルのほかに、3270ベー

スである以下の２つのシェル・インターフェースが用意さ

れている。

●　OMVSシェル

　　・　TSOコマンドにより起動

　　・　コマンド・プロンプトよりUNIXコマンドを入力

●ISPFシェル

　　・　ISPF形式のパネル操作

　　・　メニューによるオペレーション

　ISPFシェルを使用することで、UNIXコマンドを熟知し

ていなくても、オペレーションが可能である。

3.5.MVSデータセットとのデータ交換

　もう１つのUNIXシステム・サービスの代表的な機能と

して、HFSとMVSデータセット間でのデータ交換がある。

以下のコマンド（代表的なものみ記載）をTSOもしくは、

TSOバッチにて実行することによりデータ交換が可能であ

る。

●　OGET（UNIX→MVS），OPUT（MVS→UNIX）

　　・　ファイル単位でのコピー

●　OGETX（UNIX→MVS），OPUTX（MVS→UNIX）

　　・　ディレクトリ以下のファイルやPDSメンバのコ

　　　　ピー

　ただし、これらのコマンドはVSAMデータセットをサ

ポートしていないので、IDCAMSユーティリティのREPRO

機能を使用して、一旦SAMファイルにコンバートする必

要がある。

4. Webアプリケーション検証環境

4.1. 検証用アプリケーションの稼動形態



HTTP サーバー

HTTP エンジン WebSphere

Servlet エンジン

Servlet

httpd.conf was.conf Servlet

Class File

http://server_name/myappl/appl1/myservlet～

①

②

③

④

⑤

⑥

② ③

ServerInit /usr/lpp/WebSphere/AppServer/bin/ (cont)

was302plugin.so:init_exit

Service /myappl/appl1/* /usr/lpp/WebSphere/ (cont)

AppServer/bin/was302plugin.so:service_exit

ServerTerm /usr/lpp/WebSPhere/AppServer/bin/ (cont)

was302plugin.so:term_exit

deployedwebapp.myapp.host=.....

deployedwebapp.myapp.rooturi=.....

deployedwebapp.myapp.classpath=.....

deployedwebapp.myapp.documentroot=.....

webapp.myapp.jspmapping=.....

webapp.myapp.filemapping=.....

図４　Servlet処理の流れ

　Webアプリケーション環境構築の前に、アプリケーショ

ンの稼動形態を前提に検証用アプリケーションの対象選択

を行った。Webアプリケーションの稼動形態には、一般的

にCGI（Common Gateway Interface）を利用して作成

したプログラム、Java Servlet APIを使用したJavaプロ

グラム、各種サーバAPIを利用したプログラムの３つに大

別できる。

　CGIを利用したプログラムは、CGIがリクエストされる

と、プロセスが生成される。これをUNIXシステム・サー

ビスで稼動させた場合、３．２項で述べたように、プロセ

スの生成の都度、アドレス空間が起動されてしまう。メイ

ンフレームでは、このアドレス空間の起動には、多大な

CPU消費が発生することから、CGIプログラムは対象外と

した。

　Servletは、Webアプリケーションでは標準的なJava言

語を使用するため特有なスキルを必要とせず、ポータビリ

ティも高い。また、Webサーバ上のスレッドとして実行さ

れるため、CGIよりも高いパフォーマンスが得られる。

　以上の理由から、今回の検証用アプリケーションは、

Webアプリケーション・サーバであるWAS（WebSphere

Application Server）for OS/390で稼動するJava Servlet

とした。

　また、今回は、アプリケーションのポーティング検証も

検討していたため、ＮＫＫ殿で既に分散環境における

WASで本番稼動している『カラー・ネット販売システム』

のポーティング／稼動検証を鉄鋼システム開発部と協業で

実施した。ポーティングにあたっては、作成済みのServlet

ソース・ファイル、コンパイル済みオブジェクト、JSP

（JavaServer Pages）ファイルなどのアプリケーション

資源を極力変更せずにWAS for OS/390で稼動させること

を前提条件とした。

4.2. WAS for OS/390におけるServlet処理の流れ

　WAS for OS/390におけるServlet処理の流れを図４に

示す。



①　HTTPサーバであるIHSのスタート時にIHSの構成ファ

　　であるhttpd.confのServerInitディレクティブの指定

　　に従い、WAS for OS/390がIHSのプラグインとして

　　起動され、スタート時にロードするよう指定されてい

　　るServletをロードし、init()を実行する。

②　WebブラウザからのURLリクエストが発生すると、

　　httpd.confのServiceディレクティブとのマッチング

　　により、リクエストがWAS for OS/390に渡される。

③　WAS for OS/390は、構成ファイルであるwas.conf

　　からCLASSPATHやServletの初期パラメータなどの

　　情報を得る。

④　Servletがロードされていない場合は、③のCLASSPATH

　　からServletをロードし、init()を実行する。

⑤　Service()、doGet()、doPost()を実行後、IHSのリス

　　タートまたは終了時までServletをストレージ上に保

　　存する。

⑥　処理結果（HTML）をWebブラウザへ返す。

4.3. OS/390におけるJDBCドライバ

　JavaアプリケーションからRDBをアクセスするための

APIであるJDBCのドライバは、一般的に以下の４つのタ

イプに分類される。

●　Type-1 JDBC-ODBC bridge plus ODBC driver

●　Type-2 Native-API partly Java driver

●　Type-3 JDBC-Net pure Java driver

●　Type-4 Native-protocol pure Java driver

　OS/390環境では、『Type-1』と『Type-2』のJDBCド

ライバが利用可能である。JDBCドライバはDB2の標準機

能であり、利用にあたっては、DB2 V5.1以上が前提となっ

ている。

　また、Type-1 JDBCドライバが標準機能であるが、PTF

を適用することで、Type-2 JDBCドライバに変更され、

静的SQLであるSQLJも同時に利用可能となる。

　今回は、ポーティングしたアプリケーションがType-2

JDBCドライバを利用していたので、これを採用した。

4.4. JDBCからDB2への接続形態

　JDBCからDB2への接続方法として、以下の２つがある。

●　CAF（Call Attachment Facility）接続

●　RRSAF（RRS Attachment Facility）接続

　CAF接続の場合、プロセス・レベルでのセキュリティ管

理となる。また、アプリケーションの異常終了時の同期点

保証は、アプリケーション側の仕組みとして作成しておか

なければならない。

　RRSAF接続は、OS/390で提供されるRRS（Resource

Recovery Service）という資源回復機能を利用してDB2

と接続される。CAF接続のプロセス・レベルでのセキュリ

ティ管理に対し、RRSAF接続は、スレッド・レベルでの

セキュリティ管理となる。また、アプリケーションの異常

終了時は、RRSが同期点保証を実施するので、アプリケー

ション側での作成は不要となる。ただし、システム環境と

して、MonoplexまたはSysplex環境でのロガー機能が稼

動している必要がある。また、WAS for OS/390のコネク

ション・マネージャまたはコネクション・プーリング機能

（後述）を使用する場合も、RRSAF接続が必須となる。

　これも、ポーティングしたアプリケーションがコネク

ション・プーリング機能を使用していたのでRRSAF接続

を採用した。

4.4. コネクション・マネージャ／コネクション・

　　　プーリング

　データベースへの接続の確立は、大きなオーバ・ヘッド

が生じるタスクで、アプリケーション・パフォーマンスが

大幅に低下することがある。そのコストを削減するために、

一度、確立した接続を再利用するメカニズムがコネクショ

ン・マネージャ／コネクション・プーリングである。これ

を利用することにより、データベース接続ハンドルへのア

クセスを効率化するだけではなく、任意の時点でシステム

が使用している過剰な資源量の最小化も図ることができる。

　コネクション・マネージャ／コネクション・プーリング

は、WAS for OS/390に実装されている機能であり、JDBC

2.0 Standard Extension APIに準拠している。

5. Webサーバ稼動検証結果

　今回の検証では、大規模なアプリケーションの稼動、多



CPU－BUSY（%） STORAGE（Mbyte）

パターン 1 0.9 % 約 50 MB

パターン 2 2.5 % 約 130 MB

初回 2 回目以降

アプリ 1 7 秒 3 秒

アプリ 2 10 秒 2 秒

数のクライアント接続などのストレス・テストまでは実施

できなかったが、WebサーバであるIHS（WAS for OS/

390を含む）の稼動にあたっての使用CPU／MEMORY資

源といくつかのアプリケーション・レスポンスについて、

参考までに以下に記す。

5.1. IHSアドレス空間使用リソース

　　表２　使用CPU／MEMORY資源

●　パターン１：

　　・　IHSアドレス空間の開始／常駐／停止のみ

　　・　ブラウザーからのアクセスなし

●　パターン２：

　　・　IHSアドレス空間の常駐

　　・　数台のクライアントよりいくつかのアプリケー

　　　　ションを稼動

5.2. アプリケーション・レスポンス

　　表３　レスポンス実測値

●　アプリ１：

　　・　Java Servlet／JDBCでのDB2データ参照

　　・　コネクション・プーリング未使用

●アプリ２：

　　・　Java Servlet／JDBCでのDB2データ更新

　　・　コネクション・プーリング使用

　結果として、どちらも初回に時間を要したのは、Servlet

のロードに時間を必要とし、２回目以降はWebサーバ内に

常駐されたServletを使用しているためレスポンスの短縮

が図れたと考える。

　また、アプリ２の場合は、コネクション・プーリングを

利用したことによる、DB2への接続コスト削減の効果も若

干含まれているものと考える。

6. システム基盤の運用・保守に関する考察

　S/390をWebサーバとして位置付け、UNIXシステム・

サービスを活用していく上で、システム基盤の運用・保守

に関する考察を以下に述べる。

6.1. HFSのバックアップ

　前章で述べたように、UNIXシステム・サービスのファ

イル・システムであるHFSは、MVSデータセットとして

作成されるため、長年に渡りMVSで培われてきたDFSMS

などの機能を使用して、バックアップ／リストアすること

ができる。

6.2. モニタリングとチューニング

　UNIXシステム・サービスは、OS/390のシステム管理機

能SMF（System Management Facility）を利用でき、資源

測定機能であるRMF（Resource Measurement Facility）

モニタによってレポートを出力し、解析が可能となってい

る。RMFレポートはCPU、I/O、メモリなどのシステム負

荷状況や、ファイル・システムの使用状況をリアルタイム

に測定でき、パフォーマンス・チューニングに有用である。

さらには、UNIXシステム・サービスの管理機能、IHSや

WAS for OS/390のログおよびレポーティング機能を利用

することも可能である。

7. おわりに

　OS/390でUNIXアプリケーションを稼動させることは、

信頼性、連続可用性、データの高速アクセス／バックアッ

プなどのS/390の長所を活用することができる。

　大規模UNIXアプリケーションが稼動し、基幹システム

との連携が可能なUNIXシステム・サービスの利用は確実

に広まっていくであろう。

　しかしながら、検討課題もいくつか残っている。

　OS/390は、現在、出荷されている後継OSであるz/OS

などバージョン・アップと共に飛躍的に機能拡張が図られ

ている。これまでは実現不可能だった技術も次期OSでは

適用可能となる可能性が高くなる。本格的に活用していく

には、必要技術、適用時期などを慎重に見極めていく必要

があると考える。



　最後に、本検証の機会を与えてくださったＮＫＫ情報シ

ステム部、実施するにあたって多大な情報とご示唆を賜っ

た日本アイ・ビー・エムの方々に厚く感謝の意を表する。

参考文献

IBMマニュアル

　　　［OS/390 V2R9 UNIXシステム・サービスの計画］

IBMテクニカルサポートセンター W/S資料

　　　［OS/390 UNIX Service］


　　　［OS/390 V2R9 UNIXシステム・サービスの操作と運用］


　　　［WebSphere AS for OS/390 V3.02 導入と構成］


　　　［WebSphere AS for OS/390 V3.02 運用と操作］

＜問い合せ先＞

　鉄鋼システム事業部

　ＳＹＳＯＰセンター

　運用技術チーム

　　Tel.　044-322-6646　小松太志

　　E-mail：[email protected]

本文中の会社名、製品名、およびサービス名などはそれぞれ各社

の商標または登録商標です。



os/390 unixシステム・サービスを利用した web …図3...

Documents