9.11 CALL_SERVER_FUNCTION
指定されたサーバー上でLANSAアプリケーションを呼び出し(実行し)、実行が完了するまで待機します。ファンクションは*DIRECTである必要があります。
各製品の対応
|
LANSA/AD |
使用可 |
|
Visual LANSA for Windows |
使用可 |
|
Visual LANSA for Linux |
使用可 |
引数
|
番号 |
タイプ |
必須/任意 |
記述 |
最小長 |
最大長 |
最小小数桁数 |
最大小数桁数 |
|---|---|---|---|---|---|---|---|
|
1 |
A |
必須 |
定義されているサーバーのSSN |
1 |
10 |
|
|
|
2 |
A |
必須 |
呼び出されるファンクションの名前 |
1 |
7 |
|
|
|
3 |
A |
任意 |
交換リストを渡す Y：交換リストを渡す その他：交換リストを渡さない デフォルトはNです。 |
1 |
1 |
|
|
|
4 |
A |
任意 |
交換リストを戻す Y：交換リストを戻す その他：交換リストを戻さない デフォルトはNです。 |
1 |
1 |
|
|
|
5 - 14 |
L |
任意 |
サーバー上のファンクションに渡される1から10の作業リスト |
|
|
|
|
戻り値
|
番号 |
タイプ |
必須/任意 |
記述 |
最小長 |
最大長 |
最小小数桁数 |
最大小数桁数 |
|---|---|---|---|---|---|---|---|
|
1 |
A |
必須 |
戻りコード OK：呼び出し完了 ER：呼び出し中にエラーが発生し、エラー・メッセージが発行される |
2 |
2 |
|
|
技術上の注記
· 呼び出されるサーバー・ファンクションは、完全な「バッチ」ジョブです。どのような方法を用いても(Windowsを使うなどしても)、DISPLAY/REQUEST/POP_UPコマンドを実行することはできません。これは、どの形式のユーザー・インターフェースにも論理的に接続していないためです。同様に、ユーザー・インターフェースへの論理的な接続を必要とする他のiSeries製品(STRSEU、WAF/400など)も使用できません。
この点については、アプリケーションの設計にかかわりが深いため、明確に理解しておく必要があります。クライアント・ファンクションは、DISPLAY/REQUEST/POP_UPコマンドを介してユーザーと「対話」します。サーバー・ファンクションは、実際にサーバー上で実行されるため、ユーザーと「対話」するための直接的または論理的方法は存在しません。
サーバー・ファンクションは、主に、別のプラットフォームで偶然実行されるクライアント・ファンクションの「サブルーチン」です。
· 作業リストに交換または渡されるフィールドは、ASCIIからEBCDICに自動的に変換されます(その後、ASCIIに戻されます)。この変換はクライアントまたはサーバー・ファンクションからは不可視です。RDML CALLコマンドを通じて同一のマシン上で呼び出されたように見えるだけです。
· 作業リストの受け渡しのためのRDML CALLコマンドに適用されるものと同じ規則がこの組み込み関数にも適用されます。
例：すべての作業リストは、呼び出し元でも受け取り先でも常に同じ定義がされている必要があります。リストの定義が変更された場合は、両方とも再コンパイルする必要があります。
· フィールドは、サーバー・ファンクションとの間で交換したり戻したりできます。
· 作業リストは、サーバー・ファンクションに渡したり、サーバー・ファンクションから戻したりできます。
· DBCS属性を持つ英数字フィールドは、ASCIIからEBCDIC DBCSに、またはその逆方向に変換されます。このタイプの変換は、フィールドがDBCS属性(J、E、Oなど)を持ち、DBCS使用可能オプションをYに設定してサーバー接続している場合にのみ行われます。
· 作業リストの詳細をサーバー・ファンクションにのみ渡す必要がある場合は、受け渡しが完了する前に、作業リストをクリアしてください。これにより、リストをクライアントに再度戻す手間を省き、通信トラフィックを軽減できます。
· 作業リストがサーバー・ファンクションによってのみ戻される必要がある場合は、サーバー・ファンクションを呼び出す前に作業リストをクリアしてください。これにより、リストの詳細をサーバーに送信する手間を省き、通信トラフィックを軽減できます。
さらに、これはサーバー・ファンクションが空またはクリアされたリストを受信していると想定される場合に偶発的な「リストあふれ」を防ぐことにもなります。「リストあふれ」の詳細については、以下のポイントを参照してください。
· サーバー・マシンから任意の形式で送付されるメッセージ情報は、テキスト形式で届きます。これは、純粋なテキストとして通常の方法(例：GET_MESSAGE)でRDMLファンクションに表示およびアクセスすることができます。サーバーから送付されたメッセージについては、メッセージIDおよびメッセージ・ファイル名などの詳細はわかりません。アプリケーション・メッセージ待ち行列から特定のメッセージIDを読み取るようなクライアント・アプリケーションを設計すべきではありません。
|
移植性に関する考慮事項 |
DEFINE_OS_400_SERVERで定義されるサーバー： サーバーに渡される作業リストの合計バイト長は、最大で32,000バイトです。合計バイト長とは、項目のバイト長に現在の項目数を乗算した長さです。1から10までの作業リストをサーバー上のファンクションに渡す場合、サーバーに渡すことができるバイトの合計は320,000になります。つまり、32,000バイトの作業リストが10あることになります。
クライアント・ファンクションが大きすぎるリストを渡した場合、この組み込み関数は致命的なエラー・メッセージを出力します。ただし、サーバー・ファンクションでは事情が異なります。サーバーがパラメータとして受け取る作業リストは、呼び出し元(iSeriesベースのサーバー制御プログラム)によって割り当てられたメモリーの中に存在します。その作業リストにあまりにも多くの項目を追加しようとすると、サーバー制御プログラムは打ち切られ、アプリケーション・エラーが発生します。 作業リストが含まれるCALL_SERVER_FUNCTIONで予期しないエラーが発生した場合は、まず、作業リストの「リストあふれ」が第1の原因として考えられます。 |
エラー処理に関する注意事項
複雑なエラー処理スキームをご使用のアプリケーションに組み込むことは避けるよう、強くお勧めします。アプリケーションのすべてのレベルで、以下のようなごく単純なトラップを使用するようにしてください。
if (#retcode *ne OK)
abort msgtxt('Failed to .............................')
endif
標準的なエラー処理を行う組み込み関数を生成されるアプリケーションに組み入れて、問題に対処するようにしてください。ユーザー定義のエラー処理ロジックが非常に複雑になったために全RDMLコードの40から50%を占有するようなケースもあります(アプリケーションには何のメリットもありません)。このような事態に陥らないようにしてください。