- トップページ ＞
- これまでの軌跡 一覧 ＞
- これまでの軌跡
IBM i (AS/400) 脱5250エミュレーター
DataQueue による VB と RPG 連携（１）
1990 年代後半の事です。あるお客様の要望により日立系のホストコンピュータで稼働していた CUI(Character User Interface) の業務システムを Visual Basic を使用した GUI(Graphical User Interface) アプリケーションへコンバートする事になりました。データベースは信頼性を重視して IBM i (AS/400) 標準搭載の RDB を使用( OS/400 は V4R2 )して、当時流行だった C/S (クライアント・サーバー)化を行う事になった訳です。過去、Visual Basic や Access のマクロを使用したアプリケーションの実績はありましたが、IBM i (AS/400) をサーバーとした C/S 構成は当社としては初めての試みでした。
試行錯誤の連続 お客様の要望は以下の4点でした。- インターフェースは GUI であること
- パフォーマンス重視で開発すること
- データベースを一元管理すること
- 大阪からも同様のパフォーマンスでアクセスできること
コンバートするシステムには伝票入力機能があり、当初からお客様はそのパフォーマンスについて 5250 インターフェースと同様の応答速度を求められていました。 C/S 化でパフォーマンスのボトルネックになるのはデータアクセスと通信の部分です。今回はIBM i (AS/400) をデータベース・サーバーとして使用するため、パソコンからのアクセス方法としては APPC CPI-C 、ODBC 経由などいくつかの手法がありました。ただそれまでの経験上、DAO 等はPC 側のバージョンに依存し、何かとうまく動かなくなる（こちらの技術不足が原因です）ことが多かったため、APPC CPI-C を使用して通信部分を構築することにしました。当初の開発方針は以下の通りです。
- GUI は VB で開発
- IBM i (AS/400) との接続は CA/400 を使用
- プロトコルは LU6.2
- IBM i (AS/400) 側は RPGIV で開発
- 通信部分は CPI-C で記述
当時 APPC CPI-C のプログラミングは全く初めてだったため、プログラミング作業は困難を極めました。マニュアルを見ながら通信の手順を確認し、コードを書いてテストし、不具合が出たらまたマニュアルに戻り、他の手順を探すということを繰り返したのです。そういう苦労の末、トランザクション・データを登録するプロトタイプをやっと完成させることができました。ただ、この時点で IBM i (AS/400) 側のプログラムの EVOKE（呼び出し） 処理に時間がかかるという問題も判明していました。これに関してはプログラミング・レベルではどうにもならず、「これは仕方がない」との判断で、お客様に最初のお披露目をすることにしたのです（この判断はまったく論外だったことに後で気づかされます）。
散々な結果 当時、システム担当の方には、採用した通信手順に関する長所・短所、今回のプロトタイプの応答速度など事前に情報をお伝えしていたため、実際の使用感として「こんなものでしょう」という評価をいただきました。その後、伝票入力を行う方に実際の操作を行ってもらったのですが、「使えない」という評価。登録ボタンを押して、次の伝票の入力まで時間がかかり過ぎるということでした。担当者のキーボード入力のスピードはこちらの想定をはるかに超える早さだったのです。その後いろいろと模索したのですが、当時の我々の技術力等を考慮すると、同期通信で要望にあったパフォーマンスを実現することは無理との結論にいたり、このプロトタイプはお蔵入りとなったのです （図１を参照）。
この結果は開発側にとってかなりのショックでした。プロトタイプとは言え、書いたコードは相当な行数に上り、しかもそれを全て捨て去って全く新しい解決策を考えなければならなかったからです。 とはいえ、お客様の要望には迅速に解決策を提案しなければなりません。苦労の末導き出した解決策とは？ 近日中に続きを公開します。楽しみにお待ちください。
