This chapter describes configuring the SNAPlus2 product on HP-UX for usage with the Oracle Transparent Gateway for DRDA. SNAPlus2 provides SNA connectivity through the APPC/LU6.2 protocol between the HP9000 host and the remote DRDA Server. This chapter to provide more information creating server profiles.
This chapter contains the following sections:
The checklists for configuring the communications interfaces are:
You need to provide values for parameters unique to your system in order to properly configure SNAPlus2. Refer to Appendix E for a worksheet listing all of the installation parameters 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.
All SNAPlus2 product configuration is done using the xsnapadmin
program. This tool is an X-Windows application which provides a graphical interface so that you can view and modify the current SNAPlus2 configuration and the current running state of the host SNA node. Refer to the HP-UX SNAPlus2 administrators guide for more information on using xsnapadmin.
The Oracle Transparent Gateway for IBM 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, which is 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.
The gateway configuration can accommodate either independent LUs or dependent LUs. If you choose to use dependent LUs, or are restricted to using dependent LUs, the gateway will function properly; if a dependent LU is correctly defined, then you will need to make no alterations to the configuration of the Oracle Transparent Gateway for IBM DRDA, nor should any changes be needed to the DRDA Server. However, Oracle recommends using independent LUs for the Oracle Transparent Gateway for IBM DRDA because they support multiple parallel sessions or conversations. This means that multiple Oracle client applications can be active simultaneously with the same DRDA Server through the independent LU.
In contrast to independent LUs, dependent LUs support only a single active session. The Control Point for the Node (CP) queues each additional conversation request from the gateway behind an already active conversation. In other words, conversations are single-threaded for dependent LUs.
The operational impact of dependent LUs is that the first client application can initiate a conversation through the gateway with the DRDA Server, but 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 uses only a single conversation at any one time, then there should be no problem. However, at some point you might require additional concurrent conversations for testing or for other application development. Having more than one conversation requires that additional dependent LUs be defined on the remote host. Additional configuration entries will need to be added to SNAPlus2. Additional Side Information Profiles should be defined to use the new dependent LUs. Oracle Transparent Gateway for IBM DRDA instances should be created and configured to use these new Side Information Profiles.
SNAPlus2 definitions are stored in the following two files, located in the directory /etc/opt/sna
:
These files are created and maintained with the xsnapadmin
tool. Maintenance of SNA definitions is normally done by a user with administrative authority. You should have some knowledge of SNA before reading this section. The following information is intended for the person creating SNA definitions for the gateway, they are:
The $ORACLE_HOME/tg4drda/sna/snaplus
subdirectory contains a set of sample SNAPlus2 definitions for the gateway, created with the xsnapadmin.
SNA definitions are very specific to the HP9000 host and SNA network. As such, the sample definitions that are provided will not work without being tailored for the local host and SNA network.
This section describes the process of creating your SNA definitions for SNAPlus2, using xsnapadmin.
All of the tasks described in this section are performed from within xsnapadmin.
All configuration is done using the various pull-down menus and panels in xsnapadmin.
The following configuration descriptions follow the samples provided. Please tailor the various SNA values for your local host and SNA network.
The $DISPLAY
environmental variable must be set appropriately. If you are running xsnapadmin
from the local HP9000 console, then $DISPLAY
should already be set. If you are running xsnapadmin
from a remote X display, then set $DISPLAY
to the host name or IP address of that display.Use the following commands to invoke xsnapadmin.
$ DISPLAY=xstation10.us.oracle.com:0 $ export DISPLAY $ xsnapadmin &
Upon startup of xsnapadmin,
the main screen will open and display the current configuration of the local SNA node. (See Figure 8-1)
From the Services menu, select Configure Node Parameters. In the Node Parameters dialog box (see Figure 8-2), enter the APPN support type, Control Point Name, Control Point Alias, and Node ID as needed. The Control Point Name is composed of the SNA Network Name and the CP name of the local host. Click OK.
From the Services menu, select Connectivity and Add Port. In the Add to <nodename> dialog box (Figure 8-3), select the Port type and click OK.
In the SAP dialog box (see Figure 8-4), enter a Port name and network card number. The Port name will be used to logically name the physical network card that you are using and will be used to bind a Service Access Port to the card for SNA protocols. Usually, you can accept the values provided in the dialog box. If a different network card is needed, however, enter the card number as reported with the lanscan
command. Click OK.
After the Port has been defined, you need to create a Link Station. The Link Station represents the SNA node of the remote host of the DRDA Server. But before you can create the Link Station, you must create a Remote Node definition. From the Services menu select APPC and Add Remote Node. In the dialog box (see Figure 8-5) enter the SNA CPNAME of the remote node and click OK.
Now you are ready to create the Link Station. From the Services menu, select Connectivity and Add Link Station. In the dialog box (see Figure 8-6) select the Port previously defined and click OK.
In the Link Station dialog box, (see Figure 8-7) enter a name for the Link Station, choose the SNA Port name, and choose the type of link activation. Choose the LU Traffic type. For maximum flexibility, choose the Any option. For Independent LU traffic, specify the Remote Node name. Click Remote Node and select the node you previously created. Click OK. For Dependent LU traffic, specify the Local Node ID, and optionally, Remote Node ID. Then specify the Contact Information.
Contact information contains the MAC address of the remote host as well as the SAP number. Click the Advanced for additional parameters of the Link Station.
The Ethernet Parameters dialog box shows additional parameters of the Link Station (see Figure 8-8). These parameters effect initial XID contact and retransmission times and limits. The defaults are normally sufficient. Click OK.
Figure 8-8 Ethernet Parameters Dialog Box
After the Remote Node definitions have been made, create the Local LU names for the local host. From the Services menu select APPC and Add Local LU. In the dialog box, (see Figure 8-9) enter the name of the local LU and an alias. This name must correspond to the VTAM definitions on the remote DRDA Server host for the HP9000 host. Click OK.
Now define a Partner LU which represents the LU that the DRDA Server is using to communicate. From the Services menu select APPC and Add Partner LUs and Partner LU on Remote Node. In the dialog box, (see Figure 8-10) enter the Partner LU name and characteristics. The Partner LU name will contain the SNA Network Name as well as the LU name of the remote LU. Enable parallel session support. The location is the name as the Remote Node name. Click Location for a list. Click OK.
Creating Mode and CPI-C Profiles
After the local and remote LU definitions have been made, create the necessary Mode and CPI-C definitions.
From the Services menu select APPC and Modes. In the Modes dialog box (see Figure 8-11) click Add to add a new mode.
In the Mode dialog box, (see Figure 8-12) enter the Mode Name and other session parameters. The prescribed name for a DRDA mode is IBMRDB
. Contact your Remote Host system administrator for appropriate mode parameters. Click OK.
Now that the Mode has been defined, create the CPI-C Side Information Profile, which the gateway will use as a connection name. From the menu select APPC and CPI-C. In the CPI-C destination names dialog box, (see Figure 8-13) click Add to add a new profile.
Figure 8-13 CPI-C Destination Names Dialog Box
In the CPI-C destination dialog box, (see Figure 8-14) enter the Profile name, Partner TP, Partner LU, mode and Security option. The default TP name of the mode DRDA Server will typically be a Service TP named 07F6C4C2
. For the Partner LU, enter either the full LU name or the alias created previously. Enter IBMRDB
for the mode name. Lastly, choose the type of security these sessions will use. This will affect how session authorization is done. Click OK.
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 HP9000 host LU and the DRDA Server LU.
SNA and its various access method implementations (including SNAPlus2 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 HP9000 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
.
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 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 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.
SNA Security Option SECURITY=SAME
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, SNAPlus2 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.
Before proceeding with the gateway configuration tasks in Chapter 11, "Configuring the Gateway", ensure that your connection is working. Do this by starting the SNAPlus2 Node and then starting the individual link stations.
Figure 8-15 shows the relationship between SNAPlus2 definitions and the VTAM definitions on the remote host.
Figure 8-15 Relationship between SNAPlus2 Definitions and Host VTAM Definitions