Skip Headers

Oracle® Procedural Gateway for APPC Installation and Configuration Guide
Release 9.2.0.1.0 for UNIX

Part Number A96648-01
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

7
Configuring the SNA Communication Package on HP-UX

Oracle Procedural Gateway for APPC uses the SNA Advanced Program to Program Communication (APPC/LU6.2) protocol to communicate with an OLTP. HP-UX system support for APPC is provided by the SNAplus2 product.

Read this chapter to learn how to set up and configure SNAplus2 on a HP-UX system to run Oracle Procedural Gateway for APPC. This chapter contains the following sections:

This chapter contains the following sections:

Using SNA Security Validation

When an RPC request to start a remote transaction program is received by the gateway, the gateway attempts to start an APPC conversation with the OLTP. Before the conversation can begin, a session must start between the HP-UX Logical Unit (LU) and the OLTP 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 validation is carried out entirely by network software before the gateway and OLTP 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 HP-UX SNA profiles and in similar parameter structures in the OLTP to be accessed. Refer to the appropriate communications software product documentation for detailed information about this subject.

Specifying SNA Conversation Security

The PGA_SECURITY_TYPE parameter of the gateway initialization file allows you to specify either of three options that determine the security conduct of the LU6.2 conversation that is allocated with the OLTP. These options are part of the SNA LU6.2 architecture, but their precise behavior might vary depending on the particular OLTP system.

SNA Security Option SECURITY=NONE

If PGA_SECURITY_TYPE=NONE is specified, then the gateway performs no processing of the client user ID and password. The conversation is allocated with SNA option SECURITY=NONE.

SNA Security Option SECURITY=PROGRAM

If PGA_SECURITY_TYPE=PROGRAM is specified, then the gateway allocates the conversation with SNA option SECURITY=PROGRAM, and the following information is sent to the OLTP:

In general, SNA option SECURITY=PROGRAM tells the OLTP to authenticate the user ID/password combination using whatever authentication mechanisms are available. For example, if CICS/ESA is the OLTP, then RACF can be used. This is not always the case, however, because each OLTP can be configured to process inbound user IDs in other ways.

SNA Security Option SECURITY=SAME

If PGA_SECURITY_TYPE=SAME is specified, the gateway allocates the conversation with SNA option SECURITY=SAME and sends only a user ID, without a password, to the OLTP. In this case, SNAplus2 sends the owning user ID of the gateway server executable, $ORACLE_HOME/bin/pg4asrv, as the user ID. The user ID that is sent is not the Oracle user ID. This user ID can be viewed with the HP-UX ls command and can be changed by an authorized user with the chown command. Because this user ID is the same for all users of a given gateway instance, this option is of limited use.

.


Note:

The user ID sent is not translated to uppercase by SNAplus2. If your OLTP is running on a system which does not allow lowercase user IDs (MVS, for example), you must set up an uppercase user ID on HP-UX to be the owner of the gateway executable file.


SECURITY=SAME is similar to the HP-UX operating system authentication. It tells the OLTP that the user has already been authenticated at the originating side of the conversation. There might be configuration parameters or options on the server side that affect whether SECURITY=SAME conversations are accepted. When properly configured, the OLTP only confirms that the user ID itself is valid and then accepts the connection. As with SECURITY=PROGRAM, it is possible to change this behavior through configuration options in many OLTPs.

Processing Inbound Connections

Many OLTPs provide options for manipulating the security conduct of an inbound (client) APPC session request. Refer to the appropriate documentation for your OLTP for detailed information about this topic.

Note that for CICS, one security option is not supported by the gateway.

Steps for Configuring the Communications Interfaces

  1. Create SNAplus2 profiles for the gateway.

  2. Create SNA definitions for the gateway.

  3. Test the configuration.

The SNAplus2 Configuration Tool

All SNAplus2 product configuration is done using the xsnapadmin program. The xsnapadmin program is an X-Windows application which provides a graphical interface that you can use to view and modify the current SNAplus2 configuration and the current running state of the host SNA node. Refer to vendor for more information on using xsnapadmin.

Creating SNAplus2 Profiles for the Gateway

Oracle Procedural Gateway for APPC requires a stored set of definitions, called Side Information Profiles, to support connections between the gateway and remote server. Each profile consists of a profile name and a profile type, which is a set of fields describing the profile. The fields in a 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 Mode, Remote Transaction Program name and Logical Unit (LU), is described by a distinct profile type.

Independent Versus Dependent LUs

Oracle Corporation recommends independent LUs for the gateway because they support multiple parallel sessions or conversations. This means multiple Oracle client applications can be active simultaneously with the same OLTP through the independent LU.

Dependent LUs only support a single active session. SNAplus2 queues additional conversation requests from Oracle Procedural Gateway for APPC behind an active conversation. That is, conversations are single-threaded for dependent LUs.

If a dependent LU is correctly defined, no alterations to the gateway configuration are needed, nor should any changes be needed to the host transaction or how the OLTP is started.

The operational impact of dependent LUs is that the first client application can initiate a conversation through the gateway with the OLTP, and while that transaction is active (which could be seconds, to minutes, to hours, depending on how the client application and transaction are designed) any other client application initiating a conversation with the same OLTP instance appears to hang as it waits behind the previous conversation.

If a production application really only uses a single conversation or transaction at any one time, there should be no impact.

However, additional concurrent conversations or transactions might be required for testing or other application development. Each requires that additional dependent LUs be defined on the remote host, plus an additional SNAplus2 configuration file entry which defines the additional dependent LUs on the HP-UX workstation. The TIP which initiates the conversation must specify the different SNAplus2 Partner LU through a different Side Information Profile. Refer to "PGAU DEFINE TRANSACTION SIDEPROFILE" parameter in Chapter 2 of the Oracle Procedural Gateway for APPC User's Guide, and the SNAplus2 Symbolic Destination Name discussed in the section, "Sym Dest Name".

In some uses of the gateway, independent LUs cannot be used. For example, with the IMS LU6.1 Adapter for LU6.2, parallel sessions are not supported. In this case, multiple concurrent sessions with the IMS LU6.1 Adapter for LU6.2 can be achieved by defining a pool of dependent LUs. For each dependent LU, select the "LU in the pool of default LUs" option. When a conversation is requested, an available local LU from the default LU pool is assigned automatically by SNAplus2. For more information, refer to vendor documentation.

Sym Dest Name

This option lets you enter the side information associated with a particular symbolic destination name. You can use an alphanumeric string up to 8 characters as the "Sym Dest Name." The symbolic destination name is referred to as the side information profile in other parts of this guide. This name is specified by the SIDEPROFILE keyword in the DEFINE TRANSACTION statement used to define your transaction to PGAU.

The "Partner TP name" field specifies the name of the transaction to be executed on the OLTP side of the conversation. This field must be specified, but the TP name can be overridden by the gateway at conversation startup.

The "Partner LU" field specifies the LU name of the OLTP on the remote system. The "Mode Name" field specifies the mode name to be used for conversations with the specified OLTP.

The security information that can be specified in this menu is not usable for the gateway. The security parameters are always set by the gateway based on gateway initialization parameters.

Creating SNA definitions for the Gateway

SNAplus2 definitions are stored in two files, located in SNAplus2 /etc/opt/sna directory:

These files are created and maintained with the xsnapadmin tool. Maintenance of the 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.

Sample SNAplus2 Definitions

The gateway's $ORACLE_HOME/pg4appc/sna subdirectory contains a set of sample SNAplus2 definitions for the gateway, created with the xsnapadmin. SNA definitions are very specific to the HP 9000 host and SNA network; Thus, these sample definitions 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 the xsnapadmin tool. 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 configuration descriptions in the steps below follow the samples provided. You must tailor the various SNA values for your local host and SNA network.

Step 1 Invoking xsnapadmin
Step 2 Configuring the SNA node
    1. On the main screen of xsnapadmin, pull down the Services menu and select Configure Node Parameters.

    2. In the Node Parameters dialog box, enter the APPN support type, the Control Point Name, Control Point and Node ID as needed. The Control Point Name is composed of the SNA Network Name and the CP name of the local host.

    3. Click [OK].

Step 3 Adding a Port
    1. From the Service menu, select Connectivity and then select Add Port.

    2. In the Add to <nodename> dialog box, select the Port and type you are using and click [OK].

    3. In the subsequent SAP dialog box, enter a Port name and network card number. The Port name will be used to logically name the physical network card you are using and 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 lanscan command.

    4. Click [OK].

Step 4 Create a Link Station
Step 5 Create Local LUs
    1. Once 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.

    2. In the Local LU dialog box, enter the name of the local LU and an alias. This name must correspond to the VTAM definitions on the remote server host for the HP 9000 host.

    3. Click [OK].

Step 6 Create Partner LUs
    1. Now define a Partner LU which represents the LU that the remote server is using to communicate. From the Services menu select APPC and Add Partner LUs and Partner LU on Remote Node.

    2. In the resulting dialog box, 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.

    3. Enable parallel session support. The location is the name as the Remote Node name. You may click on [Location] for a list.

    4. Click [OK].

Step 7 Create Mode and CPI-C Profiles
    1. Once 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.

    2. In the Modes dialog box click on Add to add a new mode.

    3. In the subsequent Mode dialog box enter the Mode Name and other session parameters. The prescribed name for an APPC mode is "IBMRDB". Contact your Remote Host system administrator for appropriate mode parameter.

    4. Click [OK].

    5. 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, click on Add to add a new profile.

    6. In the CPI-C destination dialog box enter the Profile name, Partner TP, Partner LU, mode and Security option. The default TP name of the mode remote server will typically be a Service TP named "07F6C4C2".

    7. For the Partner LU, enter either the full LU name or the alias created previously. Enter "IBMRDB" for the mode name.

    8. Lastly, choose the type of security these sessions will use. This will affect how session authorization is done.

    9. Click [OK].

Testing the Connection

Ensure that your connection is working. Do this by starting the SNAplus2 Node and then starting the individual link stations.

Figure 7-1 shows the relationship between SNAplus2 definitions and the VTAM definitions on the remote host.

Figure 7-1 Relationship Between SNAplus2 Definitions and Remote Host Definitions

Text description of 6-1defs.gif follows.

Text description of the illustration 6-1defs.gif


Go to previous page Go to next page
Oracle
Copyright © 1996, 2002 Oracle Corporation.

All Rights Reserved.
Go To Table Of Contents
Contents
Go To Index
Index