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

１．どんなファイルか

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

• ソースユニットライブラリ（ＳＵＬ）
• コンパイルユニットライブラリ（ＣＵＬ）
• パラメータファイル（ＰＭＬ）
• ジョブストリームファイル（ＪＳＬ）
• ドキュメントキャビネットファイル（ＤＯＣ）
• 表データ定義ファイル（ＳＹＳ＠ＤＢＤＩＲ）
• ユーザスプールファイル（ＳＰＯＯＬ）
• etc.

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

２．メンバ

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

• ソースユニット（ＳＵ）
• コンパイルユニット（ＣＵ）
• パラメータ（ＰＭ）
• ジョブストリーム（ＪＳ）
• etc....

メンバとファイルは、１対１で対応しています。例えば、ソースユニット（ＳＵ）を入れるファイルが、ソースユニットライブラリ（ＳＵＬ）です。パラメータファイル（ＰＭＬ）に、ソースユニット（ＳＵ）を入れることはできませんし、逆も同じです。

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

３．オーバーフロー

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

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

４．ソースユニットファイル（ＳＵＦ）

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

ＳＵＬが１つのファイルに複数のＳＵ（ＳＵＬのメンバのことを特別にソースユニット（ＳＵ）と呼ぶ。）を入れることができるのに対して、ＳＵＦは１つのファイルに１つのＳＵしか入れることができません。
ＳＵＦには最大６５５３３レコードのサイズのＳＵを入れることができます。ＳＵは即ちＣＯＢＯＬやＦＯＲＴＲＡＮのソースプログラムのことで、１行＝１レコードなので、最大６５５３３行のＣＯＢＯＬのソースプログラムまで入れることができます。

５．待機区分編成ファイル（ＱＰ）と待機結合編成ファイル（ＱＬ）の違い

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

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

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

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

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

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

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

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

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

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