1. はじめに：なぜz/OSにUNIX環境が必要なのか？

前回の記事では、z/OSのサービスを支えるSTCの仕組みを解説しました。しかし、STCのJCLに時折現れるPGM=BPXBATCHという記述や /var/zosmf というディレクトリツリーの記述は、z/OSが持つもう一つの顔、USS（UNIX System Services） との関わりを示しています。

▼ 前回の記事

そもそも、メインフレームのOSであるz/OSに、なぜUNIX互換環境が必要なのでしょうか。その答えは、WebやJavaといったオープン系技術との連携にあります。もともとのメインフレームOSでに、USSが融合することで、z/OSはオープン系のアプリケーションも動かすことのできるサーバープラットフォームへと進化を遂げました。

この記事では、z/OSのもう一つの顔であるUSSとは一体何なのか。そして、MVSベースのSTCがUSSとどう連携し、オープン系ベースのサービスを提供しているのか。そのハイブリッドなアーキテクチャの解説していきます。

2. 二つの世界の融合：USSの役割とMVSとの得意分野

もともとのメインフレームのOSである MVS（Multiple Virtual Storage） と、オープン系の USS（UNIX System Services） 、二つのOSを併せ持つのがz/OSです

MVSとUSS、その違いとは？

両者の違いは、データの扱い方と得意な処理にあります。それぞれの特徴を見てみましょう。

MVS

ファイル管理はデータセット。例として SYS1.PROCLIB のような命名規則が用いられ、レコード形式が基本。
主なプログラム言語はCOBOL、PL/I、アセンブラ。
得意な処理は高性能・高信頼な基幹業務。具体的には、CICSやIMSによるオンライン取引処理、大規模バッチ処理など。
安定性、信頼性、一貫性を最優先する。

USS

ファイル管理は階層型ファイルシステム（ZFS）。例として /usr/local/ のようなディレクトリ構造が用いられ、バイトストリーム形式が基本。
主なプログラム言語はJava、Python、Perl、C/C++、シェルスクリプト。
得意な処理はオープンな技術との連携。具体的には、z/OSMFによるWeb/APIサーバー、SSHによるリモートアクセスなど。
柔軟性、接続性を重視するオープンソース文化。

MVSは金融機関の勘定系処理に代表される、絶対的な安定性と膨大な処理能力が求められる分野で利用されてきました。一方、USSは外部システムとの通信・連携など、オープンとの連携が求められる処理に不可欠な環境です。

USSの役割

では、なぜUSSが必要なのでしょうか。その答えは、z/OSがオープンの言語を話す必要があるからです。

例えば、z/OSをWebブラウザから管理するz/OSMF、セキュアなリモートアクセスを提供するSSHD、他システムとデータをリアルタイムに連携するIIDRといった製品があります。これらのSTCを導入する際、必ずUSS上にディレクトリを作成し、ファイルを配置する工程があります。

それは、これらの製品がオープンなシステムと連携するために、z/OS上でもオープンな世界と共通の技術やプロトコルを使用する必要があるからです。HTTP、SSH、Javaといった技術は、特定のベンダーに依存しない「共通言語」です。そして、z/OSがこれらの「共通言語」を扱える場所が、USSなのです。そのため、オープンなシステムと連携する製品はUSSを動作基盤として設計・構築されています。

結果として、プログラムの実行ファイルや設定ファイル、ログファイルなどは、UNIX文化に則ったディレクトリ構造（例：/etc/ssh、/var/zosmf）で管理されることになります。USSは、MVS上の堅牢な基幹システムがオープン系の外部システムと連携するための環境と言えます。

3. STCにおけるMVSとUSSの連携

STCのうち、JCLにPGM=BPXBATCHという記述や /var/zosmf というディレクトリツリーの記述があるものはどのように起動しているのでしょうか。

起動の動きとしては、「STCというMVSの枠組みを使い、その中でUSSのプログラムを起動する」 という動きをします。この仕組みを、z/OSへのリモートアクセスを提供するSSHDのSTCを例に解き明かしていきましょう。

【図の解説】
この図は、SSHDの起動プロセスを示しています。MVS側で始まった処理が、共通の土台であるz/OSカーネルを通じてUSS側へ連携していく様子を示しています。

処理の流れ

起動命令: オペレーターが S SSHD コマンドを実行します。
JCLの準備: JESがPROCLIBからSSHDメンバーを読み込みます。しかし、その中身は直接的なプログラムではなく、PGM=BPXBATCH というUSSプロセスを起動するためのユーティリティが指定されています。
権限の確認とユーザーIDの特定: JESがRACFに問い合わせる際、ユーザーIDだけでなく、そのユーザーがUSSの世界で活動するための許可証である 「OMVSセグメント」 を持っているかどうかも確認されます。RACFは、OMVSセグメントを持つユーザー（例：SSHDUSR）を割り当てます。
アドレス空間の準備: JESはイニシエーターに対し、特定のユーザーIDの権限で新しいタスクを開始するよう指示します。
アドレス空間の生成: イニシエーターは、STCが他のプログラムから独立して動作するための専用メモリ空間（アドレス空間）を生成します。
プログラムの実行: 確保されたアドレス空間内で、JCLに記述されたプログラム（PGM=BPXBATCH）が、割り当てられたユーザーIDの権限で実行を開始します。
USSへの連携 (最重要): BPXBATCHは、MVSの世界からUSSの世界へ処理を引き渡すための fork()やexec() といったシステムコールを発行します。この命令がz/OS Kernelに渡され、連携が始まります。
USSデーモンの起動: z/OS Kernelは、新しいUSSプロセスを生成し、その中で指定されたプログラム（sshdデーモン）を起動します。
設定ファイルの読み込み: 起動したsshdデーモンは、zFSファイルシステム上に格納されている設定ファイル（例：/etc/ssh/sshd_config）を読み込みます。
サービス開始: sshdデーモンは、ネットワークのポート22番でクライアントからの接続待ち受けを開始します。実際のSSHサービスは、このUSSプロセスによって提供されます。

まとめ
このように、USSと連携するSTCは、MVSのSTCという「ガワ（起動・停止・ログ管理の仕組み）」を使いつつ、その実体（プログラム）はz/OSカーネルを介して起動されたUSSプロセスとして動作します。2つのOSを連携させることで、MVSの良さと、オープン系の良さを両立させることができます。

4. USS連携を支える4つの重要コンポーネント

STCとUSSのハイブリッドな連携は、いくつかの重要なコンポーネントによって支えられています。ここでは、製品導入やシステム構築の際に必ず登場する、4つの必須要素について解説します。

1. ZFSとマウント

USS上のプログラムや設定ファイルは、どこに保存されるのでしょうか。その答えが、ZFS (z/OS File System) です。ZFSは、USSで標準的に利用される高性能なファイルシステムであり、UNIXでお馴染みのディレクトリ構造を提供します。

物理的にはZFSはMVSのデータセット（VSAM）として存在します。このためDUMPやRESTOREといったMVS上での処理・操作が可能です。

製品を導入する際、まず初めにこのZFSデータセットという、製品が使用する実行ファイル、設定ファイル、ログファイルなどを格納するファイルを作成します。しかし、ファイルがあるだけでは使えません。そのファイルにUSSのディレクトリツリー（/usr/lpp/my-product）を割り当てる必要があります。ディレクトリに接続する行為が マウント（MOUNT） です。マウントされて初めて、USSからファイルやディレクトリとしてアクセスできるようになります。

2. `BPXPRMxx`

システムを再起動（IPL）するたびに、手動でZFSをマウントするのは現実的ではありません。そこで登場するのが、SYS1.PARMLIBに格納されている BPXPRMxx メンバーです。

ここにマウント情報を定義しておくことで、システムのIPL時に指定したZFSが自動的にマウントされ、いつでもUSSアプリケーションが起動できる状態になります。

BPXPRMxxの記述例：

/* z/OSMFのZFSを /var/zosmf に自動マウントする定義 */
MOUNT FILESYSTEM('ZOSMF.ZFS.DATA')
      MOUNTPOINT('/var/zosmf')
      TYPE(ZFS) MODE(RDWR)

製品の導入マニュアルにこのメンバーの更新指示があるのは、その製品が使用するファイルシステムをシステム起動時に自動で使えるようにするためです。

3. `BPXBATCH`

前述の通り、BPXBATCHは、STCのJCLからUSSのプログラムを起動するためのユーティリティです。MVSとUSSを連携させる役割です。

JCLのEXECステートメントでBPXBATCHを呼び出し、PARM=パラメーターで実行したいシェルコマンドを渡すのが基本的な使い方です。SH（シェル経由で実行）やPGM（直接プログラムを実行）といったオプションを使い分けることで、様々なUSSプログラムを起動できます。

JCLでのBPXBATCH使用例：

//SSHD EXEC PGM=BPXBATCH,
// PARM='SH /usr/sbin/sshd -f /etc/ssh/sshd_config'

この一行によりMVSからUSSへ処理を引き渡します。

4. RACFのOMVSセグメント

STCに割り当てられたz/OSのユーザーIDをUSSで使用するためには、特別な許可証が必要です。それが、RACFユーザープロファイルに定義されるOMVSセグメントです。

OMVSセグメントには、USS環境でそのユーザーを識別するための情報が格納されています。

UID: UNIX/Linuxの世界で一意のユーザー番号。これが無いとプロセスを所有できません。
HOME: ログインした際のホームディレクトリ（例：/home/sshdusr）。
PROGRAM: デフォルトのシェルプログラム（例：/bin/sh）。

RACFコマンドによるOMVSセグメント追加例：

/* ユーザーSSHDUSRにOMVSセグメントを定義する */
ALTUSER SSHDUSR OMVS(UID(nnn) HOME('/home/sshdusr') PROGRAM('/bin/sh'))

このOMVSセグメントが定義されていることで、z/OSユーザーは定義された権限の範囲でUSSの操作が可能となり、USSのプロセスを起動・管理することができます

5. まとめ

二本の記事を通じて、STCと、USSを解説してきました。

MVSでは、STCという堅牢な枠組みを通じて、絶対的な信頼性と高性能な基幹業務処理を提供します。一方、オープンなUSSがあることで、階層型ファイルシステム（ZFS）やオープンソースソフトウェアとの親和性から、オープン系の外部システムとの連携が容易になります。

2つのOSはBPXBATCHやOMVSセグメントといった仕組みによって、MVSの優れた運用管理能力を維持したまま、USSのサービスを起動することができます。

最後までお読みいただき、誠にありがとうございました。

参考文献