Skip Headers
Oracle® Transparent Gateway for DRDA Installation and User's Guide
10g Release 2 (10.2) for Microsoft Windows

Part Number B16218-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

7 Configuring IBM Communication Server

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 SNA connectivity through 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:

Before You Begin

This chapter requires you to enterparameters 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.

Checklist for Configuring the Communications Interfaces

Creating IBM Communication Server Profiles for the Gateway

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 (RTP) name, and Logical Unit (LU), is described by a distinct profile type.

Independent Versus Dependent LUs

Oracle 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 one 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 start 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 starting a session with the same DRDA Server appears to stop responding as it waits behind the previous session.

If a production application really uses only one 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.

Creating SNA Definitions for the Gateway

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.

Sample IBM Communication Server Definitions

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.

Definition Types

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.

IBM Communication Server Definitions

This section describes the process of creating SNA definitions for IBM Communication Server using the SNA Node Configuration tool. All the tasks described in this section are performed within SNA Node Configuration.

Figure 7-1 Choosing a Configuration Scenario

Description of Figure 7-1 follows
Description of "Figure 7-1 Choosing a Configuration Scenario"

Creating the 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.

Figure 7-2 Creating the Node Configuration

Description of Figure 7-2 follows
Description of "Figure 7-2 Creating the Node Configuration"

Defining the Node

Each SNA Server must have a Control Point defined. This is typically called the Node definition. Click Node and click Create.

Figure 7-3 Node Definition

Description of Figure 7-3 follows
Description of "Figure 7-3 Node Definition"

In the Define the Node dialog box, in the Basic tab, enter the Control Point, Local Node ID, and Node Type information. You can also select option in the Advanced tab depending on your SNA network configuration. Click OK.

Figure 7-4 Creating Devices

Description of Figure 7-4 follows
Description of "Figure 7-4 Creating Devices"

Communication devices should be configured next. Select Devices, and click Create.

Figure 7-5 Choosing the Device Type

Description of Figure 7-5 follows
Description of "Figure 7-5 Choosing the Device Type"

Select the type of device to use for communication. The LAN type is typical for either Ethernet or Token-ring attached network devices.

Figure 7-6 Configuring a LAN Device

Description of Figure 7-6 follows
Description of "Figure 7-6 Configuring a LAN Device"

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.

Figure 7-7 Creating Peer Connections

Description of Figure 7-7 follows
Description of "Figure 7-7 Creating Peer Connections"

Peer connections should be configured next. Select Peer Connections, and click Create.

Figure 7-8 Defining the Link station

Description of Figure 7-8 follows
Description of "Figure 7-8 Defining the Link station"

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.

Figure 7-9 Defining the Adjacent Node

Description of Figure 7-9 follows
Description of "Figure 7-9 Defining the Adjacent Node"

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) as the default. Consult your SNA Network Administrator for details. The other tabs may be explored for tuning and link reactivation options. Click OK.

Figure 7-10 Create Local LUs

Description of Figure 7-10 follows
Description of "Figure 7-10 Create Local LUs"

Next, define the local LUs for this Node. Select Local LU 6.2 LUs, and click Create.

Figure 7-11 Defining Local LUs

Description of Figure 7-11 follows
Description of "Figure 7-11 Defining Local LUs"

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 Advancedtab may be explored for Synchronization support and for LU session limits. Click OK.

Figure 7-12 Create Partner LUs

Description of Figure 7-12 follows
Description of "Figure 7-12 Create Partner LUs"

Next, define remote Partner LUs for this Node to connect to. Select Partner LU 6.2 LUs and click Create.

Figure 7-13 Defining Partner LUs

Description of Figure 7-13 follows
Description of "Figure 7-13 Defining Partner LUs"

In the Basic tab, enter the name of the remote or partner LU and an alias, if desired. Seclect Fully Qualified CP from the existing list. The Advanced tab may be explored for logical record limits and security support. Click OK.

Figure 7-14 Creating the IBMRDB Mode

Description of Figure 7-14 follows
Description of "Figure 7-14 Creating the IBMRDB Mode"

Next, define the IBMRDB mode, which will be used for DRDA connections. Select Modes and click Create.

Figure 7-15 Define the IBMRDB Mode

Description of Figure 7-15 follows
Description of "Figure 7-15 Define the IBMRDB Mode"

In the Basic tab, enter the name IBMRDB and the mode session limits. Consult your SNA Network Administrator for details. The Advanced tab may be explored for pacing and autoactivation session options. Click OK.

Figure 7-16 Create the CPI-C Side Information Profile

Description of Figure 7-16 follows
Description of "Figure 7-16 Create the CPI-C Side Information Profile"

Next, define the CPI-C profile that will be use dby the gateway. Select CPI-C side information definitions and click Create.

Figure 7-17 Define the CPI-C Side Information Profile

Description of Figure 7-17 follows
Description of "Figure 7-17 Define the CPI-C Side Information Profile"

In the Basic tab, enter the Symbolic Destination name. Select IBMRDB for the Mode name drop-down list, and select 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 Advancedtab may be explored for security options.


Note:

The DRDA_CONNECT_PARM should be assigned the name of the Symbolic Destination name as entered in Figure 7-16, "Create the CPI-C Side Information Profile".

Testing the Connection

Before proceeding with the gateway configuration tasks in Chapter 10, "Configuring the Gateway", ensure that your connection is working. This can be done by using the 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

Description of Figure 7-18 follows
Description of "Figure 7-18 Relationship Between IBM Communication Server Definitions and Host VTAM Definitions"

Using SNA Session Security Validation

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 LU and the DRDA Server LU.

SNA and its various access method implementations (including IBM Communication Server) provide security validation at session initiation time, enabling 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 Microsoft SNA Server and IBM Communication Server product documentation for detailed information.

SNA Conversation Security

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.

SNA Security Option SECURITY=PROGRAM

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 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 IBM DRDA Servers can be configured to process inbound user IDs in other ways.

SNA Security Option SECURITY=SAME

The SECURITY=SAME option is not directly supported by IBM Communication Server. SECURITY=SAME implicitly validates security by using the user account under which the TNS listener was started. IBM Communication Server, however, does not support this type of validation.