はじめに
主にオンプレ環境で使われるzSystems(z/OS)のようなメインフレームは負の遺産のように語られることも多いですが、世界的にみても金融系システムを中心としてミッション・クリティカルなトランザクション処理のインフラとして重要な役割を担っているのは紛れもない事実です。
2023/3/16にガートナー株式会社は以下のようなプレス・リリースを出しています。
Gartner、オンプレミスに関する展望を発表
...従来型 (Old) のオンプレミス・テクノロジは衰退し、クラウド・ネイティブの要素を取り入れた新しいオンプレミス (Newオンプレミス) のテクノロジへのトランスフォーメーションが進み、結果としてユーザー企業はオンプレミスの在り方を変えざるを得なくなるとGartnerはみています。
...
インフラ戦略およびイノベーションを率いるITリーダーは、Newオンプレミスへの理解を深め、備えを強化し、自社システムの将来を考察するとともに、「目利き力」を獲得するためにも、スキルやマインドセット、新しいスタイルを身に付ける必要があります。既に時代は、オンプレミスかクラウドかを問う時代ではなくなってきています。むしろ、Oldオンプレミス+Oldクラウドか、それともNewオンプレミス+Newクラウドか、の議論がますます重要になってきていると捉えることが肝要です。
オンプレかクラウドかという議論は一段落しつつあり、適材適所ということでIBMさんもHybrid Cloudというのを戦略の軸に据えています。
zSystems(z/OS)は可用性、パフォーマンス、セキュリティーといった観点でのハイレベルな要件を満たすプラットフォームとして長年にわたって使われ続けてきました。コアなロジックを動かすインフラ部分は継続して実績のある仕組みを使いつつ、今後は開発環境や運用など使い勝手に関する部分はなるべく"オープンな技術"を取り入れ、"Newオンプレミス"への変革を進めることが必要になってくると思います。
当記事では、z/OS上で利用できるオープンな技術について考えてみたいと思います。
※後から指摘されたのですが、z/OS Unix System Serviceを当記事では"USS"と省略して表記していますが、どうやら略称としては"z/OS Unix"というのが正式のようです。いつも慣例的に"USS"と表現してしまっているので、当記事でも"USS"と表記したままにしておりすのでご容赦ください。
z/OSで活用できるオープンな技術
z/OSの運用や開発で利用できるオープン系で利用されている技術の例を挙げてみます。
Technology | 補足 |
---|---|
USS(Unix System Service) | POSIX準拠 |
SSH | SSHクライアントからUSSに接続可能 Jenkins、Ansibleなど外部システムからの連携でも利用される |
REST API | z/OSMFが各種z/OS操作のREST APIを提供 |
VS Code, Eclipse | COBOLやPL/Iのエディター/開発支援ツールのUIとして利用 |
Git | ソース管理の仕組みとして利用 |
Jenkins | パイプラインで自動化を組み込み USS上のJavaベースのエージェントが利用可能 |
Ansible | z/OS操作用のCollectionが提供される |
シェル・スクリプト | USS上のシェル・スクリプトからGroovyのスクリプト実行やPython実行など各種フローを記述可能 |
Java | IBM Java SDK for z/OSが提供される |
Groovy | ビルドのスクリプトをGroovyで記述可能 (要DBB) |
Python | IBM Open Enterprise SDK for Pythonが提供される 無償のZOAU(IBM Z Open Automation Utility) を使用すればJCLの代わりにPythonで各種操作を記述可能 |
Node.js | IBM Open Enterprise SDK for Node.jsが提供される |
Go | IBM Open Enterprise SDK for Goが提供される |
上に上げたもののうちGroovyのAPIを提供するDBB(Dependency Based Build)は有償製品ですが、それ以外は基本的に追加のS/Wライセンス・コスト無しで利用できます。
USSとMVSの関係
上に挙げたような新しい技術を使って各種ツールとの連携を行ったり自動化スクリプトなどを組み込むことを考えた時には、USS上で稼働させるかUSS上のコンポーネントとの連携が必要になることが多いです。
一方で、運用や開発プロセスで実際に行いたいことは、MVS上z/OS固有の操作(JCLサブミットやMVSコマンド実行など)やMVS上のリソース(データセットやJESスプール)へのアクセスということになります。
つまり、USSからMVS上の操作をどのように行うか、USS↔MVS間の橋渡しがどのように行えるかということが重要になります。
ここでは、USSや外部システムからMVS上の操作を行う手法についていくつか見ていきます。
USSのベース機能
例えば、以下の辺りの操作はUSSが提供している標準機能(コマンド)で行えます。
USSファイル・システム - MVSデータセット間でのファイルのコピー: cp コマンド
TSOコマンド実行: tsocmd コマンド
JCLサブミット: submit コマンド
USSではz/OS Shellというkshライクなシェルが提供されます。上のようなコマンドを使ってある程度の自動化の仕組みをシェル・スクリプトで作りこむこともできます。
ちなみにUSS上でMVSデータセットを扱う場合の表記は以下の記述に従います。
参考: Specifying MVS data set names in the shell environment
標準機能だけだとさすがに厳しいですが、REXXのAPIなどを使ってMVSコマンドやSYSLOGなどの操作を行う機能を作りこむということもできます。以下、以前自前で作ったユーティリティー(スクリプト群)です。
参考: Lightweight Command Utility
USS上でMVS上のリソースを扱うスクリプトを用意し、SSHサーバー(SSHD)が構成されていれば、外部のスクリプトやプログラムからはSSHクライアント機能が使えれば容易にそのスクリプトを呼び出すことが可能となります。
ZOAU (+ Python)
上に示したUSS上の標準機能(標準コマンド)だけだと利用できるMVS関連機能は限られますが、ZOAU(IBM Z Open Automation Utilities)というツールを使用すると、USS上で使用できるMVS関連の操作の幅が広がります。ZOAUは無償で利用可能なツールで、USSシェルのコマンドだけでなく、Python用のAPIも提供されています。z/OS版のPythonも無償で利用可能です。
参考:
ZOAU V1.2 - Installing and configuring ZOAU
ZOAU V1.2 - Shell command rererence
ZOAU V1.2 - ZOAU Python API reference
IBM Open Enterprise SDK for Python
ZOAUをシェル・スクリプトやPythonのスクリプトなどから使用することでMVSに対する操作の作りこみを行うことができます。また、この仕組みを利用したAnsibleのモジュールも提供されています。つまり、Ansibleのターゲットノードの1つとしてz/OSを含めることも可能となります(AnsibleのPlaybookとしてz/OSの構成等を管理)。
参考: Red Hat Ansible Certified Content for IBM Z
DBB + Groovy/Java
DBB(Dependency Based Build)という有償の製品が提供されています。これはアプリケーションのビルド(コンパイル/リンク)関連のサポート機能がGroovy, JavaのAPIとして提供され、MVS操作に関するものも含まれます。
参考:
IBM Dependency Based Build V2.0 - DBB APIs
GitHub - DBB examples
さらに、このDBBを使用したビルドの仕組みを汎用化したzAppBuildというフレームワークがOSSとして提供されています。このzAppBuildを利用してビルドを効率的に行う機能拡張がVS Code および IDzにて行われています。また、Jenkinsなどのパイプラインからもビルドの制御が行いやすくなっています。
z/OSMF
z/OSMFではMVSデータセットやUSSファイルを操作するためのREST APIが提供されていますので、これを利用して外部のRESTクライアントからz/OSMF経由でMVSの操作をすることができます。
参考: Using the z/OSMF REST services
HTTP/RESTが発行できればよいので、HTTPリクエストを発行できる様々な外部コンポーネントからMVS操作が行えるということになります(USS上のプログラムなどからも利用できます)。
また、Zowe CLIというコマンド・レベルのインターフェースを提供するツールや、さらにそれを利用したVS CodeのExtension: Zowe Exploreなど、z/OSMF提供のREST APIを内部的に使用したツールも提供されています。
USSを扱う上でのTips
USSシェルのユーザー・インターフェース
PCOM - OMVS
PCOMなどの3270端末エミュレーターを使用する場合、TSO CommandでOMVSと入力するとUSSのシェルに接続できます。
ここからUSSのシェル・コマンドなどが投入できますが、非常に使い勝手が悪いです。
特にこのUIからだとエディターとしてviが使えないので、oeditというコマンドを使う必要があります。これはMVSデータセットをISPFのエディターで編集するのと同じイメージでUSS上のファイルを編集できます。
PCOMに慣れ親しんだ人にとってはあまり苦ではないかもしれませんが、Unix/Linuxスキル保有者にとってはちょっと使っていられないUIだと思います。
Unix System Serviceと言っているのにUnixっぽくないというか、Unix互換であることの利点が全く生きていないというか...。
SSHクライアント(teraterm)
z/OS上でSSHサーバー(SSHD)の構成/稼働をしておけば、teratermに代表されるようなSSHクライアントからUSSのシェルに接続することができます。使い勝手としては、正にオープン系のUnix/Linuxを使っているのと同じ感覚で操作できます。viエディターも使えます。
ただし、以下の記述の通り、日本語は扱えませんのでご注意ください。
参考: OpenSSH and globalization
OpenSSH assumes that all text data traveling across the network is encoded in ISO/IEC 8859-1 (Latin-1). Specifically, OpenSSH treats data as text and performs conversion between the ASCII Latin-1 coded character set and the EBCDIC-coded character set of the current locale in the following scenarios:
- ssh login session
- ssh remote command execution
- scp file transfers
- sftp file transfers when the ascii subcommand is specified
USSシェルでのオペレーションはteratermを使うとPCOM/OMVSに比べると段違いに使いやすくなります。
(USS扱うのにSSHが上がっていないというのは個人的にはあり得ないですね...。)
エディターとしてviの利用についてはハードルが高いと感じる方もいるかもしれませんが、その場合はファイル編集部分についてはVS CodeやEclipseベースのツール(z/OS Explorer, IDz)などを併用すればよいでしょう。
ファイル・システム
USS上のファイルはzFSと呼ばれるファイルシステムで管理されます(以前はHFSというファイルシステムがありましたがz/OS V2.5からはHFSはサポートされなくなりました)。
zFSは実体としてはMVS上のVSAMデータセットとして管理されます。このzFSをUSS上のディレクトリ(マウントポイント)にマウントして使用することになります。考え方はUnix/Linuxと類似しています。
マウントされているファイルシステムはdf
コマンドで確認可能です。
参考: dfコマンド実行例
TAGUCHI : /u/TAGUCHI : > df -k
Mounted on Filesystem Avail/Total Files Status
/u (*AMD/u) 0/4 0 Available
/u/TAGUCHI (OMVS.USER.TAGUCHI.ZFS) 2911/10800 4294966679 Available
/u/JENKIN1 (OMVS.USER.JENKIN1.ZFS) 2431/50400 4294966114 Available
/u/zoscsrv (OMVS.USER.ZOSCSRV.ZFS) 7031/7200 4294967292 Available
/u/stcdb2 (OMVS.USER.STCDB2.ZFS) 7031/7200 4294967292 Available
/u/stcmq (OMVS.USER.STCMQ.ZFS) 7031/7200 4294967292 Available
/u/cicsuser (OMVS.USER.CICSUSER.ZFS) 7031/7200 4294967292 Available
/u/stcrse (OMVS.USER.STCRSE.ZFS) 7031/7200 4294967292 Available
/u/stcdbg (OMVS.USER.STCDBG.ZFS) 6407/7200 4294967266 Available
/u/cfzsrv (OMVS.USER.CFZSRV.ZFS) 7031/7200 4294967292 Available
/u/ibmuser (OMVS.USER.IBMUSER.ZFS) 114999/118800 4294966989 Available
/javasc (ZFS.JAVASC) 567167/1008000 4294967252 Available
/var/zosconnect (ZCONEE.VAR.ZFS) 3311/7200 4294967108 Available
/usr/lpp/IBM/zosconnect (ZCONEE.ZFS) 18199/1088000 4294958803 Available
/usr/lpp/IBM/cvg/v1r18 (GO.V1R18M0.ZFS) 12695/1052800 4294954014 Available
/usr/lpp/IBM/cvg/v1r19 (GO.V1R19M0.ZFS) 2079/1038400 4294953579 Available
/usr/lpp/IBM/cnj (NODEJS.V16R0M0.ZFS) 22675/1529440 4294954079 Available
/usr/lpp/IBM/idz (IDZ.ZFS) 258503/2880000 4294955705 Available
/usr/lpp/ing (SA.V4R3M0.ZFS) 16839/144000 4294967163 Available
/usr/lpp/IBM/cyp/v3r10 (PYTHON.V3R10M0.ZFS) 18079/457600 4294956528 Available
/usr/lpp/IBM/cyp/v3r9 (PYTHON.V3R9M0.ZFS) 4039/432000 4294956998 Available
/usr/lpp/IBM/pli/v6r1 (PLI.V6R1M0.ZFS) 35399/36000 4294967289 Available
/usr/lpp/netview/v6r4 (NETVIEW.V6R4M0.ZFS) 42799/122080 4294967199 Available
/usr/lpp/mqm (MQCD.V9R3M0.ZFS) 498667/1179360 4294964594 Available
/usr/lpp/ims (IMS.V15R1M0.ZFS) 5127/270720 4294966950 Available
/usr/lpp/IBM/cobol/igyv6r4 (IGY.V6R4M0.ZFS) 647/1440 4294967255 Available
/usr/lpp/java/java11 (JAVA.V11R0M0.ZFS) 453607/1382400 4294965159 Available
/usr/lpp/java/java8 (JAVA.V8R0M0.ZFS) 15871/1232480 4294964772 Available
/usr/lpp/db2d10 (DB2.V13R1M0.ZFS) 24855/48240 4294967194 Available
/usr/lpp/cicsts (CICSTS.V6R1M0.ZFS) 799/939200 4294958499 Available
/etc/ssh (OMVS.VS01.SSH.ZFS) 623/1440 4294967279 Available
/global/zosmf (OMVS.VS01.SIZUUSRD.ZFS) 54203/144000 4294964719 Available
/usr/lpp/zcx_zos (OMVS.VS01.ZCX.ZFS) 2866391/3837600 4294967178 Available
/usr/lpp/liberty_zos (OMVS.VS01.WLP.ZFS) 509959/2304000 4294951148 Available
/SYSTEM/dev (OMVS.VS01.DEV.ZFS) 2231/2400 4294967269 Available
/var/wbem (OMVS.VS01.VARWBEM.ZFS) 43479/115200 4294963091 Available
/var (OMVS.VS01.VAR.ZFS) 23295/24480 4294967158 Available
/etc (OMVS.VS01.ETC.ZFS) 23199/24480 4294967206 Available
/usr/lpp/fonts (OMVS.VS01.FONTS.ZFS) 297519/2016000 4294967072 Available
/ (OMVS.VS01.ROOT.ZFS) 992550/3960000 4294945168 Available
/SYSTEM/tmp (/TMPVS01) 1022760/1024000 255690 Available
また、アクセスされたタイミングで動的にファイルシステムを作成してマウントしてくれる"automount"という機能も提供されています。Wazi as a ServiceのStock Imageではこの機能が/u/以下のディレクトリ(ユーザーのホームディレクトリ)に利用されています。
参考:
How does the automount facility work?
automount - Configure the automount facility
文字コード/タグ付け
USS上のファイルは基本的にはEBCDICで扱われます(IBM-1047)。ですが、AsciiベースのコードページやUnicodeなどのファイルを扱うこともできます。これを実現しているのが、ファイルに対するタグ付けや自動コード変換機能です。
参考: Controlling text conversion for z/OS UNIX shell commands
USS上のファイルでテキストベースのものは、テキストであることのタグ付けをして、そのテキストが何の文字コードでEncodingされているか文字コード情報を付与することができます。タグや文字コード情報はlsコマンドの-T
オプションで確認することができますし、chtag
コマンドでタグ情報の変更が可能です。また、この機能に関する挙動は環境変数で制御できます。
具体的な例でみてみます。
abc.txtというファイルを作成してみます。
[CICS004@EPLEX1:/u/cics004/test] echo abc > abc.txt
[CICS004@EPLEX1:/u/cics004/test] cat abc.txt
abc
[CICS004@EPLEX1:/u/cics004/test] ls -laT
total 34
drwxrwxrwx 2 0 STC 8192 Apr 7 15:14 .
drwxr-xr-x 42 0 STC 8192 Apr 7 15:12 ..
- untagged T=off -rw-rw-rw- 1 0 STC 4 Apr 7 15:14 abc.txt
デフォルトだとこのファイルにはタグ付けがされていない状態です(untagged)。中身としてはEBCDIC(IBM-1047)でEncodingされており、特に意識しなくてもcatコマンドなどで参照できます。
これをISO8859-1(Ascii)にコード変換したファイルabc_ISO88591.txt
を作成してみます。
[CICS004@EPLEX1:/u/cics004/test] iconv -f IBM-1047 -t ISO8859-1 abc.txt > abc_ISO88591.txt
[CICS004@EPLEX1:/u/cics004/test] ls -laT
total 36
drwxrwxrwx 2 0 STC 8192 Apr 7 15:20 .
drwxr-xr-x 42 0 STC 8192 Apr 7 15:12 ..
- untagged T=off -rw-rw-rw- 1 0 STC 4 Apr 7 15:14 abc.txt
- untagged T=off -rw-rw-rw- 1 0 STC 4 Apr 7 15:20 abc_ISO88591.txt
catでabc_ISO88591.txt
の中身を表示させてみます。
[CICS004@EPLEX1:/u/cics004/test] cat abc_ISO88591.txt
/ツト纂CICS004@EPLEX1:/u/cics004/test]
abc_ISO88591.txt
はAsciiベースの文字コードでEncodingされているのでそのままでは文字化けしてしまっています。
ここで、環境変数を設定し、ファイルに対して"テキスト"としてタグ付け、および、文字コードの設定をしてみます。
[CICS004@EPLEX1:/u/cics004/test] export _BPXK_AUTOCVT=ALL
[CICS004@EPLEX1:/u/cics004/test] chtag -t -c ISO8859-1 abc_ISO88591.txt
[CICS004@EPLEX1:/u/cics004/test] ls -laT
total 36
drwxrwxrwx 2 0 STC 8192 Apr 7 15:20 .
drwxr-xr-x 42 0 STC 8192 Apr 7 15:12 ..
- untagged T=off -rw-rw-rw- 1 0 STC 4 Apr 7 15:14 abc.txt
t ISO8859-1 T=on -rw-rw-rw- 1 0 STC 4 Apr 7 15:20 abc_ISO88591.txt
この状態で再度ファイルの中身をcatで見てみます。
[CICS004@EPLEX1:/u/cics004/test] cat abc_ISO88591.txt
abc
ファイルに付与された文字コード情報を元に自動でコード変換が行われて出力してくれているため、文字化けせずにきちんと表示されるようになりました!
最初にファイルが生成される際に自動でタグ付けをするような制御に関する環境変数がいくつかあります。
例えば、最初にファイルが作成されるときに(viでの新規ファイル作成など)にファイルにタグ付けをさせる場合には以下のようにFILETAGオプションでAUTOTAGを指定します。_CEE_RUNOPTS="FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)"
また、シェルのリダイレクトした結果をテキストとしてタグ付けしたい場合は、以下のように_TAG_REDIR_OUTにTXTを指定します。_TAG_REDIR_OUT=TXT
[CICS004@EPLEX1:/u/cics004/test] export _CEE_RUNOPTS="FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)"
[CICS004@EPLEX1:/u/cics004/test] export _TAG_REDIR_OUT=TXT
[CICS004@EPLEX1:/u/cics004/test] echo bbb > bbb.txt
[CICS004@EPLEX1:/u/cics004/test] ls -laT
total 40
drwxrwxrwx 2 0 STC 8192 Apr 7 15:56 .
drwxr-xr-x 42 0 STC 8192 Apr 7 15:12 ..
- untagged T=off -rw-rw-rw- 1 0 STC 4 Apr 7 15:36 aaa.txt
- untagged T=off -rw-rw-rw- 1 0 STC 4 Apr 7 15:14 abc.txt
t ISO8859-1 T=on -rw-rw-rw- 1 0 STC 4 Apr 7 15:20 abc_ISO88591.txt
t IBM-1047 T=on -rw-rw-rw- 1 0 STC 4 Apr 7 15:56 bbb.txt
特に外部のシステムとの連携を行う際には、USS上のファイルをどの文字コードで扱うか、タグ付け、文字コードの情報は適切に付与されているか、というのを意識しなければならないことが多いのでご注意ください。
参考:
chtag
_BPXK environment variables
FILETAG
sh - Shell variables for automatic conversion
USS-MVS間でのファイル・コピーの注意
USSのシェルからcp
コマンドを使うことで、USS↔MVS間でのファイルのコピーができます。
【コマンド例】
USSファイル⇒PDSメンバー: cp /temp/test.txt "//'HLQ.XXX.YYY(TEST)'"
PDSメンバー⇒USSファイル: cp "//'HLQ.XXX.YYY(TEST)'" /temp/test.txt
USSファイル⇒PDSメンバーのコピーの際、上で示したタグ、文字コード指定について注意が必要です。
文字コードとしてIBM-1399などの日本語文字コードを指定してテキストとしてタグ付けしていて、ファイル中にDBCS文字が含まれている場合、ファイルのコピーがされない場合があります(コマンドの戻りとしてエラーメッセージが何も表示されないが、ファイルがコピーされない)。
USSファイルからPDSにファイルをコピーする際は、chtag -r
コマンドでタグを削除して(untagged)からコピーするようにしてください。
例: chtag -r /temp/test.txt
まとめ
z/OSでも使えるオープンな技術は、ほぼUSS上で稼働するかUSS上のコンポーネントとの連携が前提になっています。さらに、外部との連携でよく使われるのがSSHです(これもUSS上に構成されます)。SSHサーバーを立てておけば、SSHクライアントからの接続ができるようになりますので、オープン系のUnix/Linuxと同じような使い方ができるようになるため、活用のバリエーションが大幅に広がります。
また、外部連携という意味ではz/OSMFが提供するREST APIも有用な機能と言えます。Zowe CLI、VS CodeのExtension(Zowe Explorer, Z Open Editor)に代表されるように、これを利用した便利なツールが提供されてきています。
つまり、オープン系でも利用されている標準的な技術をz/OSでも活用するためには、
USS、SSH、z/OSMF(REST)辺りの利用は必須である
と考えていただいた方がよく、これらを軸としてその他やりたいことに応じて適宜新しい技術を組み込んで使っていく、ということを検討するのがよいと思います。
z/OSはIDE、Git、Jenkins、Ansibleなどと連携できますよー、というように、パッと見は美しい簡素化された絵が描かれている資料も多いですが、内部的にはここで示したような仕組みが使われることになります。役割分担を明確にして、「開発者やオペレーターにはあまりz/OS固有部分を見せずに使わせる」ということをするためには、インフラを整える技術者としてはそれを実現するために内部的に使われている泥臭い仕組みをきちんと理解し、カスタマイズできるようになることが肝要です。
USS, SSH, z/OSMFはz/OSのベースに含まれる機能ですので、追加コストなしですぐにでも利用できます。「今まで使っていなかったから...」と毛嫌いせずに、Newオンプレミスへ向けた変革のため、若手技術者のために積極的に利用していくようにしましょう!