|
|
FML フィールド化バッファを操作したり、VIEWS 関数を使用して構造体とフィールド化バッファ間でフィールドを移動するには、次の準備作業が必要です。
この章では、これらの内容と、関連する処理について説明します。
フィールド識別子 (fieldid) は、typedef により FLDID (FML32 の場合は FLDID32) として定義されます。フィールド識別子は、フィールド型とフィールド番号で構成されます。フィールド番号は、フィールドを識別するためのユニークな番号です。
フィールド番号 0 および対応するフィールド識別子 0 は、不正なフィールド識別子 (BADFLDID) を示すために予約されています。フィールド機能を備えた別のソフトウェアを使用して FML を操作する場合は、フィールド番号に関する別の制約が適用されることがあります。
Oracle Tuxedo システムは、フィールド番号に関する以下の規則に従っています。
Oracle Tuxedo システムでは予約されている番号の使用を強制的に制限していませんが、アプリケーションでは予約番号を使用しないようにしてください。
フィールド識別子とフィールド名のマッピング情報は、フィールド テーブル ファイルまたはフィールド ヘッダ ファイルに取り込まれます。フィールド テーブル ファイルを使用する場合は、この後で説明するマッピング関数を使用して C プログラム内のフィールド名の参照を変換する必要があります。フィールド ヘッダ ファイルを使用すると、プログラムのコンパイル時に C プリプロセッサ (UNIX リファレンス マニュアルの cpp(1) を参照) によってフィールド名からフィールド識別子へのマッピングが行われます。
フィールド テーブルにアクセスするための関数およびプログラムでは、FLDTBLDIR 環境変数および FIELDTBLS 環境変数を使用して、使用するソース ディレクトリとフィールド テーブル ファイルを指定します。(FML32 で使用される環境変数は、FLDTBLDIR32 および FIELDTBLS32 です。環境変数の設定方法については、「FML および VIEWS の環境設定」を参照してください。
複数のフィールド テーブルを使用すると、複数のフィールド グループに対して別々のディレクトリやファイルを設定できます。ただし、フィールド名およびフィールド番号は、すべてのフィールド テーブルを通してユニークでなければなりません。フィールド テーブルが C ヘッダ ファイルに変換されて同じフィールド番号が複数回発生すると、予測できない結果が発生する可能性があるためです。
フィールド テーブル ファイルは、vi などの標準的なテキスト エディタを使用して作成します。このファイルの形式は、次のとおりです。
# で始まる行および空白行は無視されます。$ で始まる行は、マッピング関数では無視されますが、mkfldhdr で生成されたヘッダ ファイルに渡されます。このとき $ は除去されます。詳細については、『Tuxedo コマンド リファレンス』の「mkfldhdr、mkfldhdr32(1)」を参照してください。マッピング関数で行を無視させる機能は、C コメントや what 文字列を、アプリケーション側から C ヘッダ ファイルに渡すときに便利です。 | 注意 : | ただし COBOL アプリケーションでは、このような行は COBOL COPY ファイルに渡されません。 |
*base で始まる行には、後続のフィールド番号をオフセットするためのベース値が含まれています。この機能により、関連するフィールドのセットをグループ化し、簡単に番号を付け直すことができます。namerel-number type flag comment
name は、フィールドの識別子です。識別子は、C プリプロセッサの識別子の制約に準拠しています。つまり、name に指定できるのは、英数字とアンダースコア (_) のみです。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 です。
# 以下のフィールドは EMPLOYEE サービス用
# 従業員 ID フィールドは 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
# すべてのアドレス フィールドは 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) をフィールド名にマッピングして、Fldid とは逆の処理を行います。次のコードを参照してください。
extern char *Fname();
name = Fname(id);
. . .
フィールド識別子からフィールド名へのマッピングは、ほとんど使用されません。フィールド識別子がわかっており、その識別子から対応する名前を確認するケースはほとんどないためです。フィールド識別子からフィールド名へのマッピングを行う例は、バッファの出力ルーチンです。バッファの出力ルーチンでは、フィールド化バッファの内容を、理解できる形式で表示する必要があります。
Fldid() を最初に呼び出すと、フィールド テーブル ファイルがロードされ、必要な検索が実行されます。フィールド テーブル ファイルは、その後もロードされたまま残ります。Fldid() が成功すると、引数に対応したフィールド識別子が返されます。失敗すると、Ferror に FBADNAME が設定され、BADFLDID が返されます (FML32 の場合は Ferror32 が設定されます)。
Fldid() でロードしたフィールド テーブルが占有するデータ領域を回復するには、Fnmid_unload() 関数を呼び出してファイルをすべてアンロードする必要があります。
Fname() 関数は、Fldid() と同じように動作しますが、処理の内容は、フィールド識別子からフィールド名へのマッピングです。ロード対象のフィールド テーブルは、Fldid() と同じ環境変数を使用して指定しますが、別のマッピング テーブルのセットが生成されます。Fname() が成功すると、fldid 引数に指定された名前を含む文字列へのポインタが返されます。失敗すると NULL が返されます。
| 注意 : | ポインタは、テーブルがロードされている限り有効です。 |
Fldid() のエラーは、フィールド テーブルが見つからないかまたはオープンできない (FFTOPEN)、フィールド テーブルの構文が間違っている (FFTSYNTAX)、フィールド テーブル内にノーヒット条件が存在する (FBADFLD)、などが原因で発生します。Fname() で作成したマッピング テーブルが占有するテーブル領域は、Fidnm_unload() 関数を呼び出して回復できます。
実行時のマッピングを使用するマッピング関数およびその他の FML 関数には、FIELDTBLS 環境変数および FLDTBLDIR 環境変数を正しく設定しておく必要があります。これらの環境変数が設定されていない場合は、デフォルト値が使用されます。これらの環境変数のデフォルト値については、「FML および VIEWS の環境設定」を参照してください。
既に説明したとおり、mkfldhdr (または mkfldhdr32) コマンドを実行すると、フィールド テーブルが C コンパイラ処理に対応したヘッダ ファイルに変換されます。生成されたヘッダ ファイルの各行の形式は、次のとおりです。
#definefnamefieldid
fname にはフィールド名を指定し、fieldid にはフィールド識別子を指定します。フィールド識別子は、エンコードされたフィールド型とフィールド番号で構成されます。フィールド番号は絶対数、つまり base に rel-number を足した数です。生成されたファイルは、C プログラムに組み込むことができます。
「フィールドを C 構造体および COBOL レコードにマッピングする」で説明するとおり、実行時のマッピング関数を使用する場合、ヘッダ ファイルを使用する必要はありません。
コンパイル時にファイル名を識別子にマッピングすると、処理を高速化でき、データ領域が少なくて済むという利点があります。逆に、サービス ルーチンのコンパイル後にフィールド名と識別子のマッピングが変更されると、サービス ルーチンに伝播されないという欠点があります。このような場合、サービス ルーチンはコンパイル済みのマッピングを使用します。
mkfldhdr コマンドを実行すると、FIELDTBLS 環境変数で指定された各フィールド テーブルが、対応するヘッダ ファイルに変換されます。ヘッダ ファイル名は、フィールド テーブル名に .h という接尾辞を付けて指定します。生成されたヘッダ ファイルは、デフォルトでカレント ディレクトリに保存されます。別のディレクトリに保存したい場合は、mkfldhdr コマンドで -d オプションを使用して、保存先ディレクトリを指定します。詳細については、『Tuxedo コマンド リファレンス』の「mkfldhdr、mkfldhdr32(1)」を参照してください。
例 1 および 2 は、環境変数を設定して mkfldhdr(1) コマンドを実行する方法を示しています。ここでは、3 つのフィールド テーブル ファイル (${FLDTBLDIR}/maskftbl、${FLDTBLDIR}/DBftbl、${FLDTBLDIR}/miscftbl) が処理され、3 つのインクルード ファイル (maskftbl.h、DBftbl.h、miscftbl.h) がカレント ディレクトリに生成されます。詳細については、『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 -d${FLDTBLDIR}
mkfldhdr のコマンドラインでフィールド テーブルの名前を指定し、環境変数をオーバーライドする (または環境変数を設定しない) ことができます。
ただし、この方法は実行時マッピングの関数に対しては適用できません。実行時マッピングの関数が使用されている場合、FLDTBLDIR がカレント ディレクトリと見なされ、FIELDTBLS はユーザがコマンドラインで指定したパラメータの一覧と見なされます。次にコマンド rex の使用例を示します。
mkfldhdr myfields
このコマンドは、フィールド テーブル ファイル myfields をフィールド ヘッダ ファイル myfields.h に変換し、そのヘッダ ファイルをカレント ディレクトリに格納します。
詳細については、『Tuxedo コマンド リファレンス』の「mkfldhdr、mkfldhdr32(1)」を参照してください。
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 記述をソース形式に戻し、内容を検証したり、編集することができます。詳細については、『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 文字です。END で始まる行
各 VIEW 記述の最初の行は、「VIEW」というキーワードで始まり、続いて VIEW 記述の名前が指定されます。メンバー記述 (マッピング エントリ) は、C 構造体または COBOL レコードのメンバーに関する情報を含む行です。キーワード END で始まる行は、VIEW 記述の最後の行です。
次のコード リストは、一般的なソース VIEW 記述の内容です。
VIEW vname
# type cname fbname count flag size null
# ---- ----- ------ ----- ---- ---- ----
--------------メンバーの記述-------------------
.
.
.
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 以下の数値を指定します。flag には、カンマで区切ったオプションのリスト、または「-」(オプションが設定されていない場合) を指定します。詳細については、「VIEW 記述でのフラグ オプションを指定する」を参照してください。size には、タイプが string、carray、または dec_t である場合のメンバーのサイズを指定します。その他のフィールド タイプでは、「-」を指定します。この場合は VIEW コンパイラがサイズを計算します。 null には、ユーザが定義した NULL 値を指定します。「-」を指定すると、該当するフィールドのデフォルトの NULL 値に設定されます。詳細については、「VIEWS で NULL 値を使用する」を参照してください。
以下は、VIEW 記述内のメンバー記述の flag 要素として指定できるオプションです (フラグ オプションは FML 対応の VIEW にのみ適用されます)。
C
このオプションは、メンバー記述で記述された構造体メンバーに加えて、連想カウント メンバー (ACM: Associated Count Member) と呼ばれる構造体メンバーの生成を要求します。
フィールド化バッファから構造体へのデータ転送時には、構造体内の各 ACM は対応する構造体メンバーに転送されたオカレンスの数に設定されます。
構造体メンバーの配列からフィールド化バッファへのデータ転送時には、ACM を使用して転送すべき配列要素の数を指定します。たとえば、あるメンバーの ACM が N に設定されている場合は、最初の N 個の NULL 以外のフィールドがフィールド化バッファに転送されます。N が配列のサイズより大きい場合、N はデフォルトで配列のサイズに設定されます。どちらの場合も、転送後、ACM はフィールド化バッファに転送される配列のメンバーの実際の数に設定されます。
ACM の型は、FML では short 型、FML32 では long 型として C ヘッダ ファイルで宣言され、C_cname という名前が生成されます。cname は、ACM が宣言された cname エントリです。たとえば、parts という名前のメンバーの ACM は、次のように宣言されます。
short C_parts;
COBOL COPY ファイルでは、C-cname という名前が生成され、型は次のように宣言されます。
PIC S9(4) USAGE COMP-5PIC S9(9) USAGE COMP-5| 注意 : | 生成された ACM 名と接頭辞 C_ で始まる名前の構造体メンバーが衝突する場合があります。VIEW コンパイラは、このような衝突を致命的なエラーとして報告します。たとえば、構造体メンバーの C_parts という名前は、メンバー parts に対して生成される ACM 名と衝突します。 |
F
このオプションは、構造体からフィールド化バッファへの一方向のマッピングを指定します。このオプションによるメンバーのマッピングは、構造体からフィールド化バッファへのデータ転送時のみ有効です。このオプションは、-n コマンドライン オプションを指定した場合は無視されます。
L
このオプションは、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 は次のように宣言されます。
unsigned short L_cname;
一方、オカレンス数が 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 名と衝突します。 |
N
ゼロ方向マッピングを指定します。C 構造体にフィールド化バッファはマッピングされません。このオプションは、C 構造体または COBOL レコードに充填文字を割り当てるときに使用することができます。このオプションは、-n コマンドライン オプションが指定された場合は無視されます。
P
このオプションは、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 コマンドライン オプションを指定した場合は無視されます。
S
このオプションは、フィールド化バッファから構造体への一方向のマッピングを指定します。このオプションを指定したメンバーのマッピングは、フィールド化バッファから構造体へのデータ転送時のみ有効です。このオプションは、-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 になりますが、以下の例外があります。
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 となります。オブジェクト VIEW ファイルは、カレント ディレクトリに作成されます。-d オプションを指定して別のディレクトリを指定することもできます。ヘッダ ファイルは、カレント ディレクトリ内に作成されます。
| 注意 : | Windows のように、大文字と小文字を区別しないオペレーティング システムの場合、オブジェクト VIEW ファイルには .vv という接尾辞が付きます。 |
詳細については、『Tuxedo コマンド リファレンス』の「viewc、viewc32(1)」を参照してください。
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
この VIEW 記述の C ヘッダ ファイルは、次のようになります。
struct test {
long empid; /* null=-1 */
float salary; /* null=0.000000 */
long phone[4]; /* null=0 */
char name[32]; /* null="NO NAME" */
};
詳細については、『Tuxedo コマンド リファレンス』の「viewc、viewc32(1)」を参照してください。
-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 プログラムに組み込まれます。
01 MYREC COPY TEST.
COPY ファイルの出力の詳細については、『COBOL を使用した Oracle Tuxedo アプリケーションのプログラミング』を参照してください。
VIEW 逆アセンブラである viewdis は、VIEW コンパイラで生成されたオブジェクト VIEW ファイルを逆アセンブルし、ソース VIEW ファイルの形式で VIEW 情報を表示します。また、対応する構造体メンバーのオフセットも表示します。
この形式の情報を参照できると、オブジェクト VIEW 記述が正確かどうかを検証するのに役立ちます。
VIEW 逆アセンブラを実行するには、次のコマンドを入力します。
viewdis objviewfile . . .
デフォルトでは、カレント ディレクトリ内の objviewfile が逆アセンブルされます。このファイルをカレント ディレクトリで検索できないと、エラー メッセージが表示されます。コマンドラインには、1 つまたは複数のオブジェクト VIEW ファイルを指定できます。
viewdis の出力は、元のソース VIEW 記述と同様であり、編集したり viewc に再入力できます。viewdis の出力に表示される行の順序は、元のソース VIEW 記述の順序と異なる場合がありますが、順序が違ってもオブジェクト VIEW ファイルの正確性とは関係ありません。
詳細については、『Tuxedo コマンド リファレンス』の「viewdis、viewdis32(1)」を参照してください。
  
|