7.49.1 FUNCTIONのパラメータ

7.49.1 FUNCTIONのパラメータ

OPTIONS

RCV_DS

RCV_LIST

TRIGGER

OPTIONS

最大9個のオプションを指定できます。このパラメータで指定できる値は以下のとおりです。

*NOMESSAGES

プログラムに対し、呼び出し元からのメッセージの経路付けや呼び出し元への経路付けが要求されません(失敗しない場合)。このオプションを指定すると、コ ンパイル済みRDMLファンクションで使用される開始時および終了時のリソースを低減することができます。

このオプションを指定した場合、保留中の開発者メッセージは検査されません。 これにより、開発者サービスが実行されている実稼動環境において頻繁に使用/呼び出されるファンクションのパフォーマンスを高めることができます。

*DEFERWRITE

このプログラム内でDISPLAY、REQUEST、またはPOP_UPコマンドに情報を提供するSystem i表示ファイルで常にDFRWRT(*YES)パラメータが使用されます。このオプションを指定すると、プログラムがデバイスの応答を待機する時間を短縮 できます。

POP_UPコマンドを使用するプログラムや、リモートで接続されたデバイスと情報をやり取りするプログラムでは、このオプションを使用してください。

*HEAVYUSAGEおよび*LIGHTUSAGE

関連付けられたプロセスで使用されるオプションに関わらず、コンパイル済みRDMLファンクションでは、HEAVY使用(高使用頻度)オプションまたは LIGHT使用(低使用頻度)オプションが使用されます。

高使用頻度オプションおよび低使用頻度オプションの詳細については、「[使用頻度]」を 参照してください。

デフォルトでは、RDMLXファンクションは、呼び出し間で状態を維持することに注意してください。状態を維持しない場合は、*DYNAMICのコンポー ネントを使用してください。

*DBOPTIMIZEまたは*DBOPTIMISE

RDMLファンクションは、I/Oモジュールによってデータベース・ファイルにアクセスせず、 直接I/O技術によってOPTIMIZEデータベース・アクセスを行います。

このオプションを指定すると、アプリケーションのパフォーマンスが高まりますが、多数の検討事項および制約が適用されます。

このオプションを使用する前に、『LANSA/AD ユーザーガイド』の「*DBOPTIMIZE/*DBOPTIMIZE_BATCH の使用」を 読むことを強 くお勧めします。

*DBOPTIMIZE_BATCHまたは*DBOPTIMISE_BATCH

RDMLファンクションは、I/Oモジュールによってデータベース・ファイルにアクセスせず、 大量の更新または削除操作を含むバッチ処理に最適な直接I/O技術によってOPTIMIZEデータベース・アクセスを行います。

このオプションを指定すると、バッチ・アプリケーションのパフォーマンスが高まりますが、多数の検討事項および制約が適用されます。

このオプションを使用する前に、『LANSA/AD ユーザーガイド』の「*DBOPTIMIZE/*DBOPTIMIZE_BATCH の使用」を 読むことを強 くお勧めします。

*PGMCOMMIT

あ らゆるタイプの更新処理のためにこのRDMLファンクションが開 いたす べてのファイルに対して個々のプログラム・レベルのコミット制御 が要求されます。

このオプションを指定すると、コミット制御の状況/自動コミット・オプションに関する個々のデータベース・ファイルの定義またはRDMLコマンドが上書きされて置き換えら れます。

また、オペレーティング・システムのコミット制御機能は、 RDMLファンクションによって自動的に開始/終了し ます。詳細については、『LANSA/AD ユーザーガイド』の｢ユー ザー 出口 F@BGNCMT - コミット制御の開始｣および｢ユー ザー 出口 F@ENDCMT - コミット制御の終了｣を参照してくださ い。

ユーザーの責任において、適切なトランザクションの境界でCOMMITおよびROLLBACKコマンドを実行してください。

この機能は、主にバッチ処理を対象としています。

このオプションを使用する前に、『LANSA/AD ユーザーガイド』の「コミット制御を使用する」を 十分に読むことを強 くお勧めします。

*PGMCOMMITを指定すると、*DBOPTIMIZEオプションが実際に指定されているかどうかに関わらず、*DBOPTIMIZEが自動的に使 用されます。

*NOPGMCOMMIT

更新処理のタイプを問 わず、このRDMLファンクションが開いたすべてのファ イルに対して個々のプログラム・レベルのコミット制御は要求されません。

このオプションを指定すると、コミット制御の状況/自動コミット・オプションに関する個々のデータベース・ファイルの定義またはRDMLコマンドが上書きされて置き換えら れます。

*NOPGMCOMMITを指定すると、*DBOPTIMIZEオプションが実際に指定されているかどうかに関わらず、*DBOPTIMIZEが自動的に使 用されます。

*NOIGCCNV

現在の言語の定義における「漢字変換を要求」フラグの設定に関係なく、このファンクションをサポートするために作成された表示ファイルに対して、 IGCCNV DDSキーワード(漢字変換用)は有効になりません。

通常、「漢字変換を要求」フラグが設定された言語では、ファンクション用に作成された表示ファイルに自動的にIGCCNV DDSキーワードが生成されます。

このオプションを指定すると、このファンクション用に生成されたすべての表示ファイルDDSで、IGCCNVキーワードの自動有効化が抑制されます。

*NO_RLTB_MIRROR

ファンクションが、右から左へ記述する言語でコンパイルされるかどうかに関わらず、このファンクションで、画面パネルおよびレポート・レイアウト上の フィールド位置の自動「ミラーリング」が有効になりません。

自動「ミラーリング」機能およびこのパラメータ値は、右から左へ記述する言語でコンパイルされるファンクションにのみ適用されます。その他すべての言語グ ループでは無視されます。

*DIRECT

このファンクションを別のファンクションから直接呼び出したり、このファンクションがプロンプト・キー要求に直接応じたりできるようになります。

注：す べてのRDMLXファンクションは、*DIRECTを使用する必要があります。これにより、移植されたSystem i RDMLファンクションが固有なものになります。

このオプションを指定することにより、このファンクションを別の呼び出し元ファンクションから直接呼び出したり、このファンクションがプロンプト・キー要 求に直接応じたりで きるようになります。

この段階では、これがこのファンクションを呼び出す完全に有効な方法かどうかは重要ではありません。このオプションは、単に、必要に応じてファンクション を直接呼び出すことができることを示すものです。

すべてのファンクションに、このオプションが指定されたFUNCTIONコマンドを含めることをお勧めします。また、このオプションの提供前に作成された アプリケーション・テンプレートは、このオプションを使用するFUNCTIONコマンドを自動的に生成するように変更してください。

ダイレクト・モード呼び出しの方法と、このタイプの呼び出し操作の使用時に適用される制約の詳細については、CALLコマンドのセクションを参照してくだ さい。

*CLOSE_DISPLAY

ファンクションがHEAVY使用(高使用頻度)プロセス、すなわち*HEAVYUSAGEファンクションとしてアクティブなままでも、終了時に表示ファイ ルが閉じ、再度アクティブになったときに再度開きます。

このオプションは、主に、最新でない「復元」画面や「瞬間的」な画面に悩まされるポップアップ・ウィンドウのプロンプト・キー・ファンクションで使用する ためのものです。

このオプションを指定した場合、すべてのブラウズ・ リストが、ファンクションの開始または再開ごとに明示的にクリア(CLR_LISTコマンド)されます。これにより、カウンター・フィールドは、リスト内 の現在の項目数に合わせて(表示ファイルが前回の終了時に閉じているため) 0にリセットされます。

*MLOPTIMIZEまたは*MLOPTIMISE

多言語サポート(区画レベルで定義)を使用するRDMLファンクションは、5言語以下の多言語アプリケーション・サポート用に最適化されます。

このオプションを指定すると、一般にサポートされる言語が5言語未満のアプリケーションのパフォーマンスを高めることができます。

RDMLファンクションをコンパイルすると、メイン・プログラム・オブジェクトになります。

RDMLファンクションが多言語区画にある場合は、「追加の」プログラム・オブジェクトも生成されます。

コンパイル済みのメインRDMLファンクションは、言語による動的な変更の影響を受けるすべての「リテラル」値を保持するための記憶域を宣言します。

コンパイル済みのメインRDMLファンクションが呼び出されると、このファンクションは、現在の言語に適したリテラル値で記憶域を初期化する追加のプログ ラムを呼び出します。

メイン・プログラムでは、1つの言語セットに十分な記憶域を宣言するだけで済むため、これは、非常に多数の言語が使用される場合に効果的な方法です。

追加のプログラムが呼び出されると、このプログラムは、すべての言語に十分な記憶域を一時的に使用し、適切な言語の詳細をメイン・プログラムの記憶域にコ ピーしてから終了します。このとき、余分な(不要になった)言語の記憶域がすべて解放されます。

この方法には、2つの欠点もあります。1つは、2つのコンパイル済みオブジェクトを生成する必要があるため、RDMLファンクションのコンパイル時間が長 くなることです。もう1つは、メインRDMLファンクションで、ファンクションの起動時に追加の初期化プログラムを呼び出す必要があることです。

*MLOPTIMIZE (または*MLOPTIMISE)を使用すると、RDMLファンクションで追加の初期化ファンクションを使用せずに済みます。すべての言語に必要な記憶域 がメイン・プログラムで宣言され、現在の言語に使用される記憶域がメイン・プログラムで初期化されます。

ファンクションで*MLOPTIMIZEを使用すると、メイン・プログラムで必要な記憶域は大きくなりますが、コンパイル時およびファンクションの呼び出 し時に使用されるリソースは少なくなります。

より大きな記憶域が使用されることから、*MLOPTIMIZEは、5言語未満の言語をサポートするファンクションでのみ使用することをお勧めします。

ただし、5という値は推奨される数に過ぎません。このオプションは、アプリケーション設計者の判断で、さらに多くの言語をサポートするファンクションで使 用することもできます。

*MLOPTIMIZEについて、以下の点にも注意してください。

·         OS/400 V2R1 (またはそれ以上)を使用している必要があります。

·         ア プリケーションは、多言語対応の区画内に存在している必要があります。

上記の条件が満たされていない状況で*MLOPTIMIZEを使用しても問題はありませんが、警告メッセージが発行され、*MLOPTIMIZE要求は無 視されます。

*ALP_SYSTEM_VARIABLE

このファンクションは、(英数字変数のみを対象とした)システム変数評価ファンクションになります。詳細については、『Visual LANSA 開発者ガイド』の「システム変数評価プログラム」を 参照してください。このオプションを指定する場合は、オプション*DIRECTも指定してください。

*NUM_SYSTEM_VARIABLE

このファンクションは、(数値システム変数のみを対象とした)システム変数評価ファンクションになります。詳細およびシステム変数評価のためのファンク ションの使用における設計上の制約については、『Visual LANSA 開発者ガイド』の「システム変数評価プログラム」を 参照してください。このオプションを指定する場合は、オプション*DIRECTも指定してください。

*ALP_FIELD_VALIDATE

このファンクションは、(英数字フィールドのみを対象とした)複雑ロジック検査ファンクションになります。

詳細については、『LANSA/AD ユーザーガイド』の「複雑なロジック検査」を 参照してください。このオプションを指定する場合は、オプション*DIRECTも指定してください。

*NUM_FIELD_VALIDATE

このファンクションは、(数値フィールドのみを対象とした)複雑ロジック検査ファンクションになります。

詳細については、『LANSA/AD ユーザーガイド』の「複雑なロジック検査」を 参照してください。このオプションを指定する場合は、オプション*DIRECTも指定してください。

*ALP_FIELD_VALIDATEおよび*NUM_FIELD_VALIDATEに関する技術ノート

複雑ロジック妥当性検査ファンクションでは、フィールド長および小数点以下桁数が異なるフィールドを処理できますが、タイプは同じでなければなりません。 FUNCTIONコマンドで*ALP_FIELD_VALIDATEオプションを指定すると、これが英数字フィールドの妥当性検査を行うファンクションで あることが示されます。また、FUNCTIONコマンドで*NUM_FIELD_VALIDATEオプションを指定した場合は、数値フィールドの妥当性検 査を行うファンクションであることが示されます。

妥当性検査ファンクション内でフィールド名、フィールド長、およびフィールド値にアクセスするには、データ・ディクショナリに以下のフィールドが定義され ている必要があります。

·         VALFLD$NM A(10)：妥当性検査対象のフィールドの名前

·         VALFLD$LN P(7,0)：妥当性検査対象のフィールドの長さ

·         VALFLD$DP P(7,0)：妥当性検査対象のフィールドの小数点以下桁数

·         VALFLD$AV A(256)：現在のフィールド値(英数字フィールド)

·         VALFLD$NV P(30,9)：現在のフィールド値(数値フィールド)

·         VALFLD$RT A(1)：戻りコード

この実装により、事実上、有効桁数が21桁を超える数値フィールドの妥当性検査が行えなくなることに注意してください。

ファンクション内でオプション*ALP_FIELD_VALIDATEまたは*NUM_FIELD_VALIDATEを使用した場合、計算された戻りコー ドがフィールドVALFLD$RTに返されます。これは妥当性検査ファンクションによって返され、値は'1' (正常)または'0' (異常)です。

ファンクションに*ALP_FIELD_VALIDATEまたは*NUM_FIELD_VALIDATEのいずれかのオプションを指定した場合、この機能 を正しく使用するために、以下のような制約を提供するようになっています。これは技術上の制約ではなく、あえて設計に盛り込んだ制 約です。

·         複 雑ロジック妥当性検査ファンクション内では、DISPLAY、REQUEST、またはPOP_UPコマンドを使用できません。

·         複 雑な検証処理が必要な場合であっても、ファンクション内から他のプロセス/ファンクションを呼び出す(CALL)ことはできません。ただし、3GLプログ ラムを呼び出すことは可能です。

·         ア クション・バー･プロセス内に、複雑ロジック妥当性検査ファンクションを記述できません。これは、アクション・バー内からこれらのファンクションを参照で きないということではなく、アクション・バー・タイプのプロセスの一部として複雑ロジック・ファンクションを定義できないということです。

·         複 雑ロジック妥当性検査ファンクションには、オプションRCV_DSまたはRCV_LISTを指定できません。

·         連 携するプロセスにパラメータを渡すことはできません。

·         交 換リストは使えません。これにより、妥当性検査の独立性を高め、モジュール性を保証しています。

·         再 帰的なファンクション呼び出しを記述することは可能ですが、実行の段階で失敗します。例えば、ファイルAへの挿入中に呼び出された妥当性検査ファンクショ ンがファイルBにデータを挿入しようとすると、それ自体が呼び出されて再帰的な状況になり、失敗する可能性があります。

·         複 雑ロジック妥当性検査ファンクションでは、オプション*DBOPTIMIZEおよび*NOMESSAGESを使用することをお勧めします。使用頻度の高い 妥当性検査ファンクションでは、*HEAVYUSAGEの使用を検討することもできます。

·         多 言語アプリケーションで使う場合は、ぜひとも*MLOPTIMIZE オプションを指定することを推奨します。

*MINI_SCREEN

このファンクション内で使用されるPOP_UPコマンドが、System iシステムに接続される「小型画面」表示デバイス用になります。このオプションを指定すると、POP_UPコマンド・ファンクションの通常のアクティブ化 方法が以下のように変更されます。

·         境 界線が表示されません。

·         1 行目の1列目の位置までウィンドウを左寄せできます。

·         境 界線のないウィンドウにより、一般的なポップアップ・ウィンドウではなく、「小型」全画面パネルの表示が生成されます。

·         ポッ プアップ・ウィンドウ内に表示されるブラウズ・リストでは、すべてのフィールドの欄見出しがブランクで上書きされ、ブラウズ・リストと見出し領域が通常の 分割線によって区切られません。

そのため、手作業で定義したテキストを「見かけ上の」欄見出しとして指定することができます。この機能は、ブラウズ・リスト内のすべての フィールドで欄見出しがブランクに上書きされている場合のみ使用されます。また、通常の分割線を、画面パネル内でブラウズ・リストを「押し下げる」目標位 置として使用できないため、画面ペインターでまったく新しいテ キスト行を挿入することは困難です。新しいテキスト行を挿入するには、RDMLエディターに戻り、FIELDSリストの末尾で見出し領域に「ダミー」 フィールドを定義して、画面ペインターを再度呼び出します。これにより、ダミー・フィールドが配置され、画面パネル内でブラウズ・リストが「押し下げ」ら れます。その後、作成した新しい行に必要なテキスト/フィールドを追加/移動します。また、「ダミー」フィールドを削除することもできます。

この機能を大規模に使用する場合は、"ET" (テンプレートの実行)エディター・アクションから呼び出せるようにアプリケーション・テンプレートを構成することを強くお勧めします。 このようなテンプレートを使用すれば、ブラウズ・リスト部分を必要な開始行まで押し下げ、見出し領域にフィールド/テキストを挿入するための十分なスペー スを確保するための1つ以上の初期「ダミー」フィールドを含む、すべての「小型画面」用の「標準レイアウト」を構成することができます。

*OS400_EXT_PRINT

LANSAにより、RDMLファンクション用のi5/OS固有の外部プリンター・ファイルが生成され、使用されます。このオプション単独では利点がありま せんが、RDMLファンクション内でユーザー定義レポート属性を使用するために指定する必要があります。

このオプションを指定すると、ファンクションがSystem iプラットフォームに依存す るようになります。

*OS400_EXT_PRINTを指定する場合、以下のような制約が適用されます。

·         *DIRECT も指定する必要があります。

·         SKIP コマンドを使用することはできません。

·         レ ポート番号1のみを使用できます。

上記の制約に従わないと、構文検査時に致命的エラーが発生します。

ユーザー定 義レポート属性および外部プリンター・ファイルの詳細について は、『LANSA/AD ユーザーガイド』の「ユーザー定義レポート属性」を 参照してください。

*BUILTIN

このファンクションは組み込み関数になります。

詳細については、『LANSA アプリケーション設計ガイド』の「独自の組み込み関数の作成」を 参照してください。このオプションを指定する場合は、*DIRECTも指定してください。

*STRICT_NULL_ASSIGN

非NULL可能フィールドに*SQLNULLを割り当てるとエラーになります。

デフォルトの動作はこれほど厳密ではなく、*SQLNULL値を非NULL可能フィールドに割り当てると、*NULLとして扱われます。各フィールド・タ イプにおける*NULL値の定義については、「CHANGE のパラメータ」を参照してください。

厳密なNULLの割り当てとデフォルトの動作の詳細については、「SQL Nullが可能なフィールドの割り当て、条件、式」を 参照してください。

RCV_DS

ファンクションが受け取ることのできる、最大20のデータ構造名を指定できます。このパラメータを使用する際は、以下の点に注意してください。

各データ構造名は、LANSAに定義されている物理ファイルの名前でなければなりません。

このパラメータを使用する場合は、FUNCTION OPTIONS(*DIRECT)を指定する必要があります。

特別な*EXCHANGEオプションが使用されている場合を除き、データ構造を受け取るファンクションには、コンパイル中にプロセス・メニュー(またはア クション・バー)から直接アクセスできないことを示すフラグが立てられます。

このようなファンクションは、プロセス・メニューまたはアクション・バーから直接呼び出すのではなく、正しいデータ構造を(正しい順序で)渡す別のファン クションから呼び出す必要があります。

指定された物理ファイル内のフィールド(すなわちデータ構造)を受け取るには、ファンクション内のどこかでそのフィールドを参照する必要があります。参照 しないと、フィールドを受け取ることができません。このことは、呼び出し元ファンクションにも当てはまります。ファイルから渡すことができるのは実フィー ルドのみで、仮想フィールドは渡すことができません。

また、データ構造の、CALLコマンドのPASS_DSパラメータでの指定順序および呼び出されるファンクションのFUNCTIONコマンドの RCV_DSパラメータでの指定順序も重要です。データ構造の順序は、呼び出されるファンクションおよび呼び出し元ファンクションにおいて同じでなければ なりません。同じでないと、エラーが発生する可能性があります。

同様に、データ構造のレイアウトが変更された場合、変更されたデータ構造が操作可能になった後に、RCV_DSまたはPASS_DSパラメータでそのデー タ構造を参照するすべてのファンクションを再コンパイルする必要があります。

RCV_DSパラメータの最初の引数として、*EXCHANGEという特殊なオ プションを使用できます(RCV_DS(*EXCHANGE CUSMST PRODMST)など)。これは、指定されたデータ構造が渡され、実際のパラメータとしてではなく、「交換リスト」タイプの構造を介して戻されることを示 します。

この機能は非常に特殊で、以下の条件に正確に適合しているファンクションでのみ使用するように設計されています。ファンクションが以下の条件に正確に適合 していない限り、このオプションを使用しないでください。

·         ファ ンクションがメニューまたはアクション・バーから直接呼び出されること。この機能は、このようなファンクションが、EXCHANGEコマンドによって多数 のフィールドを交換しなくても、ファンクション間で一連のデータ構造を「交換」できるようにするために用意されたものです。

·         ファ ンクションが他のファンクションから呼び出されないこと。呼び出し元が通常の方法でデータ方法を直接渡せる場合は、このオプションを使用する必要はありま せん。

RCV_DS(*EXCHANGE)を使用するファンクションでは、以下のような処理ロジックが使用されます。

·         ファ ンクションが開始されると、「交換領域」でデータ構造が(指定順序ではなくデータ構造名で)検索されます。一致するデータが見つかると、その内容がデータ 構造にコピーされます。一致するデータが見つからなかった場合は、データ構造の内容は変更されません。

·         そ の後、「交換領域」のすべてのデータ構造がクリアされます。

·         ファ ンクションは、通常の処理に進みます。

·         ファ ンクションが(その方法を問わず)正常終了すると、RCV_DSパラメータで指定されたすべてのデータ構造の内容が「交換領域」に戻されます。

このオプションを使用する際の技術上の検討事項は以下のとおりです。

·         交 換領域を検索、クリア、および変更するのは、RCV_DS(*EXCHANGE .....)を使用しているファンクションのみです。このオプションを使用していないファンクションは、交換領域に何の影響も与えません。

·         交 換領域の最大長は9999バイトです。合計長がこの制限を超える一連のデータ構造を使用しようとすると、アプリケーションが失敗します。

·         交 換領域への実際の保管は、M@EXCHDSという付属プログラムによって実行されます。i5/OSオペレーティング・システム環境でのパフォーマンスを最 適化し、PAG (プロセス・アクセス・グループ)の「穴」を避けるために、このプログラムには、LANSAの呼び出し前(シ ステムのサイン・オン中など)に使用可能な「開く」および「閉じる」オプションが用意されています。この「開く」および「閉じる」オプションでは LANSAの規則に従い、開く場合はCALL M@EXCHDS (X'00')、閉じる場合はCALL M@EXCHDS (X'FF')が実行されます。明らかに、閉じる操作によって交換領域はクリアされます。LANSA RDMLファンクション内からM@EXCHDSを呼び出さないでください。 これらのタイプの呼び出しは、実際にこの機能を使用するために必要なものではなく、 その使用を最適化するためのものです。

·         RCV_DS(*EXCHANGE ....)は、通常のRCV_DS(.....)パラメータほど効率的ではありませんが、EXCHANGEコマンドで多数のフィールドを処理するよりも効 率的です。

RCV_LIST

最大20個の作業リスト名を指定できます。このパラメータを使用する際は、以下の点に注意してください。

指定する各作業リストは、ファンクション内で定義されていなければなりません。

このパラメータを使用する場合は、FUNCTION OPTIONS(*DIRECT)を指定する必要があります。

作業リストを受け取るファンクションには、コンパイル時にメイン・メニューからアクセスできないことを示すフラグが立てられます。このようなファンクショ ンは、メニューからではなく、正しい作業リストを渡す別のファンクションから呼び出す必要があります。

呼び出されるファンクションと呼び出し元ファンクションの両方で、作業リストに同じ属性が定義されている必要があります。そうでないと、エラーが発生しま す。

また、作業リストの、呼び出し元ファンクションのPASS_LSTパラメータでの指定順序および呼び出されるファンクションのRCV_LISTでの指定順 序も重要です。作業リストの順序は、呼び出されるファンクションおよび呼び出し元ファンクションにおいて同じでなければなりません。同じでないと、エラー が発生する可能性があります。

TRIGGER

このファンクションが、データ・ディクショナリ・フィールドまたはデータベース・ファイルの「トリガー」として機能することを指定すために使用します。

デフォルト値*NONEを指定した場合、このファンクションはトリガー・ファンクションではありません。

*FIELDを指定した場合、このファンクションはデータ・ディクショナリ・レベルのトリガーとして機能します。関連付けるデータ・ディクショナリ・ フィールドもこのパラメータで指定する必要があります。

*FILEを指定した場合、このファンクションはデータベース・レベルのトリガーとして機能します。関連付けるデータベース・ファイル名もこのパラメータ で指定する必要があります。指定するファイルは物理ファイルでなければなりません。

詳細については、「トリガー」を 参照してください。

ファンクションをトリガー・ファンクションとして定義する場合、以下のガイドラインに従う必要があります。

·         パ ラメータRCV_LIST(#TRIG_LIST)を使用してください。

·         パ ラメータRCV_DSは使用しないでください。

·         オ プション*DIRECTも使用する必要があります。

·         オ プションxxx_SYSTEM_VARIABLEまたはxxx_FIELD_VALIDATEは使用しないでください。

·         リ スト#TRIG_LISTが、DEF_LISTコマンドでDEF_LIST NAME(#TRIG_LIST) TYPE(*WORKING) ENTRYS(2)として定義されている必要があります。また、FIELDSパラメータにフィールドを含めないでください。必要なフィールドは自動的に追 加されます。

·         DISPLAY、 REQUEST、またはPOP_UPコマンドは使用できません。これは、意図的に適用されている設計/使用上の制約で、将来的なバージョンで排除される可 能性があります。

·         別 のプロセス/ファンクションを呼び出す(CALL)ことはできません。これは、意図的に適用されている設計/使用上の制約で、将来的なバージョンで排除さ れる可能性があります。

·         組 み込み関数CALL_SERVER_FUNCTIONを使用してスーパーサーバー経由でファンクションを呼び出す場合、リスト#TRIG_LISTをサー バー・ファンクションに渡さないでください。

·         ア クション・バー・プロセス内でトリガー・ファンクションを定義することはできません。これは、アクション・バー内からこれらのファンクションを参照できな いということではなく、アクション・バー・タイプのプロセスの一部としてトリガー・ファンクションを定義できないということです。

·         関 連付けられたプロセスではパラメータを使用できません。

·         交 換リストは使えません。これは、トリガー・ファンクションの設計および使用における独立性とモジュール性を確保するために意図的に適用されている設計/使 用上の制約です。

ファンクションをトリガー・ファンクションとして定義する場合、多くの状況で以下のガイドラインに従う必要があります。

·         「トリガー」を 読んで、トリガーの定義方法と使用方法を理解してください。

·         オ プション*NOMESSAGESおよび*MLOPTIMIZEを使用してください。

·         オ プション*HEAVYUSAGEおよび*DBOPTIMIZEの使用を検討することもできます。

·         直 接または間接を問わず、トリガーがリンクされている、またはリンクされるデータベース・ファイルにアクセスしないでください。

·         ト リガーが頻繁かつ継続的に呼び出される場合は、リソースを大量に消費する操作は避けてください。このような操作を実行すると、関連付けられたファイルへの アクセス速度が低下します。

·         再 帰的なファンクション呼び出しを記述することは可能ですが、実行の段階で失敗します。例えば、ファイルAへの挿入中に呼び出されたフィールド・トリガー・ ファンクションがファイルBにデータを挿入しようとすると、それ自体が呼び出されて再帰的な状況になり、失敗します。