| Oracle® Transparent Gateway for DRDA Installation and User's Guide 10g Release 2 (10.2) for UNIX Part Number B16217-02 |
|
|
View PDF |
| Oracle® Transparent Gateway for DRDA Installation and User's Guide 10g Release 2 (10.2) for UNIX Part Number B16217-02 |
|
|
View PDF |
This chapter describes configuring the IBM Communication Server product on AIX and Linux for usage with the Oracle Transparent Gateway for DRDA. IBM Communication Server provides SNA connectivity through the APPC/LU6.2 protocol between the host and the remote DRDA Server. This chapter provides information about creating server profiles.
The following topics are included:
The checklists for configuring communications interfaces are as follows:
Configure the profiles to define APPC conversations with DRDA databases.
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 LU, is described by a distinct profile type.
SNA profile definitions are created and modified in two ways:
Directly with shell commands
Using SNA administration tools
Maintenance of SNA profiles is normally done by a user with root authority. To create server profiles, do the following:
The $ORACLE_HOME/tg4drda/sna/commsvr subdirectory contains a set of sample IBM Communication Server definitions for the gateway, created with the 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.
There are different types of Communications Server profiles relevant to gateway APPC/LU6.2 operation. Create and edit profiles using the SNA administration tool.
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.
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 Servers 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.
The Local LU Profile describes the SNA LU through which the gateway communicates. The LU type field must be LU6.2. The network name is an established name for your SNA network.
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.
Set the 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 Local LU Profile name is specified in the Side Information profile.
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 the mainframe environment, APPN support requires VTAM Version 4. Prior releases of VTAM are not APPN-enabled.
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.
The Side Information Profile is the top of the hierarchy for APPC/LU6.2 conversations. The name of the Side Information Profile is specified with DRDA_CONNECT_PARM in the Gateway Initialization file.
Enter the following information in the Side Information Profile fields:
Local LU Name: LU Name as specified in local LU profile
Fully Qualified Partner LU Name or Partner LU Alias: LU Name specified in Partner LU profile or Partner LU location profile
Mode Name: Mode Name specified in Mode profile
Remote Transaction Program Name: Remote TPN
Remote TPN in hexadecimal: 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 11, "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 the following information to the DRDA Server:
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 in to the Oracle integrating server with an explicit user ID and password, then the Oracle user ID and password are sent.
If the application logs in to 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 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.
