| Oracle® Transparent Gateway for DRDA Installation and User's Guide 10g Release 1 (10.1.0.2.0) for Microsoft Windows Part Number B12010-01 |
|
|
View PDF |
| Oracle® Transparent Gateway for DRDA Installation and User's Guide 10g Release 1 (10.1.0.2.0) for Microsoft Windows Part Number B12010-01 |
|
|
View PDF |
This chapter describes configuration of the Microsoft SNA Server product on Microsoft Windows for use with the Oracle Transparent Gateway for DRDA. The SNA Server provides the SNA connectivity via the APPC/LU6.2 protocol between the Pentium-based host and the remote DRDA Server. Microsoft Host Integration Server is the successor product to Microsoft SNA Server, but retains the same configuration information as SNA Server, and steps for configuring SNA Server therefore also apply to Host Integration Server. Read this chapter to learn more about creating server profiles.
This chapter contains the following sections:
This chapter requires you to input parameters unique to your system in order to properly configure the SNA Server. Refer to Appendix E for a worksheet listing all the installation parameters that you will need to know before you can complete the configuration process. Ask your network administrator to provide you with these parameters before you begin.
The Oracle Transparent Gateway for DRDA requires a stored set of definitions, called Side Information Profiles, to support connections between the gateway and DRDA Servers. Each profile consists of a profile name and a profile type, 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.
Oracle Corporation recommends independent LUs for the Oracle Transparent Gateway for DRDA, because they support multiple parallel sessions or conversations. This means multiple Oracle client applications can be active simultaneously with the same DRDA Server through the independent LU.
Dependent LUs only support a single active session. The CP (SNA Server for Microsoft Windows, in this case) queues additional conversation requests from the gateway server behind an already active conversation. In other words, conversations are single-threaded for dependent LUs.
If a dependent LU is correctly defined, then no alterations to the Oracle Transparent Gateway for DRDA configuration are needed, nor should any changes be needed to the DRDA Server.
The operational impact of dependent LUs is that the first client application can initiate a conversation through the gateway with the DRDA Server. 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 DRDA Server appears to hang as it waits behind the previous session.
If a production application really only uses a single conversation at any one time, then there should be no impact. However, additional concurrent conversations might be required for testing or other application development. Each requires that additional dependent LUs be defined on the remote host, plus additional SNA Server configuration entries which define the additional dependent LUs on the host.
Additional Side Information Profiles should be defined to use the new dependent LUs. New Transparent Gateway for DRDA instances should be created and configured to use these new Side Information Profiles.
SNA Server definitions can be created and modified in two ways:
Directly with the SNACFG command
Using menus in SNA Server Manager
Maintenance of SNA definitions is normally done by a user with Administrator authority. This information is intended for the person creating SNA definitions for the gateway. You should have some knowledge of SNA before reading this section.
The tg4drda\sna\mssna subdirectory contains a sample set of gateway SNA Server definitions created with the SNACFG command. The snacfg.ctl file contains sample definitions for SNA Server.
Before building the SNA Server definitions, examine the snacfg.ctl file to determine the definitions needed, their contents, and their interrelationships. The file format is text-oriented and each field of each definition is clearly labeled. You can print a copy of the file to use while working with your definitions in an SNA Server Admin or SNA Server Manager session.
You can create and modify these definitions in two ways:
Install the definitions directly on your system using the SNACFG command
For information on using the SNACFG command, refer to the SNA Server Administration Guide in the Microsoft SNA Server online documentation.
If you use this method, then you must use SNA Server Manager to review and modify the installed definitions. Because of configuration and naming differences, it is unlikely they will work without modification.
Create the definitions
SNA Server Manager is the recommended method for creating the definitions. You should be able to accept most of the defaults. The default values assigned to many of the fields in a new set of definitions are acceptable for the gateway.
There are several types of SNA Server definitions relevant to gateway APPC/LU6.2 operation. Each definition can be created and edited using a corresponding SNA Server Manager menu.
The definitions relevant to the gateway are presented here in hierarchical order. Those definition types that are lowest in the hierarchy are discussed first. This matches the logical sequence in which to create the profiles.
Refer to the Microsoft SNA Server online documentation for a complete discussion of SNA Server definitions. This section is an overview of SNA Server definitions in relation to the Oracle Transparent Gateway for DRDA for Microsoft Windows.
|
Note: Before beginning to create and edit profiles using SNA Server Admin, you must install the DLC protocol and create the link service. Prior to running SNA Server Admin, use the Microsoft Windows Control Panels Network Manager to install the DLC protocol. |
This section describes the process of creating your SNA definitions for SNA Server version 3, using SNA Server Manager. All of the tasks described in this section are performed from within SNA Server Manager. The other primary administration tool is the SNA Server Management Console. Both tools provide access to the same SNA definitions for the Node, but in slightly different views. The SNA Server Manager gives a localized view of the Node, while the SNA Server Management Console presents a more global view, where the local Node may be one of many SNA Nodes in a network that is managed by this machine. Later versions of SNA Server and Host Integration Server tools may reorganize the profiles placement within the definition tree, but the concepts remain the same. Some extrapolation by the user may be necessary.
Figure 6-1 SNA Server Manager Main Screen: Select a Server
The appropriate SNA Server must be selected to ensure that definitions created are for that server. Start the SNA Server Manager.
Click on the SNA Subdomain under your local machine (in this example, ITDEV11) and then click to open the SNA Servers folder. From a list of services for that server, select the SNA Service of your choice (in this illustration, ITDEV-NT11). Click to open it.
Each SNA Server must have a primary service definition. From the Service menu in the SNA Server Manager window, select Properties. In the Server Properties dialog box, under the General tab, change the Network Name and Control Point Name as needed. Click [OK].
A link service must be installed and configured in order for SNA Server to use the network adapter installed in your workstation. From the Insert menu, select Link Service. From the Insert Link Service dialog box, select the desired Link Service from the selection list and click the [Add] button. In this example, the DLC 802.2 Link Service is selected.
Now the Link Service Properties dialog box is displayed. Note that the contents of this dialog will vary, depending on which Link Service was selected. In this example, the DLC 802.2 Link Service Properties dialog is used:
Select the appropriate network adapter from the Adapter pull-down menu and click the [OK] button. From the Insert Link Service dialog box, click the [OK] button. The system now updates your network bindings.
You must create a connection definition to define the devices which SNA Server uses to perform SNA communication. From the Insert menu, select Connection and choose the connection type (802.2 is used in this example). The Connection Properties dialog box appears.
Select the General tab. Enter a Connection Name. This is the name used by SNA Server to name the connection. This example names the connection HQMVS2. From the Link Service pull-down menu, select a link service for the connection. All other settings can be left set to their default values.
Select the Address tab. Enter the Remote Network Address and the Remote SAP address.
Now select the System Identification tab. Under Local Node Name, enter the Network Name, Control Point Name, and Local Node ID. Under Remote Node Name, enter the Network Name, Control Point Name, and optionally, the Remote Node ID. The XID Type should be set to Format 3.
Next, select the DLC tab. In this example, the 802.2 DLC (Token Ring) is being used. For the 802.2 DLC, all of the defaults are usually acceptable. If you need to change any values, do so now. Now all of the connection properties are set. Click [OK].
You must create a local LU definition. The local LU definition describes the SNA LU through which the gateway communicates with DRDA Server systems.
From the Insert menu, select APPC Local LU. The Local APPC LU Properties dialog box appears.
Select the General tab. Enter the LU Alias, Network Name and LU Name. You should contact the person responsible for your SNA network to determine the correct LU and network names.
Select the Advanced tab. Check the Member of Default Outgoing Local APPC LU Pool box. Set the LU 6.2 Type to Independent to allow parallel sessions. Be sure the APPC Syncpoint Support box is not checked.
Now the Local LU properties are all set. Click the [OK] button to continue.
This definition describes an SNA mode entry to be used when establishing sessions between LUs. The mode defined here must match a mode defined on the target system.
From the Insert menu, select APPC Mode Definition. The APPC Mode Properties dialog box appears.
Select the General tab. Enter the Mode Name. The mode name that you specify must be defined to the DRDA Server communications software. Choose the mode name and other mode parameters after consulting the person responsible for configuring the DRDA Server communications software.
Next, select the Limits tab. Enter the Parallel Session Limit, Minimum Contention Winner Limit, Partner Min Contention Winner Limit, and Automatic Activation Limit. The Parallel Session limit determines the maximum number of concurrent conversations allowed between the gateway instance and the DRDA DRDA ServerServer. This equates to the maximum number of concurrently active remote sessions through the gateway instance.
Now, select the Characteristics tab. Enter the Pacing Send Count, Pacing Receive Count, Max Send RU Size, and Max Receive RU size. For optimal performance, check the High Priority Mode box. The pacing and RU size parameters are performance-related and should be tuned to suit your application. For most installations, the values set in the example will be sufficient.
Now all of the APPC mode properties are set. Click the [OK] button to continue.
This definition describes the SNA LU of the DRDA Server system with which the gateway communicates. You must create a remote LU definition for the remote DRDA Server system. From the Insert menu, select APPC Remote LU. The Remote APPC LU Properties dialog box appears.
Select the General tab. Determine the link with which to associate the LU (in the example, HQMVS2). Use the Connection pull-down menu to select the connection used to access this LU. Enter the LU Alias, Network Name, LU Name, and Uninterpreted LU Name. You should contact the person responsible for your SNA network to determine the correct LU and network names. Note that you can use the LU Alias to define a name known only to SNA Server, and that name can remain the same even if the remote LU name changes. This helps to reduce the amount of maintenance required when network changes occur.
Now select the Options tab. Check the Supports Parallel Sessions box. Use the Implicit Incoming Mode pull-down menu to select the mode. Set any security options you need.
The remote APPC LU properties are now set. Click the [OK] button to continue.
Once the Local and Remote Partner definitions and Mode definitions have been created, you can create CPI-C Symbolic Destination Names, also called Side Information Profiles. The Side Information Profiles are used to identify target DRDA Server systems to be accessed through the gateway. From the Insert menu, select APPC CPI-C Symbolic Name. The CPI-C Name Properties dialog box appears.
Select the General tab. Enter a Name for the Side Information. From the Mode Name pull-down menu, select the appropriate mode.
Figure 6-22 Enter CPI-C Name Properties Partner Information
Now select the Partner Information tab. Select Application TP and enter the TP name. Enter the Partner LU Name alias. Click the [OK] button to save the Side Information.
Before proceeding with the gateway configuration tasks in Chapter 10, " Configuring the Gateway", ensure your connection is working. This can be done using SNA Server Manager.
Figure 6-23, "Relationship Between SNA Server Definitions and Host VTAM Definitions" shows the relationship between SNA Server definitions and the VTAM definitions on the host.
Figure 6-23 Relationship Between SNA Server Definitions and Host VTAM Definitions
When the database link request for the gateway begins, the gateway attempts to start an APPC conversation with the DRDA Server. Before the conversation can begin, a session must start between the host Logical Unit (LU) and the DRDA Server LU.
SNA and its various access method implementations (including Microsoft SNA Server) provide security validation at session initiation time, allowing each LU to authenticate its partner. This is carried out entirely by network software before the gateway and server 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 Pentium-based host Connection Profile and in similar parameter structures in the DRDA Server system that is to be accessed. Refer to the appropriate Microsoft SNA Server and IBM Communication Server product documentation for detailed information.
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.
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 into 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.
