8 Configuring SNAPlus2

Sample SNAPlus2 Definitions

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.

Configuring SNAPlus2

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.

Invoking xsnapadmin

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)

Configuring the SNA Node

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.

Adding a Port

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.

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

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

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

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.

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