【z/OS】USS（UNIX System Services）とは？ZFS、BPXPRMの役割を解説

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といったオープンな技術との「接続性」にあります。MVSが持つ絶対的な信頼性に、USSがもたらす柔軟性が融合することで、z/OSは多様なアプリケーションを動かす、現代的なサーバープラットフォームへと進化を遂げたのです。

この記事では、z/OSのもう一つの顔であるUSSとは一体何なのか。そして、伝統的なSTCがUSSとどう連携し、現代のサービスを実現しているのか。そのハイブリッドなアーキテクチャの謎を解説していきます。

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

z/OSは、伝統的な MVS（Multiple Virtual Storage） の世界と、オープンな USS（UNIX System Services） の世界という、二つの異なる顔を併せ持つユニークなOSです。この二つは対立するものではなく、それぞれの得意分野を活かして協調することで、z/OSの強力なプラットフォームを形成しています。

MVSとUSS、その違いとは？

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

MVS（Traditional World）

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

USS（Open World）

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

MVSは金融機関の勘定系処理に代表される、絶対的な安定性と膨大な処理能力が求められる領域でその真価を発揮します。一方、USSは外部システムとのAPI連携やWebアプリケーションのホスティングなど、柔軟な「接続性」が求められる処理に不可欠な環境です。

USSがもたらす「接続性」という価値

では、なぜUSSが必要なのでしょうか。それは、現代のITシステムが単体で完結することはなく、常に外部と連携する必要があるからです。

例えば、スマートフォンアプリからメインフレーム上の口座残高を照会するサービスを考えてみましょう。このとき、アプリからのリクエストを受け付けるWeb APIサーバーを、USS上で稼働させます。そして、そのAPIサーバーがMVSの世界で動いているDB2のSTCと連携し、必要なデータを取得してアプリに返す、といったことが可能になります。

このようにUSSは、MVSが守り続けてきた基幹システムと、オープンなITの世界とを繋ぐ「架け橋」の役割を担っているのです。

3. ハイブリッドな連携：STCがUSSの世界を動かす仕組み

STCのうち、JCLにPGM=BPXBATCHという記述や /var/zosmf というディレクトリツリーの記述があるものはどのように起動しているのでしょうか。STC自体はMVSの仕組みですが、USS上の定義も使用しているということでしょうか。MVSとUSSは、一体どのようにして連携しているのでしょうか。

その答えは、「STCというMVSの優れた運用管理の枠組みを使い、その中でUSSのプログラムを起動する」 という、ハイブリッドなアーキテクチャにあります。この巧妙な連携の仕組みを、z/OSへのリモートアクセスを提供するSSHDのSTCを例に解き明かしていきましょう。

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

処理の流れ

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

まとめ
このように、USSと連携するSTCは、MVSのSTCという「ガワ（起動・停止・ログ管理の仕組み）」を使いつつ、その実体（プログラム）はz/OSカーネルを介して起動されたUSSプロセスとして動作します。このハイブリッドなアーキテクチャこそが、z/OSの堅牢な運用性と、オープンな世界の柔軟性を両立させる鍵となっています。

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

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

1. ZFSとマウント：USS世界の「土地」と「住所」

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：MVSからUSSへの「連絡船」

前述の通り、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. OMVSセグメント：USS世界の「身分証明書」

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'))

この「身分証明書」があって初めて、z/OSユーザーはUSSの世界の住人となり、STCとしてUSSのプロセスを起動・管理する資格を得ることができます。

5. まとめ

二本の記事を通じて、z/OSの根幹をなすSTCと、その現代的な進化を支えるUSSを解説してきました。

MVSの世界は、STCという堅牢な枠組みを通じて、絶対的な信頼性と高性能な基幹業務処理を提供します。一方、オープンなUSSの世界は、階層型ファイルシステム（ZFS）やオープンソースソフトウェアとの親和性によって、システムに柔軟な「接続性」をもたらします。

そして、この二つの世界は分断されているのではなく、z/OSカーネルという共通基盤上で、連携しています。BPXBATCHやOMVSセグメントといった仕組みによって、MVSの優れた運用管理能力を維持したまま、USSの柔軟なサービスを安全に起動することができます。

このMVSの信頼性とUSSのオープン性の融合こそが、z/OSが単なるレガシーシステムではなく、クラウドや最新技術とも連携できる現代的なサーバープラットフォームであり続ける理由と言えます。

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

参考文献