メインフレームオルタナティブ：伴大作の木漏れ日（1/3 ページ）

日本のユーザーは、メインフレームにいまだに固執するのか。このコラムが、メインフレームとの決別を検討している企業ユーザーの参考になればと思う。

[伴大作，ITmedia]

伴大作の木漏れ日の記事一覧はこちら。メインフレームに関するブロガーの意見はこちらです。

　メインフレームのリプレースを図る手段として日本HPは6月初旬、HPノンストップサーバ（旧Tandem）製品と東京システムハウスのレガシーマイグレーション専用ミドルウェア「AJTOOL」を組み合わせ、容易で安価な移行を可能にする新サービスを提供すると発表した。

　「AJTOOL」はこれまでメインフレームのオープンシステムへの移行で実績を持つ東京システムハウスが長年培ってきたメインフレーム・マイグレーション・サービスのツールだ。システムインテグレーターを対象に提供してきた。

　個人的には今回のHPの挑戦を応援したいと思ったが、その前に、なぜ日本のユーザーは、メインフレームにいまだに固執するのかを明らかにしたい。このコラムが、メインフレームとの決別を検討している企業ユーザーの参考になればと思う。

メインフレームリプレースに関わる問題

　メインフレームリプレースと一言で片付けられているが、実態は複雑だ。わたしは20年近く企業ユーザーへの取材を重ねてきた。メインフレームでは、1つのプロセッサ（ときには複数のプロセッサにまたがることもある）上にアプリケーションごとにミドルウエアあるいはI/Oが定義され、それらのアプリケーションが構築され、複数のシステムがマシンで動作しているので、まるで迷路のようになっている。

　当然のことながら、メモリや外部記憶装置、端末やプリンタは複数のシステムで共同で動く場合もあれば、特定のシステムでしか動作しないものもある。

　従って、メインフレームリプレースを行おうと思いついても、これらすべてのシステムに詳しくなければ全く手がつけられない。

　また、メインフレーム＝COBOLという「誤解」がある。確かに、メインフレームのプログラミングに関し、COBOLが主要言語として使用されているのは一般的だが、それだけとは限らない。一番、気を付けないといけないのはマシン言語で記述されているケースだ。

　特に製造系で使用されているメインフレームでこのようなケースが多く見られる。事務系でも、初期に開発されたシステムではマシン言語あるいはアセンブラで記述するのは当時極めて一般的だったからだ。

　これらの言語が分かっても油断はできない。当時はメモリが非常に高価だったので、できるだけメモリを消費しないようにプログラム側で細工されている場合がよくあった。これらはプログラマーの職人芸のようなもので、同時に開発に携わっていた人たちでもよく分かっていないことがあった。

　また、メインフレームが導入された初期のころ、多くのユーザーは慢性的なプログラマー不足の状態にあったため、ベンダーから全面的な協力を受けていた。従って、メインフレームのシステムそのものをユーザーが完全に把握できていないケースもあった。

　このように、メインフレームのリプレースは単にホストサーバをリプレースすると簡単にいえる話ではないのだ。