If DDF is not operational, then you must configure it and start it as described in the appropriate DB2 documentation.Įven 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. If your site uses DB2 distributed operations, then DDF is probably operational on the DB2 instance you plan to access through the gateway.
Contact the system administrator to arrange to set a location name for the instance.ĭB2 Distributed Data Facility (DDF) is the component of DB2 that manages all distributed database operations, both DRDA and non-DRDA. If the value returned by this query is blank or null, then the DRDA location name has not been established. Where any_table is a valid table with one or more rows. To determine the location name, issue the following SQL query from a DB2 SPUFI session: SELECT CURRENT SERVER FROM any_table The DRDA location name is required as a gateway parameter.
UNIVERSAL DATABASE DEFINITION PASSWORD
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.ĭetermine the user ID and password you will use for recovery. This user ID must have execute privileges on the package and must be defined in the DRDA database. If a distributed transaction fails, then the recovery process connects to the remote database using the user ID and password defined in these parameters. Ensure that this user ID is defined to both DB2 and OS/390 (MVS).ĭuring 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. System privileges of BINDADD and BINDAGENT, for example: GRANT BINDADD TO USER useridĭatabase privilege of CREATETAB, for example: GRANT CREATETAB ON DATABASE database TO USER useridĬhoose a user ID that will own the package and the ORACLE2PC table. GRANT EXECUTE ON PACKAGE drda1.* TO PUBLICĬollection privilege of CREATE IN, for example: GRANT CREATE IN ON PACKAGE drda1 TO USER userid Package privileges of BIND, COPY, and EXECUTE, for example: GRANT BIND ON PACKAGE drda1.* TO userid The user ID that is used to bind or rebind the DRDA package must have one or more of the following privileges on the DRDA Server: This user ID should be used to create and own the ORACLE2PC ( two-phase commit) table. To properly bind the package, the user ID and password that are 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. If you are using TCP/IP, then configure the TCP/IP subsystem, configure DB2s DDF to use TCP/IP, and assign a primary and recovery port number for the DB2 server.ĭuring gateway configuration, you will need to execute the Bind Package Stored Procedure to bind the gateway package on the DRDA Server. Configure DB2s DDF for SNA using the LU defined. If you are using SNA, then configure OS/390 (MVS) VTAM for the SNA LU6.2 connection from the host. Step 4: Determine DRDA location name for DB2/VM InstanceĮxperience with OS/390 (MVS), TSO, VTAM, and DB2 is required to perform the following steps: Step 4: Determine DRDA location name for DB2/UDB instance Step 1: Configure the SNA Communications Server Step 4: Determine DRDA location name for DB2/400 instance Step 5: Configure DB2 Distributed Data Facility for Gateway Step 4: Determine DRDA location name for DB2 instance Step 2: Define the user ID that owns the package Step 1: Configure the Communications Server This section provides the checklists for configuring the DRDA Server. Checklists for Configuring the DRDA Server
0 kommentar(er)
