ビジネスロジックを活かしつつ
最新機能を使ってモダナイゼーション
IBM iの前身であるAS/400が誕生してから、30年以上が経過しました。その間にプロセッサなどのハードウェアやOSなどのソフトウェアは、大きく機能を向上させました。
処理速度の高速化などハードウェア面の向上は、多くのユーザーが体感しています。バージョンアップのたびに細かく確認するのはなかなか難しいですが、アプリケーション開発に関わる機能も大幅に強化されています。すでに20年以上前からILE環境を搭載し、RPG言語もRPG ⅢからILE RPGと呼ばれるRPG Ⅳへ、さらにフリーフォームRPG(以下、FF RPG)へと進化しています。
しかし残念なことに、ILE RPGを使いこなしているケースはまだ少数で、大多数の開発者はRPG Ⅲとそのアプリケーションをそのまま継続使用しています。これは、類まれな資産継承性という、他サーバーには見られない優位性を備えるIBM iだからこそ可能です。今も、数十年前に開発された多くのアプリケーションが現役で稼働しています。
会社の業務が大幅に変更されない限り、安定稼働しているビジネスロジックを、膨大な時間とコストを費やして、わざわざ作り直す必要はないとユーザーは考えます。
しかし企業のITを取り巻く環境は急速に変化しており、業務アプリケーションも時代に応じて進化することが求められています。
IBM iはこうした時代の変化やIT環境の多様化に即応できるよう、常に最新テクノロジーを活用できるサーバーとして進化し続けています。その進化はハードウェアだけでなく、RPGも含めたアプリケーションの実行環境や開発環境にも及んでいます。
RPGで開発された業務アプリケーションがあるならば、その安定したビジネスロジックを有効活用したうえで、IBM iの進化した機能を最大限に活用し、現在のビジネスニーズに合致した改修・刷新(モダナイゼーション)を実現する。それが企業を成長させる最善の選択ではないでしょうか。
最新FF RPGは
人材確保の課題を解決する
アプリケーション保守に向けた人員の確保は、IBM iユーザーが頭を悩ませる共通した課題です。人材確保に関する将来を悲観して、現状アプリケーションの継続運用をあきらめ、リスクの高い全面再構築に踏み出さざるを得ないと判断したケースも少なからずあります。
RPGの開発人員を確保するのが難しいと考える理由には、RPGと他のオープン系言語の違いが大きいこと、そしてRPG技術者が減少している現実があります。
確かにRPG技術者は減少傾向にあります。しかしRPGと他のオープン系言語が全く異なるために、人材育成が難しいと結論付けるのは早計です。
図表1で、RPG言語とオープン系言語を比較してみました。
RPGにはⅢ、Ⅳ、FFと3種類ありますが、最新のFF RPGとオープン系言語にほとんど違いはありません。もちろん言語ごとの仕様は異なりますが、それはJavaやCなどとの違いと大差ありません。
それに対してRPG Ⅲはオープン系言語と異なる点が多く、RPG ⅢでSQLを利用していない場合は、さらにその違いを強く感じるでしょう。
たとえばRPGでリレーショナルデータベース(RDB)を利用する場合は、DDSを記述して物理ファイルや論理ファイルを作成するので、RPG技術者はSQLでテーブル(物理ファイル)やインデックス(論理ファイル)を作成するオープン系言語に違和感を抱くかもしれません。
しかし、たとえ名称や作成方法が違っても所詮はRDB、テクノロジーの基本は同じです(ちなみにIBM iでも、CREATE TABLEなどSQLコマンドは普通に利用できます)。
またRPG ⅢとRPG Ⅳも、やはり大きく違います。それは従来のオリジナル・プログラム・モデルからILE環境へ進化したことに起因します。ⅢからⅣへは、単に言語仕様だけでなく、開発・実行環境も大きく変わりました。長くRPGに携わって来た開発者にはILE環境が壁となり、なかなかILE RPGの活用に進めないかもしれません。
しかしそれが理由でRPG Ⅲの利用にとどまっているのは、決して得策ではありません。IBM iの素晴らしい進化がもたらす恩恵を享受しないのは、なんとも「もったいない」ことです。それにILE環境を習得しなければ、ILE RPGを使えないといった制限は一切ありません。最初の一歩を踏み出せば、必ず今までと違った考え方・捉え方ができるはずです。
開発者の育成・確保という面でも、それは同様です。オープン系言語の経験者であれば、FF RPGの習得にハードルはありません。オープン系言語の膨大な開発人口を、少しでもRPGの世界に誘うことができれば、RPG技術者の減少という現実は必ず変えられるのです。
現在の搭載機能を使って
アプリケーションを刷新する
現在の業務要件やニーズに合わせてアプリケーションの刷新を考えるとき、以下のような要件を検討します。
❶ マウス操作など画面操作性の向上
❷ Webやeメール、他システムとの連携
❸ 情報量増大への対応
❹ ユニコードやJIS漢字第四水準など文字拡張への対応
❶〜❹はRPGと5250アプリケーションでも対応可能です。しかし、その方法は意外に知られていません。❶、❷、❸はエミュレータの設定変更とそれを考慮したプログラミングで、❹は言語コードとCCSIDの選択で実現できます。いずれも現在のエミュレータやRPGの機能だけで実現できるのです。
本稿では、これらの刷新方法について具体的なコーディング例を交えながら解説します。これにより、IBM iがどれほどの進化を遂げているのかを実感し、これからのアプリケーション改修のヒントにしていただければと思います。
RPG Ⅲの技術を軸にしながら、抵抗なくスムーズに次のステップへ進むことで、既存アプリケーションの安定性を確保しつつ、拡張性・将来性を豊かに備えたシステムとして改修する。そのためのアイデアやノウハウを提供していきます。
簡単な改修で既存アプリケーションの操作性や保守性を高めることからスタートし、次第にIBM iが備える多彩な機能を習得して、これからの時代にも対応できるアプリケーション開発・改修のスキルを身に付けていきましょう。
IBM i Access Client Solutions
マルチOS対応で多彩な機能を提供
IBM iのバージョンアップに伴って、エミュレータ機能などをサポートする「IBM i Access Family」にも大幅な機能向上が図られました。「IBM i Access Windows」は現在、Windows 10のサポートやクライアントのマルチOS対応など、さまざまな機能が追加された「IBM i Access Client Solutions(以下、ACS)」へ移行しています(図表2)。
従来のIBM i Access for Windowsは、Windows 10での稼働保証やサポートはなく、2015年以降はACSがWindows 10以降に対応しています。
提供開始当初こそ、互換性に関する課題がいくつか認められましたが、現在では以前と同様の機能に加え、先進的な数多くの機能が提供されています。Windowsのサポート期間を考慮すると、今後はACSへの移行が必須となります(図表3)。
ACSでの大きな変更点としては、今までWindowsやLinuxはそれぞれ別製品として対応していたのに対し、ACSはマルチOS対応なので、Java環境下であれば、どのプラットフォームでも対応可能になった点が挙げられます。
また、IBM i Access for Windowsは各クライアントへのインストールが必須でしたが、ACSはzipの解凍やサーバーへのリンクにより簡単に導入できるので、容易な配布が可能です(図表4)。