バッファ管理など

１　ファイル入出力管理

ハードディスクから読み書きするときはブロック単位で、プログラムが読み書きするときはレコード単位になります。（これは他のオフコンやメインフレーム系のＯＳも共通している仕組みだと思います。）

なるべくレコード長の倍数がブロック長にした方が効率がいいです。例えばレコード長が64バイトのときは64×4でブロック長は256バイトにします。これがレコード長が60バイトでブロック長が256バイトだと60×4=240バイトで、ブロック単位で読み書きしたときに16バイト分のゴミを読み書きすることになります。

またバッファ管理の仕組みから、ブロック長の整数倍が16セクタ（つまり4096バイト）となるようにアロケートすると効率的にアクセスできます。
これはＡ−ＶＸの仕組み上、実際はブロック単位ではなく１６セクタ単位で読み書きしているからです。

また索引順編成ファイルの場合は、キーブロック長とデータブロック長が同一となるようにすると効率的にアクセスできます。

２　バッファ管理

Ａ−ＶＸでは入出力処理に入出力バッファというものが使われます。（他のＯＳでも一般的に使用されるものですが。）

ハードディスクの読み書きやプリンタへの印刷などデータの入出力の速度は、ＣＰＵと比べるととても遅いです。そこで入出力バッファというものをメモリ内に用意して、そこにデータを溜める仕組みがあります。

例えばファイルからレコードを順番に読み込むようなプログラムの場合は、いったんメモリ上の入出力バッファにまとめて読み込んで、ディスクからではなくメモリからレコードを読み込むようにすれば、処理が速くなります。またプリンタに印刷するときも、印刷データを入出力バッファ（にまとめて書き出してしまえば、プログラムはプリンタが印刷を終えるのを待ち合わせる必要がなく、次の処理に移ることができます。

１個の入出力バッファを使うシングルバッファと、２個の入出力バッファを使うダブルバッファがあります。プリンタバッファはダブルバッファにすると特に効率的に動きます。

システムが用意しているシステムバッファがあり、このバッファは全てのジョブが共有する形で使用します。このシステムバッファ上に入出力バッファを作ることができます。ハードディスクやフロッピーディスクの入出力で使用するバッファのことをディスクバッファ、プリンタで使用するバッファのことをプリンタバッファといいます。

ディスクバッファやプリンタバッファのサイズはＡ−ＶＸのシステム生成という方法で変更することができます。

３　参照モード

だいたい大まかに書くと、バッファの使い方次第でファイルアクセスの高速化の手段がいくつかあります、ということです。

入出力バッファを大きくして、物理入出力を減らし、ファイルの入出力を高速にする技法です。

3.1　ＭＯＶＥモード（ＭＯＶＥ　ＭＯＤＥ）　

ハードディスクなどの入出力装置からブロック単位で読み込んだデータをシステムが用意している入出力バッファにいったん入れて、プログラムのREAD/WRITEなどの命令に従って１レコードずつユーザプログラムの作業エリアにコピーする仕組み。ユーザプログラムは作業エリア内にコピーされたレコードを使って処理を行います。

上で「ブロック単位で読み込む」と書きましたが、実際はＡ−ＶＸの内部では１６セクタ単位で読み込んでいます。

このモードはどのファイル編成でも利用できる、一番一般的なモードです。特に指定しないとこのモードになります。

3.2　ＭＯＶＥモード１（ＭＯＶＥ　ＭＯＤＥ１）　

ＭＯＶＥモードと異なり、入出力バッファをシステムが確保したバッファではなく、ユーザメモリ内に（つまりスレッド内のメモリ空間に）バッファを確保します。

システムが用意するバッファはシステム生成で設定したサイズしかないので、多くのジョブが動くと限られたサイズでやり繰りしようとして負荷が高まります。そこでジョブが自分のメモリ内に入出力バッファを確保すれば、システムのバッファを使用する必要がないので負荷を軽減することができます。

ハードディスクなどの入出力装置からブロック単位で読み込んだデータをユーザメモリ内に確保した入出力バッファにいったん入れて、プログラムのREAD/WRITEなどの命令に従って１レコードずつユーザプログラムの作業エリアにコピーする仕組み。ユーザプログラムは作業エリア内にコピーされたレコードを使って処理を行います。

このモードはどのファイル編成でも利用できます。

3.3　ＭＯＶＥモード２（ＭＯＶＥ　ＭＯＤＥ２）　

別名バーストモードと呼ばれる高速アクセス方法です。制約が多いモードでもあります。

ＭＯＶＥモード１と同じようにユーザメモリ内に入出力バッファを作りますが、そのサイズを大きくできます。
入出力バッファのサイズはシステムの負荷状況に応じて自動的に決定され、ブロック長の整数倍（最大約６４キロバイト）分の大きさとなります。

ブロック単位でハードディスクから読み書きするのではなく、数ブロックをまとめて入出力バッファに読み込みます。最大６４キロバイトなので、１６セクタ（４キロバイト）と比べてもかなり大きなサイズのバッファが確保されます。入出力バッファに読み込んだデータから必要に応じてユーザプログラムの作業エリアにコピーするので、ファイルの高速入力、高速出力が可能になります。

ＣＰＵの負荷が非常に上がります。それは入出力装置へのアクセス待ちが無くなるため、ＣＰＵがひたすら動き続けるためです。このためバッチ処理で利用することが多いです。ただしタスクの優先度が高いとこのジョブばかりが動いて他のジョブの処理が先に進みにくくなることがあるため、優先度の調整が必要になります。一般的にはＭＯＶＥモード２を利用するジョブの優先度を下げます。

乱アクセスを行うような処理にも相性が悪いことが多いです。乱アクセスの場合は入出力バッファ内にレコードがあるときはいいのですが、入出力バッファにないときは頻繁にハードディスクにアクセス、さらに読み込みデータのサイズが大きいので、無駄に大量に読み込むことになり、逆に遅くなります。

このモードはハードディスクの順編成、相対編成ファイルに対して指定できます。そして共用モードでは使用できません。

さらにオープンモードは次の組み合わせのみ指定ができます。
・ＯＰＥＮ　ＩＮＰＵＴ　−　ＰＲＯＴＥＣＴ／ＥＸＣＬＵＳＩＶＥ
・ＯＰＥＮ　ＩＯ／ＯＵＴＰＵＴ／ＥＴＥＮＤ　−　ＥＸＣＬＵＳＩＶＥ

3.4　ＬＯＣＡＴＥモード（ＬＯＣＡＴＥ　ＭＯＤＥ）　

他のモードは入出力バッファにデータを読み込んだ後にユーザプログラムの作業エリアにレコード単位でコピーしますが、ＬＯＣＡＴＥモードは作業エリアにコピーせずに入出力バッファをそのまま作業エリアとして使用します。コピーする手間が省けるので、その分だけ速くなります。

このモードを使用できるのは順編成ファイルのみです。

４　ディスクキャッシュ

ＮＥＣの公式の説明書を引用すると、ディスクキャッシュは次のようなものです。

ディスクキャッシュ機能は、ユーザ業務プログラムからの追加・更新・削除命令に対し、実際の出力動作をユーザ業務プログラムと非同期に行うことにより、ファイル出力を高速化する機能である。 この機能はバッチ系の処理が進むために、バッチ系タスクの優先順位を低くしておくことが望ましい。 この機能は磁気ディスク上の索引順編成、複数索引順編成ファイルに対して機能する。 ［データ管理説明書（２００９年１１月版）−４．１０　ディスクキャッシュ］より

上で書いたディスクバッファは、ディスクキャッシュの有無によって動きが異なります。

4.1　ディスクキャッシュなしディスクバッファの管理

上のディスクバッファで説明したように、物理入出力の実行時に、ディスクバッファに入出力バッファが動的に確保されます。 ファイルのデータブロックの入出力バッファは、ジョブの使用ファイル毎に１つ確保され、ファイルのキーブロックの入出力バッファは、ディスクバッファに保持する目的から、確保できるだけ確保していきます。

データブロックは、同じ物理ファイルを処理する２つのジョブが実行する場合には、データブロックの入出力バッファは１〜２個確保されます。
キーブロックの入出力バッファは、データブロックをアクセスする為に必要なだけディスクバッファに確保されます。それにより、キーブロックの物理入出力を減らす効果があるからです。

ディスクバッファに確保した入出力バッファは、次のタイミングで解放します。

• ファイルのクローズ時
• ファイルの仮クローズ時
• ディスクバッファの空きが無くなったとき（LRUアルゴリズムで解放する入出力バッファを選択する）

キーブロックをディスクバッファに保持することによって、キーブロックの物理入出力を減らし、高速処理が期待できることになります。しかし、「ディスクバッファの空きがなくなった時」にキーブロックの保持の効果が無くなってしまいます。このため、ディスクバッファのサイズは大きい方が、キーブロックの保持の効果がフルに発揮できることになります。

4.2　ディスクキャッシュありディスクバッファの管理

ディスクキャッシュなしシステムのディスクバッファの管理では、キーブロックの保持によって入出力処理の効率を上げるものでした。ディスクキャッシュありシステムのディスクバッファの管理では、それに加えて出力処理の効率も上がるようにするというものです。

それは、ディスクキャッシュを使用して次のように実行されます。

ディスクキャッシュの一部がディスクバッファとなり、出力情報を記録する領域がディスクキャッシュの一部に用意されます。

ジョブからの出力命令は、ディスクバッファにデータブロックを書き込み、ディスクキャッシュに情報を書き込んで、命令は終了します。ハードディスクへの出力はありません。論理出力命令に物理出力が伴わないために、高速処理が期待できます。

ファイルへの物理出力は、Ａ−ＶＸシステムの「Ｉ／Ｏ管理タスク」が論理命令とは非同期に実行します。「Ｉ／Ｏ管理タスク」は、プロセッサとディスクバッファの使用率を監視し、効率よくハードディスクに出力します。

このように、非同期に出力を可能にするため、ディスクバッファに確保される入出力バッファはファイルのキーブロック／データブロックとは関係なく、確保できるだけ確保し保持するようになっています。そのため、ディスクバッファサイズはキャッシュなしシステムに比べ、拡大することにより効果が大きくなります。

ディスクキャッシュありシステムでは、出力命令を連続して実行するジョブは物理出力を伴わないので、ＣＰＵの使用率が上がり、他のジョブが動きにくくなることがあります。そのような場合は出力命令を連続して実行するジョブの優先順位を下げます。

非同期でハードディスクに書き込むので、突然オフコンが落ちてしまうと書き込んだデータは失われてしまう可能性があります。それを防止するためにSYS@CACHEというシステムファイルがあります。これを有効に使うには、オフコンが落ちてしまった後に一定の手順や注意が必要です。オフコンが落ちることはあまりないと思うので、ここでその説明は省略します。ＮＥＣのデータ管理説明書のシステムダウン時には〜のところを見てください。

ディスクキャッシュを使用するかどうかの設定はシステム生成で行います。

オフコンにＵＰＳが付いているときは、ディスクキャッシュを使用するように推奨しています。ＮＥＣのオフコンは（一部の例外を除いて）ＵＰＳが付いているので、ディスクキャッシュを使用する設定一択です。

ちなみにＵＰＳが付いていないオフコンはディスクキャッシュを使用しないに設定します。

Ａ−ＶＸのSRV（つまりMSD000ね）にSYS@CACHEがあります。このSYS@CACHEをSRV以外のディスクにもアロケートすることによりディスクキャッシュ機能の信頼性が向上するようです。

ちなみにシステム７２００やシステム３１００といった大昔のオフコンがＮＥＣ専用のハードウェア／ソフトウェアの時代は、ディスクキャッシュ機構と呼ばれる特別なハードウェアでディスクキャッシュ機能が実現されていました。バックアップメモリとバッテリーが組み合わさったハードウェアで書き込んだ情報をバックアップメモリに入れることによって、非同期で書き込んだり突然システムがダウンしたときにデータを保証したりということを実現していました。

Ａ−ＶＸがＷｉｎｄｏｗｓ上の仮想環境で動いている今は、普通にＷｉｎｄｏｗｓのメモリの一部を利用しているようです。突然システムがダウンしたときは、ＵＰＳを利用して電源が生きている間にSYS@CACHEに書き込んでデータを保証しているようです。