|Oracle® Procedural Gateway for APPC Installation and Configuration Guide
Release 220.127.116.11.0 for UNIX
Part Number A96648-01
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:
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.
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.
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.
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.
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.
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.
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.
ATTACHSEC=PERSISTENT, specified on the CICS CONNECTION definition, requires capability that is not yet available in the gateway.
ATTACHSEC=LOCAL, ATTACHSEC=IDENTIFY, ATTACHSEC=VERIFY, and ATTACHSEC=MIXIDPE are fully supported by the gateway.
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.
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.
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.
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.
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.
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.
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.
Use the following commands to invoke xsnapadmin. The $DISPLAY environmental variable must be set appropriately. If you are running xsnapadmin from the local HP 9000 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.
Upon startup of xsnapadmin, the main screen will open and display the current configuration of the local SNA node.
nodename> dialog box, select the Port and type you are using and click [OK].
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.