9.27 CONNECT_SERVER
注意： 9.1 組み込み関数の規則 利用オプション
実行するファンクションをファイルをサーバーに接続します。この接続は、組み込み関数DISCONNECT_SERVERを使用するか、Visual LANSA環境を終了させるなどの明らかな停止処理が取られるまで有効です。
サーバーとして、DEFINE_OS_400_SERVER、DEFINE_ANY_SERVER、DEFINE_OTHER_SERVER、 DEFINE_DB_SERVERのいずれかのBIFで定義されたSSNを指定することができます。このSSNは、ローカル・データベース・サーバーを参照する特殊なSSN *LOCALDBにすることも可能です。詳細については、「14.2.1 データベース接続」を参照してください。
接続が確立されるまでには、多少の時間を要します。
アプリケーションを設計する際は、複数の接続/接続切断を使用するのではなく、シングル・エントリー・ポイント接続が要求されるような設計にするべきです。
すでに接続中のサーバーに対する接続要求は無視されます。エラーにはなりません。
引数
番号 | タイプ | 必須/任意 | 記述 | 最小長 | 最大長 | 最小小数桁数 | 最大小数桁数 |
|---|---|---|---|---|---|---|---|
1 | A | 必須 | 定義されているサーバーのSSN | 1 | 10 | ||
2 | A | 任意 | サーバー接続用のパスワード。この値はファンクション呼び出し中にのみ存在し、保管されることはありません。 この値を指定しないと、アプリケーション・サーバー接続では、デフォルトのパスワードにx_runパラメータのPSPW= の値を使用します。 この値を指定しない場合、接続パラメータで定義されたパスワードを使用するデータベース・サーバー接続により、DEFINE_DB_SERVERが上書きされます。9.37 DEFINE_DB_SERVER の例に示すように、ODBCプロンプトでパスワードを要求する設定が可能です。 | 1 | 256 | ||
3 | A | 任意 | この値が 'Y' の場合、パスワード値が無視され、Windowsアプリケーションを実行している権限が、サーバーでのケルベロス・プロトコルによる認証に使用されます。 この値が'N'の場合は、認証にパスワード引数が使用されます。 この値を指定しない場合は、PSTCパラメータの現行の設定がデフォルト値になります。「PSXX=パラメータ」を参照してください。 | 1 | 1 | ||
4 | A | 任意 | サーバーへの接続に使用するユーザー名。この値はファンクション呼び出し中にのみ存在し、保管されることはありません。 この値を指定しない場合、アプリケーション・サーバーの接続では、デフォルトのユーザー名として、X_RUNパラメータのUSER=の値が使用されます。 この値は、データベース・サーバー接続では無視されます。 | 1 | 256 | ||
5 | A | 任意 | サーバー・エラーをハンドル この値が 'Y' の場合、クライアントの X_Run セッションはサーバーからエラーが戻ってきてもアボートしません。その代わり戻りコードに "FE" がセットされ、サーバーのエラーメッセージはメッセージキューに格納されます。 この値が'N'の場合、サーバーからエラーが戻ってくるとクライアントの X_Run セッションがアボートします。 省略値は 'N' です。 | 1 | 1 |
戻り値
番号 | タイプ | 必須/任意 | 記述 | 最小長 | 最大長 | 最小小数桁数 | 最大小数桁数 |
|---|---|---|---|---|---|---|---|
1 | A | 必須 | 戻りコード OK：接続が確立された | 2 | 2 | ||
2 | A | 任意 | サーバー・タイプ SuperServer の場合、以下のいずれかになります。 データーベース・サーバーの場合、以下のいずれかになります。 注：タイプが判別できない場合は、サーバー・タイプはUNKNOWNとして戻されます。 | 3 | 15 | ||
3 | N | 任意 | 接続エラー・コード 戻りコードがOKまたはLANSAがエラー・コードを判定できない場合はゼロ SuperServer の場合はコミュニケーション・エラー・コードになります。最も一般的なエラー・コードは、次のとおりです。 6：ログオンできなかった データベース・サーバーの場合は、ネイティブのデータベース・エラー、ODBC/CLI API戻りコード、または内部LANSAエラーを示す-9999になることがあります。 | 10 | 10 | 0 | 0 |
技術上の注記
- すべての「接続」のロジックは、多数のRDMLファンクションに分散させるのではなく、1つのファンクションだけにコーディングすることを強くお勧めします。このようにすることで、将来サーバーに対して加えられる変更からアプリケーションを保護することができます。
- この組み込み関数は、デフォルトでは、クライアントのシステム上で現在使用されているシステム区画と同じ識別子を持つサーバー・システム上のシステム区画への接続を実行します。異なる識別子を持つシステム区画への接続方法については、組み込み関数SET_SESSION_VALUEの CONNECT_PARTITIONオプションを参照してください。
- IBM iサーバーに対してケルベロス認証を使用する場合、Windowsドメイン・ユーザー(そのユーザーの権限でアプリケーションを実行)のケルベロス・プリンシパル名をLANSAユーザーに関連付ける必要があります。この関連付けは、IBM i Enterprise Identity Mapping (EIM) 機能を使用して行います。
技術上の注記 (IBM i の場合)
Kerberos は、このために直接サーバーの構成をする必要がなく、SQL サーバーやファイル共有などのサーバー以外のものにアクセスもすることなく、作動します。
サーバー以外のものにアクセスする必要がある、いわゆるマルチホップの場合は、以下の状態がサポートされます。
- コンピュータ全体を *すべての* サービスに信頼を委任します。- これはテスト済で、作動することが確認されています。
- 特定のドメイン・ユーザーを *すべての* サービスに信頼を委任します。- これはテスト済で、作動することが確認されています。(このためには、特定のユーザーで実行できるよう、リスナーが適切に設定されている必要があります。まず最初に lcoecho を使って検証してください。)
上記の構成のいずれかが可能でない環境の場合は、マルチホップは使用できません。
技術上の注記 (IBM i の場合)
- 同時に複数の異なるIBM iサーバーに接続することができます。
- 同じIBM iサーバーに何度でも接続することができます(異なるSSN名を使用します)。
- データベース・サーバー接続のセットアップは、通常、通信サーバーに比べると、より簡潔にできます。通信サーバーへの「初回」の接続が、最も困難です。初回の接続では、複雑で多くの場合に意味不明な(『Host Integration Server 2000 Error Major/Minor error codebook』を参照しない限り)エラー・メッセージ番号が次々と表示され、フラストレーションが募ります。
- ワークステーション・クライアントとIBM iサーバー間の通信の構成や保守については本書の範囲外ですが、以下のヒントや手法が問題の原因を突き止めるのに役立つかもしれません。 現在使用中のユーザー・プロファイルについて、以下の点を確認します。
- IBM i に定義されているか
- 必要なLANSAの区画に対する権限があるか
- 長さは10文字以下であるか
- 関連するジョブ記述を持ち、その初期ライブラリ・リストにLANSAのプログラム・ライブラリ (通常は DCXPGMLIB) およびライブラリ DCXCOMLIB が含まれているか
- 問題解決を試みる場合は、そのジョブ記述のログ・レベルがLOG(4 00 *SECLVL)に設定されているかどうか。このように設定することで、プロファイルが開始するIBM i のジョブにより、IBM i ジョブ・ログを作成できます。ジョブ・ログによって、ほとんどの場合に有益なエラー情報が提供されます。
- ADDDIRE コマンドおよびADDOFCENRコマンドを通じてOffice Servicesに登録します。
- ダム端末にサインオンし、その直後にLANSA PARTITION(xxx)コマンドを入力してIBM i ユーザー・プロファイルを検証してください。思いがけない事態になりましたか? 通信リンクを通じてユーザー・プロファイルのテストを行う前に、明らかになったエラーまたは使用権限の問題の原因を取り除いてください。
- IBM i コマンドのWRKSBSJOB QCMNを使用して、サブシステムQCMNにアクティブなジョブを表示してください。F5のリフレッシュを繰り返し使用して、通信ジョブが開始されるように、リストをリフレッシュしてください。 サブシステムQCMNがアクティブになっていますか?
いいえ：
サブシステムを開始し、操作をやり直してください。
はい：
サブシステムQCMNにIBM i の「サーバー」ジョブが表示されていますか?
表示されている場合：
直ちに「5=処理」を使用して、このジョブをトレースしてください。トレースが終了するまで待ち、ジョブ・ログ・ファイルにスプールされた結果を詳しくチェックしてください。ログが生成されていない場合は、問題の原因がトレースされるまで、使用中のユーザー・プロファイルに関連するジョブの記述をLOG (4 00 *SECLVL)に変更してください。
IBM iシステムに、"LXX"(LANSA SuperServer)ライセンスがインストールされていますか?また、それは最新ですか?LANSA REQUEST(LICENSE)コマンドを使用してチェックしてください。
表示されていない場合：
PC 上でコミュニケーション・マネージャ、PC Support、その他のコミュニケーション・ルーターが開始されていますか?
コミュニケーション・マネージャのメッセージの表示オプションに、エラー情報が表示されますか?
IBM i のDSPLOG(ログ表示)コマンドを実行すると、通信エラー情報が表示されますか?
エラー処理に関する注意事項
複雑なエラー処理スキームをご使用のアプリケーションに組み込むことは避けるよう、強くお勧めします。アプリケーションのすべてのレベルで、以下のようなごく単純なトラップを使用するようにしてください。
if (#retcode *ne OK)
abort msgtxt('Failed to .............................')
endif
標準的なエラー処理を行う組み込み関数を生成されるアプリケーションに組み入れて、問題に対処するようにしてください。ユーザー定義のエラー処理ロジックが非常に複雑になったために全RDMLコードの40から50%を占有するようなケースもあります(アプリケーションには何のメリットもありません)。このような事態に陥らないようにしてください。