This chapter describes configuring the SNAP-IX product on Solaris for usage with the Oracle Transparent Gateway for IBM DRDA. SNAP-IX provides SNA connectivity through the APPC/LU6.2 protocol between the Sun host and the remote DRDA Server. Read this chapter to provide information about creating server profiles.
This chapter contains the following sections:
The checklists for configuring the communication interfaces are:
This chapter requires you to provide values for parameters unique to your system in order to properly configure SNAP‑IX. 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 SNAP‑IX product configuration is done using the xsnaadmin
program. This tool is an X-Windows application which provides a graphical interface so that you can view and modify the current SNAP‑IX configuration and the current running state of the host SNA node.
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 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 SNAP‑IX. 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.
SNAP‑IX definitions are stored in the following two files, located in the directory /etc/opt/sna
:
These files are created and maintained with the xsnaadmin
tool. Maintenance of SNA definitions is normally done by a user with administrative authority. The following information is intended for the person creating SNA definitions for the gateway. You should have some knowledge of SNA before reading this section. To create the SNA definitions use the following information:
The $ORACLE_HOME/tg4drda/sna/snapix
subdirectory contains a set of sample SNAP‑IX definitions for the gateway, created with the xsnaadmin.
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.
This section describes the process of creating your SNA definitions for SNAP‑IX, using xsnaadmin.
All of the tasks described in this section are performed from within xsnaadmin.
All configuration is done using the various pull-down menus and panels in xsnaadmin.
The following configuration descriptions follow the samples provided. Please tailor the various SNA values for your local host and SNA network.
Use the following commands to invoke xsnaadmin.
The $DISPLAY
environmental variable must be set appropriately. If you are running xsnaadmin
from the local console, then $DISPLAY
should already be set. If you are running xsnaadmin
from a remote X display, then set $DISPLAY
to the host name or IP address of that display.
$ DISPLAY=xstation10.us.oracle.com:0 $ export DISPLAY $ xsnaadmin &
Upon startup of xsnaadmin,
the main screen will open and display the current configuration of the local SNA node. (See Figure 6-1)
From the Services menu select Configure Node Parameters. In the Node Parameters dialog box (see Figure 6-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 New Port. In the Add to <nodename> dialog box (Figure 6-3), select the Port type and click OK.
In the SAP dialog box (see Figure 6-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. Normally 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 dmesg
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 6-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 New Link Station. In the dialog box (see Figure 6-6) select the Port previously defined and click OK.
In the Link Station dialog box (see Figure 6-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. Choose the type of the Remote node, typically a network node. For Dependent LU traffic, specify the role of the remote node, typically 'host', 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 Advanced for additional parameters of the Link Station.
The Token Ring Parameters dialog box shows additional parameters of the Link Station (see Figure 6-8). These parameters effect initial XID contact and retransmission times and limits. The defaults are normally sufficient. Click OK.
Figure 6-8 Token Ring 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 New Local LU. In the dialog box (see Figure 6-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 UNIX 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 New Partner LUs and Partner LU on Remote Node. In the dialog box (see Figure 6-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. You may click Location for a list. Then click OK.
Create 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 6-11) click New to add a new mode.
In the Mode dialog box (see Figure 6-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 6-13) click New to add a new profile.
Figure 6-13 CPI-C destination Names Dialog Box
In the CPI-C destination dialog box, (see Figure 6-14) enter the profile name, local LU name, partner TP, partner LU and mode, and security option. The default TP name of the mode DRDA Server will typically be a service TP named 07F6C4C2
. For the local LU, you may specify a specific LU or choose the default LU. For the Partner LU, enter either the full LU name or the alias created previously. Enter IBMRDB
for the mode name. 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 host LU and the DRDA Server LU.
SNA and its various access method implementations (including SNAP‑IX 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 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.
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 in to 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, SNAP‑IX 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 SNAP‑IX Node and then starting the individual link stations.
Figure 6-15 shows the relationship between SNAP‑IX definitions and the VTAM definitions on the remote host.
Figure 6-15 Relationship between SNAP-IX Definitions and Host VTAM Definitions