Oracle Transparent Gateway for IBM DRDA Installation and User's Guide
Release 9.0.1.0.1 for AIX-Based Systems (64-bit)

Part Number A90839-01
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

6
Configuring the DRDA Server

The steps for configuring your remote DRDA server cover the following DRDA servers:

Configuring a DRDA database to allow access by the gateway requires actions on the DRDA database and on certain components of the host operating system.  Although no Oracle software is installed on the host system, access to, and some knowledge of, the host system and DRDA database are required during the configuration.  Refer to the vendor documentation for complete information about your host system and DRDA database.

Checklists for Configuring the DRDA Server

Use the following checklists for configuring the DRDA server.

Checklist for the DB2/MVS

Step 1: Configure the Communications Server

Step 2: Define the user ID that owns the package

Step 3: Define the recovery user ID

Step 4: Determine DRDA location name for DB2 instance

Step 5: Configure DB2 Distributed Data Facility for gateway

Checklist for DB2/400

Step 1: Configure the Communications Server

Step 2: Define the user ID that owns the package

Step 3: Define the recovery user ID

Step 4: Determine DRDA location name for DB2/400 instance

Checklist for DB2/Universal Database

Step 1: Configure the Communications Server

Step 2: Define the user ID that owns the package

Step 3: Define the recovery user ID

Step 4: Determine DRDA location name for DB2/UDB instance

Checklist for DB2/VM

Step 1: Configure the Communications Server

Step 2: Define the user ID that owns the package

Step 3: Define the recovery user ID

Step 4: Determine DRDA location name for DB2/VM instance

DB2/MVS

Experience with MVS, TSO, VTAM, and DB2 is required to perform the following steps:

Step 1: Configure the Communications Server

If you are using SNA, then configure MVS VTAM for the SNA LU6.2 connection from the RS/6000 host.  If you are using TCP/IP, then configure the TCP/IP subsystem, configure DB2's DDF subsystem to use TCP/IP, and assign a Primary and Recovery port number for the DB2 server.

Step 2: Define the user ID that owns the package

During gateway configuration, you will need to execute the Bind Package Stored Procedure to bind the gateway package on the DRDA server.  To properly bind the package, the user ID and password used when the procedure is executed (either implied as the current Oracle user or explicitly defined in the CREATE DATABASE LINK command) must have proper authority on the DRDA server to create the package.  This same user ID should be used to create and own the ORACLE2PC (two-phase commit) table.  The user ID that is used to bind or rebind the DRDA package must have the following privileges on the DRDA server:

Choose a user ID now that will own the package and ORACLE2PC table.  Ensure that this user ID is defined to both DB2 and MVS.

Step 3: Define the recovery user ID

During gateway configuration, the recovery user ID and password are specified in the Gateway Initialization File using the DRDA_RECOVERY_USERID and DRDA_RECOVERY_PASSWORD parameters.  If a distributed transaction fails, then the recovery process connects to the remote database using the user ID and password defined in these parameters.  This user ID must have execute privileges on the package and must be defined to the IBM DRDA database.  If the user ID is not specified in DRDA_RECOVER_USERID, then the gateway attempts to connect to a user ID of ORARECOV when a distributed transaction is in doubt.

Determine the user ID and password you will use for recovery.

Step 4: Determine DRDA location name for DB2 instance

The DRDA location name is required as a gateway parameter.  To determine the location name, issue the SQL query:

SELECT CURRENT SERVER FROM any_table 

where any_table is a valid table with one or more rows. 

If the value returned by this query is blank or null, then the DRDA location name has not been established.  Contact the system administrator to arrange to set a location name for the instance.

Step 5: Configure DB2 Distributed Data Facility for gateway

DB2 Distributed Data Facility (DDF) is the component of DB2 that manages all distributed database operations, both DRDA and non-DRDA.

If your site uses DB2 distributed operations, then DDF is probably operational on the DB2 instance you plan to access through the gateway.  If DDF is not operational, then you must configure it and start it as described in the appropriate DB2 documentation.

Even if DDF is operational on the DB2 instance, it might be necessary to make changes to the DDF Communication Database (CDB) tables to specify the authorization conduct of DRDA sessions from the gateway.  This can be done by properly authorized users with a utility like the DB2 SPUFI utility.  If you make changes to CDB tables, then you must stop and restart DDF for the changes to take effect.  Refer to Chapter 11, "Security Considerations", for additional CDB tables and security information.

DB2/400

Experience with DB2/400 and AS/400 is required to perform the following steps:

Step 1: Configure the Communications Server

If you are using SNA, then configure AS/400 communications for the SNA LU6.2 connection from the RS/6000 host.  If you are using TCP/IP, then configure the TCP/IP subsystem, configure DB2/400 to use TCP/IP, and assign a Primary and Recovery port number for the DB2 server.

Step 2: Define the user ID that owns the package

During gateway configuration, you will need to execute the Bind Package Stored Procedure to bind the gateway package on the DRDA server.  To properly bind the package, the user ID and password used when the procedure is executed (either implied as the current Oracle user or explicitly defined in the CREATE DATABASE LINK command) must have proper authority on the DRDA server to create the package.  This same user ID should be used to create and own the ORACLE2PC (two-phase commit) table.  The user ID that is used to bind or rebind the DRDA package must have the following privileges on the DRDA server:

Choose a user ID now that will own the package and ORACLE2PC table.  Ensure that this user ID is defined to DB2/400 and AS/400.

Step 3: Define the recovery user ID

During gateway configuration, the recovery user ID and password are specified in the Gateway Initialization File using the DRDA_RECOVERY_USERID and DRDA_RECOVERY_PASSWORD parameters.  If a distributed transaction fails, then the recovery process connects to the remote database using the user ID and password defined in these parameters.  This user ID must have execute privileges on the package and must be defined to the IBM DRDA database.  If the user ID is not specified in DRDA_RECOVER_USERID, then the gateway attempts to connect to a user ID of ORARECOV when a distributed transaction is in doubt.

Determine the user ID and password you will use for recovery.

Step 4: Determine DRDA location name for DB2/400 instance

The DRDA location name is required as a gateway parameter.  To determine the location name, issue the following SQL query.  If SQL is unavailable on the system, then use the AS/400 command DSPRDBDIRE to identify your "*LOCAL" DRDA server.

SELECT CURRENT SERVER FROM any_table 

where any_table is a valid table with one or more rows.

If the value returned by this query is blank or null, then the DRDA location name has not been established.  Contact the system administrator to arrange to set a location name for the instance.

DB2/UDB (Universal Database)

Experience with DB2/UDB, SMIT, and AIX is required to perform the following steps.

Step 1: Configure the Communications Server

If you are using SNA, then use SMIT to configure AIX Communications Server for the SNA LU6.2 connection from the RS/6000 host.  If you are using TCP/IP, then use SMIT to configure TCP/IP, configure DB2/UDB to use SNA and/or TCP/IP, and assign a Primary and Recovery port number for the DB2 server.

Step 2: Define the user ID that owns the package

During gateway configuration, you will need to execute the Bind Package Stored Procedure to bind the gateway package on the DRDA server.  To properly bind the package, the user ID and password used when the procedure is executed (either implied as the current Oracle user or explicitly defined in the CREATE DATABASE LINK command) must have proper authority on the DRDA server to create the package.  This same user ID should be used to create and own the ORACLE2PC (two-phase commit) table.  The user ID that is used to bind or rebind the DRDA package must have the following privileges on the DRDA server:

Choose a user ID now that will own the package and ORACLE2PC table.  Ensure that this user ID is defined to both the DB2 instance ID and AIX.

Step 3: Define the recovery user ID

During gateway configuration, the recovery user ID and password are specified in the Gateway Initialization File using the DRDA_RECOVERY_USERID and DRDA_RECOVERY_PASSWORD parameters.  If a distributed transaction fails, then the recovery process connects to the re mote database using the user ID and password defined in these parameters.  This user ID must have execute privileges on the package and must be defined to the IBM DRDA database.  If the user ID is not specified in DRDA_RECOVER_USERID, then the gateway attempts to connect to a user ID of ORARECOV when a distributed transaction is in doubt.

Determine the user ID and password you will use for recovery.

Step 4: Determine DRDA location name for DB2/UDB instance

The DRDA location name is required as a gateway parameter.  To determine the location name, issue the SQL query:

SELECT CURRENT SERVER FROM any_table  

where any_table is a valid table with one or more rows.

If the value returned by this query is blank or null, then the DRDA location name has not been established.  Contact your system administrator to arrange to set a location name for the instance.

DB2/VM

Experience with VM, AVS, and DB2/VM is required to perform the following steps:

Step 1: Configure the Communications Server

If you are using SNA, then configure VM VTAM and AVS for the SNA LU6.2 connection from the RS/6000 host.  If you are using TCP/IP, then configure the TCP/IP Service.

Step 2: Define the user ID that owns the package

During gateway configuration, you will need to execute the Bind Package Stored Procedure to bind the gateway package on the DRDA server.  To properly bind the package, the user ID and password used when the procedure is executed (either implied as the current Oracle user or explicitly defined in the CREATE DATABASE LINK command) must have proper authority on the DRDA server to create the package.  This same user ID should be used to create and own the ORACLE2PC (two-phase commit) table.  The user ID that is used to bind or rebind the DRDA package must have the following privileges on the DRDA server:

Choose a user ID now that will own the package and ORACLE2PC table.  Ensure that this user ID is defined to DB2/VM and VM.

Step 3: Define the recovery user ID

During gateway configuration, the recovery user ID and password are specified in the Gateway Initialization File using the DRDA_RECOVERY_USERID and DRDA_RECOVERY_PASSWORD parameters.  If a distributed transaction fails, then the recovery process connects to the remote database using the user ID and password defined in these parameters.  This user ID must have execute privileges on the package and must be defined to the IBM DRDA database.  If the user ID is not specified in DRDA_RECOVER_USERID, then the gateway attempts to connect to a user ID of ORARECOV when a distributed transaction is in doubt.

Determine the user ID and password you will use for recovery.

Step 4: Determine DRDA location name for DB2/VM instance

The DRDA location name is required as a gateway parameter.  To determine the location name, issue the SQL query:

SELECT CURRENT SERVER FROM any_table 

where any_table is a valid table with one or more rows.

If the value returned by this query is blank or null, then the DRDA location name has not been established.  Contact the system administrator to arrange to set a location name for the instance.


Go to previous page Go to next page
Oracle
Copyright © 2001 Oracle Corporation.

All Rights Reserved.
Go To Table Of Contents
Contents
Go To Index
Index