Google
オフコン練習帳内を検索
インターネット全体を検索

NECオフコン関連
オフコン一般
情報
トップ  >  理論編  >  A−VX - 待機結合編成ファイル

待機結合編成ファイルについてもう少し詳しく

1.どんなファイルか

待機編成ファイルの一種でQLという略称で呼ばれることもあります。ファイルの中にさらにメンバと呼ばれるものを複数(ファイルのサイズが許す限り)入れることができます。データファイルとしては使用できず、頻繁にメンバのデータ内容の更新がかかるような用途に使用されます。主に以下のようなファイルとして使用されます。

  • ソースユニットライブラリ(SUL)
  • コンパイルユニットライブラリ(CUL)
  • パラメータファイル(PML)
  • ジョブストリームファイル(JSL)
  • ドキュメントキャビネットファイル(DOC)
  • 表データ定義ファイル(SYS@DBDIR)
  • ユーザスプールファイル(SPOOL)
  • etc.

これも待機区分編成ファイルと同じで、通常のA−VXでは、ユーザプログラムから自由に読み書きする手段が用意されていません。
用途も限られているので、あまり書くことはありません。

2.メンバ

メンバは、いろいろな種類があります。

  • ソースユニット(SU)
  • コンパイルユニット(CU)
  • パラメータ(PM)
  • ジョブストリーム(JS)
  • etc....

メンバとファイルは、1対1で対応しています。例えば、ソースユニット(SU)を入れるファイルが、ソースユニットライブラリ(SUL)です。パラメータファイル(PML)に、ソースユニット(SU)を入れることはできませんし、逆も同じです。

同じメンバというものが入っていますが、待機結合編成ファイルに入れるべきメンバを待機区分編成ファイルに入れることはできません。例えば、ソースユニット(SU)をロードモジュールライブラリ(LML)に入れることはできないということです。

3.オーバーフロー

はるか昔ITOS(1980年代)の初期バージョンでは、一旦オーバーフローするとメンバをいくら削除してもオーバーフローを解除することができないという仕様だったらしく、はるか昔の説明書にはそのようなことが書いてあるものがありますが、今はそんなことはありません。

ただしマルチエクステント構成は取れないので、エクステントの拡張/追加も行えません。
待機結合編成ファイルがオーバーフローになった場合は2つの方法があります。1つは不要なメンバを削除して空きを作る方法、もう1つはもっと大きなファイルで作り直してメンバをそのファイルに移動する方法です。

4.ソースユニットファイル(SUF)

ソースユニットライブラリファイル(SUL)とは別にソースユニットファイル(SUF)と呼ばれるファイルがあります。 これは待機編成ファイルではなく、ある種の特殊な形式のファイルですが、説明の都合上ここに書いておきます。

SULが1つのファイルに複数のSU(SULのメンバのことを特別にソースユニット(SU)と呼ぶ。)を入れることができるのに対して、SUFは1つのファイルに1つのSUしか入れることができません。
SUFには最大65533レコードのサイズのSUを入れることができます。SUは即ちCOBOLやFORTRANのソースプログラムのことで、1行=1レコードなので、最大65533行のCOBOLのソースプログラムまで入れることができます。

5.待機区分編成ファイル(QP)と待機結合編成ファイル(QL)の違い

両方とも待機編成ファイルで、ファイルの中に複数のメンバを格納できるという点で共通しています。
何が異なるかというと、待機区分編成ファイルはメンバを連続領域で格納しなければならず、待機結合編成ファイルはメンバが連続領域に格納されていなくてもよいという点です。

Windowsではハードディスクにファイルの書き込みや削除・更新を続けているとファイルのデータがハードディスクのあちこちに散らばってしまう「断片化」というものが発生しますが、A−VXでも同じです。待機編成ファイルは1つのファイル中に複数のメンバが入っているので、メンバの書き込みや更新を続けていると「断片化」が発生してしまいます。

違いを具体的に例を挙げて説明します。

図のように、いっぱいメンバが入っていて空きが4セクタ分しかなく、おまけに「断片化」により空きがファイル中にバラバラに存在する待機編成ファイルがあるとします。
このような状態のファイルに3セクタ分の大きさのメンバを新規に入れようとしました。




待機結合編成ファイルは、空き領域がバラバラにあっても、入れるメンバのレコード分あれば問題ないので、メンバはバラバラになって格納されます。

ところが待機区分編成ファイルの方は、空き領域が連続していないといけないので、図のように入れるメンバのサイズ分の連続領域が無い場合は、たとえ空きの合計が十分あったとしてもファイルオーバーフローになってしまいます。
待機区分編成ファイルは、「ファイルの再編成」というものが用意されており、この処理を行うことにより(最近のA−VXはオーバーフローすると自動的にやってくれる。ユーティリティを使って手作業でもできます。)連続した空き領域を作ることができます。
メンバのサイズ分の連続した空き領域を作ることができれば、無事メンバを格納することができます。

一見するといちいち「ファイルの再編成」をしなくてもよい待機結合編成ファイルだけあれば良さそうに見えます。

なぜ待機区分編成ファイルがあるかというと、読み込みで利点があるからです。
待機結合編成ファイルはバラバラにメンバが格納されているので、1つのメンバを読み込む場合、最悪あっちこっちから読み込まなくてはなりません。一方待機区分編成ファイルは連続した領域に格納されているので、一気に読み込むことができます。待機区分編成ファイルの方が読み込みが速いのです。

ロードモジュール(実行するプログラム)はすばやくロードされて実行してほしいので、ロードモジュールを格納するLMLは待機区分編成ファイルになっています。
ソースプログラムは頻繁に書き換えが行われて「断片化」しやすいので、SULは「断片化」していても再編成なしで書き込める待機結合編成ファイルになっています。

ライブラリファイルは、効率良く動けるようにQLかQPのどちらかになっています。これはシステムで決まっているので、「俺は開発効率を上げるために、作成中のソースプログラムを早く読み込みたいので、ソースユニットライブラリをQPにしたい!」とか思っても無理です。ソースユニットライブラリはQLと決まっています。