ボリュームやファイルを管理しているもの
- １ ボリュームやファイルを管理しているもの
-
Ａ−ＶＸは、システム全体のファイルやハードディスク内のファイルを管理するために、いくつかのシステムファイルを用意しています。全く意識しなくて良いもの、サーバ管理者レベルで使用するものなどそれぞれ異なります。。
ファイルの管理の仕組みを知らなくても使えますが、万が一トラブったときのために理解しておいたほうが良いので、少しだけ説明しておきます。
ファイル名 簡単な説明 SYS＠FDF ファイルディレクトリファイル SYS＠FSDF フリースペースディレクトリファイル SYS＠CAT ボリュームカタログファイル SYS＠DDF データディクショナリファイル SYS＠DBDIR 表データ定義ファイル - ２ ファイルディレクトリファイル（SYS@FDF）
-
磁気ディスクのボリューム毎（ＭＳＤｘｘｘ）に各１個ある。ボリューム内にあるファイルのいろいろな情報が保存されている。
データ管理説明書にいろいろ説明が書いてあるが、Ａ−ＶＸのシステムが使用するもので、一般ユーザは全く意識する必要は無い。ファイルをアロケートしたりデアロケートするとシステム側が自動的にこのファイルの内容を書き換える。
このファイルが壊れたりするとデータファイルが読めなくなったりするので、非常にまずい。当然ユーザが勝手にこのファイルを削除したり作ったり中身を書き換えたりファイルサイズを変更したりといったことはできない。
昔、ボリュームが壊れたときに、このファイルの中のバイナリ情報を書き換えて復旧したという超絶技巧の持ち主がいたらしい。普通の人はできない。
- ２ フリースペースディレクトリファイル（SYS＠FSDF）
-
磁気ディスクのボリューム毎（ＭＳＤｘｘｘ）に各１個ある。ボリューム内にある未使用の領域の情報が保存されている。
データ管理説明書にいろいろ説明が書いてあるが、Ａ−ＶＸのシステムが使用するもので、一般ユーザは全く意識する必要は無い。当然ユーザが勝手にこのファイルを削除したり作ったり中身を書き換えたりファイルサイズを変更したりといったことはできない。
- ３ ボリュームカタログファイル（SYS＠CAT）
-
システムに１個、ＳＲＶと呼ばれるボリュームに作られる。ＳＲＶは通常はＭＳＤ０００なので、ＭＳＤ０００に作られるということです。
SYS@FDFがボリューム毎のファイルを管理しているのに対して、SYS@CATはシステム全体のファイルを管理しています。
物理ファイル情報、リモートファイル情報、ＲＤＢファイルや仮想表の情報が格納されていいます。
使い方としては、ＷｉｎｄｏｗｓやＬｉｎｕｘのｐａｔｈに近いです。ボリュームカタログファイルにファイル情報を格納することによって、MSDと装置タイプだけ指定するだけで、装置番号を補完して、ファイルを探してくれたりします。システムがＲＤＢの表に紐づけされている物理ファイルを探すことができるのも、ボリュームカタログファイルのおかげです。
ＲＤＢファイルのように、表を作成したときにシステムがボリュームカタログファイルに登録してくれる場合もあれば、遠隔ファイルのようにユーティリティを使って登録しなければならない場合もあります。
SYS@CATはＡ−ＶＸをインストールするときに、ファイルサイズを指定します。（SYS@FDFやSYS＠FSDFはファイルサイズを指定できず、システムが勝手に決めます。）Ａ−ＶＸのシステム全体で何個のファイルを使うなら何セクタのサイズのSYS@CATにするという風に計算式があります。
Ａ−ＶＸをインストールするときに作られて、その後は（例えオーバーフローしたとしても）ファイルサイズは変更できません。例えばＡ−ＶＸ全体で５００個のファイルを使用するつもりでSYS@CATのファイルサイズを決めて、実際に５０１個アロケートしたりするとSYS@CATがオーバーフローしてしまいます。
最初に大きすぎず小さすぎずちょうどいいサイズで作らなければならないというめんどくさいファイルです。将来何個のファイルを使うか予想なんかできないでしょう。
- ４ データディクショナリファイル（SYS＠DDF）
-
条件によっては無くてもいいですが、必要ならシステムに１個作ります。データベースの実表や仮想表（ビュー）の情報を登録したり、一般ファイルのフィールド情報を登録したりします。ＳＭＡＲＴやその他いろいろユーティリティで情報を登録したり使用したりとよく使われる。このファイルのサイズによって、そのシステムで使用可能な仮想表（ビュー）の数が決まります。
データディクショナリファイルは説明が少し難しい。用途は２つあります。
まず簡単な方。１つはデータベースの表の情報が格納されています。データベースを利用するときは必ずこのSYS@DDFに表やフィールド（項目）の情報を入れないといけません。プログラム上とSYS@DDFに格納されているフィールドの構成は一致していないと動きません。
もう一つは、ファイルの情報を格納することができます。こちらは別に格納しなくてもよいです。格納しなくても普通にファイルは使えます。
何の役に立つの、という話ですが、これも別に格納してもそれほど役に立つわけではありません。
ファイルの情報を格納する役割は、ファイルの情報をシステム内に入れておくことによって、そのファイルがどのような用途のファイルであって、どういうフィールド（項目）で構成されているか、ということを登録できます、ということです。目的は何か？を説明します。ファイルを見ても、そのファイルのサイズや種類・属性はわかりますが、そのファイルがどんな用途で、どんなフィールド構成になっているかはわかりません。そこでSYS@DDFにフィールド情報などを登録しておくことにより、そのような情報が一目でわかるようになるという目的をもっています。
プログラムを改造して、ファイルのフィールドの構成が変わってしまった、というときは実際に使用しているフィールド構成とSYS@DDFに登録してあるフィールド構成に差異が生じます。差異が生じても、実行時に参照されないのでプログラムの実行やデータの読み書きには何の影響もありません。このようなこともあって、プログラムを改造してもSYS@DDFの方は更新しないことが多く、たいていの場合はプログラムとSYS@DDFの情報は一致しないことの方が多いです。常に一致するように運用するのは非常に多くの労力を使います。
一致させるには、プログラムを開発したり改造したりするときに工夫が必要です。
SYS@DDFからＣＯＢＯＬのレコード記述のＣＯＰＹ原文ソースを出力することができます。レコードのフィールド構成を変更する場合は、��SYS@DDF上のフィールド構成を変更する→�◆遙庁庁討鮖箸辰�SYS@DDFからレコード記述のＣＯＰＹ原文ソースを出力する→��そのＣＯＰＹ原文ソースを利用してプログラムを改造する、という流れで行うとプログラムとSYS@DDFの情報を一致させることができます。
というか、ＮＥＣはこのような手順でのプログラム開発を推奨しています。データベースも使わないし、提供するいくつかの便利機能も使わない、というようなシステムならば必要ありません。データディクショナリファイル自体作る必要もありません。
このファイルも計算してファイルサイズを決めて、Ａ−ＶＸインストール時にファイルを作る必要があります。このファイルも無計画にファイルを作るとオーバーフローしたりすることがある。こうなるとそれ以上仮想表は作れなくなり、ファイルサイズを拡張しなければならないので面倒になります。
今思い出しましたが、データディスクファイルが無い頃に作られたＳＭＡＲＴのプログラムは項目を桁位置指定していましたね。データディクショナリファイルができてからは項目名指定も可能になりました。
- ５ 表データ定義ファイル（SYS＠DBDIR）
-
データベースの実ファイルの情報を管理しているファイルです。データベースを使用しないのなら無くてもよいです。
説明書ではSYS＠DDFとセットで出てくることが多いです。データベースを使うならば、システムに１個必要となり、このファイルのサイズ次第でデータベースの規模が決まります。このサイズ設計が悪いとオーバーフローしたりするので面倒なことになります。
