最大9個のオプションを指定できます。このパラメータで指定できる値は以下のとおりです。
*NOMESSAGES
プログラムに対し、呼び出し元からのメッセージの経路付けや呼び出し元への経路付けが要求されません(失敗しない場合)。このオプションを指定すると、コンパイル済みRDMLファンクションで使用される開始時および終了時のリソースを低減することができます。
このオプションを指定した場合、保留中の開発者メッセージは検査されません。これにより、開発者サービスが実行されている実稼動環境において頻繁に使用/呼び出されるファンクションのパフォーマンスを高めることができます。
*DEFERWRITE
|
移植性に関する考慮事項 |
Visual LANSAコードで使用した場合は無視され、アプリケーションには何の効果もありません。 |
このプログラム内でDISPLAY、REQUEST、またはPOP_UPコマンドに情報を提供するIBM i表示ファイルで常にDFRWRT(*YES) パラメータが使用されます。このオプションを指定すると、プログラムがデバイスの応答を待機する時間を短縮できます。
POP_UPコマンドを使用するプログラムや、リモートで接続されたデバイスと情報をやり取りするプログラムでは、このオプションを使用してください。
*HEAVYUSAGEおよび*LIGHTUSAGE
関連付けられたプロセスで使用されるオプションに関わらず、コンパイル済みRDMLファンクションでは、HEAVY使用 (高使用頻度) オプションまたは LIGHT使用 (低使用頻度) オプションが使用されます。
高使用頻度オプションおよび低使用頻度オプションの詳細については、「[使用頻度]」を参照してください。
デフォルトでは、RDMLXファンクションは、呼び出し間で状態を維持することに注意してください。状態を維持しない場合は、*DYNAMICのコンポーネントを使用してください。
*DBOPTIMIZEまたは*DBOPTIMISE
|
移植性に関する考慮事項 |
Visual LANSAおよびRDMLXコードで使用した場合は無視され、アプリケーションには何の効果もありません。 |
RDMLファンクションは、I/Oモジュールによってデータベース・ファイルにアクセスせず、直接I/O技術によってOPTIMIZEデータベース・アクセスを行います。
このオプションを指定すると、アプリケーションのパフォーマンスが高まりますが、多数の検討事項および制約が適用されます。
このオプションを使用する前に、『LANSA/AD ユーザーガイド』の「*DBOPTIMIZE/*DBOPTIMIZE_BATCH の使用」を読むことを強くお勧めします。
*DBOPTIMIZE_BATCHまたは*DBOPTIMISE_BATCH
|
移植性に関する考慮事項 |
Visual LANSAおよびRDMLXコードで使用した場合は無視され、アプリケーションには何の効果もありません。 |
RDMLファンクションは、I/Oモジュールによってデータベース・ファイルにアクセスせず、大量の更新または削除操作を含むバッチ処理に最適な直接I/O技術によってOPTIMIZEデータベース・アクセスを行います。
このオプションを指定すると、バッチ・アプリケーションのパフォーマンスが高まりますが、多数の検討事項および制約が適用されます。
このオプションを使用する前に、『LANSA/AD ユーザーガイド』の「*DBOPTIMIZE/*DBOPTIMIZE_BATCH の使用」を読むことを強くお勧めします。
*PGMCOMMIT
|
移植性に関する考慮事項 |
Visual LANSAおよびRDMLXコードで使用した場合は無視され、アプリケーションには何の効果もありません。ビルド警告が生成されます。 |
あらゆるタイプの更新処理のためにこのRDMLファンクションが開いたすべてのファイルに対して個々のプログラム・レベルのコミット制御が要求されます。
このオプションを指定すると、コミット制御の状況/自動コミット・オプションに関する個々のデータベース・ファイルの定義またはRDMLコマンドが上書きされて置き換えられます。
また、オペレーティング・システムのコミット制御機能は、RDMLファンクションによって自動的に開始/終了します。詳細については、『LANSA/AD ユーザーガイド』の｢ユーザー出口 F@BGNCMT - コミット制御の開始｣および｢ユーザー出口 F@ENDCMT - コミット制御の終了｣を参照してください。
ユーザーの責任において、適切なトランザクションの境界でCOMMITおよびROLLBACKコマンドを実行してください。
この機能は、主にバッチ処理を対象としています。
このオプションを使用する前に、『LANSA/AD ユーザーガイド』の「コミット制御を使用する」を十分に読むことを強くお勧めします。
*PGMCOMMITを指定すると、*DBOPTIMIZEオプションが実際に指定されているかどうかに関わらず、*DBOPTIMIZEが自動的に使用されます。
*NOPGMCOMMIT
|
移植性に関する考慮事項 |
Visual LANSAおよびRDMLXコードで使用した場合は無視され、アプリケーションには何の効果もありません。ビルド警告が生成されます。 |
更新処理のタイプを問わず、このRDMLファンクションが開いたすべてのファイルに対して個々のプログラム・レベルのコミット制御は要求されません。
このオプションを指定すると、コミット制御の状況/自動コミット・オプションに関する個々のデータベース・ファイルの定義またはRDMLコマンドが上書きされて置き換えられます。
*NOPGMCOMMITを指定すると、*DBOPTIMIZEオプションが実際に指定されているかどうかに関わらず、*DBOPTIMIZEが自動的に使用されます。
*NOIGCCNV
|
移植性に関する考慮事項 |
Visual LANSAコードで使用した場合は無視され、アプリケーションには何の効果もありません。 |
現在の言語の定義における「漢字変換を要求」フラグの設定に関係なく、このファンクションをサポートするために作成された表示ファイルに対して、 IGCCNV DDSキーワード(漢字変換用)は有効になりません。
通常、「漢字変換を要求」フラグが設定された言語では、ファンクション用に作成された表示ファイルに自動的にIGCCNV DDSキーワードが生成されます。
このオプションを指定すると、このファンクション用に生成されたすべての表示ファイルDDSで、IGCCNVキーワードの自動有効化が抑制されます。
*NO_RLTB_MIRROR
ファンクションが、右から左へ記述する言語でコンパイルされるかどうかに関わらず、このファンクションで、画面パネルおよびレポート・レイアウト上のフィールド位置の自動「ミラーリング」が有効になりません。
自動「ミラーリング」機能およびこのパラメータ値は、右から左へ記述する言語でコンパイルされるファンクションにのみ適用されます。その他すべての言語グループでは無視されます。
*DIRECT
このファンクションを別のファンクションから直接呼び出したり、このファンクションがプロンプト・キー要求に直接応じたりできるようになります。
注：すべてのRDMLXファンクションは、*DIRECTを使用する必要があります。これにより、移植されたIBM i RDMLファンクションが固有なものになります。
このオプションを指定することにより、このファンクションを別の呼び出し元ファンクションから直接呼び出したり、このファンクションがプロンプト・キー要求に直接応じたりできるようになります。
この段階では、これがこのファンクションを呼び出す完全に有効な方法かどうかは重要ではありません。このオプションは、単に、必要に応じてファンクションを直接呼び出すことができることを示すものです。
すべてのファンクションに、このオプションが指定されたFUNCTIONコマンドを含めることをお勧めします。また、このオプションの提供前に作成されたアプリケーション・テンプレートは、このオプションを使用するFUNCTIONコマンドを自動的に生成するように変更してください。
ダイレクト・モード呼び出しの方法と、このタイプの呼び出し操作の使用時に適用される制約の詳細については、CALLコマンドのセクションを参照してください。
*CLOSE_DISPLAY
|
移植性に関する考慮事項 |
Visual LANSAコードで使用した場合は無視され、アプリケーションには何の効果もありません。 |
ファンクションがHEAVY使用(高使用頻度)プロセス、すなわち*HEAVYUSAGEファンクションとしてアクティブなままでも、終了時に表示ファイルが閉じ、再度アクティブになったときに再度開きます。
このオプションは、主に、最新でない「復元」画面や「瞬間的」な画面に悩まされるポップアップ・ウィンドウのプロンプト・キー・ファンクションで使用するためのものです。
このオプションを指定した場合、すべてのブラウズ・ リストが、ファンクションの開始または再開ごとに明示的にクリア(CLR_LISTコマンド)されます。これにより、カウンター・フィールドは、リスト内の現在の項目数に合わせて(表示ファイルが前回の終了時に閉じているため) 0にリセットされます。
*MLOPTIMIZEまたは*MLOPTIMISE
|
移植性に関する考慮事項 |
Visual LANSAおよびRDMLXコードで使用する場合は無視されます。 |
多言語サポート(区画レベルで定義)を使用するRDMLファンクションは、5言語以下の多言語アプリケーション・サポート用に最適化されます。
このオプションを指定すると、一般にサポートされる言語が5言語未満のアプリケーションのパフォーマンスを高めることができます。
RDMLファンクションをコンパイルすると、メイン・プログラム・オブジェクトになります。
RDMLファンクションが多言語区画にある場合は、「追加の」プログラム・オブジェクトも生成されます。
コンパイル済みのメインRDMLファンクションは、言語による動的な変更の影響を受けるすべての「リテラル」値を保持するための記憶域を宣言します。
コンパイル済みのメインRDMLファンクションが呼び出されると、このファンクションは、現在の言語に適したリテラル値で記憶域を初期化する追加のプログラムを呼び出します。
メイン・プログラムでは、1つの言語セットに十分な記憶域を宣言するだけで済むため、これは、非常に多数の言語が使用される場合に効果的な方法です。
追加のプログラムが呼び出されると、このプログラムは、すべての言語に十分な記憶域を一時的に使用し、適切な言語の詳細をメイン・プログラムの記憶域にコピーしてから終了します。このとき、余分な(不要になった)言語の記憶域がすべて解放されます。
この方法には、2つの欠点もあります。1つは、2つのコンパイル済みオブジェクトを生成する必要があるため、RDMLファンクションのコンパイル時間が長くなることです。もう1つは、メインRDMLファンクションで、ファンクションの起動時に追加の初期化プログラムを呼び出す必要があることです。
*MLOPTIMIZE (または*MLOPTIMISE)を使用すると、RDMLファンクションで追加の初期化ファンクションを使用せずに済みます。すべての言語に必要な記憶域がメイン・プログラムで宣言され、現在の言語に使用される記憶域がメイン・プログラムで初期化されます。
ファンクションで*MLOPTIMIZEを使用すると、メイン・プログラムで必要な記憶域は大きくなりますが、コンパイル時およびファンクションの呼び出し時に使用されるリソースは少なくなります。
より大きな記憶域が使用されることから、*MLOPTIMIZEは、5言語未満の言語をサポートするファンクションでのみ使用することをお勧めします。
ただし、5という値は推奨される数に過ぎません。このオプションは、アプリケーション設計者の判断で、さらに多くの言語をサポートするファンクションで使用することもできます。
*MLOPTIMIZEについて、以下の点にも注意してください。
上記の条件が満たされていない状況で*MLOPTIMIZEを使用しても問題はありませんが、警告メッセージが発行され、*MLOPTIMIZE要求は無視されます。
*ALP_SYSTEM_VARIABLE
このファンクションは、(英数字変数のみを対象とした)システム変数評価ファンクションになります。このオプションを指定する場合は、オプション*DIRECTも指定してください。
*NUM_SYSTEM_VARIABLE
このファンクションは、(数値システム変数のみを対象とした)システム変数評価ファンクションになります。このオプションを指定する場合は、オプション*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オプションを指定した場合は、数値フィールドの妥当性検査を行うファンクションであることが示されます。
妥当性検査ファンクション内でフィールド名、フィールド長、およびフィールド値にアクセスするには、データ・ディクショナリに以下のフィールドが定義されている必要があります。
この実装により、事実上、有効桁数が21桁を超える数値フィールドの妥当性検査が行えなくなることに注意してください。
ファンクション内でオプション*ALP_FIELD_VALIDATEまたは*NUM_FIELD_VALIDATEを使用した場合、計算された戻りコードがフィールドVALFLD$RTに返されます。これは妥当性検査ファンクションによって返され、値は'1' (正常)または'0' (異常)です。
ファンクションに*ALP_FIELD_VALIDATEまたは*NUM_FIELD_VALIDATEのいずれかのオプションを指定した場合、この機能を正しく使用するために、以下のような制約を提供するようになっています。これは技術上の制約ではなく、あえて設計に盛り込んだ制約です。
*MINI_SCREEN
|
移植性に関する考慮事項 |
アプリケーションがIBM i ベースで、画面パネル・サイズが標準的な24行×80列よりも小さい「小型」または「パームトップ」デバイスで使用する場合を除き、このオプションを使用しないでください。 通常のフル・パネルのDISPLAYまたはREQUESTコマンドが含まれるファンクションでは、このオプションを使用しないでください。 GUI 対応のファンクションでは、このオプションを使用しないでください。Visual LANSAコード内で使用すると無視され、ビルド警告が生成されます。 |
このファンクション内で使用されるPOP_UPコマンドが、IBM iシステムに接続される「小型画面」表示デバイス用になります。このオプションを指定すると、POP_UPコマンド・ファンクションの通常のアクティブ化方法が以下のように変更されます。
*OS400_EXT_PRINT
|
移植性に関する考慮事項 |
Visual LANSAおよびRDMLXコードではサポートされません。使用すると、ビルド警告が生成されます。 |
LANSAにより、RDMLファンクション用のIBM i 固有の外部プリンター・ファイルが生成され、使用されます。このオプション単独では利点がありませんが、RDMLファンクション内でユーザー定義レポート属性を使用するために指定する必要があります。
このオプションを指定すると、ファンクションがIBM i プラットフォームに依存するようになります。
*OS400_EXT_PRINTを指定する場合、以下のような制約が適用されます。
上記の制約に従わないと、構文検査時に致命的エラーが発生します。
ユーザー定義レポート属性および外部プリンター・ファイルの詳細については、『LANSA/AD ユーザーガイド』の「ユーザー定義レポート属性」を参照してください。
*BUILTIN
このファンクションは組み込み関数になります。
詳細については、『LANSA アプリケーション設計ガイド』の「独自の組み込み関数の作成」を参照してください。このオプションを指定する場合は、*DIRECTも指定してください。
*STRICT_NULL_ASSIGN
非NULL可能フィールドに*SQLNULLを割り当てるとエラーになります。
デフォルトの動作はこれほど厳密ではなく、*SQLNULL値を非NULL可能フィールドに割り当てると、*NULLとして扱われます。各フィールド・タイプにおける*NULL値の定義については、「7.12.1 CHANGE のパラメータ 」を参照してください。
厳密なNULLの割り当てとデフォルトの動作の詳細については、「SQL Nullが可能なフィールドの割り当て、条件、式」を参照してください。
ファンクションが受け取ることのできる、最大20のデータ構造名を指定できます。このパラメータを使用する際は、以下の点に注意してください。
各データ構造名は、LANSAに定義されている物理ファイルの名前でなければなりません。
このパラメータを使用する場合は、FUNCTION OPTIONS(*DIRECT)を指定する必要があります。
特別な*EXCHANGEオプションが使用されている場合を除き、データ構造を受け取るファンクションには、コンパイル中にプロセス・メニュー(またはアクション・バー)から直接アクセスできないことを示すフラグが立てられます。
このようなファンクションは、プロセス・メニューまたはアクション・バーから直接呼び出すのではなく、正しいデータ構造を(正しい順序で)渡す別のファンクションから呼び出す必要があります。
指定された物理ファイル内のフィールド(すなわちデータ構造)を受け取るには、ファンクション内のどこかでそのフィールドを参照する必要があります。参照しないと、フィールドを受け取ることができません。このことは、呼び出し元ファンクションにも当てはまります。ファイルから渡すことができるのは実フィールドのみで、仮想フィールドは渡すことができません。
また、データ構造の、CALLコマンドのPASS_DSパラメータでの指定順序および呼び出されるファンクションのFUNCTIONコマンドの RCV_DSパラメータでの指定順序も重要です。データ構造の順序は、呼び出されるファンクションおよび呼び出し元ファンクションにおいて同じでなければなりません。同じでないと、エラーが発生する可能性があります。
同様に、データ構造のレイアウトが変更された場合、変更されたデータ構造が操作可能になった後に、RCV_DSまたはPASS_DSパラメータでそのデータ構造を参照するすべてのファンクションを再コンパイルする必要があります。
RCV_DSパラメータの最初の引数として、*EXCHANGEという特殊なオプションを使用できます(RCV_DS(*EXCHANGE CUSMST PRODMST)など)。これは、指定されたデータ構造が渡され、実際のパラメータとしてではなく、「交換リスト」タイプの構造を介して戻されることを示します。
この機能は非常に特殊で、以下の条件に正確に適合しているファンクションでのみ使用するように設計されています。ファンクションが以下の条件に正確に適合していない限り、このオプションを使用しないでください。
RCV_DS(*EXCHANGE) を使用するファンクションでは、以下のような処理ロジックが使用されます。
このオプションを使用する際の技術上の検討事項は以下のとおりです。
最大 20 個の作業リスト名を指定できます。このパラメータを使用する際は、以下の点に注意してください。
指定する各作業リストは、ファンクション内で定義されていなければなりません。
このパラメータを使用する場合は、FUNCTION OPTIONS(*DIRECT)を指定する必要があります。
作業リストを受け取るファンクションには、コンパイル時にメイン・メニューからアクセスできないことを示すフラグが立てられます。このようなファンクションは、メニューからではなく、正しい作業リストを渡す別のファンクションから呼び出す必要があります。
呼び出されるファンクションと呼び出し元ファンクションの両方で、作業リストに同じ属性が定義されている必要があります。そうでないと、エラーが発生します。
また、作業リストの、呼び出し元ファンクションのPASS_LSTパラメータでの指定順序および呼び出されるファンクションのRCV_LISTでの指定順序も重要です。作業リストの順序は、呼び出されるファンクションおよび呼び出し元ファンクションにおいて同じでなければなりません。同じでないと、エラーが発生する可能性があります。
このファンクションが、データ・ディクショナリ・フィールドまたはデータベース・ファイルの「トリガー」として機能することを指定すために使用します。
デフォルト値 *NONE を指定した場合、このファンクションはトリガー・ファンクションではありません。
*FIELD を指定した場合、このファンクションはデータ・ディクショナリ・レベルのトリガーとして機能します。関連付けるデータ・ディクショナリ・フィールドもこのパラメータで指定する必要があります。
*FILE を指定した場合、このファンクションはデータベース・レベルのトリガーとして機能します。関連付けるデータベース・ファイル名もこのパラメータで指定する必要があります。指定するファイルは物理ファイルでなければなりません。
詳細については、「トリガー」を参照してください。
ファンクションをトリガー・ファンクションとして定義する場合、以下のガイドラインに従う必要があります。
ファンクションをトリガー・ファンクションとして定義する場合、多くの状況で以下のガイドラインに従う必要があります。
