はじめに
当記事では、メインフレームのモダナイゼーションを考える際に関連するコンポーネントとして、z/OSMF、USSにフォーカスします。
関連記事
メインフレーム担当者の必須スキルを再考する - (1)背景
メインフレーム担当者の必須スキルを再考する - (2)モダナイゼーションのベースとなるオープン技術
メインフレーム担当者の必須スキルを再考する - (3)ケーススタディ
モダナイゼーションのベースとなるオープン技術
誤解を恐れずに言ってしまいますが、モダナイゼーションを前提とした場合、今後必須となるであろうオープン技術は SSH と REST だと考えています。
そして、これらのベースとなるコンポーネントが
- USS（z/OS Unix System Services）
- z/OSMF（z/OS Management Facility）
です。
これはあくまで 個人的な見解であり、体系的にこうなっていますよというのが正式に謳われているわけではありません。いろいろとモダナイゼーション関連のソリューションを見てきたり、技術サポートをしている中で非常に強く感じるところです。
逆に言うと、あまりこの辺りの重要性が浸透していないのではないかと思われる場面がよくありますので、改めてここで強調しています。
個人的には、SSH や REST API で z/OS に接続してオペレーションするのが「当たり前」になってほしい、という思いがあります。
※昨今の生成AIの潮流を踏まえて付け加えるのであれば、MCP(Model Context Protocol)というのがAI Agentとの連携する上では非常に重要な技術になるであろうと考えています。これはいずれ別の記事で取り上げようと思います。
スキル階層イメージ
ざっくりとですが、スキルの階層イメージを図で示してみるとこんな感じになるかなと考えています(あくまでイメージです！)。
新しい技術が出てくるときには、別の技術がベースになってより新しい仕組みが構築されるということはよくあると思います。
下の方にいわゆるトラディショナルなz/OS固有のスキルがあって、それをベースにモダナイゼーション関連技術やソリューション関連のスキルを拡張していくことを考えた場合、使用するソリューションにもよりますが、USS、z/OSMFが介在することが非常に多いという印象です。
具体例は後ほど紹介しますが、つまり、これらがベースとなって新しいソリューションが提供さる傾向にあると言えると思います。
これはあくまでイメージですので、完全にこういう階層になっているわけではないです。z/OSMFはUSS上で稼働するコンポーネントですので、ここも依存関係があったりします。あくまで傾向としてこの部分が中心になってくるというイメージでとらえていただければと思います。
USS(z/OS Unix System Service)とは
USS は z/OS 上で POSIX 準拠の Unix 環境 を提供する機能です。
USSは z/OS Unix System Servicesの略です。正式な略称としてはz/OS Unixというらしいですが、経験上ではUSSと表現することが多いと思いますのでこの記事ではUSSと表現しています。
z/OSの中でいわゆる旧来型のトラディショナルな使われ方をする部分をMVSと表現するとすると、その横にMVSと合わせてUnix互換のサービスが立ち上がっているというイメージになります。
Unixという名前が付いていますし、もうこれはUnix環境と同等に使える環境がz/OS上でも稼働していると考えていただければよいです。
シェル
通常MVSの世界では、PCOMからTSOログインして、ISPFやSDSFといった3270ベースのユーティリティーを使用してデータセットを参照したりシステム管理を行うことになります。
Unixだとシェルというコマンドラインのインターフェースを介して操作するのが一般的です。USSではデフォルトではz/OSシェルというkshライクのシェルが提供されていますし、追加でbashを利用することも可能です。
ファイルシステム
ファイルシステムはzFSと呼ばれるUnixと同様の階層型のディレクトリ/ファイル管理が行われます。これにより一般的なUnix系のファイルシステムと同じような考え方でファイルの管理が行えるようになります。
ただ、zFSの実体としてはMVS上のデータセットとして保持されることになります(zFS用の特殊なフォーマットをしたデータセットを作成し、USSにマウントして使用する)。
接続プロトコル
接続プロトコルとしてはUSS上でOpenSSHがサポートされていますので、USS上にSSHサーバーを立ち上げることでSSH Clientからシェルに接続することができます。
SSHクライアントからシェルに接続してコマンドベースでディレクトリやファイルの管理が行えるというのは、Unix/Linuxお使いになったことがある方はお分かりと思いますが、それとまったく同じようなイメージで操作が行えるということになります。
その他の特徴
USS上のファイルとMVS上のデータセット間でのファイルコピーを行ったり、TSOコマンドを発行したり、JOB実行を行ったりすることが可能です。
しかも、USS上だと新しい言語のサポートも追加されてきており、Java、Groovy、Python、Node.jsといった言語もUSS上で動かせるようになってきています。つまりこういう言語でMVS操作の自動化や連携の仕組みが作りやすくなってきていると言えます。
ただ、一般的なUnix/Linux環境との大きな違いとして、文字コードは意識する必要があります。USS上では、EBCDICとそれ以外のASCII/UTF-8が混在することになります。ここは意識してオペレーションを行う必要があり、各ファイルには"タグ"と呼ばれる文字コードを表す情報を付与して管理されます。この辺りの詳細につては、以下の記事もご参照ください。
参考: z/OS技術者が学ぶべきオープンな技術 ～USSの活用～ - 文字コード/タグ付け
ちなみにSSHでの通信では基本的にASCII - EBCDIC変換が行われることになり、日本語は扱えません(文字コード変換は別途考慮する必要あり)。
z/OSMF (z/OS Management Facility) とは
z/OSMFはz/OS管理用の新しいインターフェースを提供するコンポーネントです。
大きな特徴としてはブラウザー・ベースの専用のUIを提供しているので、PCOMなどの3270画面に比べてリッチなUIでMVSの管理が行えるということが挙げられます。
また、各種z/OS上の操作を REST API でアクセスできるような機能を提供しています。
このREST APIが提供されるというのが非常に意味のあることで、このREST APIを利用することで利用形態の幅が大いに広がることになります。
例えば、以下のような各種管理機能をREST API として提供しています。
- データセットやUSS上のファイル操作
- ジョブの管理
- システムコマンド実行
- ワークフローの管理
- などなど...
z/OSMFの実装についても補足しておくと、この実体はLibertyと呼ばれるJavaベースのアプリケーションサーバーが稼働し、その上でz/OSMFとしての機能を実装したWebアプリケーションが稼働するという形態になっています。
つまりこれ自体はUSSのJVM上で稼働するコンポーネントですので、zIIPオフロードの対象になります。
この機能はz/OS V2.2からz/OSのベースエレメントに含まれて出荷されている機能で、V2.3からはデフォルトで自動起動するようになっているのですが、現行踏襲というポリシーの元、残念ながら敢えて起動しないよう設定しているというお客様も多いと聞いています。
これを活用しないのは非常にもったいと思いますので、本番環境はともかく、開発/テスト環境では活用の場面は多いと思いますのでぜひ利用を検討していただくのがよいと思います。
"架け橋"としてのUSSとz/OSMF
z/OSMF、USSというコンポーネントは、REST、それからUnixやSSHというメインフレーム固有の作法ではなく標準的な作法での接続性を提供する、という意味において、オープンな環境と旧来型のメインフレーム環境の架け橋として、非常に重要な要素であると考えています。
つまり、このメインフレームの特異性という壁を低くするためのコアなピースになると考えています。
モダナイゼーションで求められる具体的スキル
(1) Unix 観点での管理スキル
新しい機能や製品、特にOSSだとかJava系のコンポーネントはUSS上に実装されることが多いです。
これは当たり前と言えば当たり前だと思うのですが、オープン系のUnix/Linux上で培われた技術をz/OSに取り込む際には、USSはほぼUnixですのでUSS上にポーティングしてしまえば互換性も高く楽にポーティングできるということがあります。
先に紹介したz/OSMFも実体はLibertyというJavaベースのコンポーネントですので、これもUSS上に構成されることになります。
USS上で構成されるということは、構成ファイルや実行モジュールも当然USSのファイルシステム上に管理されますし、運用管理対象のログ・ファイルもUSS上のファイルとして出力されることになります。
つまり、Unixそのものの運用/管理スキルと同等のことが求められるということになります。
新しい機能や製品は基本的にUSSファイルシステムの利用が前提:
- 構成ファイル
- ファイル参照/更新
- 実行モジュール
- モジュール配置
- メッセージ・ログ
- 問題判別時のログ参照
- ログ・ファイルのアーカイブ、クリーンアップ運用
その他全般的に必要な考慮事項:
- ファイルシステム管理(zFS)
- ディレクトリ管理
- USS上のリソース管理
- ユーザー/グループ/アクセス権管理 (RACF)
- バックアップ
- 自動化
- 文字コード (EBCDIC/UTF-8)
余談: USS上の操作を行う必要がある場合、どのようなツールで行っていますか？
モダナイゼーションをしていくにあたってはUnixとして運用管理が避けて通れない状況になってきていますが、現実問題として構成ファイルやログの操作などをどのようなツールで実施しているでしょうか？
実際にはまだまだPCOMなどの3270ベースのツールが使われている状況をよく目にします。
具体的には、ISHELLでディレクトリ、ファイルを確認したり、OMVSでシェルに接続したり、OEDITでファイル編集したり...
技術支援をしているなかでご質問などをいただく際に、構成情報やログの確認を依頼すると、右端が切れた状態で連携されていたり、文字化けが発生してうまく参照できない、といったような基本的な操作でうまく情報連携できない時がままあります。話をうかがっていると、Unix上のファイルでもこういう3270ベースのツールがメインで使われている状況だったりします。
Unix上の管理をきちんと行うには、Unix環境に適したツールを使わないと効率が非常に悪いというか、3270ベースのツールだけだとかなり無理があると思っています。
シェルの操作であれば汎用的なSSH Client、Windowsだと代表的なものとしてはteratermが使えますし、エディターとしてはVS Codeも使えるようになってきていますし、個人的にはこれらの組み合わせが使いやすいと思っています。
あとはz/OSMFが提供するブラウザーベースのUIとかEclipseベースのツールなんかも提供されていたりします。
一時しのぎくらいであれば3270ベースのツールでもよいかもしれませんが、今後それだけだと効率が悪すぎて厳しいと思います。特にUnixを扱ったことがある人にこのインターフェース使わせるのは苦行といってもいいくらいありえないと思います。
PCOMを駆使している人からは「慣れればこっちの方が早いんだよ」という意見をよく聞きます。MVS上の操作であればそれに特化したUIを提供している3270のツールは使いやすいのかもしれないですけれども、Unixの操作においても全く同じことが言えるわけで、「Unixを扱うのであればUnixを操作するのに適したツールを使った方が慣れれば早いんだよ」 と言えるわけです。
早く下の世界が当たり前になってほしいなと切に願うところです。
(2) 外部連携その1: SSH
モダナイゼーションで求められるスキルの2つ目として、外部連携に関連する重要な技術としてのSSHがあります。
オープン系との連携というと、REST APIで連携するということが頭に浮かぶ方も多いのではないかと思いますが、インフラ観点で考えた場合はREST APIと同じくらい重要なプロトコルがSSHだと思っています。
SSHでつながることで、z/OS活用のバリエーションが大幅に広がることになるのですが、REST APIに比べると、メインフレームの世界ではその有用性が今一つ認識されていないのではないかと感じます。
そもそもSSHサーバーを立てていないという環境もよくあるように見受けられます。
SSHがつながることの利点としては、さきほど挙げたUIが改善されるというのがありまして、teratermなどの汎用的なSSHクライアントからシェルに接続して操作できます。
それに加えて、標準技術を使った自動化の仕組みとの連携が行える、というのがもう一つの非常に大きなメリットになります。代表的なものがJenkinsやAnsibleといった技術との連携です。
インフラ担当者に求められるスキル:
- SSH構成、運用
- ユーザー管理
- 鍵認証
SSH経由での外部連携の挙動
上の動画ではSSHが重要であるということのベースとなっている原点の挙動を実際のオペレーションで紹介しています。
具体的には、SSH経由でz/OSのコマンドを実行する以下のパターンを紹介しています。
(1)-1. sshコマンド → USSシェル接続 → USSシェル上でREXX実行
(1)-2. teraterm → USSシェル接続 → USSシェル上でREXX実行
(2) sshコマンド + シェル上のコマンド (SSH経由で直接REXX実行)
(3) 2をWindowsバッチ化
こちらは、恐らくUnixを扱ったことのある方であれば、何をいまさら当たり前のことを、と思うような内容だと思いますが、メインフレームの世界だとまだあまりこの認識が浸透していないと思われますので、そこに大きなギャップがあるのだと思っています。
上の例では、3つのレベルで、WindowsからUSS上のシェル・コマンドを実行する流れを示しています。
まず一つ目として、SSHコマンドでシェルに接続してシェル上でコマンドを実行するというケースです。
ユーザーID/パスワードを入力するのではなく、鍵認証方式といって、秘密鍵/公開が気のペアを作成して公開鍵をUSS上に設定しておくことで、対応する秘密鍵を持っているユーザーだけが接続できるという、そういう認証方式がとれるというのもSSH接続のメリットです。
このsshコマンドで接続先と秘密鍵を指定して接続すると、USSのシェルに接続できます。プロンプトが変わってUSSに接続できたことがわかります。ここでUSS上のコマンドを打つことができます。
この環境では、MVSコマンドを実行するためのrexスクリプトを作っているので、そのREXX経由で、"D T"という時刻を表示させるコマンドを打っています。
次に、Windows上の汎用的なsshクライアントツールであるteratermから同じことを実行してみます。
REXX経由で"D T"、"D A,L"をシェル上で実行できます。
これが1つめの例です。
2つめは、SSHコマンドの引数として、直接シェル・コマンドを指定するということができます。こちらが自動化という意味では重要な使い方です。
例えばpwdとか、先ほどのREXX実行を直接sshコマンドの引数として指定すると、ssh接続をしてコマンド実行して切断、というのを一気に実行してくれます。
これだと実行する命令が長ったらしいので、3つ目の例では(2)をWindows上にバッチのスクリプト(sdsf.bat)として作成しておき、MVSコマンド部分だけを引数で与えるようにしておきます。
そうすると、このようにあたかもWindowsのコマンド実行をしているような形で、MVSコマンドを実行することができるようになります。
これを拡張していけば色んなことができそうだということが皆さんなんとなくイメージ沸きますでしょうか？
上の例はWindowsのコマンドプロンプトからSSHコマンド経由で単純なMVSコマンド実行した例ですけれども、JOBサブミットやTSOコマンド実行やデータセット操作など色んな操作が行えます。
さらに、SSHというのは標準的なプロトコルですので、このようなコマンドとして提供されるだけでなく、JavaとかPythonとかよく使われる言語のライブラリーというのも普通に提供されますので、連携のためのツールというのがどんどん出てきています。
オープンな世界とメインフレームの世界の壁がものすごく低くなっているように感じないでしょうか？
先ほども触れたように、この延長線上にある代表的な連携の例が、JenkinsやAnsibleといったものになります。
(3) 外部連携その2: REST
モダナイゼーションで求められるスキルの3つ目として挙げたいのはREST APIです。
これは標準的かつシンプルなプロトコルでアプリケーションの呼び出しを行えるということで、具体的にはHTTPというプロトコル、JSONというデータ構造を使ってサービス呼び出しを実現するというものです。業務アプリの連携などで広く知れ渡っていると思いますので、その有用性というのは言わずもがなかなと思います。
先に示したように、z/OSMFはz/OSに関する様々なオペレーションをREST APIとして呼び出されるような仕組みを提供しています。これを利用した便利なツールがいろいろと提供されていますが、代表的なものとして、Zowe Explorerと呼ばれるVS CodeのExtensionで、VS Codeからデータセットの編集やJOBサブミット、MVSコマンド実行などが行えるようになっています。
これらはオープンソースとして提供されていますが、標準的なインターフェースを提供する、すなわち、メインフレームの特異性の壁を低くしたことでオープンな技術の活用がすすむ顕著な例だと思います。
これを実現するには、インフラ担当者としては、z/OSMFの構成、運用であるとか、REST APIの理解や問題判別といったところは必要になってきます。
インフラ担当者に求められるスキル:
- z/OSMF構成、運用
- RESTの理解、問題判別
- HTTPS(TLS)
- OpenAPIドキュメント(Swagger)
- テストツール
- curl, SwagerUI, ブラウザ
参考: REST API簡易テストに使えるツール
構成の確認や問題判別の際には、REST APIを簡易的に発行してどういう挙動を示すかを確認する必要がありますが、その時にこのようなツールは使えるようになっておくと重宝します。
一般的によく使われるツールとしては、コマンドラインで使うcurlと呼ばれるコマンド、あとはSwaggerと呼ばれるAPI定義を読み込ませてブラウザからAPI発行できるようなUIを提供するものがあったり、個人的によく使っているのは、Chromeのプラグインとして提供されているTarend API Testerというので単発のREST APIが投げられたりします。
他にも有名どころだとPostmanやJMeterといった負荷をかけられるツールなどもあったりしますので、このようなツールの利用も使えるとよいでしょう。
First Step
SSHやRESTあたりの重要性というのを示してきましたが、これらをあまり使っていなければまずは使ってみるところから始めましょう、というのをおすすめしたいと思います。
これで何をするのかという話ですが、まずは、VS Code + Zowe Exlorerでz/OSMF経由でアクセスできるようにする、SSH ClientからUSSにシェルで入って操作する、という環境を整備するのが分かりやすいと思います。
将来的にモダナイゼーションを進めるのであれば、ここは避けては通れない部分だと思いますので、この辺りは必須の構成だと考えてなるべく早めに活用を検討いただくのがよいのではないかと思います。
OSのバージョンアップ等を行う際には、現行踏襲という殻を打ち破って活用を検討いただくのがよいのではないでしょうか。
参考: