CONNECT (タイプ 2)

CONNECT (タイプ 2) ステートメントは、アプリケーション指向分散作業単位の規則を使用して、アプリケーション・プロセス内の活動化グループを識別されたアプリケーション・サーバーに接続します。次に、このサーバーはその活動化グループの現行サーバーになります。 このタイプの CONNECT ステートメントは、CRTSQLxxx コマンドに RDBCNNMTH(*DUW) の指定があった場合に使用します。

これら 2 つのタイプのステートメントの相違点については、CONNECT (タイプ 1) と CONNECT (タイプ 2) の相違点を参照してください。 接続状態の詳細については、アプリケーション指向の分散作業単位を参照してください。

呼び出し

このステートメントは、アプリケーション・プログラムに組み込むか、または対話式に呼び出すことができます。 これは実行可能ステートメントですが、動的に準備することはできません。Java™ または REXX では指定できません。

CONNECT は、トリガーおよび関数で使用できません。

権限

このステートメントの権限 ID によって保持される特権には、通信レベルのセキュリティーが含まれていなければなりません。 (「分散データベース・プログラミング」トピック集のセキュリティーに関するセクションを参照してください。)

アプリケーション・サーバーが Db2® for i である場合は、次の場合に該当しない限り、ステートメントの発行者のプロファイル ID をアプリケーション・サーバー・システム上でも有効なユーザー・プロファイルにする必要があります。

  • USER が指定されている。 USER が指定されている場合は、USER 文節で、アプリケーション・サーバー・システム上の有効なユーザー・プロファイルを指定する必要があります。
  • TCP/IP が、アプリケーション・サーバーのサーバー権限記入項目で使用されている。 この場合は、サーバー権限記入項目で、アプリケーション・サーバー・シス テム上の有効なユーザー・プロファイルを指定する必要があります。

ステートメントでグローバル変数を参照する場合は、ステートメントの権限 ID が保持する特権に、少なくとも次のいずれか 1 つが含まれなければなりません。

  • ステートメント内で識別されるグローバル変数に対して、
    • そのグローバル変数に対する READ 特権
    • グローバル変数が含まれるスキーマに対する USAGE 特権
  • データベース管理者権限

構文

構文図を読む構文図をスキップする
>>-CONNECT--+----------------------------------------+---------><
            +-TO--+-server-name-+--+---------------+-+   
            |     '-variable----'  '-authorization-' |   
            '-RESET----------------------------------'   

authorization

|--USER--+-authorization-name-+--USING--+-password-+------------|
         '-variable-----------'         '-variable-'   

説明

TO server-name または variable
指定したサーバー名、または指定した変数に入っているサーバー名によってアプリケーション・サーバーを識別します。スキーマ名で修飾すれば、グローバル変数を使用することもできます。変数を指定する場合、
  • CHAR または VARCHAR ホスト変数でなければなりません。
  • 標識変数を伴っていてはなりません。
  • サーバー名は、その変数内で左寄せし、通常 ID の形成の規則に従っていなければなりません。
  • サーバー名の長さが、変数の長さよりも短い場合、右側をブランクで埋めなければなりません。
  • サーバー名の値には小文字を含めてはなりません。

この CONNECT ステートメントが実行される場合、指定したサーバー名または変数に入っているサーバー名は、ローカル・ディレクトリーに記述されているアプリケーション・サーバーを識別する必要があります。

以下の説明で S は、指定したサーバー名または変数に入っているサーバー名を表しています。 S は、該当のアプリケーション・プロセスの既存の接続を識別していてはなりません。

USER authorization-name または variable
アプリケーション・サーバーへの接続に使用される権限名を識別します。 スキーマ名で修飾すれば、グローバル変数を使用することもできます。

変数 を指定する場合、

  • CHAR または VARCHAR ホスト変数でなければなりません。
  • 標識変数を伴っていてはなりません。権限名は、その変数に左寄せして入れ、権限名の命名規則に従っていなければなりません。
  • 権限名の長さが、変数の長さよりも短い場合には、右側をブランクで埋めなければなりません。
USING password または variable
アプリケーション・サーバーへの接続に使用されるパスワードを識別します。

パスワードをリテラルとして指定する場合、そのリテラルは文字ストリングでなければなりません。最大長は 128 文字です。左寄せしなければなりません。 リテラル形式のパスワードは、静的 SQL または REXX では許可されていません。

変数 を指定する場合、

  • この変数は、グローバル変数にすることはできません。
  • CHAR または VARCHAR ホスト変数でなければなりません。
  • 標識変数を伴っていてはなりません。
  • パスワードは、変数に左寄せして入れなければなりません。
  • パスワードの長さが変数の長さよりも短い場合には、右側をブランクで埋めなければなりません。
RESET
CONNECT RESET は、CONNECT TO x と同等です。ここで、x はローカル・サーバー名です。
CONNECT (オペランドの指定なし)
この形式の CONNECT ステートメントは、現行サーバーについての情報を戻し、 接続状態、オープン・カーソル、準備されたステートメント、またはロックに対してまったく影響を与えません。 接続情報は、SQL 診断域 (または SQLCA) にある接続情報項目に戻されます。

さらに、SQL 診断域にある DB2_CONNECTION_STATUS 接続情報項目 (または SQLCA のフィールド SQLERRD(3)) には、 該当の作業単位の接続の状況を示す値が入れられます。次の値のいずれかが入れられます。

  • 1 - この作業単位の接続では、コミット可能な更新を行うことができる。
  • 2 - この作業単位の接続では、コミット可能な更新を行うことはできない。

接続成功: CONNECT ステートメントが正常に完了した場合 :

  • アプリケーション・サーバー S への接続が作成され、現行および保留状態に置かれます。それ以前の接続は (存在する場合)、休止状態になります。
  • S が特殊レジスター CURRENT SERVER に入れられます。
  • アプリケーション・サーバーについての情報は、 SQL 診断領域の接続情報項目 に入れられます。
  • アプリケーション・サーバー S に関する情報も、SQLCA のフィールド SQLERRP および SQLERRD(4) に入れられます。そのアプリケーション・サーバーが IBM® リレーショナル・データベース・プロダクトである場合は、 フィールド SQLERRP の中の情報は、pppvvrrm の形式をとります。ただし、
    • ppp は、製品を次のように識別します。
      • ARI (Db2 UDB サーバー (VM および VSE 版) の場合)
      • DSN (Db2 for z/OS® の場合)
      • QSQ (Db2 for i の場合)
      • 他のすべての Db2 プロダクトの場合は SQL
    • vv は、2 桁のバージョン ID です (例えば、'09' など)。
    • rr は、2 桁のリリース ID です (例えば、'01' など)。
    • m は、「0」のような 1 文字の修正レベルを示します。

    例えば、アプリケーション・サーバーがバージョン 9 の Db2 for z/OS の場合は、SQLERRP の値は「DSN09010」になります。

    SQLCA の SQLERRD(4) フィールドには、アプリケーション・サーバー S がコミット可能な更新の実行を許可するかどうかを示す値が入ります。以下は、この CONNECT に関して SQLCA のフィールド SQLERRD(4) に入れられる値とその意味を示しています。
    • 1 - コミット可能な更新を行うことができる。会話は、無保護会話です。1
    • 2 - コミット可能な更新は行うことができない。会話は、無保護会話です。
    • 3 - コミット可能な更新を行うことができるか否かは不明である。会話は、保護会話です。
    • 4 - コミット可能な更新を行うことができるか否かは不明である。会話は、無保護会話です。
    • 5 - コミット可能な更新を行うことができるか否かは不明である。接続は、ローカル接続、またはアプリケーション・リクエスターのドライバー・プログラムとの接続です。
  • 接続についての追加情報は SQLCA のフィールド SQLERRMC に入れられます。SQLCA (SQL 連絡域)を参照してください。

接続失敗: CONNECT ステートメントが正常に実行 されなかった場合は、その活動化グループの接続状態、およびその 接続の状態は変わりません。

暗黙接続: 暗黙接続では、常に アプリケーション・リクエスター・ジョブの権限名 が送信 され、パスワードは送信されません。 アプリケーション・サーバー・ジョブの権限名 が異なる場合や、パスワードを送る必要がある場合は、明示的な接続ステートメントを使用する必要があります。

TCP/IP を RDB との接続に使用している場合、暗黙の接続は上記の制約に拘束されることはありません。 ADDSVRAUTE コマンドと他の -SVRAUTE コマンドを使用すると、暗黙 (または明示) の CONNECT の実行元である所定のユーザーに対して、該当の RDB との接続で使用されるリモート権限名とパスワードを指定することが可能になります。

パスワードが ADDSVRAUTE コマンドや CHGSVRAUTE コマンドで保管されるようにするには、QRETSVRSEC システム値をデフォルト値の '0' ではなく、'1' に設定する必要があります。これらのコマンドを DRDA 接続に使用している場合に非常に重要なことは、SERVER パラメーターに RDB 名の値を英大文字で入力しなければならないと認識しておくことです。 詳細については、タイプ 2 の CONNECT の節の例 2 を参照してください。

暗黙的な接続について詳しくは、「SQL プログラミング」を参照してください。ユーザー・プロファイルとリレーショナル・データベースとの接続が一度確立されると、同じユーザー・プロファイルと同じリレーショナル・データベースとの以後の接続では、パスワード (指定がある場合) の妥当性が再検証されない場合があります。パスワードの妥当性の再検証は、会話がまだ活動状態であるかどうかによって異なります。 詳しくは、「分散データベース・プログラミング」を参照してください。

SET SESSION AUTHORIZATION: SET SESSION AUTHORIZATION ステートメントがスレッド内で実行された場合、接続ステートメントより前に SYSTEM_USER 値が SESSION_USER と同じでなければ、ローカル・サーバーへの CONNECT は失敗します。

これには、ACTGRP(*NEW) を指定するプログラムを呼び出すことによる暗黙的な接続が含まれます。

例 1: SQL ステートメントを TOROLAB および SVLLAB で実行します。 最初の CONNECT ステートメントは TOROLAB との接続を確立し、2 番目の CONNECT ステートメントはその接続を休止状態にします。

  EXEC SQL  CONNECT TO TOROLAB;

    (TOROLAB にあるオブジェクトを参照するステートメントを実行)

  EXEC SQL  CONNECT TO SVLLAB;

    (SVLLAB にあるオブジェクトを参照するステートメントを実行)

例 2: リモート・サーバーに接続してユーザー ID およびパスワードを指定し、 そのユーザーとして作業を行ってから、今度は別のユーザーとして接続し、さらに作業を行います。

  EXEC SQL  CONNECT TO SVLLAB USER :AUTHID USING :PASSWORD;

    (サーバー上のデータにアクセスする SQL ステートメントを実行)

  EXEC SQL COMMIT;

    (AUTHID および PASSWORD を新規の値に設定する)

  EXEC SQL  CONNECT TO SVLLAB USER :AUTHID USING :PASSWORD;

    (サーバー上のデータにアクセスする SQL ステートメントを実行) 

例 3: ユーザー JOE は、パスワードが SHIBBOLETH のユーザー ID ANONYMOUS によって TOROLAB3 に接続し、SQL ステートメントを実行したいとします。 TOROLAB3 の RDB ディレクトリー項目では、その接続タイプに *IP を指定します。

アプリケーションを実行する前に、ある種のセットアップを行う必要があります。

IBM i オペレーティング・システムでサーバーのセキュリティー情報を保存できるようにするために、以下のコマンドをまだ実行していなければ、まずこのコマンドを実行する必要があります。

   CHGSYSVAL SYSVAL(QRETSVRSEC) VALUE('1')

このコマンドによって、必須のサーバー権限項目が追加されます。

   ADDSVRAUTE USRPRF(JOE) SERVER(TOROLAB3) USRID(ANONYMOUS) +
              PASSWORD(SHIBBOLETH)

JOE のユーザー・プロファイルのもとで実行されるこのステートメントは、この時点で、必要な接続を確立します。

   EXEC SQL CONNECT TO TOROLAB3;
   (TOROLAB3 にあるオブジェクトを参照するステートメントを実行)