9.11 CALL_SERVER_FUNCTION

指定されたサーバー上でLANSAアプリケーションを呼び出し(実行し)、実行が完了するまで待機します。ファンクションは*DIRECTである必要があります。   

...

• 呼び出されるサーバー・ファンクションは、完全な「バッチ」ジョブです。どのような方法を用いても(Windowsを使うなどしても)、DISPLAY/REQUEST/POP_UPコマンドを実行することはできません。これは、どの形式のユーザー・インターフェースにも論理的に接続していないためです。同様に、ユーザー・インターフェースへの論理的な接続を必要とする他のIBM i 製品(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を読み取るようなクライアント・アプリケーションを設計すべきではありません。

...