|
Oracle Procedural Gateway® for APPC Installation and Configuration Guide
10g Release 1 (10.1) for UNIX Part No. B12175-01 |
|
|
|
|
Oracle Procedural Gateway® for APPC Installation and Configuration Guide
10g Release 1 (10.1) for UNIX Part No. B12175-01 |
|
|
|
|
The Oracle Procedural Gateway for APPC uses the SNA Advanced Program to Program Communication (APPC/LU6.2) protocol to communicate with an OLTP. APPC support on Solaris Operating System (SPARC 64-bit) is provided by the SNAP-IX product.
Read this chapter to learn how to configure SNAP-IX on a Solaris system to run the Oracle Procedural Gateway for APPC.
|
Note: When you are finished following the instructions in this chapter, go back to Chapter 5, " Configuring Your Oracle Network " to continue your network configuration. |
This chapter contains the following sections:
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 issue.
Note that for CICS, one security option is not supported by the gateway.
The following sections describe how to configure SNAP-IX version 6.
This section requires you to input parameters unique to your system to configure SNAP-IX version 6 properly. Before you begin, request these parameters from your network administrator.
All of the 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 Procedural Gateway for APPC requires a stored set of definitions, called Side Information Profiles, to support connections between the gateway and gateway 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 Logical Unit (LU), is described by a distinct profile type.
The gateway configuration can accommodate either independent or dependent LUs. If you choose to use dependent LUs, or are restricted to using dependent LUs, the gateway functions properly; if a dependent LU is correctly defined, then you do not need to make changes to the configuration of the gateway, nor should any changes be needed to the gateway server. However, Oracle recommends that you use independent LUs for the gateway because they support multiple parallel sessions or conversations. This means that multiple Oracle client applications can be active simultaneously with the same gateway server through the independent LU.
In contrast to independent LUs, dependent LUs support only a single active session. The CP (Control Point for the Node) 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 gateway 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 gateway 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 not be a 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 must be added to SNAP-IX. Additional Side Information Profiles should be defined to use the new dependent LUs. Gateway 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 /etc/opt/sna directory:
sna_node.cfg - SNA node definitions
sna_domn.cfg - SNA domain definitions
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.
The $ORACLE_HOME/pg4appc/sna subdirectory contains a set of sample SNAP-IX definition files for the gateway, created with the xsnaadmin. These sample files are sna_domn.cfg and sna_node.cfg. 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=<your_display:0 $ export DISPLAY $ xsnaadmin &
On startup of xsnaadmin, the main screen opens and displays the current configuration of the local SNA node.
From the Services menu select Configure Node Parameters. In the Node Parameters dialog box 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, select the Port type and click [OK].
In the SAP dialog box, 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].
When the Port has been defined, you must create a Link Station. The Link Station represents the SNA node of the remote host of the gateway 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, 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, select the Port previously defined and click [OK].
In the Link Station dialog box, 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 on [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. Press the [Advanced] button for additional parameters of the Link Station.
The Token Ring Parameters dialog box shows additional parameters of the Link Station. These parameters effect initial XID contact and retransmission times and limits. The defaults are normally sufficient. Click [OK].
When 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 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 gateway server host for the UNIX host. Click [OK].
Now define a Partner LU which represents the LU that the gateway server is using to communicate. From the Services menu select APPC and New Partner LUs and Partner LU on Remote Node. In the Partner LU dialog box, enter the Partner LU name and characteristics. The Partner LU name contains 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 can click on [Location] for a list. Then click [OK].
When 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 click on New to add a new mode.
In the Mode dialog box enter the Mode Name and other session parameters. The prescribed name for a gateway mode is "CICSPGA". 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 click on New to add a new Profile.
In the CPI-C destination dialog box enter the Profile name, Local LU name, Partner TP, Partner LU and mode, and Security option. The default TP name of the mode gateway server will typically be a Service TP. 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 "CICSPGA" for the mode name. Choose the type of security these sessions will use. This will affect how session authorization is done. Click [OK].
Before proceeding with the gateway configuration tasks, ensure that your connection is working. Perform this by starting the SNAP-IX Node and then starting the individual link stations.
Figure 8-1 shows the relationship between SNAP-IX definitions and the VTAM definitions on the remote host.
Figure 8-1 Relationship Between SNAP-IX Definitions and Host VTAM Definitions
When you have finished configuring the SNA communication package for Solaris, proceed to Chapter 10, " Configuring the OLTP " to continue configuring the network.
