9.32 DEFINE_OS_400_SERVER

LANSA

9.32 DEFINE_OS_400_SERVER


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

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

定義の詳細は、永続的なものではなく、LANSA環境がアクティブな間だけ存続します。

サーバーを定義するのにかかる時間は、ほんのわずかです。

RDMLXファイルに対して実行するI/Oコマンドで、BIFであるDEFINE_ANY_SERVERを使用する必要があります。それ以外の場合は、 サーバーでRDMLXファンクションを呼び出してください。

各製品の対応

LANSA/AD

未 対応

Visual LANSA for Windows

使 用可

Visual LANSA for Linux

未 対応

 

引数

番号

タイプ

必須/任意

記述

最小長

最大長

最小小数桁数

最大小数桁数

1

A

必 須

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

1

10

 

 

2

A

必 須

LU パートナー名

1

20

 

 

3

A

必 須

サー バー上でコミットメント制御を開始します。このサーバーの接続が完了すると、クライアントからRDMLレベルのCOMMITまたはROLLBACKコマン ドが発行されるたびに、"commit"または"rollback"要求を受け取ります。

Y または1:コミットメント制御を使用

そ の他:コミットメント制御を使用しない

1

1

 

 

4

A

任 意

サー バーがDBCSを使用可能かどうか指定

Y または1:DBCSを使用可能

そ の他:DBCSが使用できないサーバー

デ フォルトはNです。

1

1

 

 

5

A

任 意

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

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

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

Z: LOCK_OBJECT要求を転送し、このサーバーに権限検査要求も転送する(権限検査要求を転送する対象としては、1つのサーバーのみ指定してくださ い)

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

そ の他 - LOCK_OBJECT要求を転送しない

デ フォルトはNです。

1

1

 

 

6

A

任 意

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

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

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

デ フォルトはYです。

1

1

 

 

7

A

任 意

IBM i実行の優先順位。デフォルトは20です。他の値は、IBM iのCHGJOBコマンドのRUNPTYパラメータに指定してください。指定された値を変更する権限がユーザーに許可されている必要があります。

1

2

 

 

8

A

任 意

ク ライアントからサーバーへの変換テーブル名。ライブラリ名を指定することはできません。デフォルトでANSEBC1140に設定されます。

1

10

 

 

9

A

任 意

サー バーからへクライアントの変換テーブル名。ライブラリ名を指定することはできません。デフォルトでEBC1140ANSに設定されます。

1

10

 

 

 

戻り値

番号

タイプ

必須/任意

記述

最小長

最大長

最小小数桁数

最大小数桁数

1

A

必 須

戻 りコード

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

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

2

2

 

 

 

技術上の注記

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

·         LU パートナー名は、以下のいずれかである必要があります。

·         コ ミュニケーション・ルーターにすでに定義されている完全に修飾されたパートナーLU(論理ユニット)名

これは、通常「ネットワーク名.制御ポイント名」という形式で、「ローカル・ネットワークID」および「ローカル制御ポイント名」のIBM i DSPNETA値と一致しています。

一般に、5250エミュレーション・セッションを実行することができるコミュニケーション・ルーターであれば、これらの詳細がすでに使用可能な状態に構成 されています。
例:APPN.SYDASD25

·         ま たは、LU名としてalias名(別名)を使用している場合は、完全に修飾されたLU名の代わりにそれを使用することができます。
例:5250PLU

·         指 定された変換テーブルは、接続中に実際にIBM iサーバーからアップロードされます。初期の接続フェーズでは、指定したテーブルがアップロードされない場合、デフォルトの変換テーブルによって初期の接 続詳細を変換する必要があります。
初期の接続詳細(サーバーに送信される)には、以下のものがあります。

·         シ ステム区画

·         言 語コード

·         タ スク識別子

·         ク ライアントからサーバーへの変換テーブル名

·         サー バーからクライアントへの変換テーブル名

上記にリストしたオブジェクトの名前には、潜在的な問題を回避するために、AからZのアルファベットと0から9までの数字のみを使用するようにしてくださ い。

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

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

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

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

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

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

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

·         拡 張可能である

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

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

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

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

コミット制御に関す る注意事項

·         「コ ミット制御の開始」をYにした場合、LANSAは自動的にコミット制御の開始および終了を実行します。詳細については、『LANSA/AD ユーザーガイド』「ユー ザー 出口 F@BGNCMT - コミット制御の開始」および「ユー ザー 出口 F@ENDCMT - コミット制御の終了」を参照してくださ い。

·         サー バーがコミットメント制御を使用するよう指定されると、それ以降のすべてのCOMMITおよびROLLBACKコマンドで適用されます。

COMMITおよびROLLBACKコマンドが発行されると、現在接続中のすべてのサーバーに対して関連するルーチンがループします。

コミットメント制御がアクティブなサーバーに対しては、"commit"または"rollback"要求を発行し、サーバーからの応答を待機してから続行 します。

これは、ローカル/クライアントのデータベース・マネジメント・システムに対してcommit/rollbackが正しく発行された後で実行されます。

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

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

if (#retcode *ne OK)

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

endif

 

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

DBCSに関する考慮事項

サーバーがDBCS使用可能に指定されている場合は、クライアントのPC上に追加の変換テーブルが必要となります。

このテーブルは、X_CT<language code>.DATという名前で、X_LANSA\EXECUTEディレクトリに配置する必要があります。

<language code>の部分が"JPN"(日本語)のX_CTJPN.DATという名前のテーブルは、日本語を使用するユーザー用のものです。

この変換ファイルの使用では、以下の点に注意してください。

·         こ のテーブルは、ユーザーが変更できるように「現状のまま」の状態で出荷されます。警告は、明示的にも暗黙的にも示されません。このテーブルの保守および検 証は、各ユーザーの責任で行う必要があります。

·         こ のテーブルは、サーバーがDBCS使用可能に指定されている場合、Visual LANSAのDEFINE_OS_400_SERVERファンクションによってロードされます。

·         ロー ドされたテーブルの名前は、"x_ct"と現在の言語コード(jpnなど)に接尾辞".dat"が組み合わされたものになります。したがって、言語コード jpnを使用する場合のテーブル名は、"x_ctjpn.dat"となります。言語コードがtchiの場合は、テーブル名は"x_cttchi.dat" です。

·         こ のテーブルは、<drive>:\x_lansa\executeディレクトリにある必要があり、< drive>は、Visual LANSAがインストールされているローカルまたはサーバーのディスク・ドライブです。

·         こ の変換テーブルは、文字列のダブル・バイトの部分に対してのみ使用されます。文字列のシングル・バイトの部分(DBCSのサポートの有無に関わらず)は、 常に、DEFINE_OS_400_SERVERファンクション呼び出しで指定されたI5/OSのシングル・バイト変換テーブルを使用して変換されます。

·          これは、ダブル・バイトとシングル・バイトが混在するフィールドは、ある部分はこのテーブルによって、別の部分は(DBCSと非DBCSの両方の変換に使 用される)シングル・バイトの変換テーブルによって変換されることを意味します。

·         フィー ルドがDBCS使用可能に指定されている(例:ディクショナリ・キーボード属性がj、e、oなど)の場合、および、 DEFINE_OS_400_SERVER組み込み関数でサーバーがDBCS使用可能と指定されている場合にのみ、個々のフィールド内のデータのDBCS 変換が実行されます。これらの条件が両方とも当てはまらない場合は、前述のシングル・バイト変換テーブルによって、フィールド全体がシングル・バイト文字 列に変換されます。

·         1 列目(先頭)に*がある行はコメント行であることを示します。

·         す べての値は、16進数のフォーマットで指定されます。

·         区 切り文字に使用できるのは、シングル・カンマ(,)のみです。