S/34 RPGⅡ 論理サイクルを使用したエントリー・プログラム

1980年の初め、当時プログラマー成り立てであった私に、RPGプログラム開発の指示がマネージャーから舞い込んできました。お客様は新規顧客。弊社が選ばれた理由は、後日判明したことですが、お客様はメインフレームを既に導入されている石油関連会社で、担当のIBM営業マンが弊社を評して「中小型機の開発なら何でもやれる会社」と噂していたのを、開発担当マネージャーが聞きつけたからだということでした。お客様のアプリケーションはCOBOLがほとんどで RPG （バージョンⅡ）プログラム開発はお客様にとっては未知の世界。そこで新たに経験豊かなSE（これも外注）と経験豊かな？プログラマー（私）のコンビでということになった次第であります。

お客様がこの新規プロジェクトに踏み切られた理由と、そこで提示された要件は以下のとおりでした。

• メインフレームからのダウンサイジングの一環として、開発コストの削減
• 基幹業務の大幅なコスト削減の一環として、小回りの利くアプリケーションが必要
• 配送指示業務における経路の選択は、変動要素が多分に存在する
• 実地における検証を踏まえて、効果を上げるためのタイムリーなアプリケーション変更が行えること

お客様の要件に基づき、経験豊かな外注の SE から提示されたアプリケーション開発要件は以下のとおりでした。

• 最大限のパフォーマンスを上げること
• 保守しやすいプログラムであること（構造化プログラミングに徹する）
• 32KB のメモリーの制約があるために、プログラム・サイズは 32KB 以下にすること
• RPGⅡ プログラムの論理サイクルを使用したエントリー・プログラムであること

RPGⅡ プログラムを作成されたことのない読者の方のためには、この SE が提示した３番目と４番目の要件はいささか説明が必要と思われます。S/34 システムは IBM の中小型機用として開発されたコンピューターですが、S/36 と同様に仮想記憶域をサポートしていませんでした。（因みに RDB　のようなデータベースもサポートしていません）　従って、そこで動くプログラムはメモリー（主記憶域）のサイズに大きく影響を受けます。メモリーより大きいサイズのプログラムを作成することは可能でしたが、その結果、プログラム実行時にスワッピングが発生してしまい、パフォーマンス的に大きなネックになります。そのためこの第３の要件は第１の要件を満たすための前提になります。さらに、第４の要件も同様のことが言えます。RPG プログラムは作成時に論理サイクルを自動的に組み込んでしまうために、その論理を使用して無駄な論理のためのサイズ削減を図ることが重要になるわけです。但し、当時対話型プログラムで論理サイクルを使用することはあまり一般的ではなく、私にとって初めての経験でした。因みに、SLS(単一レベル記憶域管理)と呼ばれる独自の仮想記憶域管理を搭載したS/38(IBM i (AS/400) の前身)の出現により、仮にプログラム・サイズがメモリー・サイズを超えたとしても（実際には、メモリー・サイズが大幅に拡張された結果あり得ないことですが）仮想記憶域空間で処理されるために、第３の問題点は解消されることになります。S/38当時、この仮想記憶域空間は48ビット(280TB)のサイズでしたが、1995年(IBM i (AS/400) 時代)に64ビット(16EB)に拡張され現在に至ります。

３ヶ月の開発期間を経て、どうにか SE の要件を満たすことの出来るプログラムを１本作成できました。（図２を参照）　アプリケーション・カットオーバー後は私の手を離れて、お客様の要件を満たすための変更は担当 SE の方が直接行われておりましたが、構造化プログラミングを考慮した設計を心掛けたおかげで、SE の方から保守しやすいプログラムだと非常に喜ばれました。プログラマー冥利に尽きるとはこのことですね。その後、このプロジェクトの導入事例が業界誌で紹介され、数ヶ月間で数億円のコスト削減が実現できたという記事が掲載されたことを記憶しております。

この成功は、私にとってもうひとつの大きな意味があります。当時私は、今回作成したアプリケーション・ロジックが、アプリケーション開発における標準化として使用できないはずはないと考えました。事実、当時会社においてアプリケーション開発ロジックの標準化は存在していませんでした。そこで、対話型プログラムの構造化ロジックを含むアプリケーション開発の標準化として会社全体で活用出来るように纏め上げました。その後、RPGⅡ は RPGⅢ、RPGⅣと改訂されて現在に至りますが、この標準化も改訂に改訂を重ねて、その後 20年以上もの間、幾多の SE およびプログラマーによって活用され、その効果は現在の IBM Sytem i でも実証済みです。

RPGⅡの論理が現在の RPGⅣ でも十分生きていることが驚きです。文字通りこれが「資産の継承」ということなのでしょう。（図２を参照）

参考）RPGⅡでは、画面ファイルはプライマリーにより自動読み取りですが、RPGⅣでは全手順処理になります。但し、RPGⅣでもプログラム作成時に、論理サイクルが自動的に組み込まれるためメイン・ルーチンでのループ処理のコーディングが不要になります。

お客様からの要望を実現するため我々は様々な角度からソリューションをご提案させていただきます。
お一人で悩まずに我々に是非ご相談ください。