Oracle® Transparent Gateway for DRDA Installation and User's Guide
10g Release 1 (10.1) for UNIX
Part No. B12009-02
This chapter describes configuring the IBM Communication Server product on AIX for usage with the Oracle Transparent Gateway for DRDA. IBM Communication Server provides SNA connectivity via the APPC/LU6.2 protocol between the host and the remote DRDA Server. Read this chapter to learn more about creating server profiles.
The following topics are included:
Communications Server requires a stored set of definitions, called profiles, to support connections between the gateway and DRDA Servers. Each profile consists of a profile name and a profile type, a set of fields describing the profile. The fields in a given profile type are generally a mixture of operating parameter values and names of other SNA profiles relevant to the profile. Each functional part of APPC, such as the Mode, Remote Transaction Program name, and Logical Unit (LU), is described by a distinct profile type.
Maintenance of SNA profiles is normally done by a user with root authority.
The $ORACLE_HOME/tg4drda/sna/commsvr subdirectory contains a set of sample IBM Communication Server definitions for the gateway, created with the SMIT administration tool. SNA definitions are very specific to the host and SNA network. As such, the sample definitions provided will not work without being tailored for the local host and SNA network.
Before building the SNA profiles, examine these files to determine requirements. The export file format is text-oriented, and each field of each profile is labeled. You can print a copy of the export file to use while working with your profiles in a SMIT session.
There are different types of Communications Server profiles relevant to gateway APPC/LU6.2 operation. You can create and edit profiles by using a corresponding SMIT menu reached from the "Communications Applications and Services" primary menu.
The profiles relevant to the gateway are presented here in hierarchical order. Those profile types that are lowest in the hierarchy are discussed first. This matches the logical sequence for creating the profiles. You can use the SMIT "list" pop-up menu to fill in profile names.
The Mode Profile specifies parameters that determine:
send and receive pacing values
SNA RU size
the mode name that is sent to the server at session initiation
The mode name that you specify must be defined in the DRDA Server's communication software. 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 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.
An LU name must be assigned to the gateway. The LU name assigned to the gateway might be required elsewhere in the SNA network. Contact the person responsible for your SNA network to determine the correct network and LU name to specify in the profile.
dependent LU field to "no". Setting the
dependent LU field to "yes" prevents more than one instance of the gateway from running at the same time.
The Link Profiles describe and control the connection of the host to the network. The gateway does not impose special requirements on these profiles.
The Link Profile name is specified in the Local LU Profile.
The Partner LU Profile 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.
The Partner LU Location Profile is only required when the target OLTP resides on a non-APPN (advanced peer-to-peer networking) node. The profile is also required if the owning node of the network connection to the target OLTP system is a non-APPN node.
In configurations where the Partner LU Location Profile is required, the fully qualified partner owning CP name in the profile should be set to the value specified in the VTAM SSCPNAME start parameter. The Partner LU Location Profile name is specified as the alias in the Partner LU Profile.
Enter the following information in the Side Information Profile fields:
Specification – LU Name as specified in local LU profile
Specification – LU Name specified in Partner LU profile or Partner LU location profile
Specification – Mode Name specified in Mode profile
Specification – Remote TPN
Specification – Yes
The Remote Transaction Program Name (TPN) generally identifies the program to be executed on the server side of an APPC conversation. IBM 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 is X'07F6C4C2'. Specify this TPN for DB2/MVS and DB2/400 DRDA Servers.
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 entered in non-hexadecimal characters. The RESID is specified when DB2/VM is configured.
Before proceeding with the gateway configuration tasks in Chapter 12, "Configuring the Gateway", ensure that your connection is working. This can be done using SMIT.
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 IBM Communication Server 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 SNA server 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, IBM Communications Server 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
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.