現在のRPG における最新バージョンは RPGⅣ であり、今回取り上げる RPGⅢ はすでに機能拡張を終えた言語です。IBM i 7.3 が発表され、最新の RPG は完全フリーフォームも実現している今、なぜ RPGⅢ を連載2回目で取り上げるのか?この言語が最新の IBM i で担う「ミッション」はあるのか?今回はこの点を掘り下げていきます。キーワードは「SoR」です。
どのコンピュータ言語もほぼ例外なく、最新バージョンが発表されると機能拡張の大半は最新バージョンを中心に実装されていき、前バージョンで開発された既存システムも新しいバージョンで書き換えることが計画され実行されます。これは将来 OS のバージョンアップが行われた時、最新のバージョンの言語製品のみしかサポートされないことが多いからです。そして古いバージョンの言語はメーカーのサポートがなくなり、その役目をひっそりと終える時がやって来ます。
では、RPGⅢ も同様の運命をたどる言語なのでしょうか?
この点を論じる前に少しだけ RPGⅢ の歴史のおさらいをして、この言語が登場した背景と果たしてきた役割について見ておきましょう。
RPGⅢの歴史
RPG の開発は 1959 年に始まったと言われています。もとは、パンチカードで表現したデータを処理するタビュレーティング・マシンの代替として開発された IBM1401 用の言語でした。その後 1960 年台に System/3 用に RPGⅡ にバージョンアップされました。RPGⅡ はその後 System/36 まで使用され、1978年にリリースされた System/38 で RPGⅢ にバージョンアップ、そしてAS/400(IBM i)に引き継がれていきます。AS/400 では RPG は RPG/400 と呼ばれていますが、これは AS/400 上で稼働する RPGⅢ のことです。
System/38 のリリースは 1978 年。つまり RPGⅢ の歴史もすでに38年を経過しており、古い言語という印象をお持ちの方も多くいらっしゃるかもしれません。ただし、歴史が長いということはそれだけ資産(RPGⅢ で記述されたプログラム)も数多く存在するという事です。
RPG の最新バージョンである RPGⅣ は1994年に発表になりました。その後 2001 年に OS/400 の V5R1 が発表され、この時点で RPGⅢ の機能拡張はストップします。その後の新しい機能拡張は RPGⅣ に引き継がれていきました。
先ほども触れたように、通常であればここで RPGⅢ を使用したプログラムは作成されなくなり、新しい RPGⅣ に開発言語は移行していくはずですが、RPG 言語ではそれは起きませんでした。相変わらずシステム開発の主要な言語は RPGⅢ であり、お客様によっては現在でもその状況は変わっていません。なぜなのでしょうか?
新しいバージョンが発表になり、機能拡張がストップしてもその言語を使ってプログラム開発をおこなうことができる理由はただ一つ。新たに作成したプログラムも将来に渡って確実に「実行することができる」というメーカー側の保証です。これが、AS/400 から IBM i に脈々と受け継がれてきている「過去の資産の継承」という DNA なのです。この「安心感」があるからこそ、RPGⅢ は機能拡張がストップしてからすでに15年が経過していてもなお、第一線で活躍し続けることができるのです。
IBM i におけるRPGⅢの役割
ここで、
第1回の記事でも触れた SoR と SoE について少しおさらいをしておきましょう。従来の基幹業務システム全般のことを SoR(Systems of Record)と言い、外部の人やサービスと連携する部分のことを SoE(Systems of Engagement)と言います。IBM i においては、SoR 構築に主に使われている言語が RPG です。ここでポイントになる点は、SoR は寿命が長く SoE は短期であるという点です。場合によっては SoR はハードウェアの寿命すら超えることもあるのです。IBM i で稼働している基幹業務の多くは、RPGⅢ で開発されたものがまだまだ現役であり、実際 System/38 と AS/400(IBM i)という2つのハードウェアを経験しています。
IBM i の前身である AS/400 は、System/36 と System/38 を統合して開発されました。そのため、それぞれの環境で稼働していたシステムをサポートするために、エミュレーション・モード(S36 および S38 環境)を搭載しました。そして驚くべきことに、これは IBM i 7.3 においても変わりなく搭載されています。つまり、最新の IBM i 上においてSystem/36で開発された基幹業務(RPGⅡ)が今も稼働できるのです。
System/36 および 38 で稼働していたシステムを最新の IBM i でも稼働させることができるということがどういうことか。まさにこれが基幹業務を支えるコンピュータとして果たさなければならない最も大切な役割であり、これを具現化しているのが IBM i なのです。「過去の資産の継承」の意味するところと、それを実直なまでに最新の OS でも実現していることの凄さがわかっていただけると思います。
IBM i における RPGⅢ の役割についてさらに深く考えてみましょう。前段「RPGⅢ の歴史」でお話したように、RPGⅢ は発表からすでに 38年が経過し、言語としての機能拡張は終了、今後新しい機能が追加されることはありません。すなわち、新規プログラムを開発する際の言語としてはその役目を終えています。しかし一方で、現在でも基幹業務の根幹部分が RPGⅢ で作成されているシステムが数多く残っています。現時点において IBM i における RPGⅢ の役割は、まさにこの根幹部分のプログラムの保守にあるのだろうと思います。つまり、まだまだ現役だということです。基幹業務は日々仕様が変わります。そして、その仕様を実装するプログラムは RPGⅢ で開発されていることがまだまだ多いのです。元が RPGⅢ で記述されているのであれば、その言語バージョンで修正するのが最も適しています。 最新の IBM i 7.3 においてもこれを実現可能なのが、IBM i の凄さなのです。
ただし、すべてこの方法が良いわけではありません。求められる仕様が、2001 年時点の技術では実現できないものであれば、そのプログラムは積極的に RPGⅣ で書き換えるべきです。今後は RPGⅣ を採用していかないと実現できない業務仕様がますます増えていくと思われます。幸い IBM i では RPGⅢ のソースコードを RPGⅣ に変換するコマンドがシステムから提供されていますので、これを積極的に使っていきましょう。RPGⅣ については次回詳しく紹介する予定です。
開発ツールのサポートはどうか
RPGⅢ の言語仕様の特徴のひとつに定位置記入形式があります。ご存知ない方のために解説しておくと、RPG 言語はいくつかの仕様書で構成されており、それぞれの仕様書ごとにどの桁位置に何を指定するかが決まっています。そしてそのルールに反すると文法違反とみなされコンパイル時にエラーとなります。
RPGⅢ をコーディングする際に使われてきたエディタは SEU です。このエディタには、プロンプト機能が提供されており、桁位置を全く覚えていなくても入力した値を適切な桁位置にセットしてくれます。また、ある桁位置に入力できない文字があれば、行単位の構文エラーとしてユーザーに知らせてくれます。SEU のこの機能のおかげで RPG プログラマーは素早くソースコードを入力することができるわけです。
RPG プログラマーの多くは桁位置とそこに何を記述するのかを正確に記憶している人は殆どいないと思います。少なくとも私はまったく覚えていません。ましてや、コードを記述するエディター上で、その桁位置までカーソルを移動し間違いなく記述していくことは至難の業。にもかかわらず、このことで悩んでいる RPG プログラマーはいないはずです。それはこの SEU という素晴らしいエディターのプロンプト機能のおかげでしょう。メインの開発言語が RPGⅢ の場合は、エディターは SEU がまだまだ現役だと思います。
ご存知の方もいらっしゃると思いますが、実は SEUの機能拡張も IBM i 6.1 の時点ですでに終了しています。RPGⅣ はまだ機能拡張が行われている言語であるにもかかわらずです。実際、IBM i 7 で実装された新機能や FFRPG を SEU で記述すると構文エラーになってしまうものがたくさんあります。ですから最新の機能を効率よくコーディングするためには、SEU に変わるエディターが必要となるのです。これを担うツールとして現在 RDi および Orion が利用可能ですが、この詳細は別の記事で解説しますのでお楽しみに。
SEU は RPGⅢ の文法を完全にサポートしていますので、この言語を使う限りは SEU はまだまだ現役であり続けると思います。基幹業務を支えるコンピュータという側面で見た場合、今でも現役で稼働している RPGⅢ で作成されたプログラムは今後も保守されるべきものです。RPGⅢ 言語に SEU + PDM という「3種の神器」は今後も IBM i のプログラマーの基本セットであり続けることでしょう。
あらためて RPGⅢ という言語バージョンの立ち位置について
現在も IBM i で稼働している基幹システムの根幹のプログラムが RPGⅢ である限り、この言語は開発者にとってとても重要なものであることは変わりありませんし、その立ち位置も変わることはないでしょう。しかし一方で、今後新規のプログラムおよびシステム開発にこのバージョンを使用されることはないという点も我々は今一度確認しておく必要があると思います。
新しいシステムおよびプログラムの開発に RPGⅢ を使う理由は見つかりません。RPGⅣ でもサイクルを使用したプログラム作成は可能な上、印刷プログラム、対話型プログラムももちろん作成できます。しかし、すでに機能拡張が2001年に終わっているこの言語を用いて、これからのビジネスに要求されることを、記述するのはまったく意味がありません。これからの要求を実現する手段としては、RPGⅢ の役目はすでに終わっているという認識を持つことが大切ではないでしょうか。
おわりに
「ひとつだけでは多すぎる」とは、アメリカの作家ウィラ・キャザーの「ひとりでは多すぎる」というセリフを「思考の整理学」の著者である外山滋比古さんがアレンジして紹介したものです。「ひとつだけだとこだわりが生まれ、妙に力む」、「ひとつだけを信じこむと、他のものが見えなくなってしまう」から良くないという意味だそうです。
SoR(基幹業務)を支えるシステムを開発する言語のバージョンは、「ひとつだけでは多すぎる」と思います。必要に応じてどのバージョンにて保守、開発すべきなのか、視野を狭めることなく RPG の各バージョンに向き合うことが、ハードウェアを超えて今後もサポートされている基幹業務をお客様に最も適した形で提供していくことに繋がっていくことになるのです。
何度も繰り返してきましたが、IBM i には長年基幹業務を支えてきた RPGⅢ で構築されたシステムと、これからの業務要件を実現するために RPGⅣ で構築していくシステムとが今後も共存していきます。さらに、今後は SoE を記述するさまざまオープンソース言語も基幹業務システムの開発言語に加わってきます。
「ひとつでだけでは多すぎる」。適材適所に最適な言語やそのバージョンを考えながら全体を俯瞰したシステム開発が重要な時代に変わりつつあることを強く意識しておく必要があるのではないでしょうか。
今回は、RPGⅢ という言語のミッションが基幹業務を迅速に保守する点にあることを解説いたしました。この言語を大事にしながら、最新となる RPGⅣ についてもより理解を深めていきましょう。次回の RPGⅣ の記事をお楽しみに!
おまけのコラム
東京マラソンのエントリーが8月31日で締め切られました。今回の申込総数(マラソンと10km)は32万2703人だそうです。マラソンの抽選倍率は約12.2倍とか。まったく当たる気がしない倍率です。結果は9月中旬にメールにて通知されるそうです。次回のコラムで結果は報告できそうですね。
そういえば京都マラソンにも応募していたことを思い出しました。こちらも昨今のマラソン人気で抽選となっています。倍率は3.8倍とのこと。こちらはまだ当たりそうな気がします。東京マラソンに比べればですが。
京都マラソンは2017年2月19日開催、そして東京マラソンは1週間後の26日開催です。両方当選すれば2週連続フルマラソン。いや、そんな「ミッション」は残念ながら私には課せられないと思います・・・・・・。
著者プロフィール