はじめに
新卒から4年ほどメインフレームで構築されたシステムの機能追加に携わってきました。部署異動前にアサインされた最後のプロジェクトで今回アプリだけでなくハードについても大規模な変更を加えるプロジェクトにアサインされたので、これを機にまとめてみることにしました。
ちなみに、今回対象とするメインフレームは富士通社製のメインフレーム（MSP）だが基本的な仕組みはIBM社製のものと変わらないはずです。
メインフレームのアーキテクチャ
メインフレーム（MSP）の構成は下の図の通りです。WS（ワークステーション）やサーバ・メインフレームなどの外部システムとの接続についてはネットワーク制御を行うVTAMで管理し、オンラインの処理分散機能を提供するIDCMで外部からのリクエストを溜め込んだ上で、オンライントランザクションを管理するAIMでオンライン制御・データベース制御・ログ制御を行っています。
ちなみにMSPとは富士通社製メインフレームのOSの名前です。MSPの他にはXSPがあります。MSPが比較的大規模なシステムに使われるのに対して、XSPは比較的中規模のシステムに使用されるらしいです。（個人的に国産ハード＆OSというところにロマンを感じます）
メインフレームを構成するミドルウェアについて
VTAM （Virtual Telecommunications Access Method ）
ネットワーク制御を担当するミドルウェアです。TCP/IPの他にxNA（IBMであればSNA、富士通であればFNA）と呼ばれる各社独自のプロトコルに対応しています。機能として、ネットワークの制御、ノードの管理、通信サービスの提供を担当しています。
IDCM (Integrated Data Communication Manager)
AIMのDCMSと連携してオンライン処理を制御します。WSからの要求に対する分散処理機能（要求メッセージを溜め込む機能）も提供しています。
AIM （Advanced Information Manager）
メインフレームの堅牢性・高性能を支える根幹となるミドルウェアです。次の章で詳しく説明します。外部システムからのオンライン制御を担当するDCMS、データベースのマネジメントを担当するDBMS、ログ情報を管理するISMSというサブシステムで構成されています。
AIMのコンポーネント
外部からリクエストが発生した時のフローは下図の通りです。WSからの要求メッセージをIDCM内のDCバッファに溜め込み、次にメッセージはDCMS内のSMQNにキューとして格納されます。このSMQNがユーザが作成したオンラインプログラムに紐づくため、メッセージはSMQNより各オンラインプログラムに渡されます。
また、オンラインプログラムはDBMSを介してDB（ネットワークDB）を制御できます。DBの制御には、SQLのようなDBを利用するための命令文(GETとか）が利用できます。
DCMS (Data Communication Manager Subsystem)
WSからの要求メッセージと起動するプログラムの紐付けおよびメッセージの受け渡し機能を提供しています。外部からのオンライン要求は、IDCM（DCバッファ）を経由して、DCMSのMQN(Message Quene Node）のSMQN（Secondary Queue Node）というキューに溜まっていきます。このSMQNは対外的に見れば、WSと紐づき、内部的にはユーザーが構築したオンラインプログラムと紐づくため、「各WSとオンラインプログラムの紐付け」というオンライン制御で重要な役割を担っています。
なお、メッセージがSMQNに格納されたかどうかの監視は、システムACPが行っています。システムACPはMQNと紐付いており、MQN内のSMQNにメッセージが格納されたら、そのSMQNに紐づくオンラインプログラムをシステムACPが起動します。
DBMS (Data Base Management Subsystem)
RDB（Relational Data Base）およびNDB(Network Data Base)のデータベース処理機能、データベースのリカバリ機能や排他制御機能を提供しています。一般的なRDBMSと違うところは、ひと昔前のDBであるNDBをサポートしていることです。
NDBはデータベースの構造が複雑になる（OWNER、MEMBERの親子関係）点や、その複雑な構造をアプリ側で理解しておく必要がある点などの弱点から、現在のサーバ・クラウドベースのシステムではほとんど利用されていません。しかし、メインフレームで稼働しているシステムは歴史があり、かつデータの移行に障壁がある（金融系データなど）あるシステムが多いため、現在もNDBをサポートしています。
ISMS (Integrity and Schedule Management Subsystem)
DCMSおよびDBMSと連携し、オンラインデータベースの保証機能を提供しています。AIMにはデータベースに対するトランザクション中に障害が起こった場合、トランザクション前の状態に戻すリカバリ機能がありますが、その機能をISMSが担っています。
個人的に面白いと思うところ
セション内でstate管理する仕組みはReact × Reduxと似ている
メインフレーム・WS間の操作には、サーバ・クライアント間の画面操作と同じようにセションという概念が存在します。（メインフレームの概念が継承されたという理解が正しいかもしれません）セション内で複数の画面を読み出す際、画面に応じて読み出されるオンラインプログラムは変わりますが、プログラム内に定義されたSPA(Scratch Pad Area)という領域を各プログラムは共有することができます。
これにより、前にDBから読み出したレコードを再利用したい時、再度DBを読み出すことなくSPAに書き込まれた内容を読み込めば良いので、IO性能が上がります。この考え方が、ちょうど今触っているReact × Reduxに似てて面白いなと思いました。
直接アドレス指定してDBからデータをGETできる
DBMSでは、RDBMSのようにGET文を使用してデータを取得できますが、その際、検索したいレコードのアドレス（IDみたいな抽象的ものではなく、対象のレコードが何バイト目にあるのか？というとても物理的な値です）を取得することができます。そのため、「取得したアドレスの8バイト先から6バイトを取得する」みたいな記述ができるのでとても自由度に富んだ処理が行えます。（ただ、アドレスを直接操作するなんて危なすぎるので、共通のサブルーチンが提供されていることがほとんどのようです）
終わりに
メインフレームのアーキテクチャについて簡単ですが振り返りがてらまとめてみました。参考になれば幸いです。
コメント