| Oracle® Transparent Gateway for DRDA Installation and User’s Guide 10g Release 1 (10.1) for UNIX Part No. B12009-01 |
|
 |
 |
| Oracle® Transparent Gateway for DRDA Installation and User’s Guide 10g Release 1 (10.1) for UNIX Part No. B12009-01 |
|
|
|
This chapter describes configuring the SunLink SNA Peer-to-Peer product on Solaris for use with the Oracle Transparent Gateway for DRDA. SunLink provides SNA connectivity via the APPC/LU6.2 protocol between the Sun host and the remote DRDA Server. Read this chapter to learn more about creating server profiles. host
This chapter contains the following sections:
The gateway name plays an important role in the use of the SunLink software. The gateway name is how users of SunLink client programs (for Oracle, it is the Oracle gateway kernel) identify the gateway.
After you decide on a gateway name on your Sun host, you can define it in one of two ways:
Use NIS/NIS+ to create the gateway name in the NIS/NIS+ database. Refer to the SunLink Runtime and System Administrator䴜s Guide for an example.
Use a flat file, /etc/appc, to define the gateway name in your workstation.
For example, enter:
sunlinkgtw sunhost:sunlinkgtw
where:
sunlinkgtw is the gateway name.
sunhost is the hostname of the Sun workstation.
To enable communication between a SunLink gateway and a remote SNA host, you must specify (in SNA terms) the precise configuration of a SunLink gateway on your Sun host. The information is contained in a flat ASCII file, ./appc.
For SunLink Version 9.0, this ./appc file is input to the sunpu2.1 utility.
The input file has the form of verbs with associated parameters. Each of the verb identifiers corresponds to an Application Programming Interface (API) verb. Depending on the hardware configuration of your SNA network, this input file might have different verbs and parameters.
Refer to the SunLink Runtime and System Administrator䴜s Guide for a detailed description of each verb in the input file and its associated parameters.
A sample SNA configuration file for SunLink Version 9 is shipped with the gateway. After you have successfully installed the Oracle Transparent Gateway for IBM DRDA, you can find it in the tg4drda/sna/sunlink subdirectory. The sample file is:
$ORACLE_HOME/tg4drda/sna/sunlink/SunLink9.cfg, for sunpu2.1 configuration connecting the Sun host to several IBM hosts
Also shipped with the gateway are sample Side Information Files. They are also located in the tg4drda/sna/sunlink subdirectory as outlined in the following list:
$ORACLE_HOME/tg4drda/sna/sunlink/DB251ALU, a Version 9 sample Side Information File
$ORACLE_HOME/tg4drda/sna/sunlink/DB2V23LU, a Version 9 sample Side Information File
$ORACLE_HOME/tg4drda/sna/sunlink/DRDA400, a Version 9 sample Side Information File
$ORACLE_HOME/tg4drda/sna/sunlink/DB2VM51, a Version 9 sample Side Information File
Before starting an APPC conversation with a partner program, a CPI-C program requires certain information. This information, known as side information, is provided by the Side Information File. The symbolic destination name corresponds to an entry in the Side Information File containing the Partner_LU_name, Mode_name, and TP_name.
This identifies the name of the remote, or partner LU associated with the DRDA Server. In addition to specifying the fully qualified partner LU name, you can also specify a partner LU alias to identify a partner LU location profile (if required).
To allow more than one concurrent conversation between the gateway and the DRDA Server, specify that parallel sessions are supported in this profile.
This must be defined in the communication software of the DRDA Server. DRDA Servers use the mode name IBMRDB in many DRDA examples, but this is not required. Choose the mode name and the other mode parameters after consulting the person responsible for configuring the DRDA Server-side communications software. The mode_name you specify must exist at the target DRDA Server. It does not need to be defined in the same SNA gateway.
The parameters, related to parallel session limits, play a role in determining the maximum number of concurrent conversations allowed between a gateway instance and the DRDA Server. This equates to the maximum number of open database links using the gateway instance.
This generally identifies the program to be executed on the server side of an APPC conversation. DRDA uses a special reserved TPN (called an SNA Service Transaction Program) that is expressed in hexadecimal because it contains non-printable characters. The TPN for DB2/MVS, DB2/UDB, and DB2/400 is X’07F6C4C2’.
For DB2/VM, the DRDA Server does not use the standard DRDA TPN. Instead, the TPN identifies the VM Resource ID (RESID) of the target DB2/VM server virtual machine, and can be non-hexadecimal characters. The RESID is specified when DB2/VM is configured.
The name of the Side Information File for Version 9 must be specified in the Gateway Initialization File initsid.ora as:
DRDA_CONNECT_PARM=/oracle/tg4drda/side9/DB2V23LU
Enter the value in the Appendix E, " Configuration Worksheet".
Here is a sample Side Information File for SunLink Version 9.0:
PTNR_LU_NAME = DB2V23 MODE_NAME = IBMRDB TP_NAME = x’07F6C4C2’
Before proceeding with the installation and configuration of the Oracle Transparent Gateway for DRDA, test that your connection is working. You can do this using sunop or sungmi. Refer to your Sunlink documentation for more details.
When the database link request for the gateway begins, the gateway attempts to start an APPC conversation with the DRDA Server. Before the conversation can begin, a session must start between the host Logical Unit (LU) and the DRDA Server LU.
SNA and its various access method implementations (including SunLink and VTAM) provide security validation at session initiation time, allowing each LU to authenticate its partner. This is carried out entirely by network software before the gateway and server application programs begin their conversation and process conversation-level security data. If session-level security is used, then correct password information must be established in the host Connection Profile and in similar parameter structures in the DRDA Server system that is to be accessed. Refer to the appropriate SunLink product documentation for detailed information.
SNA conversation security is determined by the setting of the gateway initialization parameter, DRDA_SECURITY_TYPE. This parameter determines whether SNA security option SECURITY is set to PROGRAM or to SAME. Generally, the gateway operates under SNA option SECURITY=PROGRAM, but it can also be set to operate under SNA option SECURITY=SAME.
If DRDA_SECURITY_TYPE=PROGRAM is specified, then the gateway allocates the conversation with SNA option SECURITY=PROGRAM and sends this information to the user ID:
If the database link has explicit CONNECT information, then the specified user ID and password are sent.
If the database link has no CONNECT clause and if the application has logged into the Oracle integrating server with an explicit user ID and password, then the Oracle user ID and password are sent.
If the application logs into the Oracle integrating server with operating system authentication, and if the database link lacks explicit CONNECT information, then no user ID and password are sent. If no user ID and password are sent, and if the DRDA Server is not configured to assign a default user ID, then the connection fails.
In general, SECURITY=PROGRAM tells the DRDA Server to authenticate the user ID/password combination using whatever authentication mechanisms are available. For example, if DB2/OS390 is the DRDA Server, then RACF can be used. This is not always the case, however, because each of the DRDA Servers can be configured to process inbound user IDs in other ways.
If DRDA_SECURITY_TYPE=SAME is specified, then the gateway allocates the conversation with SNA option SECURITY=SAME, and the following information is sent to the DRDA Server:
If the database link has explicit CONNECT information, then the specified user ID is sent.
If the database link has no CONNECT clause, and if the application has logged into the Oracle integrating server with an explicit user ID and password, then the Oracle user ID is sent.
If the application logs into the Oracle integrating server with operating system authentication, and if the database link lacks explicit CONNECT information, then no user ID is sent. If no user ID is sent, and if the DRDA Server is not configured to assign a default user ID, then the connection fails.
For this option to function properly, SunLink requires that the effective user ID under which the gateway is executing must be a member of the system group. In UNIX terms, this means that the user ID must be defined with its primary group set to system. In addition, the owning user ID of the gateway executable must be set to the desired effective user ID, and the set-uid bit of the executable file permissions must also be set. The ls -l command shows the owning user ID and the setting of the set-uid bit for the executable file. The owning user ID can be changed by the root user with the chown command, and the set-uid bit can be set using the chmod u+s command. The gateway executable, as installed by the Oracle Universal Installer, has its set-uid bit disabled.
The simplest way to cause the gateway to execute under an effective user ID that is a member of the system group is to change the owning user ID of the gateway executable to root. Another way is to change the primary group for the owning user ID of the gateway executable to system. However, be careful when choosing the user ID. Oracle Corporation recommends using root and recommends never changing the Oracle dba user ID primary group to system.
When the effective user ID is not a member of the system group, a failure is generated when the gateway attempts to allocate a conversation with the DRDA Server, and an error message is sent to the gateway user.
