9.39 DEFINE_OS_400_SERVER

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

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

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

引数

戻り値

技術上の注記

• サーバー定義ロジックは、多数のRDMLファンクションに分散させるのではなく、1つのファンクションにだけコーディングすることを強くお勧めします。このようにすることで、将来サーバーに対して加えられる変更からアプリケーションを保護することができます。
  
  
• LU パートナー名は、以下のいずれかである必要があります。
  • コミュニケーション・ルーターにすでに定義されている完全に修飾されたパートナーLU (論理ユニット) 名
    これは、通常「ネットワーク名.制御ポイント名」という形式で、「ローカル・ネットワークID」および「ローカル制御ポイント名」のIBM i DSPNETA値と一致しています。
    一般に、5250エミュレーション・セッションを実行することができるコミュニケーション・ルーターであれば、これらの詳細がすでに使用可能な状態に構成されています。 
    例：APPN.SYDASD25
  • または、LU名としてalias名 (別名) を使用している場合は、完全に修飾されたLU名の代わりにそれを使用することができます。 
    例：5250PLU
    
    
• 指定された変換テーブルは、接続中に実際にIBM iサーバーからアップロードされます。初期の接続フェーズでは、指定したテーブルがアップロードされない場合、デフォルトの変換テーブルによって初期の接続詳細を変換する必要があります。 初期の接続詳細(サーバーに送信される)には、以下のものがあります。
  • システム区画
  • 言語コード
  • タスク識別子
  • クライアントからサーバーへの変換テーブル名
  • サーバーからクライアントへの変換テーブル名

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

• SSN 値は、メッセージにしばしば表示される場合があるため、エンド・ユーザーにとって意味のある名前にすることをお勧めします(CHICAGO、BOSTONCHARLIE1など)。
  
  
• SSN 名は、英語のアルファベット(大文字のAからZまで)で始まる固有の名前である必要があります。
  
  
• サーバーが接続されていない時は、繰り返し(再)定義することができます。現在接続されているサーバーを(再)定義しようとすると、致命的なエラーが発生します。
  
  
• 定義された詳細は、永続的なものではありません。X_RUNコマンドが終了すると消滅します。ユーザー独自のSQLベースのテーブルを定義して、サーバー詳細を保持したり、テーブルを実際に読み込んでこの組み込み関数に渡される値を取得することができます。
  
  
• これらの機能で十分に経験を積んでから、組織で使用する特定のサーバー・アーキテクチャを設計するようにしてください。サーバー・アーキテクチャは、以下のような特徴が必要です。
  • 組織の要件を満たしている
  • 手早く容易に変更できる
  • 拡張可能である

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

• クライアントの日付形式は自動的にサーバーに渡されます。日付形式同士が異なる場合(MDYとDMYなど)、サーバーはクライアントの形式で自動的にデータを戻します。 
  クライアントの日付形式は、x_runパラメータのDATF= を指定するとデフォルトから変更することができます。このパラメータの詳細については、「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ファンクション呼び出しで指定されたIBM i のシングル・バイト変換テーブルを使用して変換されます。
• これは、ダブル・バイトとシングル・バイトが混在するフィールドは、ある部分はこのテーブルによって、別の部分は (DBCSと非DBCSの両方の変換に使用される) シングル・バイトの変換テーブルによって変換されることを意味します。
• フィールドがDBCS使用可能に指定されている (例：ディクショナリ・キーボード属性がj、e、oなど) の場合、および、DEFINE_OS_400_SERVER組み込み関数でサーバーがDBCS使用可能と指定されている場合にのみ、個々のフィールド内のデータのDBCS 変換が実行されます。これらの条件が両方とも当てはまらない場合は、前述のシングル・バイト変換テーブルによって、フィールド全体がシングル・バイト文字列に変換されます。
• 1列目 (先頭) に*がある行はコメント行であることを示します。
• すべての値は、16進数のフォーマットで指定されます。
• 区切り文字に使用できるのは、シングル・カンマ (,) のみです。