9.33 DEFINE_OTHER_SERVER

LANSA

9.33 DEFINE_OTHER_SERVER


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

現在のRDMLファンクションに対するサーバーとして使用される非IBM i (他の)システムの詳細を定義します。

定義の詳細は、永続的なものではなく、LANSA環境がアクティブな間だけ存続します。サーバーを定義するのにかかる時間は、ほんのわずかです。

このBIFを使用するには、x_runパラメータCDLLをLCOMGR32.DLLに、x_runパラメータCMTHをCかTにそれぞれ設定する必要が あります。

各製品の対応

LANSA/AD

未 対応

Visual LANSA for Windows

使 用可

Visual LANSA for Linux

未 対応

 

引数

番号

タイプ

必須/任意

記述

最小長

最大長

最小小数桁数

最大小数桁数

1

A

必 須

SSN (サーバーの別名)。これは、今後のこのサーバーへのすべての参照でこのファンクションおよび他のRDMLファンクションが使用する名前です。

1

10

 

 

2

A

必 須

サー バー・ネットワーク名

1

20

 

 

3

A

任 意

LOCK_OBJECT 要求をこのサーバーに転送します。このオプションを使用する場合は、後続するすべてのLOCK_OBJECT要求がこのサーバーに転送されます。複数の サーバーが共にこのオプションを使用可能に設定している場合、各サーバーとも同じLOCK_OBJECT要求を受け取ります。

こ のような場合は、LOCK_OBJECTを実行するすべてのサーバーが正常に処理を完了するためには、サーバーにロックが許可されている必要があります。 1つのサーバーでロックの許可に失敗すると、すでにオブジェクトのロックが許可されているすべてのサーバーに対してUNLOCK_OBJECT要求が発行 されます。

Y または1:LOCK_OBJECT要求を転送する

Z: ロック要求を経路指定し、その上で権限要求を経路指定する

R: ロック要求、権限要求、リポジトリ・データ要求(ローカルで検出されない場合)を経路指定します。X_RUNパラ メータについては、「X_RUNコマンドの使 用」を参照してください。

そ の他:要求を転送しない

デ フォルトはNです。

1

1

 

 

4

A

任 意

接 続待ちの間に「しばらくお待ちください」というメッセージを表示します。

Y または1:上記メッセージを表示する

そ の他:メッセージを表示しない

デ フォルトはYです。

1

1

 

 

5

A

任 意

X_RUN 例外引数

1

256

 

 

6

A

任 意

サー バー依存例外引数。現在は実装されていません。

こ の引数を使用しないでください。

1

256

 

 

7

A

任 意

将 来の拡張のために予約されています。現在は実装されていません。

こ の引数を使用しないでください。

1

256

 

 

8

A

任 意

将 来の拡張のために予約されています。現在は実装されていません。

こ の引数を使用しないでください。

1

256

 

 

 

戻り値

番号

タイプ

必須/任意

記述

最小長

最大長

最小小数桁数

最大小数桁数

1

A

必 須

戻 りコード

OK: サーバーが定義された

ER: サーバーが未定義でエラー・メッセージが発行される

2

2

 

 

 

技術上の注記

·         こ の組み込み関数の呼び出しで指定するサーバー・ネットワーク名は、サーバーがLANSAコミュニケーション管理機能で登録されたか登録予定のパートナーLU名と 一致している必要があります。

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

·         SSN 値は、メッセージにしばしば表示される場合があるため、エンド・ユーザーにとって意味のある名前にすることをお勧めします(CHICAGO、 BOSTON、CHARLIE1など)。

·         SSN 名は、英語のアルファベット(大文字のAからZまで)で始まる固有の名前である必要があります。

·         サー バーが接続されていない時は、繰り返し(再)定義することができます。現在接続されているサーバーを(再)定義しようとすると、致命的なエラーが発生しま す。

·         X_RUN 例外引数を使用して、サー バー・システム上で開始しているX_RUNコマンドのパラメータ をオー バーライドすることができます。

デフォルトでは、サーバー・システム上で開始しているX_RUNコマンドに、以下のクライアントX_RUNパラメータが渡されます(このコマンドから継承 されます)。CMTH=、CDLL=、DATF=、DATS=、DBCF=、DBCL=、DBLK=、DBTC=、DBUS=、DEVE=、FXQF=、 FXQM=、HSKC=、INIT=、ITHP=、ITRC=、ITRL=、ITRM=、ITRO=、LANG=、PART=、PRTR=、PSPW=、 PSTC=、PSWD=、TASK=、TERM=、USER=、XAFP=、およびXCMD。以下のクライアントX_RUNパラメータ値は、クライアント とサーバーが同じオペレーティング・システムを使用する場合にのみこれらから継承されます。DBID=、DBII=、DBIT=、DBUT=、ODBI =、およびWPEN (および関連するWindows印刷拡張パ ラメータ)。

サーバー・システム上のその他すべてのX_RUNパラメータ値は、通常の方法(プロフィール・ファイルから、システム環境設定からなど)でデフォルトが指 定されます(サー バー・システム上で)。X_RUNコマンドに関する説明を参照し て、すべてのパラメータの詳細およびその設定方法またはデフォルトの指定方法について確認してください。

·         CDLL =、CMTH=、DATF=、DATS=、DBUG=、DEVE=、LANG=、MODE=、PART=、PROC=、PSPW=、USER=、および XAFP=以 外のサーバーX_RUNパラメータは、(X_RUN例外引数値を 使用して)すべてオーバーライドすることができます。これらのX_RUN引数は、無 条件にク ライアント・システムから継承されます。ただし、一部のパラメータは、CONNECT_SERVERを呼び出す前にSET_SESSION_VALUEを 呼び出すことにより変更できます。

パラメータのオーバーライドにより、特定の値または特殊な値*SERVERが指定される場合があります。*SERVERは、デフォルトのサーバーを使用す る必要があることを示す値です。例えば、DBII=*NONEを使用するWindowsクライアントは、Oracleを実行するWindows Serverに接続する場合があります。デフォルトでは、Windowsはデータベース・タイプMSSQLS (SQL Server)を使用するため、DBUTをオーバーライドする必要があります。X_RUN例外引数値には、DBUT=ODBCORACLEかDBUT= *SERVERのいずれかを設定することができます。

·         こ の組み込み関数を使用して定義された詳細は、永続的なものではありません。X_RUNコマンドが終了すると消滅します。ユーザー独自のSQLベースのテー ブルを定義して、サーバー詳細を保持したり、テーブルを実際に読み込んでこの組み込み関数に渡される値を取得することができます。

·         こ れらの機能で十分に経験を積んでから、組織で使用する特定のサーバー・アーキテクチャを設計するようにしてください。サーバー・アーキテクチャは、以下の ような特徴が必要です。

·         組 織の要件を満たしている

·         手 早く容易に変更できる

·         拡 張可能である

    大規模な設計あるいは開発プロジェクトに着手する前に、これを実行し てください。

·         ク ライアントの日付形式は自動的にサーバーに渡されます。日付形式同士が異なる場合(MDYとDMYなど)、サーバーはクライアントの形式で自動的にデータ を戻します。

クライアントの日付形式は、x_runパラメータのDATF=を指定するとデフォルトから変更することができます。このパラメータの詳細については、 『Deploying Client and Server Applications』の標準のX_RUNパラメータを参照してください。

クライアントとサーバーで日付形式が異なる場合、正確な形式(DDMMYY)を指定する日付形式の妥当性検査は失敗します(戻されるデータはMMDDYY の形式になる場合があります)。クライアントが別の日付形式を使用する必要がある地域(米国および英国のクライアントなど)では、SYSFMTの日付形式 を使用されることをお勧めします。

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

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

if (#retcode *ne OK)

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

endif

 

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