| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > FML を使用した Tuxedo アプリケーションのプログラミング > フィールドの定義と使用 |
|
FML を使用した Tuxedo アプリケーションのプログラミング
|
フィールドの定義と使用
ここでは、次の内容について説明します。
FML および VIEWS を使用するための準備
FML フィールド化バッファを操作したり、VIEWS 関数を使用して構造体とフィールド化バッファ間でフィールドを移動するには、次の準備作業が必要です。
この章では、これらの内容と、関連する処理について説明します。
FML および VIEWS のフィールドの定義
ここでは、次の内容について説明します。
フィールド名とフィールド識別子を定義する
フィールド識別子 (fieldid) は、typedef により FLDID (FML32 の場合は FLDID32) として定義されます。フィールド識別子は、フィールド型とフィールド番号で構成されます。■訳文不要■フィールド番号は、フィールドを識別するための一意な番号です。
フィールド番号は、次の範囲内の番号でなければなりません。
フィールド番号 0 および対応するフィールド識別子 0 は、不正なフィールド識別子 (BADFLDID) を示すために予約されています。フィールド機能を備えた別のソフトウェアを使用して FML を操作する場合は、フィールド番号に関する別の制約が適用されることがあります。
BEA Tuxedo システムは、フィールド番号に関する以下の規則に従っています。
BEA Tuxedo システムでは予約されている番号の使用を強制的に制限していませんが、アプリケーションでは予約番号を使用しないようにしてください。 フィールド識別子とフィールド名のマッピング情報は、フィールド・テーブル・ファイルまたはフィールド・ヘッダ・ファイルに取り込まれます。フィールド・テーブル・ファイルを使用する場合は、この後で説明するマッピング関数を使用して C プログラム内のフィールド名の参照を変換する必要があります。フィールド・ヘッダ・ファイルを使用すると、プログラムのコンパイル時に C プリプロセッサ (UNIX リファレンス・マニュアルの cpp(1) を参照) によってフィールド名からフィールド識別子へのマッピングが行われます。 フィールド・テーブルにアクセスするための関数およびプログラムでは、FLDTBLDIR 環境変数および FIELDTBLS 環境変数を使用して、使用するソース・ディレクトリとフィールド・テーブル・ファイルを指定します。(FML32 で使用される環境変数は、FLDTBLDIR32 および FIELDTBLS32 です。環境変数の設定方法については、FML および VIEWS の環境設定を参照してください。 複数のフィールド・テーブルを使用すると、複数のフィールド・グループに対して別々のディレクトリやファイルを設定できます。ただし、フィールド名およびフィールド番号は、すべてのフィールド・テーブルを通して一意でなければなりません。フィールド・テーブルが C ヘッダ・ファイルに変換されて同じフィールド番号が複数回発生すると、予測できない結果が発生する可能性があるためです。
フィールド・テーブル・ファイルを作成する
フィールド・テーブル・ファイルは、vi などの標準的なテキスト・エディタを使用して作成します。このファイルの形式は、次のとおりです。
注記 ただし COBOL アプリケーションでは、このような行は COBOL COPYファイルに渡されません。
name rel-number type flag comment
各項目の説明は次のとおりです。
項目は、空白文字またはタブで区切ってください。
フィールド・テーブルの例
次のリストは、基数が 500 から 700 にシフトするフィールド・テーブルの例です。基数が 500 のグループの場合、最初のフィールド番号は 501 です。基数が 700 のグループの場合、最初のフィールド番号は 701 です。
コード リスト 4-1 フィールド・テーブル・ファイル
# 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) をフィールド名にマッピングして、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 コンパイラ処理に対応したファイルに変換されます。生成されたヘッダ・ファイルの各行の形式は、次のとおりです。
#define fname fieldid
fname にはフィールド名を指定し、fieldid にはフィールド識別子を指定します。フィールド識別子は、符号化されたフィールド型とフィールド番号で構成されます。フィールド番号は絶対数、つまり base に rel-number を足した数です。生成されたファイルは、C プログラムに組み込むことができます。
フィールドを C 構造体および COBOL レコードにマッピングするで説明するとおり、実行時のマッピング関数を使用する場合、ヘッダ・ファイルを使用する必要はありません。
コンパイル時にファイル名を識別子にマッピングすると、処理を高速化でき、データ領域が少なくて済むという利点があります。逆に、サービス・ルーチンのコンパイル後にフィールド名と識別子のマッピングが変更されると、サービス・ルーチンに伝播されないという欠点があります。このような場合、サービス・ルーチンはコンパイル済みのマッピングを使用します。
mkfldhdr コマンドを実行すると、FIELDTBLS 環境変数で指定された各フィールド・テーブルが、対応するヘッダ・ファイルに変換されます。ヘッダ・ファイル名は、フィールド・テーブル名に .h という接尾辞を付けて指定します。生成されたヘッダ・ファイルは、デフォルトでカレント・ディレクトリに保存されます。別のディレクトリに保存したい場合は、mkfldhdr コマンドで -d オプションを使用して、保存先ディレクトリを指定します。詳細については、『BEA Tuxedo コマンド・リファレンス』の「mkfldhdr、mkfldhdr32(1)」を参照してください。
フィールド・テーブルからヘッダ・ファイルへの変換例
例 1 および 2 は、環境変数を設定して mkfldhdr(1) コマンドを実行する方法を示しています。ここでは、3 つのフィールド・テーブル・ファイル (${FLDTBLDIR}/maskftbl、${FLDTBLDIR}/DBftbl、${FLDTBLDIR}/miscftbl) が処理され、3 つのインクルード・ファイル (maskftbl.h、DBftbl.h、miscftbl.h) がカレント・ディレクトリに生成されます。詳細については、『BEA Tuxedo コマンド・リファレンス』の「mkfldhdr、mkfldhdr32(1)」を参照してください。
例 1
FLDTBLDIR=/project/fldtbls
FIELDTBLS=maskftbl,DBftbl,miscftbl
export FLDTBLDIR FIELDTBLS
mkfldhdr
例 2
FLDTBLDIR32=/project/fldtbls
FIELDTBLS32=maskftbl,DBftbl,miscftbl
export FLDTBLDIR32 FIELDTBLS32
mkfldhdr32
例 3
例 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 を実行する
mkfldhdr のコマンド行でフィールド・テーブルの名前を指定し、環境変数をオーバーライドする (または環境変数を設定しない) ことができます。
ただし、この方法は実行時マッピングの関数に対しては適用できません。実行時マッピングの関数が使用されている場合、FLDTBLDIR がカレント・ディレクトリと見なされ、FIELDTBLS はユーザがコマンド行で指定したパラメータの一覧と見なされます。次の例を参照してください。
mkfldhdr myfields
このコマンドは、フィールド・テーブル・ファイル myfields をフィールド・ヘッダ・ファイル myfields.h に変換し、そのヘッダ・ファイルをカレント・ディレクトリに格納します。
詳細については、『BEA Tuxedo コマンド・リファレンス』の「mkfldhdr、mkfldhdr32(1)」を参照してください。
フィールドを C 構造体および COBOL レコードにマッピングする
ここでは、次の内容について説明します。
VIEWS 機能とは
FML VIEWS は、フィールド化バッファと C 構造体、またはフィールド化バッファと COBOL レコードの間でデータを交換するためのメカニズムです。この機能は、時間のかかるデータ操作を、C 関数を使用して C 構造体で行うために用意されています。この方が、FML 関数を使用してフィールド化バッファでデータを操作するより効率的です。また、VIEWS を使用して、COBOL プログラムで FML フィールド化レコードを扱う C プログラムとメッセージを送受信する方法としても使用できます。
この節では、VIEWS を使用してフィールド化バッファと C 構造体をマッピングする方法を説明します。
VIEWS の構造
次の図は、VIEWS の構成要素とそれらの相互関係を示しています。
図 4-1 VIEWS 機能の構成要素
VIEW ファイルを作成する
ソース VIEW ファイルは、vi などの任意のテキスト・エディタで作成する標準テキスト・ファイルです。このファイルには、1 つまたは複数のソース VIEW 記述 (フィールドから構造体への実際のマッピング情報) が格納されています。
VIEW コンパイラの最も重要な役割は、オブジェクト VIEW ファイルを生成することです。このファイルには、コンパイル済みのオブジェクト VIEW 記述が含まれています。オブジェクト VIEW ファイルは逆に、VIEW 逆アセンブラ (viewdis または viewdis32) での入力として使用できます。VIEW 逆アセンブラを使用すると、オブジェクト VIEW 記述をソース形式に戻し、内容を検証したり、編集することができます。詳細については、『BEA Tuxedo コマンド・リファレンス』の「viewdis、viewdis32(1)」を参照してください。
ソース VIEW 記述を作成および編集し、viewdis の出力を編集することができます。コンパイル済みの VIEW 記述 (バイナリ形式) を直接読み取ることはできません。
VIEW ファイルには、VIEW 記述のほかに # または $ で始まるコメント行を格納できます。# で始まる空白行は、VIEW コンパイラによって無視されますが、$ で始まる行は、VIEW コンパイラが生成するヘッダ・ファイルに渡すことができます。この規則によって、C のコメントなどの what の文字列を VIEW コンパイラが生成する C ヘッダ・ファイルに渡すことができます。
注記 この規則は、COBOL には適用されません。したがって、$ で始まる行は COBOL COPY ファイルには渡されません。
VIEW 記述を作成する
ソース VIEW ファイル内の各ソース VIEW 記述は、次の 3 つの部分で構成されています。
各 VIEW 記述の最初の行は、「VIEW」というキーワードで始まり、続いて VIEW 記述の名前が指定されます。メンバ記述 (マッピング・エントリ) は、C 構造体または COBOL レコードのメンバに関する情報を含む行です。キーワード END で始まる行は、VIEW 記述の最後の行です。
次のリストは、一般的なソース VIEW 記述の内容です。
コード リスト 4-2 VIEW 記述のソース
VIEW vname
# type cname fbname count flag size null
# ---- ----- ------ ----- ---- ---- ----
--------------member descriptions-------------------
.
.
.
END
以下は、リストの説明です。
VIEW 記述でのフラグ・オプションを指定する
以下は、VIEW 記述内のメンバ記述の flag 要素として指定できるオプションです (フラグ・オプションは FML 対応の VIEW にのみ適用されます)。
このオプションは、メンバ記述で記述された構造体メンバに加えて、連想カウント・メンバ (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 という名前が生成され、型は次のように宣言されます。
注記 生成された 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 は次のように宣言されます。
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 名と競合します。
ゼロ方向マッピングを指定します。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 値を使用する
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」を指定する必要はありません。
VIEW ファイルをコンパイルする
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 という接尾辞が付きます。
詳細については、『BEA Tuxedo コマンド・リファレンス』の「viewc、viewc32(1)」を参照してください。
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
この VIEW 記述の C ヘッダ・ファイルは、次のようになります。
struct test {
long empid; /* null=-1 */
float salary; /* null=0.000000 */
long phone[4]; /* null=0 */
char name[32]; /* null="NO NAME" */
};詳細については、『BEA Tuxedo コマンド・リファレンス』の「viewc、viewc32(1)」を参照してください。
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 プログラムに組み込まれます。
01 MYREC COPY TEST.
COPY ファイルの出力の詳細については、『COBOL を使用した BEA Tuxedo アプリケーションのプログラミング』を参照してください。
コンパイル後に VIEW ファイルの情報を表示する
VIEW 逆アセンブラである viewdis は、VIEW コンパイラで生成されたオブジェクト VIEW ファイルを逆処理し、ソース VIEW ファイルの形式で VIEW 情報を表示します。また、対応する構造体メンバのオフセットも表示します。
この形式の情報を参照できると、オブジェクト VIEW 記述が正確かどうかを検証するのに役立ちます。
VIEW 逆アセンブラを実行するには、次のコマンドを入力します。
viewdis objviewfile . . .
デフォルトでは、カレント・ディレクトリ内の objviewfile が逆アセンブルされます。このファイルをカレント・ディレクトリで検索できないと、エラー・メッセージが表示されます。コマンド行には、1 つまたは複数のオブジェクト VIEW ファイルを指定できます。
viewdis の出力は、元のソース VIEW 記述と同様であり、編集したり viewc に再入力できます。viewdis の出力に表示される行の順序は、元のソース VIEW 記述の順序と異なる場合がありますが、順序が違ってもオブジェクト VIEW ファイルの正確性とは関係ありません。
詳細については、『BEA Tuxedo コマンド・リファレンス』の「viewdis、viewdis32(1)」を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||