6 Configuring SNAP-IX Interfaces

Sample SNAP-IX Definitions

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.

Configuring SNAP-IX

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.

Invoking xsnaadmin

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)

Configuring the SNA node

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.

Adding a Port

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.

Create a Link Station

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.

Create Local LUs

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.

Create Partner LUs

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.

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.

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 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

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.