17.4.System36とRPG2

今日は、研修で学んだ、ＳＹＳＴＥＭ３６について、お話しましょう。といっても、詳しいことは分かりません。なぜかというと、研修でやっただけなのです。

研修内容は、プロシージャを理解して、ＲＰＧＩＩを学習して、リストを印刷するソースを作成して、コンパイルして、リストを実際に印刷する。それだけでした。

さて、初めてここで、ＲＰＧが出てきました。ＲＰＧＩＩはその当時、ＲＰＧＩＩＩと並んでＩＢＭが提供する（推薦する）言語でした。パソコンのＢＡＳＩＣとはぜんぜん違います。表記方法が、フリーカラムではないのです。命令語を記入する場所も、各種パラメータも、場所が決まっています。「表記入形式」と呼ばれたりします。

皆さんは、パンチカードって知っていますか。少し年を召した方なら、実際に使っていたものです。80桁のカラムがあって、ここに穿孔タイプして、それをカードリーダにどかっとセットします。リーダがガシュガシュ読み込みます。このカードが80桁のため、ＲＰＧＩＩもＲＰＧＩＩＩも80桁までの表記になりました。

この予備校の目的は、ＡＳ／400ですが、ＲＰＧＩＩに関しても学ぶべきところがあります。つまり、ＲＰＧＩＩＩにしろ、ＲＰＧ４００にしろ、ＲＰＧＩＬＥにしろ、原形はＲＰＧＩＩにあります。ほんとに、初めての方は、戸惑うかもしれませんが、分からずとも気にしないで、どんどん先に進んでください。後で、分かってくるはずです。

ＲＰＧの基本

名前の由来（はじめに）

ＲＰＧはReport Program Generatorのアクロニムです。もともとは帳票やバッチ処理の簡易言語です。ＩＢＭ以外のメーカでも、擬ＲＰＧがあるのですが、彼らのメインはＣＯＢＯＬです。彼らにとっての擬ＲＰＧは、ただの簡易言語なのです。ツールの一種のようです。昔、東芝のプログラマーに、よくあんな簡易言語で画面表示できるね、と真顔で感心されました。張り飛ばそうかと思いましたが、彼らは知らないのです。ＲＰＧは、ＡＳ／400のバックアップを受けた、恐ろしくパワフルな言語です。ＣＯＢＯＬなんて目じゃない。

言い忘れましたが、ソースを入力して、コンパイラにより、それをコンパイルをして、マシン語を生成します。コンパイルとは、COM-PILEつまり、PILE(積み上げた山）をCOM(一つにする）ことです。アメリカ人は、われわれ日本人よりも、コンピュータを身近に感じているではずです。言葉のニュアンスまでは日本人には分からないですから。

構文エラー検査は、入力ツールで、一行以内までは検査してくれるのですが、別の行との関連のエラー検査まではしてくれません。よって、このような、前後関係によるエラーはコンパイルで初めて分かります。たいてい、未定義エラーが多いと思います。ＢＡＳＩＣでは、（入力バッファの定義はきちんとしますが）、プログラム内部だけで使われる変数の桁は指定しませんでしたが（全部省略値が適用される）、ＲＰＧでは（他のコンパイラ型も）プログラム内部変数の定義はきちんとしなければなりません。これがないと、コンパイルエラーです。定義したつもりでも、フィールド名を間違えて、同じエラーが出たりします。

コンパイルでエラーは無いのに、処理したら変な場合、「バグ」があるといい、このバグを取ることを「デバッグ」といいます。バグのことを、「不具合」という人もいます。「バグ」という言葉がきつい印象を与えたり、正式な場では、俗語に聞こえると思う人が、「不具合」という言葉を使うようです。なんと言おうと、バグはバグなのです。それから、チェッカー（納品前のプログラムの動作検査）をしていて、分かりましたが、どんなに優秀な人でもバグを出します。つまり、バグの無いプログラムは、この世に無いと思ってもいいでしょう（気構え）。ありとあらゆる状況を想定して、テストをすべきです。１０回テストしてｏｋでも１１回目にバグを発見します。２０回テストしてｏｋでも２１回目にバグを発見します。

昔、ある映画で、ある車が「欠陥車」なのに、販売してしまい、爆発事故がおきて、その大手自動車会社を相手取って訴訟する、という映画がありました。この映画の中で、出荷予定のその自動車にあらゆるテストをした学者（？）が重要なファクターとなったのですが、この学者がこう、言ったのです。

「すばらしい自動車で、何の欠点も無かった。但し、一つを除いては。つまり、左に曲がろうと、ウインカーをつけたまま、半分くらい曲がったところで、左後ろから追突される場合だけ、大爆発するので、出荷を止めるようにレポートを出したんだ。」

結局、確率的に、この大爆発による損害賠償の総額より、RECALLの方が高くかかるという「計算部」の考えで、そのまま出荷してしまったのです。

ところで、この学者の、この大爆発の条件の入り込んでいること。

ガソリンを霧状にし、車の左内部にある、エンジンルームに渡す管が異様に細いので、左後ろから追突されるとこの管が折れて、しかも、ウインカー点滅の電気がスパークするので、爆破するのが原因でした。（映画の話ですよ。）

ここにも、バグがあったのです。このバグはさまざまの要因が、全部成就するとおきるようです。このようなバグも探し出すのは、結構大変です。10年以上動いていたのに、設定を変更したら、急に止まったというような話は、「日経コンピュータ」によく出ています。これから、プログラムを作り始めれば、必ずこのバグとの付き合いも始まってしまうのです。

ＲＰＧＩＩ仕様書（ＳＰＥＣ）

ＲＰＧは、あらかじめ決められたカラム（定位置）を持っています。命令語などは、その決まった場所に書きます。「表記述言語」と呼ばれるゆえんです。このあたりは、暗記するしかありません。特に、「仕様書」という概念は大事です。これはつまり、その「表」の種類を意味します。特に大事なのは、IとCとOです。

この仕様書は、処理内容の種類と考えてもいいようです。順番が決まっています。研修時代は、Ｈのフェルチコと覚えました。HFELTICOです。さて、現在のＲＰＧ400では、HFEICOです。Ｌは使えたか覚えてませんが、ＡＳ／400では不要です。「Ｈのフェイ子」でしょうか？

プログラムの基本

それは、入力 (input)－処理 (calculate、process) －出力 (output) です。

仕様書も、ＩＣＯの順番ですよね。結局、プログラムというのは、データを取り込んで、処理して、吐き出すだけです。これに対して、「出力だけのプログラム」、「処理するだけのプログラム」、「入力するだけのプログラム」なんて、意味がありません。(たまに、テストデータをファイルにかき出すだけのプログラムというのがありますが、まともな使い方ではありません)、入力して、処理して、出力する、この三つがそろわなければ無意味です。必ず、プログラムには入口と出口があって、中でなにかするものなのです。

ファイルの扱い

ファイルを10本参照する、プログラムであっても、その大半は、メインに参照するファイルはたいてい１本です。たとえば、一本のファイルを順次読み込んでいくのだけど、他のファイルにある名称を取り出したり（名寄せという）、他のファイルにある金額などを参照したりして、処理するのが大半です。それで、たいていはメインのファイルが一つ決まります。（これとは別に、まれにまったく違う形式も出てきます。たとえばマッチング処理などですが、この予備校で説明するものではないと思いますので、スキップ（無視）します。）

また、他の言語では、ファイルを参照する場合、ファイルのオープン処理やクローズ処理をコーディングしますが、このＲＰＧシリーズ全体を通じて共通に、それは不要です。プログラム起動時に「暗黙のオープン」をします。省略値は勝手に開閉する、と覚えてください。注意：クローズはサイクルでは自動、全手順では、ＬＲ(Last Record)をオンにする必要がある。また、オープンの順番は、Ｆ仕様書に指定したファイルの一番最後を最初にオープンして、次に最後から二番目をオープンして、最後に、Ｆ仕様書の最初に定義したファイルをオープンします。上からではなく、下からオープンしていくのです。理由は知りません。

自分の都合でオープンしたり、クローズしたりするコーディングをしたければ、逆に明示的にオープン指定（ユーザーコントロール）をせねばなりません。このユーザーコントロールは後で覚えてください。

ＲＰＧサイクル

ＲＰＧの特徴は、ＲＰＧサイクルと呼ばれる処理があることです。（この機能を使わない場合を、全手順（FULL PROCEDURE）といいます。）この機能だけ見ると、確かに簡易言語的です。つまり、おおざっぱに言うなら、ファイルを読み込んで、大中小の合計を出すための、画期的な機能です。ＲＰＧサイクルの利用形態の大半はこの、合計制御です。サイクル指定はＦ仕様書で決まります。上で述べたように、メインとなるファイルを「プライマリーファイル」と読んで、Ｆ仕様書の、ファイルの指定にＰと記述します。するとコンパイラは、このプログラムを、サイクル処理と判断します。そして、ファイルオープンから、レコードの読み込みまで、「勝手に」やってくれます。非常にすばらしい機能です。折りたためればコンパクトで、広げるとなんでもできるような、すばらしい道具のイメージです。

入力で関係するもの（内部記述とは）

プログラムの入力で関係するものは、ファイル(F仕様書)、レコード（Ｉ仕様書）、そして、入力パラメータです。

このレコードの定義、Ｉ仕様書こそ、今回の講義の核心です。

そもそも、プログラムは入力したデータを、ある長さで区切り（レコード）、その内容を、意味のあるデータ（フィールド）に分解して、処理を続けます。これは、「すべてのＲＰＧ」に共通です。ＢＡＳＩＣですら同じことをします。そして、このフィールドに分解する部分が無ければ、そのレコードを構成するフィールドたちは、続く「処理」「出力」でも認識されません。だから、この入力処理は、処理の前に定義されます。

たとえば、ある人の設計で、このようなレコードを作ったとします。

ファイル名は、「MASTER」で、「社員番号：6桁：文字」、「社員名：３０桁、漢字」（漢字の話はまた後でします）。
この2つだけのフィールドで構成されるとします。これをプログラム的には、以下のように考えます。

こうやって、ソースを入力します。今回、２つのフィールドなので、超簡単ですが、こえが200個あったら大変ですよね。たいてい、ＳＥが、てってけと、Ｉ仕様書の部分だけ入力してあって、他のプログラムはそれをコピーします。すると、フィールドの名前も共通になりますよね。これでいくと、プログラムの中に、この入力レコードのレイアウト（１から６が何、7から36が何のこと）を、プログラマーが、「こつこつ」入力しなくてはいけませんよね。これに対して、RPG IIIとかRPG400では、ファイルに記述情報が入るので、それを利用します。つまり、コンパイラが、そのファイルの記述を勝手に取り出してくれて、入力レコードのレイアウトを作ってくれます。そこで、前者の「こつこつ入力型」を「内部記述」または「プログラム記述」、後者のコンパイラ使役型（お気楽モード）を「外部記述」といいます。「内部」「外部」は、プログラムを中心に考えた、言葉です。RPGIIは、内部記述だけですが、RPGIII,RPG400は「内部」「外部」とも可能です。

※そもそも、外部記述は、OS400の機能があって、可能となるものなので、RPGIIが違うOS上の言語である以上「外部記述」を使えるはず無いのです。

ここで、声を大にして言いたいのは、ＡＳ／400で、たとえ「外部記述」を使い、プログラマー自身が「こつこつ」I仕様書を入力していなくとも、コンパイラが勝手に取り込んでくれるので、入力のレイアウトは存在するということです。まるで、魔法でもかけたように勝手にOSが入力レイアウトを決めているわけではありません。そりゃ、私だってそうしてほしいけど、現状ではまだだめなんですよ！これを、絶対に忘れないでください。基本中の基本です！

SEO		[PR] 爆速!無料ブログ無料ホームページ開設無料ライブ放送