9.21 CONNECT_FILE

LANSA

previous page next page

9.21 CONNECT_FILE

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

指定された物理ファイル(およびそれに基づくビュー)に対する後続の全I/O要求をサーバーに再経路指定するようにLANSAを準備します。詳細については、「データベースの接続」を参照してください。

ファイル接続の確立は非常に高速で、時間はほとんどかかりません。経路指定テーブルを更新するだけで、サーバーとの通信はまったく行われません。

この接続は、組み込み関数DISCONNECT_FILEを使用するか、LANSA環境を終了させるなどの明らかな停止処理が取られるまで有効です。

アプリケーションを設計する際は、接続および切断ポイントを最小限にするような設計にすべきです。

複数のファイルを複数のサーバー・システムに同時に接続することは可能ですが、1つのファイルを複数のサーバーに同時に接続することはできません。

ここで言及する「ファイル」とは、基本となる物理ファイル(またはテーブル)とそれに基づくすべての論理ファイル(またはビュー)を指します。

すでに接続されているファイルに対する接続要求があると、選択ブロック・サイズと選択制限がリセットされることを除き、無視されます。エラーにはなりません。

以下の場合に接続要求を出すと、致命的なエラーが発生します。

·         現在、あるサーバーと接続しているファイルに対して、別のサーバーへの接続要求を出した場合

·         LANSAファイル(外部ファイルおよびSQLビューを除く)に対して接続要求を出した場合で、RRNパスの定義を必要とするデータベースについてのAUTO_RRNがこのファイルで設定されていない場合

各製品の対応

LANSA/AD

使用可

RDMLXでのみ使用可

Visual LANSA for Windows

使用可

 

Visual LANSA for Linux

使用可

 

 

引数

番号

タイプ

必須/任意

記述

最小長

最大長

最小小数桁数

最大小数桁数

1

A

必須

物理ファイル/テーブル名

この名前は大文字で指定する必要があります。

指定された名前に対する妥当性検査や、この名前が存在するかどうかの確認は行われません。

名前は総称名で指定することが可能です。総称名の区切り文字としては、'*'を使用してください。

1

10

 

 

2

A

必須

定義されているサーバーのSSN

1

10

 

 

3

N

任意

選択ブロック・サイズ。デフォルト = 50

注1：RETURN_RRNパラメータと一緒にSELECTループで使用されるファイルに対しては、ブロック・サイズ1を使用する必要があります。
これより大きいブロック・サイズを使用すると、RETURN_RRNの戻り値が予期できない値になります。

注2：SELECTループで使用され、WITH_KEYまたはWITH_RRNパラメータを持たないDELETEコマンドまたはUPDATEコマンド(最新の読み込んだレコードの更新または削除)によって変更されるファイルに対しては、ブロック・サイズ1を使用する必要があります。

注3：選択するフィールドのいずれかがBLOBまたはCLOBで、このためサーバーからクライアントにファイルを送信する必要がある場合、SELECTプロセスにブロック・サイズ1を使用したかのような振る舞いになります。

1

10

0

0

4

N

任意

選択制限値このオプションは、プログラムで選択ループを'n'行に制限するものではありません。この目的に使用しないでください。

暴走した(すなわち、制御不能の)SELECTループによる大量データの転送を阻止するよう設計されています。

選択制限値を超えると、致命的なアプリケーション・エラーが発生します。このエラー状況で返される行数は未確定です。

デフォルト = 10000

1

10

0

0

 

戻り値

戻り値はありません。

技術上の注記

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

·         どのような場合でも、この組み込み関数を使用して、LANSA/ADの内部データベース・ファイルDC@Fnnをアプリケーションに接続することはできません。この点については検査されませんが、ルールには従うようにしてください。

·         全面的に、LANSA SuperServer機能は、いかなる方法または形式においても複数メンバー・ファイルをサポートしていません。複数メンバー・ファイルにアクセスするサーバー・ファンクションを実行あるいは呼び出す方法を工夫することは不可能ではありませんが、その機能はサポートされていないこと、また、IBM iに100%依存していることを覚えておいてください。この機能からIBM iベースのI/Oモジュールが呼び出されると、現行のライブラリ・リスト(*LIBL)からI5/OSの論理的な最初のメンバーとして(通常は*FIRSTというシンボル名で)必要なファイル・メンバーが開きます。

クライアント・ベースのファンクション(ライブラリ*LIBL、メンバー*FIRSTを使用)とサーバー・ベースのファンクション(ライブラリおよび/またはメンバーに対するPOINTコマンドを使用)を同時に実行し、両方のファンクションが同じファイルにアクセスする場合は、メッセージIOM0033が発行され、関連するI/Oモジュールにエラーが発生します。これは、クライアントのファンクションのPOINTコマンドが存在するかどうかに関係なく発生します。すべてのVisual LANSA(クライアント)環境では、POINTコマンドは無視されます。

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

·         すでにあるサーバーに接続しているファイルに対して、同じサーバーへの接続要求を行ってもエラーにはなりません。接続しようとしたファイルがすでに接続中の場合は、選択ブロックと選択制限値が更新されます。この技法は、選択ブロック/制限値をダイナミックに変更する場合には使用できますが、I/O操作が保留中(SELECTループの実行中)の場合は除きます。

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

·         ファイルを総称名(LM*、GL*、*など)にする場合は、総称名が重複しないように十分注意してください。このルールが守られないと、予期しない結果を招きます。このルールでは、"*"(任意の名前)を使用してファイルを指定する際は、名前そのものが一致する場合のみ指定可能です。つまり、"*"の前後の名前による接続ファイルは重複することになります。

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

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

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

if (#retcode *ne OK) 

    abort msgtxt('失敗しました.............................')

endif

 

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

CONNECT_FILEブロック・サイズの使用

ブロック・サイズのパラメータのデフォルトの値は50です。これは、サーバーと接続するたび、アプリケーションの最後に50個ずつレコードがクライアント側に戻されるという意味です。データは、特定のファイルに存在する順序で処理され、デバッグによって50のレコードをループするコードが示されますが、サーバーからデータを取得する接続は1回しか行われません。

このため、相対レコード番号または最後に読み取られたレコードを使用することには危険が伴います。

以下のコードで考えてみましょう。

SELECT FIELDS(...) FROM_FILE(FILEA) RETURN_RRN(#RRN)

...

UPDATE FIELDS(...) IN_FILE(FILEA) WITH_RRN(#RRN)

ENDSELECT

 

これは、IBM iサーバーでは許容されているコードです。しかし、クライアント/サーバー環境では、選択後のRRN値は、50番目のレコードの相対レコード番号になります。サーバー上のOAMは読み取りを1回実行しているため、これが最新のRRNとして認識されて戻されます。

同じことが次のコードにも当てはまります。

SELECT FIELDS(...) FROM_FILE(FILEA) RETURN_RRN(#RRN)

...

UPDATE FIELDS(...) IN_FILE(FILEA)

ENDSELECT

 

OAMに関する限り、最新のレコードは50番目のレコードになります。試行されるすべてのUPDATEまたはDELETEは、読み取られたこの最新レコードに対して実行されます。

SELECTループで使用されるファイルに対するキーの更新は許可されていません。このため、ブロック・サイズを1に設定することがこの場合の唯一の解決法です。こうすると、データには1回に1つずつレコードが戻されるようになります。

この方法のマイナス面は、アプリケーションのパフォーマンスが著しく低下することです。現時点では、サーバー上の複数のレコードを更新する最も効率的な方法は、CALL_SERVER_FUNCTION組み込み関数を使用してサーバー上で更新コードを実行する方法であることに注意する必要があります。

複数の詳細レコードをオープンできるようにアプリケーションを保守する場合にも、同様の問題が発生します。例えば、Visual LANSAアプリケーションで社員のリストを表示する場合があります。ユーザーがリスト内のある項目をダブル・クリックすると、その保守フォームをオープンすることができます。このリストから社員番号を受け取り、FETCHを使用してデータを読み取ります。FETCHによってOAMはレコードを1つだけ読み取ります。変更を保存する前に、ユーザーは別の社員の詳細情報も同様にオープンします。最後に読み取られた値がサーバー上のOAMに格納され、OAMが関係する間は、この値が2番目の社員情報となります。

したがって、実行されたのがFETCHであっても、社員情報の保守はキーを指定して更新する必要があります。最後に読み取られたレコードを更新すると、このレコードは上書きされます。

previous page start next page