メインフレームシステムの未来像

By 岡田 - Posted: 2013/11/01 Last updated: 2013/11/01 - 2 Comments
印刷用ページの表示 印刷用ページの表示
現在抱えているメインフレームの問題点から、これからのメインフレームの未来像を考えてみました

VOS3をベースに書いていますが、他のベンダーでも当てはまる部分はあるかと思います。

1.現在のシステム生成、PP(アプリケーション)組み込みなどを行う時の問題点

新たにシステムを構築をする時、OSのバージョンアップ、PPの組み込み、
SUT(PTF)でバグ修復をする場合の問題点です

インストール

*本作業の前に作業に必要なデータが格納されたCDーROM媒体を入手します

1)CDーROMの内容をCDーROMドライブ搭載パソコンからftpを起動してVOS3システム上に”バイナリ転送”でアップロードする
2)アップロードしたデータをDMFVTLSなどで仮想テープとして認識させます
3)作業JCLを実行してデータをインストールする

<本作業における問題点>
#CDーROM媒体など(日立では”出荷媒体”と呼んでいます)を入手する必要がある
以前は、磁気テープなどが主流でした。何らかの媒体を製品出荷部門から提供してもらう事に変わりありません。このため、、

4)媒体を提供してもらうのに時間を要する
5)媒体不良を無視出来ない
6)ftpが実行できるCDーROMドライブが搭載されたパソコンが必須

CDーROMの媒体が陳腐化した時、また新しい媒体を模索する必要があるので、媒体が不要な状態に持っていく必要性を感じていました

そこで、新しい手法として思いついたのが、次の方式です

インストール改善1

仮想ディスクの技術を使って、媒体管理部署のデータそのものに通信回線などでアクセスできるようにして、直接読み込むのです

この手法で、、
7)媒体での出荷を原則的に行わない事で、提供スピードの迅速化や緊急で対策が必要なバグの対処が容易となる
8)媒体不良を考慮する事が不要になる

今後の課題としては、、
9)物理的な通信回線の確保の検討
10)仮想ディスクとして認識させる場合のセキュリティ面の検討 など


2.メインフレームシステムの将来像

現在の世の中を影で支えている大型汎用機(メインフレーム)システムですが、稼働しているVOS3システムは以下の根本的問題点を持っています。

11)サイトで稼働しているシステムには、システムボリュームが存在します。
このボリュームの中にVOS3の基本データの他に各サイトでの個別情報が混在している事により、OSのバージョンアップを行う際、多大な労力と時間、そしてOSの変更による不安(デグレードなど)を顧客は抱える事になります。

 そのため、新しいOS(機能のリリースなど)に変更したくても、対応できる要員の確保が出来なかったり、OSの更改によって発生するリスクを恐れて、システム自体にメスを入れることを拒絶するサイトがあります

12)大規模災害を考慮してBCPなどを確保している現代のシステムですが、システムボリューム自体が被災した時のリカバリ方法については全てのシステムで確保する必要があります。
 しかし、リカバリ方法を確保していても、スムーズに回復させるには人の介在が必要なため日頃からの訓練は必要です。この部分の作業品質は顧客が手がける費用に依存されているため、品質の確保が保証できません。

VOS3の場合、システムに障害が発生して、システム自身の再起動が必要となった時、原因調査(製品提供側の潜在バグの可能性調査)のため「高速ダンプ(JSLDUMP)」の取得を行います。
ところが、この高速ダンプの取得能力は各サイトに依存されているのが実情です。サイトによっては緊張のあまり、ほとんど実施した事がない作業がスムーズに出来ずに、再起動の時間を遅らせる事にもつながります。

この、”高速ダンプの取得”については昔から懸念していた事であり、抜本的対策を必要と感じている部分です

13)他の投稿で既にご説明しておりますが、「セキュリティ」、「コンプライアンス遵守」、「機密情報漏洩防止」といった言葉で、システムを保守するソフトウェア要員ですら、日頃から容易にシステムに触れることが出来なくなっています。TSS(TSO)にログインする事すらです

この結果、今後、要員の作業品質が低下していき、これがメインフレームシステムを縮退化させる原因にもなりかねない大問題だと思っています

もっと、サイト側でのOSにかかる負担を軽くしたりするような抜本的対策を感じて居ました

そこで、考えた手法が以下のイメージです。
クラウドやデータセンタといった技術をメインフレームにも持ち込む事です

最終構想

VOS3を含めて、OSには工場から提供される基本部分と、各サイトで個別に準備が必要となる情報(ゼネレーション情報、通信定義、システム設定を決めるパラメタなど)に分けられます。

サイト個別情報は従来どおり各サイトで持ちますが、基本部分は切り離して、管理センタとのレプリケーションもしくは媒体提供という形で持つのです。

この事により、、
14)OSのバージョンアップや機能追加が必要になった場合、基本部分を容易に変更が出来るようになるため、業務時間外に切り替えテストをするといった事前準備を積み重ねる事により、デグレードに対する懸念が極小化できます。顧客が安心してOS更改を判断しやすくなると考えます

15)新しいOSへの切り替えが容易になっていく事で、古いOSの保守期限を早める事が可能になってきます。その部分に掛けている要員を他の部分にシフトできるというメリットが製品提供側にも生まれてきます

16)OS基本部が他の部分にある事で、サイトが障害などでトラブルがあっても迅速にシステムボリュームの回復が容易になってきます(その半面、製品提供側はデータを冗長化をするなどの環境強化が求められると考えます)

17)システムの変更作業が製品提供側で行う事が可能になってくるため、現在各サイトで抱えている要員を製品提供側に集約させる事が可能になり、要員の作業品質を高い状態で維持する事が可能になってきます

18)緊急に対策が必要なSUT(PTF)も迅速化が可能になってきます

これにはVOS3の改造が必要ですが、NUCLEUSやPARMLIBなどからサイト個別情報を分離させる事は容易な事と考えていますので、技術的にはそれほど難しくないと考えています


<最後に>
この手法は、先日、日立のある部署に公開しました。
私は日立に(社会人として)育てていただいた恩がありましたので、、

しかし、本手法は日立だけが行う事ではなくて、メインフレームを抱えるすべてのベンダーが行うべき課題と考えましたので、ここでの投稿を決断しました。

メインフレームの未来を明るくするため、ぜひ本手法を検討して下さい。
Posted in つぶやき・雑感 • • Top Of Page

2 Responses to “メインフレームシステムの未来像”

Comment from 野良猫
Time 2013年11月3日 at 19:37

提案しているシステムができると良いですネ。

ちなみに、MSPでは障害発生でシステムダウンした場合は、自動でSADUMPを取得する事ができます。

Comment from okada
Time 2013年11月3日 at 21:20

野良猫さん

コメントいつもありがとうございます
MSPでは、自動で取得できるんですね。羨ましいです

どうしてVOS3は駄目なのだろうか、、
メインフレームには、SVP(サービスプロセッサ)があります。パソコンのBIOSのようなものと考えて下さい

SVPで監視して、自動で取得をさせることも可能になると思うのですが、、処理が重くなるので、、