技術コラム：メインフレームの画面移行 webブラウザ対応するときの注意点

今回は、メインフレームの画面移行についてお話しします。メインフレームの画面は、各メーカーが用意した画面定義ソフトウェアで画面定義して作成しています。オープン化する場合も、通常は、オープン製品であるメーカーの画面定義ソフトウェアを利用して移行する場合が大半を占めています。

今後もホスト同様に運用していく場合は、安価で有効な手段となっています。しかし、オープン化する機会に、現在の主流である画面をWEB化したいと言うニーズがある事も事実です。その場合、画面をHTML、JSP、およびjavaを使用した本来のオープンソースで開発する必要があります。これまで開発、運用に関わってきた人材とjava開発を行う人材の両方が必要となります。

いずれは、すべてオープンソースで開発を進めていくとしても、一時的に要員コストの増加は否めません。本コラムでは、メインフレームの画面をHTML、JSP、およびjavaを使用したオープンソースへ移行して、移行後の保守をどのように行なうのかについて考えます。

画面移行時のポイント

メインフレームの画面をWEB化するにあたり、移行のポイントは次の通りです。

• 画面を利用しているプログラムとWEB化する画面のインターフェースを決定します。
• 画面を利用しているプログラムを改修します。
• 画面の操作や制御を行う機能をJAVA言語などで開発します。
• 画面をHTML、JSPなどでWEB開発します。

画面を使用する場合、その画面を利用して稼働するプログラムがあります。メインフレームの場合、大半がCOBOL言語で作成されています。まずは、そのCOBOLプログラムと画面とのインターフェース項目を決定する必要があります。既存のCOBOLプログラムと同様なインターフェース項目を設定することで、COBOLプログラムの改修は最小限に留めることができます。

また、画面操作や制御を行う機能については、JAVA言語などで共通化して開発することで、メインフレームで行っている画面操作や制御をある程度実現できます。あとは、画面定義体を参考に画面をHTMLやJSPなどで開発します。このような段取りで進めていきます。

移行後の運用について

移行後は、画面についてはHTMLやJSPで保守メンテナンスを行います。また、画面操作や制御についても、共通で開発したjava言語などを保守メンテナンスを行う必要があります。一方、バックエンドで稼働するプログラムは、COBOL言語を保守メンテナンスすることになります。

バックエンドで稼働するプログラムもjava言語化出来れば言語が統一されて問題はありませんが、長年稼働してきたプログラムをjava化するのは、それなりの期間とコスト、およびプログラムの内容を理解する必要があるため容易ではありません。

これまで開発、運用に関わってきた要員と、java開発を行う新しい要員、もしくは、現在の要員にWEB開発を出来るように教育し、時間をかけてスキルアップを図る必要があります。

保守メンテナンスの支援ツールの活用

この様に現在の運用、保守要員は、HTML、JSP、およびjavaを使用した画面をWEB化するだけでも、オープン化した後の保守メンテナスは容易ではありません。そこで、弊社では画面をWEB化する際に、HTML、JSP、およびjava言語のスキルをあまり必要としないで、現在の保守要員でも運用できるよう、以下の支援ツールを用意しています。

• 画面定義をEXCELで行ないWEB化に必要なJSP、javaを生成します。
• 画面操作や制御を行う共通モジュール（java言語）を提供します。

メインフレームの画面定義をもとにEXCELにて画面定義を行います。EXCELで作成した画面定義情報からJSPやjavaを生成します。また、画面操作や画面制御についても、お客様の要望に合わせた共通モジュールカスタマイズしてJAVA言語にて提供しますので、HTML、JSP、およびJAVA言語の知識がなくても保守、運用が可能となります。オープン化したシステムは、javaなどが稼働する環境ですので、その後のWEB化は、新規で開発することも可能です。

まとめ

この様に画面をオープン化移行するには、WEB化に伴う保守要員のスキルアップや、期間など考慮すべきポイントが多数あります。

一気に移行するのではなく、まずは、オープン化の環境でWEB化を図り、徐々に保守要員のスキルアップを図りながら、オープン化を進めていくことをお勧めします。