FMLフィールド化バッファを操作したり、VIEWS関数を使用して構造体とフィールド化バッファ間でフィールドを移動するには、次の準備作業が必要です。
|
•
|
フィールド定義をアプリケーション・プログラムで使用できるようにします。実行時にフィールド表ファイルおよびマッピング関数を使用するか、またはコンパイル時にCヘッダー・ファイルを使用します。 |
|
•
|
ソースVIEW記述をオブジェクトVIEW記述にコンパイルし、対応するCヘッダー・ファイルおよびCOBOL COPYファイルを生成します。 |
この章では、これらの内容と、関連する処理について説明します。
フィールド識別子(
fieldid)は、
typedefにより
FLDID (FML32の場合は
FLDID32)として定義されます。フィールド識別子は、フィールド型とフィールド番号で構成されます。フィールド番号は、フィールドを識別するための一意の番号です。
フィールド番号は、次の範囲内の番号でなければなりません。
フィールド番号0および対応するフィールド識別子0は、不正なフィールド識別子(
BADFLDID)を示すために予約されています。フィールド機能を備えた別のソフトウェアを使用してFMLを操作する場合は、フィールド番号に関する別の制約が適用されることがあります。
Oracle Tuxedoシステムは、フィールド番号に関する以下の規則に従っています。
|
|
|
|
|
|
|
|
|
|
|
1-3,999, 6,000-10,000, 30,000,001-33,554,431 |
4,000-5,999, 10,001-30,000,000 |
Oracle Tuxedoシステムでは予約されている番号の使用を強制的に制限していませんが、アプリケーションでは予約番号を使用しないようにしてください。
フィールド識別子とフィールド名のマッピング情報は、フィールド表ファイルまたはフィールド・ヘッダー・ファイルに取り込まれます。フィールド表ファイルを使用する場合は、この後で説明するマッピング関数を使用してCプログラム内のフィールド名の参照を変換する必要があります。フィールド・ヘッダー・ファイルを使用すると、プログラムのコンパイル時にCプリプロセッサ(UNIXリファレンス・マニュアルの
cpp(1)を参照)によってフィールド名からフィールド識別子へのマッピングが行われます。
フィールド表にアクセスするための関数およびプログラムでは、
FLDTBLDIR環境変数および
FIELDTBLS環境変数を使用して、使用するソース・ディレクトリとフィールド表ファイルを指定します。(
FLDTBLDIR32および
FIELDTBLS32は、
FML32と同じ目的で使用されます)環境変数の設定方法については、
「FMLおよびVIEWSの環境設定」を参照してください。
複数のフィールド表を使用すると、複数のフィールド・グループに対して別々のディレクトリやファイルを設定できます。ただし、フィールド名およびフィールド番号は、すべてのフィールド表を通して一意でなければなりません。フィールド表がCヘッダー・ファイルに変換されて同じフィールド番号が複数回発生すると、予測できない結果が発生する可能性があるためです。
フィールド表ファイルは、
viなどの標準的なテキスト・エディタを使用して作成します。このファイルの形式は、次のとおりです。
|
•
|
$で始まる行は、マッピング関数では無視されますが、 mkfldhdrで生成されたヘッダー・ファイルに渡されます。このとき $は除去されます。(詳細は、 『Oracle Tuxedoコマンド・リファレンス』の mkfldhdr、mkfldhdr32(1)に関する項を参照してください。)マッピング関数で行を無視させる機能は、Cコメントや what文字列を、アプリケーション側からCヘッダー・ファイルに渡すときに便利です。
|
|
注意:
|
ただしCOBOLアプリケーションでは、このような行はCOBOL COPYファイルに渡されません。 |
|
•
|
文字列 *baseで始まる行には、後続のフィールド番号をオフセットするためのベース値が含まれています。この機能により、関連するフィールドのセットをグループ化し、簡単に番号を付け直すことができます。 |
name rel-number type flag comment
|
•
|
nameは、フィールドの識別子です。識別子は、Cプリプロセッサの識別子の制約に準拠しています(つまり、英数字とアンダースコア文字のみを含む必要があります)。nameは、内部で30文字以降が切り捨てられるので、nameの最初の30文字は一意でなければなりません。
|
|
•
|
rel-numberは、フィールドの相対番号を示す数値です。 *baseが指定されている場合、この数値を現在の基数に加算すると、フィールドのフィールド番号を取得できます。
|
|
•
|
typeは、フィールドの型を示します。指定できる型は、 short、 long、 float、 double、 char、 string、 carray、 mbstring、 ptr、 fml32、または view32のいずれかです。
|
|
•
|
flagフィールドは、将来使用するために予約されています。このフィールドにはダッシュ( -)を指定してください。
|
|
•
|
commentは、フィールドの内容を説明するためのオプションのフィールドです。
|
エントリは、空白文字またはタブで区切ってください。
次のリストは、基数が500から700にシフトするフィールド表の例です。基数が500のグループの場合、最初のフィールド番号は501です。基数が700のグループの場合、最初のフィールド番号は701です。
# following are fields for EMPLOYEE service
# employee ID fields are based at 500
*base 500
#name rel-number type flags comment
#---- ---------- ---- ------ -------
EMPNAME 1 string - emp name
EMPID 2 long - emp id
EMPJOB 3 char - job type
SRVCDAY 4 carray - service date
*base 700
# all address fields are now relative to 700
EMPADDR 1 string - street address
EMPCITY 2 string - city
EMPSTATE 3 string - state
EMPZIP 4 long - zip code
実行時のマッピングは、
Fldid()関数および
Fname()関数を使用して行います。これらの関数は、
FLDTBLDIR環境変数および
FIELDTBLS環境変数で指定されたフィールド表ファイルのセットを参照します。(FML32が使用されている場合、
Fldid32()関数と
Fname32()関数は、
FLDTBLDIR32環境変数および
FIELDTBLS32環境変数を参照します。)
Fldidは、引数(フィールド名)を
fieldidにマッピングします。次のコードを参照してください。
char *name;
extern FLDID Fldid();
FLDID id;
...
id = Fldid(name);
Fnameは、その引数(
fieldid)をフィールド名にマッピングすることにより、逆の処理を行います(次のコードを参照):
extern char *Fname();
name = Fname(id);
. . .
フィールド識別子からフィールド名へのマッピングは、ほとんど使用されません。フィールド識別子がわかっており、その識別子から対応する名前を確認するケースはほとんどないためです。フィールド識別子からフィールド名へのマッピングを行う例は、バッファの出力ルーチンです。バッファの出力ルーチンでは、フィールド化バッファの内容を、理解できる形式で表示する必要があります。
Fldid()を最初に呼び出すと、フィールド表ファイルがロードされ、必要な検索が実行されます。フィールド表ファイルは、その後もロードされたまま残ります。
Fldid()は、成功時にその引数に対応するフィールド識別子を返し、失敗時には
FBADNAMEに設定した
Ferrorと共に、
BADFLDIDを返します。(FML32を使用している場合は、
Ferror32がかわりに設定されます。)
Fldid()でロードしたフィールド表が占有するデータ領域を回復するには、
Fnmid_unload()関数を呼び出してファイルをすべてアンロードする必要があります。
Fname()関数は、
Fldid()と同じように動作しますが、処理の内容は、フィールド識別子からフィールド名へのマッピングです。ロード対象のフィールド表は同じ環境変数を使用して指定しますが、マッピング表の別のセットが生成されます。
Fname()が成功すると、
fldid引数に指定された名前を含む文字列へのポインタが返されます。失敗するとNULLが返されます。
Fldid()の障害は、フィールド表が見つからないかまたはオープンできない(
FFTOPEN)、フィールド表の構文が間違っている(
FFTSYNTAX)、フィールド表内にノーヒット条件が存在する(
FBADFLD)、などが原因で発生します。
Fname()で作成したマッピング表が占有する表領域は、
Fidnm_unload()関数を呼び出して回復できます。
実行時のマッピングを使用するマッピング関数およびその他のFML関数には、
FIELDTBLS環境変数および
FLDTBLDIR環境変数を正しく設定しておく必要があります。そうでない場合は、デフォルト値が使用されます。(これらの環境変数のデフォルト値については、
「FMLおよびVIEWSの環境設定」を参照してください。)
すでに説明したとおり、
mkfldhdr (または
mkfldhdr32)コマンドを実行すると、フィールド表がCコンパイラ処理に対応したヘッダー・ファイルに変換されます。生成されたヘッダー・ファイルの各行の形式は、次のとおりです。
fnameにはフィールド名を指定し、
fieldidにはフィールド識別子を指定します。フィールド識別子は、エンコードされたフィールド型とフィールド番号で構成されます。フィールド番号は絶対数、つまり
baseに
rel-numberを足した数です。生成されたファイルは、Cプログラムに組み込むことができます。
コンパイル時にファイル名を識別子にマッピングすると、処理を高速化でき、データ領域が少なくて済むという利点があります。逆に、サービス・ルーチンのコンパイル後にフィールド名と識別子のマッピングが変更されると、サービス・ルーチンに伝播されないという欠点があります。(このような場合、サービス・ルーチンはコンパイル済のマッピングを使用します。)
mkfldhdrコマンドを実行すると、
FIELDTBLS環境変数で指定された各フィールド表が、対応するヘッダー・ファイルに変換されます。ヘッダー・ファイル名は、フィールド表名に
.hという接尾辞を付けて指定します。生成されたヘッダー・ファイルは、デフォルトでカレント・ディレクトリに保存されます。別のディレクトリに保存したい場合は、
mkfldhdrコマンドで
-dオプションを使用して、保存先ディレクトリを指定します。詳細は、
『Oracle Tuxedoコマンド・リファレンス』の
mkfldhdr、mkfldhdr32(1)に関する項を参照してください。
例1および2は、環境変数を設定して
mkfldhdr(1)コマンドを実行する方法を示しています。ここでは、3つのフィールド表ファイル(
${FLDTBLDIR}/maskftbl、
${FLDTBLDIR}/DBftbl、
${FLDTBLDIR}/miscftbl)が処理され、3つのインクルード・ファイル(
maskftbl.h、
DBftbl.h、
miscftbl.h)がカレント・ディレクトリに生成されます。詳細は、
『Oracle Tuxedoコマンド・リファレンス』の
mkfldhdr、mkfldhdr32(1)に関する項を参照してください。
FLDTBLDIR=/project/fldtbls
FIELDTBLS=maskftbl,DBftbl,miscftbl
export FLDTBLDIR FIELDTBLS
mkfldhdr
FLDTBLDIR32=/project/fldtbls
FIELDTBLS32=maskftbl,DBftbl,miscftbl
export FLDTBLDIR32 FIELDTBLS32
mkfldhdr32
例3は例1と同じですが、出力ファイル(
maskftbl.h、
DBftbl.h、
miscftbl.h)が
${FLDTBLDIR}で指定されたディレクトリに保存される点だけが異なります。
FLDTBLDIR=/project/fldtbls
FIELDTBLS=maskftbl,DBftbl,miscftbl
export FLDTBLDIR FIELDTBLS
mkfldhdr -d${FLDTBLDIR}
環境変数をオーバーライドしてmkfldhdrを実行する
mkfldhdrのコマンド行でフィールド表の名前を指定し、環境変数をオーバーライドする(または環境変数を設定しない)ことができます。
ただし、この方法は実行時マッピングの関数に対しては適用できません。実行時マッピングの関数が使用されている場合、
FLDTBLDIRがカレント・ディレクトリと見なされ、
FIELDTBLSはユーザーがコマンド行で指定したパラメータの一覧と見なされます。たとえば、次のコマンド:
は、フィールド表ファイル
myfieldsをフィールド・ヘッダー・ファイル
myfields.hに変換し、そのヘッダー・ファイルをカレント・ディレクトリに格納します。
フィールドをC構造体およびCOBOLレコードにマッピングする
FML VIEWSは、フィールド化バッファとC構造体、またはフィールド化バッファとCOBOLレコードの間でデータを交換するためのメカニズムです。この機能は、時間のかかるデータ操作を、C関数を使用してC構造体で行うために用意されています。この方が、FML関数を使用してフィールド化バッファでデータを操作するより効率的です。また、VIEWSを使用して、COBOLプログラムでFMLフィールド化レコードを扱うCプログラムとメッセージを送受信する方法としても使用できます。
この項では、VIEWSを使用してフィールド化バッファとC構造体をマッピングする方法を説明します。
次の図は、VIEWSの構成要素とそれらの相互関係を示しています。
ソースVIEWファイルは、
viなどの任意のテキスト・エディタで作成する標準テキスト・ファイルです。このファイルには、1つまたは複数のソースVIEW記述(フィールドから構造体への実際のマッピング情報)が格納されています。
VIEWコンパイラの最も重要な役割は、オブジェクトVIEWファイルを生成することです。このファイルには、コンパイル済のオブジェクトVIEW記述が含まれています。オブジェクトVIEWファイルは逆に、VIEW逆アセンブラ(
viewdisまたは
viewdis32)での入力として使用できます。VIEW逆アセンブラを使用すると、オブジェクトVIEW記述をソース形式に戻し、内容を検証したり、編集することができます。詳細は、
『Oracle Tuxedoコマンド・リファレンス』の
viewdis、viewdis32(1)に関する項を参照してください。
ソースVIEW記述を作成および編集し、
viewdisの出力を編集することができます。コンパイル済のVIEW記述(バイナリ形式)を直接読み取ることはできません。
VIEWファイルには、VIEW記述のほかに
#または
$で始まるコメント行を格納できます。
#で始まる空白行は、VIEWコンパイラによって無視されますが、
$で始まる行は、VIEWコンパイラが生成するヘッダー・ファイルに渡すことができます。この規則によって、Cのコメントなどの
whatの文字列をVIEWコンパイラが生成するCヘッダー・ファイルに渡すことができます。
|
注意:
|
この規則は、COBOLには適用されません。したがって、 $で始まる行はCOBOL COPYファイルには渡されません。 |
ソースVIEWファイル内の各ソースVIEW記述は、次の3つの部分で構成されています。
|
•
|
キーワード VIEWで始まり(接尾辞 「32」は付かない)、続いてVIEW記述の名前が指定された行。この名前は、英数字とアンダースコアで構成されます。 viewcに指定できる最大文字数は33文字ですが、 tpalloc(3c)が受け付けるサブタイプの最大文字数が16文字であるため、実際に指定できる最大文字数は16文字です。 |
各
VIEW記述の最初の行は、「VIEW」というキーワードで始まり、続いてVIEW記述の名前が指定されます。メンバー記述(マッピング・エントリ)は、C構造体またはCOBOLレコードのメンバーに関する情報を含む行です。キーワード
ENDで始まる行は、VIEW記述の最後の行です。
次のリストは、一般的なソースVIEW記述の内容です。
VIEW vname
# type cname fbname count flag size null
# ---- ----- ------ ----- ---- ---- ----
--------------member descriptions-------------------
.
.
.
END
|
•
|
vnameには、VIEW記述の名前を指定します。この名前は、C構造体の名前としても使用されるので、有効なC識別名を指定する必要があります。アンダースコアは、COBOL COPYファイルでは自動的にダッシュ(-)にマッピングされます。
|
|
•
|
typeは、メンバーの型を示します。指定できる型は、 int、 short、 long、 char、 float、 double、 string、 carray、または dec_tのいずれかです。 typeの値が 「-」の場合、デフォルトである fbnameの値が使用されます。
|
|
•
|
cnameには、構造体メンバーの識別子を指定します。これは、C構造体メンバーの名前なので、有効なC識別名にする必要があります。 cnameは内部で30文字以降が切り捨てられるので、 cnamesの最初の30文字が一意でなければなりません。アンダースコアは、COBOL COPYファイルでは自動的にダッシュ(-)にマッピングされます。
|
|
•
|
fbnameには、フィールド化バッファのフィールド名を指定します。フィールド表ファイルにある名前を指定します。
|
|
•
|
countには、割り当てる要素の数(このメンバーに格納されるオカレンスの最大数)を指定します。FMLでは65,535以下、FML32では2,147,483,647以下の数値を指定します。
|
|
•
|
sizeには、タイプが string、 carray、または dec_tである場合のメンバーのサイズを指定します。その他のフィールド・タイプでは、 「-」を指定します。この場合はVIEWコンパイラがサイズを計算します。
|
|
•
|
stringまたは carrayの場合、 sizeの値には、FMLでは65,535以下、FML32では2,147,483,647以下の数値を指定します。
|
|
•
|
typeが dec_tの場合、 sizeには、カンマで区切って指定した2つの数値を指定します。最初の数字は小数値のバイト数を表します。0より大きく10より小さくする必要があります。2番目の数字は小数点の右側の小数の位置を表します。0よりも大きく、バイト数の2倍から1を引いた数字よりも小さくする必要があります。 |
|
•
|
nullには、ユーザーが定義したNULL値を指定します。 「-」を指定すると、該当するフィールドのデフォルトのNULL値に設定されます。詳細は、 「VIEWSでNULL値を使用する」を参照してください。
|
以下は、VIEW記述内のメンバー記述の
flag要素として指定できるオプションです。
このオプションは、メンバー記述で記述された構造体メンバーに加えて、連想カウント・メンバー(ACM: Associated Count Member)と呼ばれる構造体メンバーの生成をリクエストします。
フィールド化バッファから構造体へのデータ転送時には、構造体内の各ACMは対応する構造体メンバーに転送されたオカレンスの数に設定されます。
|
•
|
ACMの値0は、対応する構造体メンバーにフィールドが転送されなかったことを示します。 |
|
•
|
正の値は、構造体メンバーの配列に実際に転送されたフィールドの数を示します。 |
|
•
|
負の値は、構造体メンバーの配列に転送できる数以上のフィールドがバッファ内にあったことを示します。この場合、ACMの絶対値と構造体に転送されないフィールド数は同じです。 |
構造体メンバーの配列からフィールド化バッファへのデータ転送時には、ACMを使用して転送すべき配列要素の数を指定します。たとえば、あるメンバーのACMがNに設定されている場合は、最初のN個のNULL以外のフィールドがフィールド化バッファに転送されます。Nが配列のサイズより大きい場合、Nはデフォルトで配列のサイズに設定されます。どちらの場合も、転送後、ACMはフィールド化バッファに転送される配列のメンバーの実際の数に設定されます。
ACMの型は、FMLでは
short型、FML32では
long型としてCヘッダー・ファイルで宣言され、
C_cnameという名前が生成されます。
cnameは、ACMが宣言された
cnameエントリです。たとえば、
partsという名前のメンバーのACMは、次のように宣言されます。
COBOL COPYファイルでは、
C-cnameという名前が生成され、型は次のように宣言されます。
|
•
|
FMLの場合: PIC S9(4) USAGE COMP-5 |
|
•
|
FML32の場合: PIC S9(9) USAGE COMP-5 |
|
注意:
|
生成されたACM名と接頭辞 C_で始まる名前の構造体メンバーが競合する場合があります。VIEWコンパイラは、このような競合を致命的なエラーとして報告します。たとえば、構造体メンバーの C_partsという名前は、メンバー partsに対して生成されるACM名と競合します。 |
このオプションは、構造体からフィールド化バッファへの一方向のマッピングを指定します。このオプションによるメンバーのマッピングは、構造体からフィールド化バッファへのデータ転送時のみ有効です。このオプションは、
-nコマンド行オプションを指定した場合は無視されます。
このオプションは、
carray型または
string型のメンバー記述に対してのみ使用され、これらのフィールドが可変長の場合に転送されるバイト数を示します。
carrayフィールドまたは
stringフィールドを常に固定長データ項目として使用する場合、このオプションを指定する利点はありません。
Lオプションは、
carray型または
string型の構造体メンバーに対応する連想長メンバー(ALM: Associated Length Member)を生成します。フィールド化バッファから構造体へのデータ転送時には、ALMは、対応する転送フィールドの長さに設定されます。フィールド化バッファ内のフィールドの長さがマッピングされた構造体メンバーに割り当てられた領域を超える場合は、割り当てられたバイト数のみが転送されます。対応するALMは、フィールド化バッファ項目のサイズに設定されます。したがって、ALMが構造体メンバーの配列サイズより大きい場合、フィールド化バッファ情報は転送時に切り捨てられます。
構造体メンバーからフィールド化バッファのフィールドにデータを転送する場合、そのフィールドが
carray型であれば、ALMを使用してフィールド化バッファに転送するバイト数を指定します。
string型のフィールドの場合、ALMは転送時に無視されますが、転送後、転送されたバイト数に設定されます。
carrayフィールドには長さ0も指定できます。ALMが0の場合は、関連する構造体メンバーの値がNULL値でない限り、フィールド化バッファに長さ0のフィールドが転送されます。
ALMの型は、FMLではunsigned short型、FML32ではunsigned long型としてCヘッダー・ファイルで定義され、
L_cnameという名前が生成されます。
cnameは、ALMが宣言された構造体の名前です。
ALMが宣言されたメンバーのオカレンス数が1の場合(またはデフォルトが1の場合)、ALMは次のように宣言されます。
一方、オカレンス数が1より大きい場合(N)、ALMは次のように宣言されます。
unsigned short L_cname[N];
これはALM配列と呼ばれます。このような場合は、ALM配列内の各要素は構造体メンバー(またはフィールド)の対応するオカレンスを参照します。COBOL COPYファイルでは、FMLは
PIC 9(4) USAGE COMP-5型、FML32は
PIC 9(9) USAGE COMP-5型として宣言され、
L-cnameという名前が生成されます。メンバーが複数回発生する場合は、COBOLの
OCCURS句を使用して複数のオカレンスを定義します。
|
注意:
|
生成されたALM名と接頭辞 L_で始まる名前の構造体メンバーが競合する場合があります。VIEWコンパイラは、このような競合を致命的なエラーとして報告します。たとえば、構造体メンバーの L_partsという名前は、メンバー partsに対して生成されるALM名と競合します。 |
ゼロ方向マッピングを指定します。C構造体にフィールド化バッファはマッピングされません。このオプションは、C構造体またはCOBOLレコードに充填文字を割り当てるときに使用することができます。このオプションは、
-nコマンド行オプションが指定された場合は無視されます。
このオプションは、
string型および
carray型の構造体メンバーのNULL値としてVIEWが解釈する内容を指定します。このオプションを指定しない場合、構造体メンバーの値がユーザー指定のnull値と等しいと(後続のnull文字は考慮しない)、構造体メンバーがnullになります。
一方、このオプションを指定した場合は、ユーザー指定のnull値と構造体メンバーの値が等しく、さらに最後の文字が完全な長さまで及んでいると(後続のnull文字は考慮しない)、構造体メンバーがnullになります。
C構造体またはCOBOLレコードからフィールド化バッファへデータを転送する場合、値がNULLのメンバーは転送先のバッファに送信されません。たとえば、構造体のメンバー
TESTが
carray[25]型で、ユーザー定義のNULL値
「abcde」が指定されているとします。
Pオプションを設定しない場合、最初の5文字が順に
a、
b、
c、
d、
eであれば、
TESTはNULLと見なされます。
Pオプションを指定した場合、最初の4文字が順に
a、
b、
c、
dで、かつ
carrayの残りの文字がすべて
「e」であれば(
eが21個)、
TESTはNULLと見なされます。
このオプションは、
-nコマンド行オプションを指定した場合は無視されます。
このオプションは、フィールド化バッファから構造体への一方向のマッピングを指定します。このオプションを指定したメンバーのマッピングは、フィールド化バッファから構造体へのデータ転送時のみ有効です。このオプションは、
-nコマンド行オプションを指定した場合は無視されます。
VIEWSのNULL値は、C構造体またはCOBOLレコードのメンバーが空であることを示すために使用されます。NULL値はデフォルト値として提供されていますが、独自に定義することもできます。
デフォルトのNULL値は、数値型の場合はすべて
0 (
dec_tの場合は
0.0)、
char型の場合は “
\0"、
string型と
carray型の場合は “ “ です。
null値を指定するためにエスケープ規則定数を使用することもできます。VIEWコンパイラで認識されるエスケープ定数は、
\ddd (
dは8進数)、
\0、
\n、
\t、
\v、
\b、
\r、
\f、
\\、
\'、および
\"です。
string型、
carray型、および
char型のNULL値は、二重引用符または一重引用符で囲みます。VIEWコンパイラは、ユーザー定義のnull値の内部のエスケープされていない引用符は受け付けません。
要素は、値がその要素のNULL値と同じであればNULLになりますが、以下の例外があります。
|
•
|
構造体メンバーに Pオプションが設定されており、構造体メンバーの型が string型または carray型である場合。 Pオプションの詳細は、前の項を参照してください。 |
|
•
|
メンバーの型が string型の場合。メンバーの値はNULL値と同じ文字列でなければなりません。 |
|
•
|
メンバーの型が carray型であり、NULL値の長さがNの場合。文字配列内の最初のN個の文字はNULL値と同じでなければなりません。 |
VIEW記述のnullフィールドにキーワード “
NONE"を指定することもできます。これは、そのメンバーに対するnull値がないことを意味します。
string型および文字配列(
carray)型のメンバーのデフォルトの最大サイズは、2660文字です。
|
注意:
|
string型のメンバーは通常 「\0」で終了するため、ユーザー定義のNULL値の最後の文字として 「\0」を指定する必要はありません。
|
FMLではviewc、FML32では
viewc32がVIEWコンパイラ・プログラムです。これらのプログラムは、ソースVIEWファイルを取り込み、オブジェクトVIEWファイルを生成します。生成されたオブジェクトVIEWファイルは実行時に解釈され、データの実際のマッピングに影響を与えます。実行時には、
viewcに対してCコンパイラを使用する必要があります。コマンド行は、次のようになります。
viewc [-n] [-d
viewdir] [-C]
viewfile [
viewfile . . . ]
このコマンド行の
viewfileは、ソースVIEW記述を含むソースVIEWファイルの名前です。コマンド行には、1つまたは複数の
viewfileを指定できます。
-Cオプションを指定すると、
viewfileで定義した各VIEWに対してCOBOL COPYファイルが1つ作成されます。これらのコピー・ファイルはカレント・ディレクトリに作成されます。
-nオプションを使用すると、
FMLバッファにマップしないC構造体またはCOBOLレコードのVIEW記述ファイルをコンパイルできます。
デフォルトでは、
viewfileのすべてのVIEWがコンパイルされ、複数のファイルが作成されます。つまり、VIEWファイルごとにオブジェクトVIEWファイル(接尾辞
「V」)とヘッダー・ファイル(接尾辞
「h」)が作成されます。VIEWSの構成要素については、
「VIEWS機能の構成要素」の図を参照してください。
オブジェクトVIEWファイルの名前は
viewfile.
Vとなります。それは、カレント・ディレクトリに作成されます。
-dオプションを指定して別のディレクトリを指定することもできます。ヘッダー・ファイルは、カレント・ディレクトリ内に作成されます。
|
注意:
|
Windowsのように、大文字と小文字を区別しないオペレーティング・システムの場合、オブジェクトVIEWファイルには .vvという接尾辞が付きます。 |
viewcを使ってコンパイルしたヘッダー・ファイルを使用する
VIEWコンパイラ(
viewc)を使用して作成したヘッダー・ファイルを任意のCアプリケーション・プログラム内で使用すると、VIEWで記述したC構造体を宣言できます。たとえば、次のようなVIEW記述:
VIEW test
#TYPE CNAME FBNAME COUNT FLAG SIZE NULL
int empid EMPID 1 - - -1
float salary EMPPAY 1 - - 0
long phone EMPPHONE 4 - - 0
string name EMPNAME 1 - 32 "NO NAME"
END
struct test {
long empid; /* null=-1 */
float salary; /* null=0.000000 */
long phone[4]; /* null=0 */
char name[32]; /* null="NO NAME" */
};
VIEWコンパイラを使って作成したCOBOL COPYファイルを使用する
-Cオプションを使用してVIEWコンパイラで作成したCOBOL COPYファイルを任意のCOBOLアプリケーション・プログラムで使用すると、VIEWで記述したCOBOLレコードを宣言できます。たとえば、前の項に示したVIEW記述のCOBOL COPYファイルは、
TEST.cblファイルでは次のようになります。
* VIEWFILE: "test.v"
* VIEWNAME: "test"
05 EMPID PIC S9(9) USAGE IS COMP-5.
05 SALARY USAGE IS COMP-1.
05 PHONE OCCURS 4 TIMES PIC S9(9) USAGE IS COMP-5.
05 NAME PIC X(32).
COPYファイルの名前は、VIEWコンパイラによって自動的に大文字に変換されます。COPYファイルは、次のようにCOBOLプログラムに組み込まれます。
COPYファイルの出力の詳細は、
『COBOLを使用したOracle Tuxedo ATMIアプリケーションのプログラミング』を参照してください。
VIEW逆アセンブラである
viewdisは、VIEWコンパイラで生成されたオブジェクトVIEWファイルを逆アセンブルし、ソースVIEWファイルの形式でVIEW情報を表示します。また、対応する構造体メンバーのオフセットも表示します。
この形式の情報を参照できると、オブジェクトVIEW記述が正確かどうかを検証するのに役立ちます。
VIEW逆アセンブラを実行するには、次のコマンドを入力します。
viewdis
objviewfile . . .
デフォルトでは、カレント・ディレクトリ内の
objviewfileが逆アセンブルされます。このファイルをカレント・ディレクトリで検索できないと、エラー・メッセージが表示されます。コマンド行には、1つまたは複数のオブジェクトVIEWファイルを指定できます。
viewdisの出力は、元のソース表示の記述に似ているように見えます。編集可能で、
viewcに再入力できます。
viewdisの出力に表示される行の順序は、元のソースVIEW記述の順序と異なる場合がありますが、順序が違ってもオブジェクトVIEWファイルの正確性とは関係ありません。
