| Oracle® Transparent Gateway for DRDA Installation and User's Guide 10g Release 1 (10.1.0.2.0) for Microsoft Windows Part Number B12010-01 |
|
|
View PDF |
| Oracle® Transparent Gateway for DRDA Installation and User's Guide 10g Release 1 (10.1.0.2.0) for Microsoft Windows Part Number B12010-01 |
|
|
View PDF |
This chapter describes configuration of the IBM Communication Server product on MS Windows for use with the Oracle Transparent Gateway for DRDA. IBM Communication Server provides the SNA connectivity via the APPC/LU6.2 protocol between the host and the remote DRDA Server. Read this chapter to learn more about creating Communication Server profiles.
This chapter contains the following sections:
This chapter requires you to input parameters unique to your system in order to properly configure the IBM Communication Server. Refer to Appendix E for a worksheet listing all the installation parameters that you will need to know before you can complete the configuration process. Ask your network administrator to provide you with these parameters before you begin.
Step 1: Creating IBM Communication Server Profiles for the Gateway
Step 2: Definition Types
Step 3: Testing the Connection
The Oracle Transparent Gateway for DRDA requires a stored set of definitions, called Side Information 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.
Oracle Corporation recommends independent LUs for the Oracle Transparent Gateway for DRDA, because they support multiple parallel sessions or conversations. This means multiple Oracle client applications can be active simultaneously with the same DRDA Server through the independent LU.
Dependent LUs support only a single active session. The CP (IBM Communication Server, in this case) queues additional conversation requests from the gateway server behind an already active conversation. In other words, conversations are single-threaded for dependent LUs.
If a dependent LU is correctly defined, then no alterations to the Oracle Transparent Gateway for DRDA configuration are needed, nor should any changes be needed to the DRDA Server.
The operational impact of dependent LUs is that the first client application can initiate a conversation through the gateway with the DRDA Server. While that session is active (which could be seconds, minutes or hours, depending on how the client application and transaction are designed), any other client application initiating a session with the same DRDA Server appears to hang as it waits behind the previous session.
If a production application really only uses a single conversation at any one time, then there should be no impact. However, additional concurrent conversations might be required for testing or other application development. Each requires that additional dependent LUs be defined on the remote host, plus additional IBM Communication Server configuration entries which define the additional dependent LUs on the host.
Additional Side Information Profiles should be defined to use the new dependent LUs. New Transparent Gateway for DRDA instances should be created and configured to use these new Side Information Profiles.
IBM Communication Server definitions are created using the SNA Node Configuration tool, while the actual operation of the server is done using the SNA Node Operations tool, both of which are provided with IBM Communication Server. Maintenance of SNA definitions is normally done by a user with Administrator authority.
The tg4drda\sna\commsvr subdirectory contains a sample set of IBM Communication Server definitions created with the SNA Node Configuration tool. The oracle.acg file contains sample definitions for IBM Communication Server.
Before building the IBM Communication Server definitions, examine the oracle.acg file to determine the definitions needed, their contents, and their interrelationships. The file format is text-oriented and each field of each definition is clearly labeled. You can print a copy of the file to use while working with your definitions in an SNA Node Configuration session.
There are several types of IBM Communication Server definitions relevant to gateway APPC/LU6.2 operation. Each definition can be created and edited using a corresponding SNA Node Configuration menu.
The definitions relevant to the gateway are presented here in hierarchical order. Those definition types that are lowest in the hierarchy are discussed first. This matches the logical sequence in which to create the profiles.
Refer to the IBM Communication Server online documentation for a complete discussion of IBM Communication Server definitions. This section is an overview of IBM Communication Server definitions in relation to the Oracle Transparent Gateway for DRDA.
This section describes the process of creating your SNA definitions for IBM Communication Server using the SNA Node Configuration tool. All of the tasks described in this section are performed within SNA Node Configuration.
SNA Node Configuration will first ask if you are creating a new configuration or loading an existing configuration. The following example is presented with the assumption that a new configuration is being created.
SNA Node Configuration will next prompt you for a configuration scenario. Our example is made assuming that a CPI-C or APPC scenario is being chosen.
Each SNA server must have a Control Point defined. This is typically called the Node definition. Click on Node and click the [Create] button.
In the Define the Node dialog box, under the Basic tab, enter the Control Point, Local Node ID, and Node Type information. Under the Advanced tab are options that may be selected depending on your SNA network configuration. Click [OK].
Communication Devices should be configured next. Click on Devices, and click the [Create] button.
Select the type of device to use for communication. The LAN type is typical for either Ethernet or Token-ring attached network devices.
In the Basic tab, select the Adapter to use and the Local SAP. The other tabs may be explored for network tuning parameters. Click [OK].
Peer Connections should be configured next. Click on Peer Connections, and click the [Create] button.
In the Basic tab, enter a Link station name for this connection. Choose the Device for the connection, and enter the Destination address and Remote SAP.
Select the Adjacent Node tab. Enter the Adjacent CP name of the remote system and pick its CP Type. You may have to choose a different Transmission Group (TG) that the default. Consult your SNA Network Administrator for details. The other tabs may be explored for tuning and link reactivation options. Click [OK].
Next, define the Local LUs for this Node. Click on Local LU 6.2 LUs and click the [Create] button.
In the Basic tab, enter the name of the Local LU and an Alias, if desired. The name must match the Local LU definition of the remote host for this Node. The other tab may be explored for Synchronization support and for LU session limits. Click [OK].
Next, define remote Partner LUs for this Node to connect to. Click on Partner LU 6.2 LUs and click the [Create] button.
In the Basic tab, enter the name of the Remote or Partner LU and an Alias, if desired. Choose the Fully Qualified CP from the Existing list. The other tab may be explored for logical record limits and security support. Click [OK].
Next, define the IBMRDB Mode, which will be used for DRDA connections. Click on Modes and click the [Create] button.
In the Basic tab, enter the name IBMRDB and the mode session limits. Consult your SNA Network Administrator for details. The other tab may be explored for pacing and auto activation session options. Click [OK].
Next, define the CPI-C profile that will be use by the gateway. Click on CPI-C Side Information Definitions and click the [Create] button.
In the Basic tab, enter the Symbolic Destination name. Choose IBMRDB for the Mode name, and choose the Partner LU either by name or by alias. Enter the TP name for the remote DRDA Server. Mode DRDA Servers use the default Service TP name X'07F6C4C2' or '076DB'. Consult your DRDA Server Administrator for the correct TP name. The other tab may be explored for security options.
Before proceeding with the gateway configuration tasks in Chapter 10, " Configuring the Gateway", ensure your connection is working. This can be done using SNA Node Operations tool.
Figure 7-18, "Relationship Between IBM Communication Server Definitions and Host VTAM Definitions" shows the relationship between IBM Communication Server definitions and the VTAM definitions on the host.
Figure 7-18 Relationship Between IBM Communication Server Definitions and Host VTAM Definitions
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) 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 Pentium-based host Connection Profile and in similar parameter structures in the DRDA Server system that is to be accessed. Refer to the appropriate Microsoft SNA Server and IBM Communication 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 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 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 IBM DRDA Servers can be configured to process inbound user IDs in other ways.
