|
RPGで仕事をする人にとって、RPG400とRPGIVの2者択一に迫られると、きわめて、悩ましい問題になりうる。もし、何のためらいもなく、RPG
IVに移行できる人は、恵まれている。 AS/400本体の価格は、10年前の発表のころに比べると、かなり安くなっている。安価なマシンで、安定していて、言語も豊富なら、魅力がないわけがなく、グループ会社で、親子会社で、AS/400のハードを複数持つケースは、増えてきている。その状況で、言語上問題なのは、そのバージョンだ。 システム部門のパワーが弱く、いまだにV3R7（RISCのほぼ最初のバージョン）を、しゃぶり尽くしている（もう味はないだろうが）会社もある。V4R5で開発して、SNADSなりFTPなりで、ソースを転送してコンパイルする状況で、RPG400は、問題を起こさない。もう、カサカサに乾ききっていて、枯れも枯れたり、のバージョンだから、とにかく、V2,V3,V4(多分V5も)ともに、ソースをコピーしても、コンパイラは文句をいわない。結構、気が付かないことだけれども、これは、かなり重要なことなのだ。自分がダウンロードツールをRPG400に限定しているのもそのためだ。 ガーンな出来事
RPGIVで、標識を極力へらそうと、%EOF,
%FOUNDを使って、V4R5で、テストを繰り返し、満足の笑みを浮かべて、V3R7にコピーしてコンパイルすると、なんと、コンパイルエラーとなる。血も凍る、嫌な予感に、飲み込まれながら、コンパイルリストを読むと、組み込み関数がすべて、認識されていなかった。 力
が 抜 け る .
. . この組み込み関数は、V3R7にはなかったのだ。もう、なんだか、何べんも、使っているので、自分が生まれたころからあるような錯覚すら、覚えていた。それも、一本ではないのだ。同じ組み方で、何本もつくり、いっせいに移行しようとしたのだ。V4R5でちゃんと動く。テストもして、画面の動きから、レコードロック、エラーメッセージの表示、印刷の桁確認、すべて、行ったのに、READ, READE, READC, CHAIN,
SETLLのEQに、また、標識をつけていかなくてはならない。後ろ向きの仕事だった。その気になれば、30分程度で終わることなのに、この組み込み関数をはずす作業は、とても長く感じられた。なんだか、後悔ばかりして、集中できなくなっていた。
DANDAN
でも、RPGIVは、次第に自分としては、プライマリーのものになってきた。確か、V4R4からV4R5にOSがバージョンアップしたとき、たいていは、OSとともに、RPGIVもバージョンアップしていたのに、そのときは何もなかった。これで、RPGは死ぬと騒いだユーザーもいたが、ちょっと、違うと思う。枯れてきているのだ。ひとつの山の高みにきているのだ。下がることはない。だから、現状維持か、別の山（多分RPGVと呼ばれるのだろう）への準備だったのだろうと思う。 まだRPGIVも足りない予約語があると思う。いづれ、メールで要求してみたい。でも、それがなくては、プログラムができない、というほど深刻な問題ではない。当初、紛糾していた、EVALも、使い方を考えれば、オーバーフローも問題ない。むしろ、あれは、RPG400をCVTRPGSRCでコンバージョンして、そのままよく調べもせずに、コンパイルをして、動かしていたことに問題があったのだろう、と今では思う。イデオロギー論に近かったのだろう。最近では、ポイントがわかってきているので、さほど、ストレスにはならない。オーバーフローエラーも最近は見かけなくなっている。
RPGIVは便利か
ソースをそのまま、簡単に読めるか、読めないか、ということを考えるときに、いくつかの、障壁が立ちふさがる。
-
定義がどこにあるのかわからない。
-
標識90がオンの時、のその標識90は、文脈を読まないとわからない。
-
便利なように工夫したつもりが、別の人が読むと、何だかよくわからない。
-
RPG400では、数式演算が直感的に表現できていない。
-
フィールド名、サブルーチン名、タグ名、エクセプト名は、もっと、内容を予感させる名称になっていてほしい。
挙げれば、きりがないが、RPG400よりも、RPGIVのほうが、解決しやすい。
定義
もちろんD仕様書がある。スタンドアロンや、固定情報、データ構造が、プログラム前方に固まってあるのは、助かる。最近は、ユーザー定義の標識までできた。これは便利だ。ただ、残念なのは、PARM.
KLIST. DEFINEがC仕様書のままだったことだ。これが、D仕様書だったら、言うことないのに。KLISTやPARMは、人によっては、プログラム前半にまとめ、人によっては、プログラム後半にまとめ（非実行文は最後にもってくるつもりなのだろう）、人によっては、CHAINの直前にKLISTを定義している人もいた。すべて、コンパイル成功となる。この煩雑さが嫌な人は、「コーディングルールをまとめよう！」と言い出し、結局、貧乏くじを自分で作って、自分でひく引く羽目になる。これは、仕方ないのか。何で、D仕様書を作って、C仕様書に非実行文を残したのだろう...コンパチ目的か？
標識
もう、標識は使いたくない。画面のサブファイルなどの関連標識も、INDARAを使うと、標識データ構造によりプログラム内部でドキュメント化できる。また、機能キーも標識によらずにAIDで、ドキュメント化できる。工夫次第で、あの、*IN01から99の煉獄から抜けられるかもしれない。完璧ではないけど、不可能ではない。あとは、もちろん、%EOF,
%FOUND, %EQAULを使っていくことだ。IF *IN90 よりも、IF %EOFのほうが、より、事象を具体的に表現しているのだ。本当の理想は、人間の言葉にもっと近い、超高級言語を期待しているけれど、まあ、当分無理だろう。 INDDSの例
※この機能を使うには、DDS側に INDARA の指定が必要です。
FDspFile CF E Workstn IndDS( DspDS ) * Indicator data structure D DspDS DS
D Exit 3 3N
D Return 12 12N
D SflDspCtl 31 31N
D SflDsp 32 32N
D SflClr 33 33N * Set subfile indicators and display subfile C Eval SflDspCtl = *On
C Eval SflDsp = *On
C Eval SflClr = *Off
C ExFmt SflCtlRec * Check response indicators C If Exit or Return
C Return
C EndIf |
便利な関数とAPI
RPG400で、数字の文字列を、数字編集しようとすると、APIの無い頃は、いろいろと工夫しなくてはいけなかった。わざわざ、長さ50バイトそこそこのワークファイルに1レコード、O仕様書から数字編集付きで書き出して、それを読み込んで、数字編集したように見せかけたり（最初何しているのかわからなかった）、あるいは、それこそ、編集記号と、編集語を解釈して、対象文字列を配列に転送して、気の毒としか思えないような苦労をしているERPもあった。それが、APIの登場で、共通関数代わりに使えるようになり、しかもRPGIVでは、その機能がBIF（組み込み関数）として、利用できる。これは、数字編集に限らない。日付操作にしても、文字列操作にしても、関数のおかげで、昔より、ぐっとソースが見やすくなった。何しろ、その関数名は、プログラマー全員共通して「知っている」のだから、いちいちコメントを入れる必要も無い。読めば内容が推定できるのは、かなりストレスが減る。
ADDは＋へ
もう、RPGIIのころから、親しんできた、ADD命令。結果の標識をわざわざ利用している人は少ないだろうから、きっと、ただの足し算程度にしか使っていないだろう。
ADD 1 COUNT は、もう、すぐに意味がわかる。さらに、
COUNT = COUNT + 1 は、もっと、よくわかる。実は、自分はコンピュータ言語初体験が、（旧）BASICだからだ。BASICでは、正確には、
LET COUNT = COUNT + 1 なのだが、LETで命令系になり、「左辺に、右辺の演算結果を代入しなさい」、となる。やっぱり、足し算ツーたら、あなた、 ＋記号を使うものでしょう。これができるのもうれしい（かなり、低レベルの喜びだけれども）。また、お約束どおり、文字演算にも使える。こうでなくちゃ、とちょっと思う。
6文字地獄からの脱出
長い文字列をフィールド名に使えるようになった。うれしい！サブルーチン名や、ワークフィールド名も、わかりやすくなる。また、D仕様書では、15文字までの名前も使える。（「...」とは参ったが）
D ReturnedDs DS
D RiBytesReturned...
D 10I 0
D RiBytesAvailable...
D 10I 0 Inz( %Size( ReturnedDs ) ) |
なんにしろ、フィールド名が、記号の寄せ集めだった頃に比べれば、すばらしい飛躍だ。 もっと使いこなしたいな！
2002-2-2 | 
