9.43 DISCONNECT_FILE

9.43 DISCONNECT_FILE

Þ 注：組み込み関数の規則

サーバーに接続されているファイルを切断します。

警告：

·         I/O操作が保留中のファイルにこの組み込み関数を使用すると、予期しない結果を招きます。

·         現在接続されていないファイルへの切断要求は無視されます。エラーにはなりません。

各製品の対応

引数

戻り値

戻り値はありません。

技術ノート

·         総称名を指定する場合、前に発行したCONNECT_FILE組み込み関数で指定した総称名と一致させる必要があります。

·         例えば、A*のファイルを接続した後にAB*のファイルを切断したとします。この結果、Aで始まるファイルのうち、ABで始まるファイルを除くものが現在接続されていることにはなりません。切断要求のAB*は、接続されたファイルとは一致しないとみなされ、この要求は無視されます。Aで始まるすべてのファイルは引き続き接続されます。

·         ファイルの使用中(サーバーに接続されていない、または別のサーバーに接続されたファイルに対するSELECTループの実行中など)に、そのファイルに切断要求を実行すると、アプリケーション・エラーまたは予期しない結果を招きます。

·         「切断」のロジックは、多数のRDMLファンクションに分散させるのではなく、1つのファンクションだけにコーディングすることを強くお勧めします。このようにすることで、将来サーバーに対して加えられる変更からアプリケーションを保護することができます。

·         ファイル名がブランクのファイルには切断を試みないでください。

·         ファイルを総称名(LM*、GL*、*など)にする場合は、総称名が重複しないように十分注意してください。このルールが守られないと、予期しない結果を招きます。このルールで、"*"(すべての名前)はそれだけでしか使用できません。したがって、"*"の前後に切断するその他のファイル名はすべて重複することになります。

·         ファイルの切断が実際に必要とされることはありません。X_RUNコマンドは終了するときに接続済みのファイルをすべて自動で切断するからです。

·         サーバー・マシンから任意の形式で送付されるメッセージ情報は、テキスト形式で届きます。これは、純粋なテキストとして通常の方法(例：GET_MESSAGE)でRDMLファンクションに表示およびアクセスすることができます。サーバーから送付されたメッセージについては、メッセージIDおよびメッセージ・ファイル名などの詳細はわかりません。アプリケーション・メッセージ待ち行列から特定のメッセージIDを読み取るようなクライアント・アプリケーションを設計すべきではありません。

エラー処理に関する注意事項

複雑なエラー処理スキームをご使用のアプリケーションに組み込むことは避けるよう、強くお勧めします。アプリケーションのすべてのレベルで、以下のようなごく単純なトラップを使用するようにしてください。

if (#retcode *ne OK) 

    abort msgtxt('Failed to .............................') 

endif

標準的なエラー処理を行う組み込み関数を生成されるアプリケーションに組み入れて、問題に対処するようにしてください。ユーザー定義のエラー処理ロジックが非常に複雑になったために全RDMLコードの40から50%を占有するようなケースもあります(アプリケーションには何のメリットもありません)。このような事態に陥らないようにしてください。