なかなか、わかりやすく説明できなくて、気になっていたことを、何とか、説明できないものかと、このページを書きます。そして、これが、予備校最後の講義になります。
基本としては
プログラムの基本は、データベースの読み、書き、更新です。プログラムは、データベースを「レコード」単位に読み（READ系,
CHAIN系,）、「レコード」単位に書き(WRITE)、「レコード」単位に更新(UPDATE)します。もう少し詳しく見ると、
-
レコードの読込 ＝ レコードを構成するフィールドの読み込み（更新ファイルの呼び込みならレコードロック）
-
演算
-
フィールドの上書きセットなど
-
レコードの更新 ＝ レコードを構成するフィールドの書き出し（更新）
この一連の作業のためにプログラムを作成するわけです。
プログラムは、コンパイルの時にファイル情報を取り込みます。また、データベース（ファイル）は、その定義の中にファイル情報を持っています。このプログラムの持つファイル情報と、データベースの持つファイル情報が一致して初めて、プログラムは、目的の作動を行うわけです。このファイル情報は、9割がフィールド情報だと思ってください。ファイルからデータを読み込むと、ファイルの長さぶんのデータが、プログラムの入力域に入ってきます。そこを通過すると、そのファイルの長さ分のデータを、独立したデータに分解しています。そのあと、演算で、そのデータを参照したり、上書き変更、新規データセットをして、出力域から、ファイルの長さ分のデータに連結して、データベースに書き出しを行います。これを、もう少しプログラム的に表現したのが、上図の１から４です。
レコードの意義
パソコンのプログラムからこのRPGまで、必ず、プログラムは、「入力域」、「出力域」、のどちらか、もしくは両方 持ちます。（例外的に、パラメータに答えを返すだけのプログラムがありますが、ここでは無視します。）この入力域は、F仕様書でI、Uなどで定義したファイルのフィールドの情報（入力バッファ）をレコード別に持っています。出力域は、F仕様書で、O、Uなどで定義したファイルのフィールドの情報（出力バッファ）をレコード別に持っています。このときの、「フィールド情報」とは、フィールド名、フィールド長、フィールド属性です。これらの情報を一つ、一つ、左から右へ、くっつけていき、最後のフィールドまでくっつけた状態を、レコード といいうわけです（入力や出力のバッファの定義です）。つまり、入力域は、入力ファイルが持つ全レコードの情報を持ち、出力域は、出力ファイルが持つ全レコードの情報を持ちます。
先ほども書きましたが、そのプログラムに連結された（あるいは内包された）入出力域は、「コンパイル時」に生成されます。つまり、プログラムの実行時ではなく、プログラムの作成時点で、コンパイラーがファイル定義の中から、レコードのフィールド情報をかき集めて、プログラムに組み込んで生成します。このときに、レコード別のIDも同時に取り込んでいます。このIDと実行時のレコードレベル検査については、3.3.二つのレベル識別コードについてを参照してください。入力域、出力域はコンパイルリストを精読すれば、己とわかります。
データベースファイル - 入出力域 - プログラム
プログラムと入力域、出力域は、完全に連結されます。つまり、プログラムを実行すると、DBMSは、その入力域と出力域をデータベースファイルと連結します。つまり、<データベースファイル>-<入出力域>-<プログラム>という図式ができます。たとえば、プログラムは、レコードからREAD命令をだせば、DBMSの機能を経由して、入力域からプログラムにレコード情報が渡ります。また、プログラムは、出力域にレコードをセットしてレコードをWRITEすれば、そのレコード情報は、DBMSの機能を経由して、データベースに書き込まれます。さらに、プログラムは、レコードを更新モードで読み込（READ)むと、DBMSは、そのレコードをロックし、プログラムがそのレコードを上書きして、更新命令（UPDATE)をすれば、そのレコードは、DBMSを経由して上書きされ、そのレコードのロックは解除されます。
重要なのは、プログラムから見れば、ファイルのレコードにREAD、WRITE、UPDATEをすれば、勝手に、DBMSの援助のもとに、データベースファイルの読み込み、書き込み、更新が、行われる点です。つまり、プログラムは、データベースが見えておらず、ただ、定義されているバッファにデータをセットして、READ
WRITE UPDATE をしているだけです。書き出そうとしているファイルが、データベースなのか、画面ファイルなのか、印刷ファイルのなのか、はあまり気にしておらず（もちろん、印刷ファイルにREADはできないくらいの検査は、コンパイルで行いますが）、ただただ、レコードの読み込み、書き出しが、プログラムの入出力の範疇なのです。これは、とても大事なことです。つまりは、プログラムはDBMSの上でしか、動けない、と言っているのと同じことです。
画面装置ファイル
画面ファイル（画面装置ファイル）は、物理ファイルと同じようにDDSで作成されます。ちがうのは、画面上の表示位置の指定と画面やキーボードのDDSキーワードくらい。当然、レコードを持っていてて、プログラムでは、このレコードへのREAD,WRITE、EXFMTを行います。また、注意してほしいのは、バッファの定義順は、あくまで、DDSの上からの定義であって、行や桁の順番ではないのです。5行目10桁目にAFLD、6行目10桁目にBFLDがあっても、DDSでAFLDを先に定義し、そのあとにBFLDを定義したら、レコードはAFLD+BFLDの順番に定義されます。また、DDSでBFLDを先に定義し、そのあとにAFLDを定義したら、レコードはBFLD+AFLDの順番に定義されます。レコードの定義内容が変われば、レコードレベル検査にひっかかります。DDSの定義の中のフィールドの定義順番はとても重要です。（物理ファイルと同じですね）
画面ファイルのレコード様式に、READをすると、画面装置からの入力を待ちます。つまり、オペレータが、画面ファイルのレコードのフィールドにキーボードを使ってデータを入力して、最後に「実行キー」を押すのを待ちます。実行キーが押されると、データがプログラムの入力域にセットされて、プログラム内部にフィールドとして渡されます。これは、READ命令の直後に、フィールドを参照できます。このときも、DBMSが画面装置に結びついた画面装置ファイルのレコードと入力域を連結して、プログラムが入力域から、入力されたフィールドのデータを取り込んでいるわけです。上に書いた<データベースファイル>-<入出力域>-<プログラム>という図式の最初の部分が<画面>-<画面装置ファイル>に置き換わったわけです。つまり <画面装置>-<画面装置ファイル>-<入出力域>-<プログラム>という図式ですね。
印刷装置ファイル
印刷ファイル（印刷装置ファイル）も、同じように、DDSで記述されます。ここでは、出力だけですが、F仕様書に印刷ファイルが定義されるとコンパイラーは出力バッファへ、印刷ファイルのレコード情報を取り込みます。そのプログラムを実行すると、<プログラム>-<出力域>-<印刷装置ファイル>-<印刷装置>が連結されて、プログラムが出力域にレコードをセットして、WRITE命令をだせば、印刷装置ファイルを経由して、実際のプリンターから、紙が出てきます。実際には、スプールされるので、いったんOUTQに入って、印刷を待ちますね。まあ正確には、<プログラム>-<出力域>-<印刷装置ファイル>-<OUTQ>-<印刷装置>となります。どこのOUTQかなんて、プログラムは本来気にしてないのです。
プログラムはOSの手のひらの上
プログラムは、OSの上で動くものなので、OS側で定義すべきものは、装置ファイルに取り込まれ、プログラムは、それとは独立し、また、無駄な情報を装置ファイルとプログラムとで、２つ重複して定義しないようにすべきです。L仕様書がなくなったのもそんな経緯だと思います。OUTQの指定が、プログラムと装置ファイルの両方にある場合、とても処理が面倒です。ただし、ファイルを読み込んで、その区分でOUTQを変更しながら印刷する場合、プログラムの中でOUTQを指定することもあるでしょう。これは例外です。原則としては、実行時の環境定義は、プログラムの外で、そのお膳立ての上で、無駄に重複定義しないで、プログラムが存在してほしいのです。
さて、このように、プログラムからは、直接装置は見えていませんが、OS機能の一部が、プログラムに必要な機能を「お膳立て」して、プログラムの実行を援助しています。OSが援助してくれなければ、プログラムが必要とするファイルなどの資源の利用は不可能です。また、プログラムの実行中にこのOS機能（DBMS機能）の情報から必要なものを取り出すこともできます。ファイル情報データ構造です。オープンしたファイルのファイル名やライブラリー名、メンバー名などDSを経由して取り出せますが、通常の適用業務で使うことは、あまりまりません。しかし、だからと言って、おろそかにせず、これらの勉強もしてください。RPGのマニュアルにでています。
最後に
長かった、というより、休講が多かったのですが、お付き合いくださり、ありがとうございました。今の時点で、できる限りのことはしたつもりです。
がんばって、RPGの達人になってくださいね。
では
起立、礼、着席。
2005-7-7
| 
