この連載が始まって、はや2年半が過ぎようとしています。たかだか2年半、ともいえますが、今年の秋はこの数年のなかでもとくに天候に恵まれず、各地で災害、それに伴う農作物の不作を耳にします。この号が発売されるころには日照不足が解消し、秋晴れのもとで連載を届けられる状況であることを願ってやみません。
また、この2年半でRPG Ⅳの素晴らしさをお伝えしてきたつもりですが、何かの素晴らしさを伝えようとするとき、対比して「素晴らしくない」対象物を槍玉に挙げることが多々あります。
RPGⅣの場合、対比するのはどうしてもRPGⅢになってしまい、RPGⅢをお使いの方にはいささか不愉快な内容であったかもしれません。そこで今回は、RPGⅢのよさを再認識してみたいと思います。
RDBを使うためのRPG Ⅲ
RPGⅢは1978年、S/38の登場とともに歴史が始まります。今でこそ多くの人が当たり前のように使っているリレーショナルデータベースですが、S/38はビジネス用のリレーショナルデータベースを初めて搭載したコンピュータです。当時のS/38ユーザーは、リレーショナルデータベースとは知らずに使っている人が多く、さらに言えばリレーショナルデータベースの存在さえ知らず、漠然と「コンピュータのファイルとはこういうもの」と思っていた人も多かったようです。
このリレーショナルデータベースの登場によって、S/38で使用するRPGプログラムは、データベースを扱える必要がありました。そして、リレーショナルデータベースを外部記述ファイルとして利用できるように改良されたのがRPGⅢなのです。
外部記述ファイルの利用は、それまでのRPGⅡでのプログラミング手法を大きく変えました。RPGⅡでは、印刷装置ファイルの操作には出力仕様書、表示装置ファイルを使うときには入力仕様書と出力仕様書のコーディングがそれぞれ必須でした。これに対してRPGⅢでは、データベース、印刷装置ファイル、表示装置ファイルの各フィールド情報を、プログラムコンパイル時に自動的に取り込むので、入力仕様書や出力仕様書の記述がいっさい不要となり、開発効率を大幅に上げることができたのです。
RPG ⅡからRPG Ⅲへの変更メリット
RPGⅡからRPGⅢへの変更によるメリットはそれだけではありません。ファイルのブロックサイズの適正化をシステムが自動的にやってくれるので、ファイル仕様書へのブロックサイズの記入や、それを考えることが不要になりました。コンパイルリストのソースの最後の「RPG はファイル XXXXXXXにブロック化または非ブロック化サポートを提供している」というメッセージは、このことを意味しています。
また、外部記述ファイルの使用により入力仕様書への記入が不要になったことにより、RPG内部論理から脱却するユーザーも増え始めました。
RPGⅡでは、入力ファイルに対して入力仕様書の記入が必要で、ファイルにフィールドが100あれば、ステートメントも100以上になりました。これにより演算仕様書にシンプルさが要求され、RPG内部論理を使ったコーディングは必須でした。
RPG内部論理は、ファイルの入力から出力までのプロセスを演算仕様書でコーディングすればよいだけで、そもそもRPGはこれが使えるから習得しやすい言語、という売り文句がありました。この書き方だと、演算仕様書はシンプルになるものの、標識の多用は必須になり、入力仕様書、出力仕様書はけっこう賑やかになります。
それがRPGⅡでは、演算仕様書でREAD／WRITEの読み書き命令やDOWXX、ENDDOの繰り返し命令を使うことによって、プログラム論理をプログラマーが制御できるようになりました。この手法は、とくにCOBOLプログラマーには理解しやすいものでした（もっとも、RPG内部論理の肯定派と否定派にはっきり分かれているので、どちらがよいとは明言できません）。
RPG Ⅳは魅力的に映らない？
そしてAS/400の登場後、1994年にRPGⅣが登場しました。RPGⅣではこれまでの連載で紹介してきたように、フィールド名が6桁から10桁へ拡張され、関数が使用できるなどILE（Integrated Language Environment／統合言語環境）の言語としてのメリットが数多くあります。
しかし現実問題として、それらの機能はRPGⅢプログラマーにとっては、あまり魅力的に映らなかったようです。いえ、もちろん魅力的に映っていることは間違いないと思うのですが、現在は、RPGⅡからRPGⅢへ移行した当時とは状況がまったく違います。今までのファイルをデータベースへ移行するといった大手術が必要なわけではありません。むしろCPUがPOWER7からPOWER8へと進化するなかで、RPGⅢプログラムは今まで以上のパフォーマンスで動いてくれるのです。
ILEは、プログラムをコンパクトにし、CALLするプログラムを同一オブジェクト化することでパフォーマンスを向上させますが、しかし従来の何千ステップもあるようなRPGⅢプログラムでも、IBM iの最新ハードウェアでは高パフォーマンスで稼働するのです。そして、それやこれやで、現状を変える必要はない、という結論に行き着きそうな感じもあります。
SoRとSoEを容易に連携できるRPG
しかし現実問題として、5250画面で操作するアプリケーションに対し、現場からは「Web画面にできないのか」という要望も数多く出ています。世の中全体を見渡すと、「もはや文字ベースの5250画面は古い」、書籍やネットでは「RPGはもう古い」などのコメントをよく見かけます。38年もの歴史がある言語を使い続けていることが何となく罪悪のように思えてしまう情報が、けっこう多く見受けられます。
とくにIT業界は、「古いこと＝悪いこと」のように吹聴する傾向があります。いつまでRPGをやっているんだ、という悪魔のささやき（!?）を聞いたことも多いかと思います。
RPGは、基幹業務の言語に分類されます。基幹業務はほかのシステムとの連携が不得手、と言われます。だからほかのシステムに変えよう、ほかの言語に変えましょう、という提案がなされるのですが、IBM iにおいては、その通説はあたりません。今存在する基幹業務、つまりSoR（Systems of Record）そのままに、基幹業務以外のSoE（Systems of Engagement）との連携を築けるコンピュータなのです。
現在の5250画面をWeb系に移行するにはいろいろな言語がありますが、IBM iはその選択肢が非常に豊富です。
代表的な言語としてはJavaやPHPが挙げられます。どちらもIBM i以外のプラットフォームではリレーショナルデータベースとの連携に苦労するのですが、IBM i上ではデータベースとの連携が非常に容易です。JavaもPHPもIBM iのデータベースと連携するためのTOOLKITが用意されており、さらにデータベースだけでなく、RPGプログラムとの連携も容易です。これを使わない手はないでしょう。
しかし、ここでまた1つの懸念が発生するかもしれません。「RPGとJava／PHPそれぞれのプログラマーを確保しないといけないのか」という問題です。
RPGプログラマーを育てるのはコストがかかる、と言われています。今の若い技術者のほとんどは大学・専門学校でJavaやCなどを中心に勉強します。
JavaやCをご存じであれば、PHPは難なく習得できます。しかしこれらの技術者がRPGを習得するのは「難なく」というわけにはいかないようです。それはRPGという言語が、RPG仕様書を使いステートメント上で決められた固定位置に記入するという、JavaやC、PHPにはまったくない記述方法だからです。おかげで、と言っては怒られるかもしれませんが、私たち研修会社のRPGⅢプログラミング講座には、比較的多くの受講者があります。
JavaやCなどの記述方法に近づく
今使用中のRPGⅢを、RPGⅣ、フリーフォームのRPGにすると、RPGの記述方法が大幅にJavaやC、PHPに近づき、RPGプログラマーになるための習得期間を大幅に減らせます。実際にフリーフォームのRPGで書いたソースをJava、Cのプログラマーに見せると、何の処理を行っているかを即座に理解できるのです。
これは以前にも話したことですが、Javaの経験者にフリーフォームのRPGをRDi（Rational Developer for i）を使って入力してもらうと、何の抵抗もなくスラスラと入力します。
文字ベースの画面でSEUを使い、RPGⅢのソース入力となると、そうはいきません。メインフレーム系の技術者がSEUを操作しても、同じ文字ベースの画面だから、というわけにはいかないのです。私どもの研修でも、メインフレーム系の人がSEUで苦労する場面はかなりの頻度で見受けます。
しかしWindowsやGUIの画面を使った操作なら自然に手が動くようで、このインターフェースにはかなわないと痛感しています。このインターフェースでRPGが入力、編集できるなら、IBM iの未来は明るいと言えるでしょう。
フリーフォームRPGの入力は、RDiだけでなく、オープンソースの開発環境であるOrionでも使用可能になっており、フリーフォームRPGはさらに身近なものになりました。こういった新しいRPGの開発環境や、IBM iで開発するJavaやPHPのノウハウを、SoRとSoEの視点でご紹介すべく、私どもアイ・ラーニングではこのたび、Web環境があればPCでもスマホでも勉強できるe-learning教材の提供を予定しています。
今までのものを捨てる必要はありません。捨てずに新しいものを取り入れていく、それがIBM iの素晴らしさです。そのことが実感していただける教材になると自負しています。
そしてRPGは、ⅢであれⅣであれ、またフリーフォームであれ、今後も基幹業務を支えていくことは間違いありません。むしろRPGやCOBOLで構築されたSoR、基幹業務システムの基盤なしに、SoEの発展を遂げることのほうが困難といえるでしょう。
著者｜中村 潤 氏
株式会社アイ・ラーニング
IT研修本部 IBM製品研修部
ラーニング・アドバイザー
［i Magazine 2016年11月号掲載］
････････
◎ 連載｜RPG Ⅳの魅力と可能性 目次
- 第1回 RPG ⅢとRPG Ⅳのコーディングの違い
- 第2回 驚くほど簡単になる、RPG Ⅳの日付計算機能
- 第3回 静的プロシージャーによるパフォーマンス向上
- 第4回 RPGⅢからRPGⅣへの移行の実際
- 第5回 RPGⅣのフリーフォームの特長と魅力
- 第6回 RPGⅣの関数を使おう！
- 第7回 フリーフォームRPGで開発要員養成コストを削減
- 第8回 若い人の声に耳を傾けるべき時がきた
- 第9回 フリーフォームRPGで「プログラム記述」レポート印刷プログラムにトライ！
- 第10回 組み込みRPGのすすめ
- 第11回 RPG Ⅳのメリット：保守の容易性を考える
- 第12回 RPG Ⅲのよさを再考する
- 第13回 RPG資産を次世代へ引き継ぐための準備は、今が踏ん張り時
- 第14回（最終回） 独学では得られない知識・情報が詰まったIBM iの研修コース
