IBM i のウンチクを語ろう
～ その23： サーバー比較の観点から見たIBM i -4
皆さん、こんにちは。これまで市場全体をとおして揺れ動くITトレンドを俯瞰してまいりました。黎明期からしばらくの間は統合型サーバーであるレガシーシステム、1990 年代にピークを迎えた分散型サーバーであるオープンシステム、2000 年を越えると統合型使用にも耐え得るオープンシステム、といった流行があり、更に最近はクラウドも台頭しています。この動きが意味するのは異なるタイプのシステムへの移行であり、場合によってはアプリケーションの作り直しという、負荷の極めて大きな作業を伴います。これを後押ししていたのはコスト削減欲求です。そして分散化は初期導入コスト低減を目指したのに対して、統合化はTCO（総所有コスト）、という意識の差異がありました。
コスト意識の有無とは無関係に、文字通り世界中の基幹業務システムの見直しが必須となった時期がありました。企業にとってのビジネス上の課題というレベルを超えて、アプリケーションが利用されている業種・業態によっては、各種産業や社会インフラの維持・運営がリスクに晒されてしまったのです。原因はアプリケーション内で使用する日付、特に西暦の表記法にあります。コンピュータが登場した第二次世界大戦当時以来、長らく1900年代のみしか視野に入らない時期が続きました。コンピュータ・システムは極めて高価ですから、その資源を可能な限り節約しようと、多くのアプリケーションにおいて年号表記は、四桁ではなく下二桁のみで済ませていたのですが、その工夫が裏目に出ます。2000年（00）は1999年（99）の翌年ではなく、99年遡った過去の年と見なされてしまいますので、放置すればシステムが停止ないし予期しない振舞いをするかも知れません。世に言うところの2000年問題です。企業にとっては死活問題ですので、2000年が近付くにつれてアプリケーション見直しの機運が高まります。数字二桁を削減したところで効果は微々たるものしか期待できないような気もしますし、忘れた頃になってアプリケーションンの見直しを強いられるくらいなら、最初から四桁で年号を利用しておけば良かったのに、などと部外者は思ってしまいます。
コストを削減するために別のサーバーに移行したいのでアプリケーションに手を入れよう、というのが通常だとしたら、アプリケーションを見直さなければならないので、ついでに（という表現が妥当かどうかはさておき）マシンを刷新しておこう、場合によってはコスト削減できそうな別のサーバーに移行しよう、というやや特殊な行動パターンが優先された時期でもありました。
JEITA（一般社団法人電子情報技術産業協会）のホームページに、日本国内における汎用機の年間合計出荷台数が掲載されています。NEC、日立、富士通といった国産ベンダーだけでなく、IBMやユニシスもこの統計値に含まれていますので、日本国内全数と見て良さそうです。これによると、1990年代は概ね3,000台前後であるのに対して、西暦2000年を越えたところで一気に半減、その後じわじわと減少を続け、2016年度は228台という結果に終わっています。（JEITAトップ・ページから「統計資料」、「コンピュータおよび関連装置出荷統計」、「サーバ・ワークステーション出荷実績」の順に選択してください。）2000年を挟んだ駆け込み需要と直後の反動、その後の長期的漸減傾向が見て取れます。
マシンを置き換える際は、同一ベンダー、同一シリーズの後継機を選択するのが最も自然だと言えます。アプリケーションに手を付けなければ最小限の労力で移行できますし、たとえアプリケーションを修正したとしても、システムそのものの使い勝手は旧来と大きく変わる事はないでしょう。後継機を提案するベンダーにとって安全確実ですし、ユーザー企業のIT担当者にとっても付き合うベンダーは変わりませんので、心理的にも最も負担の少ない策だと言えます。変化が無いという事は進化が無い、さらに言うと1990年代に流行り始めていたオープンの波には乗らない事を意味します。実際にシステムを業務用途に使用するユーザーからすると、時代から取り残されているといった不満が出るかも知れません。
オープンシステムへの移行は最新テクノロジーの利用を意味し、多くのユーザーにとって魅力的な選択肢であろうと思います。ただ旧来のアプリケーションはそのままでは使えませんので、何らかの形で手を入れる必要があります。汎用機で稼働しているのは最も重要な基幹業務アプリケーションですので、これをリスクに晒すわけにはいきませんし、移行できたとしてもこれまでの性能や安定性・信頼性を維持できるのかという不安が残ります。新旧システムのアーキテクチャーや、元々備えている機能セットの差異が大きいと、移行リスクはそれなりに大きくなります。汎用機における基幹業務アプリケーションはCOBOL言語で記述されるケースが多いわけですが、オープンシステム用にもCOBOL処理系は存在します。だからと言って、それが全てではない事に注意する必要があります。
汎用機でサポートされる文字コードは、典型的にはIBMのEBCDIC、ないしそこから派生した各ベンダー固有の体系が採用されています。EBCDICの特徴は、英数字などのシングル・バイト文字と漢字やひらがななどのダブル・バイト文字を混在させる際に、ダブル・バイト文字列前後に標識となるコード（シフト・アウトとシフト・インと呼ばれます）を埋め込んで表現します。オープン系で採用されるシフトJISにはこのような標識を含めない代わりに、各文字に割り当てるコードの領域を分ける事によってシングル・バイトとダブル・バイトを識別します。すなわち汎用機からオープンシステムへの移行は、標識コードの有無により文字列の長さが変わる事を意味します。そしてこれはデータベースのカラムの長さや、画面設計におけるデータ入出力領域の大きさに影響し、さらにはこれらを利用するアプリケーションにも波及します。
どのようなシステムでもそうなのですが、印刷を行おうとすると、システムに比べてプリンタの速度はあまりにも遅いために、一旦スプールと呼ばれる待機用記憶域に印刷データが置かれ、その後時間をかけて順次印刷されてゆきます。汎用機ですと印刷終了後もスプールのデータは残りますので、さらにそれを活かしたアプリケーションを利用できます。一方例えばWindowsの場合は、スプールのデータはプリンタに送信されると消滅しますので、同様の事はできません。アプリケーションを移植できたとしても、スプールに代えて印刷データを残すような仕組みを新たに作らなければなりません。
1～2の例を挙げたに過ぎませんが、汎用機とオープンシステムのアーキテクチャーの差異を埋めるためには、単なる移植に留まらず、ツールやアプリケーションなど何らかの手段で、相当量の機能を作り込まなければなりません。新規開発部分があればそれだけバグが入り込む余地が増え、安定稼働に対するリスクも大きくなります。特に基幹業務アプリケーションの移行作業においては、この状態は望ましい事ではありません。とても2000年問題を解決する「ついでに」こなせるような作業量に収まらない事実に直面します。
以上見てきたように、後継の汎用機もオープンシステムもなかなか決定打とはなりません。ここで第三の選択肢として浮上するのがIBM i です。次回は汎用機の基幹業務アプリケーション移行における安全性とか、オープン性の実装という観点から、IBM i を眺めてみたいと思います。ではまた
