Novell is now a part of Micro Focus

Managing Host Connectivity with NetWare for SAA and NDS

Articles and Tips: article

KEVIN PIDD
Technical Specialist
Asia Pacific Technical Support Centre

01 Jun 1999


Thanks to Rich Hanley of Network System Integrators for his contributions to this AppNote.

Managing and controlling client access to IBM host systems has long been the Holy Grail for system administrators with NetWare connections. Here's a look at the latest version of NetWare for SAA, which promises simpler maintenance and greater control via NDS.

Introduction

With the release of NetWare for SAA version 4, Novell and IBM are continuing the development and enhancement of a product that enables network administrators to manage and control client access to IBM host systems. The first directory-enabled version of NetWare for SAA, version 2.2, was released in December 1996. NetWare for SAA version 4 builds on version 2.2 and subsequent releases of NetWare for SAA to provide tighter integration with Novell Directory Services (NDS). Many applications and clients are now available from vendors such as Novell, IBM, WRQ, Attachmate, Wall Data, and others that use NDS to provide simpler and more controlled access to host systems.

This AppNote discusses aspects of configuring your network for NetWare for SAA, extending the NDS schema, and creating and maintaining NDS objects.

Since this AppNote was written in Australia, it retains the British spelling used by the author.

Configuring NetWare for SAA

Traditional configuration of NetWare for SAA clients and applications involves a number of options that determine the characteristics of the host session required. In the past, these emulators were written to Novell's Queue Element/Message Unit (QEL/MU) specification. QEL/MU was the original 3270 emulator specification written to interface clients with Novell's SNA Gateway and then with NetWare for SAA. A sample of a QEL/MU configuration is shown in Figure 1.

Figure 1: Example of a traditional QEL/MU emulator configuration.

Emulators that are written to this original specification and that have not been updated to QEL/MU with NDS support are bindery-based, unaware of NDS. NetWare for SAA continues to support QEL/MU clients, but because these clients are bindery-based, bindery emulation must be enabled at the NetWare for SAA server. The user objects that will use NetWare for SAA services must exist within one of the bindery contexts specified on the NetWare for SAA server. In the 3270 environment, the following configuration choices usually need to be made at the client.

Transport Protocol: TCP/IP or IPX

NetWare for SAA is a "split-stack" gateway as used in the centralised model. A centralised gateway uses native SNA to communicate with the host and routable protocols such as IPX/SPX or TCP/IP to communicate with the clients. This avoids the need to move SNA across the internetwork as is done in the distributed gateway model. (NetWare for SAA may also act as a distributed gateway when configured as an APPN network node.)

NetWare for SAA has always offered a choice of client transport: IPX, IP, or AppleTalk. NetWare for SAA sessions operate at the Transport Layer and use TCP or SPX to communicate from client to server. As these sessions do not use NetWare Core Protocols, they do not consume a NetWare-licensed connection on the NetWare for SAA server. This also means that TCP/IP connections do not require NetWare IP on a NetWare 3 or 4 server, native TCP/IP is sufficient.

The server configuration for transport protocol is minimal as it requires only two steps. The protocol must be loaded and bound in the AUTOEXEC.NCF file (see Figure 2) or enabled with the INETCFG utility.

Figure 2: Loading TCP/IP from AUTOEXEC.NCF.

The appropriate protocol must then be checked in the COMMEXEC configuration (see Figure 3) to cause the appropriate NetWare for SAA connection manager NLM (CMTCP.NLM or CMAT.NLM) to load.

Figure 3: Enabling TCP/IP in the Communications Excutive.

Server Name

This will be the name or TCP/IP address of the NetWare for SAA server. There may be more than one choice if load balancing or hot standby are in use.

Service

In this case, "service" refers to the name of the NetWare for SAA profile or host link. The profile or host link name will refer to a description of link control configuration. There may be multiple configurations to different hosts or even the same host to allow redundant paths for hot standby.

LU Name

Here you need to choose the type of LU from public, pooled, or dedicated. In the case of pooled and dedicated, you need to enter the pool or dedicated LU name so clients are able to nominate the pool or dedicated LU they require.

Session Type

This option selects 3270 Display or 3270 Printer. A printer will require a dedicated or pooled LU.

Model ID

3270 displays come in a number of flavours according to their screen format. Models 2, 3, 4, and 5 corresponding to a row and column format of 24 x 80, 32 x 80, 43 x 80, and 27 x 132 respectively, can be requested in this option. 3270 printers can be of LU type 1 or 3 depending on the host datastream. Configuration of the specific printer type is not necessary as NetWare for SAA identifies the printer from the bind at session initialisation and configures the printer automatically.

For AS/400 clients, several configuration options are required (see Figure 4). The transport protocol and NetWare for SAA server name need to be entered as in the 3270 example.

Figure 4: Example of traditional AS/400 client configuration.

Local LU Name. This is the APPN Name of the client and will match the name of the device description on the AS/400. This device description is normally created by the AS/400 at connection time using the AUTOCREATE feature.

Common User ID. This is the user name to be used on the AS/400.

AS/400 Link Systems. This is the AS/400 system name which is normally the serial number of the AS/400 and can be obtained via the DSPNETA command on the AS/400 console.

The server-centric approach to management of these configuration profiles is to store them centrally on a server. This approach is simple in an environment with a single server, but becomes complex in a large organisation that is taking advantage of distributed computing. It is typical that a NetWare for SAA gateway will be dedicated to that gateway task and may be duplicated for load balancing and hot standby purposes. A server-centric approach requires that the user identities be duplicated across all servers that a user may access, which can become a complex task in an enterprise environment.

The solution to this distributed configuration is to centralise the configuration for all clients and applications in the directory. The extensible schema of NDS allows developers to enhance the directory and design new attributes that describe directory resources. NetWare for SAA is an example of an application that takes advantage of the directory in this way.

NetWare for SAA Schema Extensions

NetWare for SAA extends the NDS schema by adding three new objects and five new attributes for user objects. The new objects are Commexec, NetWare for SAA Server, and Server List. These new objects have two main purposes:

  • To provide the system administrator with the ability to configure host access properties at the user, group, or container level

  • To allow applications that use NetWare for SAA to obtain information about network resources

The NDS schema is extended upon the installation of the first NetWare for SAA server into the tree. For this reason, supervisory rights are required to the [ROOT] of the tree for this first NetWare for SAA installation. Subsequent installations only require supervisory rights to the container in which the Commexec and NetWare for SAA objects will be created. When NetWare for SAA is installed from the file server console, an NDS user name will be requested during the installation program. This user must have the Write Property right to the Object Trustees (ACL) Property of the [Root] or the Supervisor Object right to the [Root] to extend the schema. See the table below for a list of the rights required at the different stages of installation.


Task Description

Rights Required to Complete Task

Installing the first NetWare for SAA gateway into the Directory. This extends the schema.

Write Property Right to the Object Trustees (ACL) Property of [Root]

Supervisor Object Right to [Root]

Create the Comm Services and NetWare for SAA objects in the Install container.

Create Object Right to the Install container

Write Property Right to All Properties of the Install container

Installing servers after the schema has been extended when the Install container and the User Context container are the same container.

Create Object Right to the container

Read, Compare and Write Property Rights to All Properties of the container

Installing servers after the schema has been extended when the Install container and the User Context container are different containers.

Create Object Right to the Install container

Write Property Right to All Properties of the Install container

Create Object Right to the User Context container

Read, Compare and Write Property Rights to All Properties of the User Context container

Installing just the source files on the gateway without creating any Comm Services or NetWare for SAA objects.

Supervisor Object Right to the File Server Object

Rights granted to the Commexec Server Object during the installation of NetWare for SAA. (These are also the rights that must be granted to the Commexec Server Object if you want to change the gateway's user context.)

Browse Object Right to the User Context container

Read, Compare and Write Property Rights to All Properties of the User Context container

Administering NetWare for SAA in NWAdmin

To administer these schema updates, NWAdmin must also be updated. This can be done by installing the NetWare for SAA client configuration utility. For NetWare for SAA 4, this will install the client configuration extensions to NWAdmin in the following directories:

  • SYS:PUBLIC\WIN32\

  • SYS:PUBLIC\WIN32\SNAPINS\95ONLY\

  • SYS:PUBLIC\WIN32\SNAPINS\NTONLY\

If NWAdmin is executed from a server other than the NetWare for SAA server, these snap-ins can be installed on other servers using NWCONFIG (NetWare 5) or INSTALL (NetWare 4) from the \SNAPINS directory on the CD-ROM (see Figure 5).

Figure 5: Client configuration snap-ins installation console.

Creating NDS Objects

The NDS objects required by NetWare for SAA may be created during the software installation of NetWare for SAA or at a later time. The installer may not have the required rights to the containers that will be affected, or the installation may be performed in a staging centre with the ultimate destination of the NetWare for SAA server yet to be finalised. This portion of the installation can be completed at a later date by unchecking the "Create CommExec and NetWare for SAA NDS Objects" option in the Select Options panel at the beginning of the installation program. In this case, the NDS objects will be created when COMMEXEC is first loaded.

The "NetWare for SAA Object Installation" panel allows you to enter two pieces of information: an NDS user name and a context (see Figure 6).

Figure 6: NetWare for SAA Object Installation console.

The NDS user name is the name of a user who has rights to create the NetWare for SAA NDS objects in the container where NetWare for SAA is to be installed, the rights to give COMMEXEC trusteeship of the USER CONTEXT container, and (if this is the first NetWare for SAA 4 server in the tree) rights to update the schema.

The purpose of entering the User Context is to specify which users will, by default, have access to NetWare for SAA resources. Users in this specified container will have rights to use NetWare for SAA resources and, due to inheritance, so will users in containers below.

For example, if you specify a user context of LON.CORP.EMA, this will grant access to those objects in LON.CORP.EMA, ACCT.LON.CORP.EMA, and ENG.LON.CORP.EMA, but not to any objects below or in PAR.CORP.EMA. The default user context is [ROOT], which enables access for everyone in the tree. It makes sense to set this user context as high as possible in the tree but not so high as to cause excessive tree walking, especially if that walk involves crossing a WAN link.

The Commexec object will be named COMMEXEC_<server name<. This object has no configuration details, but it is very important as it determines who can and cannot use NetWare for SAA resources. The Commexec object is granted Browse Object rights and Read and Compare Property Rights to all properties in the container specified in the User Context field.

If rights to NetWare for SAA resources need to be assigned to an object or container that is in a different part of the tree, you can assign those rights manually with NWAdmin.

The NetWare for SAA server object is also created during installation and will be named in the format <server name<_NWSAA (see Figure 7).

Figure 7: Objects created by NetWare for SAA install.

This new object is primarily used by applications. Applications can use this object to store configuration information. The NDS attributes of this object are also used by user objects, as discussed later in this AppNote.

The Server List object is the object that contains most of the configuration options the administrator is interested in. This object will be referenced each time a user connects to NetWare for SAA services. The server list will be configured for a list or a scope of NetWare for SAA servers. If the list is chosen, you can explicitly define up to four NetWare for SAA servers and individually nominate the transport protocol (IP or IPX) and whether client server encryption is enabled. This server name can be browsed with NWAdmin, or the dotted decimal IP address can be entered if the connection is to be IP.

You can also specify an asterisk ( * ) for the server name to allow any available NetWare for SAA server to be used. With this method, more than four NetWare for SAA servers can be referenced.

For IP clients only, you can also configure a scope. Configuring a scope allows TCP/IP clients that support the Service Location Protocol (SLP) to access a group of servers (see Figure 8).

Figure 8: Server List configuration panel.

The list of servers configured in the server list allows the client to choose between any of those servers to take advantage of any of the following NetWare for SAA features:

  • Rollover. This is the ability to search the servers for a particular LU resource. For example, the user may be a programmer who requires a Model 5-wide screen format. If no free Model 5 sessions are available on the first NetWare for SAA server in the server list, NDS will search sequentially through the list of servers to find an available session.

  • Load Balancing. Load balancing is achieved by configuring LU pools on multiple NetWare for SAA servers. NDS searches through the server list to find the least loaded server with the required pool. If all servers are equally loaded, then the CPU speed and RAM of the NetWare for SAA servers will be factored in to choose a server.

  • Hot Standby. A NetWare for SAA server can be configured to monitor a critical NetWare for SAA server. If the critical NetWare for SAA server goes down, the hot standby server will activate a backup configuration, and clients who were connected to the critical server will find this alternate server through the server list. In practice, hot standby and load balancing are usually used concurrently so that all NetWare for SAA servers monitor and balance each other in a round-robin configuration.

Schema Updates

The next part of the schema update for NetWare for SAA deals with new attributes for existing objects. Five new properties have been added:

  • 3270/LUx Configuration

  • AS/400 Configuration

  • LU6.2 Configuration

  • LU6.2 Attach Manager

  • CPIC Side Information

For our purposes here, we will just look at the 3270/LUx and AS/400 clients and their configuration requirements.

3270/LUx

If you are using a 3270 client emulator, use this attribute to configure a definition record that is used to provide that 3270 client emulator with the information it needs to connect to the mainframe.

Clients that are written to QEL/MU with NDS support and LUA API specification can make use of the 3270/LUx definition record. The LUA API specification is Novell's recommended implementation due to its flexibility and because any future API enhancements will be added only to the LUA specification. The NetWare for SAA 4 Software Development Kit can be downloaded from http://developer.novell.com/ and this SDK is supported by IBM at http://www.software.ibm.com/network/commserver/partners/support/inwsaa.html.

In the 3270/LUx dialogue box, you can add a session name to associate the 3270 definition record with an NDS object. The definition record can be assigned at the container level so user objects have access to these records by inheritance. The definition record may also be assigned to a group and the user object will have access to the records via group membership. If more than one definition is available, you can set a default session to verify which record is used (see Figure 9).

Figure 9: NetWare for SAA session configuration panel.

With NetWare SAA 4, you also have the option to limit the number of 3270 sessions a user may establish. In previous versions of NetWare for SAA, this was only achievable with the "Limit concurrent sessions" value of login restrictions. If the value is undefined, it will use an inherited value if it exists; otherwise there will be no limit. Setting login restrictions to "OFF" will override any inherited value. If both a Session Limit value and a Limit Concurrent sessions value are defined, the lowest value is used.

The definition record name is informational and can contain up to eight alphanumeric characters. Up to four explicit links can be defined to search for the required NetWare for SAA resources, or Link 1 can be set to "*" (the default) to search any available link.

The Link Name corresponds to the Link Name of the NetWare for SAA server. The Link Name must be unique on the NetWare for SAA server, but it can be duplicated on all or any NetWare for SAA servers in the server list.

The LU Category, Dedicated LU Name, LU Pool Name, Session Type, and Model Number are all optional parameters and correspond explicitly to those parameters previously configured for the client.

The server list parameter must be set, and this parameter will be the distinguished NDS name of the server list object. This parameter has a browse button so the server list name may be obtained directly from NDS.

AS/400 Configuration

AS/400 clients that are written to WINAPPC or EHNAPPC APIs can take advantage of an NDS-stored configuration. NetWare for SAA ships with a NetWare for SAA client, which is a set of SNA API programs and utilities for 32-bit platforms (Windows 95, 98, NT, and OS/2). One of these utilities is AS400 Connections, which an LUA emulator may use to connect to AS/400.

The AS/400 Configuration in NWAdmin allows you to enter all the information previously configured at the client directly into NDS. The properties that require configuration for the user to connect through an NDS-enabled emulator are described below.

  • The AS/400 Configuration describes the AS/400 Systems that the user, containers, or group objects can access.

  • The Host System Name will be the APPN name of the AS/400, as determined by the DSPNETA command. Host System entries may be inherited through NDS or group memberships. The Host System may contain a username and password for the AS/400 system. As multiple AS/400s can be specified, a specific AS/400 may be nominated as default. If a common UserID is used on multiple AS/400 connections, the username and password can be set on this panel.

  • The usual mode for Client Access/400 is QPCSUPP (the default). Alternate modes can be set as required. Modes are simply a set of session characteristics that the transaction program will use. These include parameters such as window size, maximum RU size, Class of Service, and so on that are used in APPN networking. If the default modes are not suitable, then the required mode will normally be supplied by the transaction program developer.

As client connections to an AS/400 are always from LU6.2 nodes, it is also necessary to configure the LU6.2 Configuration Panel (see Figure 10). The only compulsory configuration option you need to enter is the Server List object. This is the fully-distinguished name, usually selected with the browse button.

Figure 10: LU6.2 configuration panel.

If load balancing is turned on, the client load will be distributed amongst the servers nominated in the Server List object. An important point to remember is that load balancing requires all servers to use the same transport protocol—either IP or IPX. If the load balancing property is enabled, it will be effective only if there are suitable servers in the server list.

The Conversation Limit function is equivalent to the Session Limit in the 3270/LUx Definition. If this parameter is set, it is important to remember that application suites like Client Access/400 require multiple sessions so that each activated application requires a separate LU6.2 pipe.

Client Access/400 Configuration

Now we can look at the client configuration for a Client Access/400 user. In the example below, we will consider IBM's Client Access/400. Client Access/400 provides a suite of applications such as 5250 terminal emulation, printing services, file transfer, and so on. Similar suites are available from vendors such as Attachmate, NetManage, and WRQ.

Client Access/400 takes advantage of the NetWare for SAA client that is supplied with NetWare for SAA, requiring that this client be installed first. The installation files may be copied to the NetWare for SAA server during the NetWare for SAA installation by checking the "Copy Client API Install Images to Server" option in the Select Options panel. Otherwise they may be found on the NetWare for SAA CD-ROM. Versions of this client are supplied for Windows 3.1x, 95, 98, and NT, OS/2, and DOS. For the purposes of this example, we will only look at the 32-bit Windows installation.

To initiate the install, execute SETUP.EXE from the directory SYS:SYSTEM\ NWSAA\APIS\WINDOWS\WIN32\language\. NetWare for SAA and its clients are available in English, French, Spanish, German, Italian, and Portuguese.

The 32-bit Windows NetWare for SAA client has four components (see Figure 11):

  • SNA API Client

  • Host Access API

  • Files on Demand and CPI-C for Java Class Libraries

  • AS/400 OLE DB Provider

Figure 11: NetWare for SAA client installation panel.

Selecting the "Typical" install option will install all four components, but only the SNA API Client is required for basic Client Access functions. The "Compact" option will install only the API client.

To complete the client setup, the next step is to install Client Access/400. To work with the NetWare for SAA client and NDS, the Client Access/400 client needs to be at least V3R1M3 and the corresponding licensed program must be installed on the AS/400. This can be verified via the GO LICPGM command at the AS/400 console.

To install Client Access/400, execute \WIN95NT\SETUP.EXE. This will ask you to acknowledge that Client Access requires a license for certain nominated components of Client Access, which can be verified with the WRKLICINF command at the AS/400 console. You will also be asked to choose an installation type (\Typical\ is suitable), create program groups, and finally reboot the workstation.

To configure Client Access/400 to connect to the AS/400, you need to create an AS/400 configuration using the following steps:

  1. Right-click on the Windows desktop and select New | AS400 System.

  2. In the Communications panel, select NetWare for SAA (32-bit) as the provider (see Figure 12).

    Figure 12: Client Access/400 communications provider selection panel.

  3. Enter the AS/400 system name.

  4. Enter a Default User ID.

  5. Choose a default view from the options:

    • AS/400 Operations Navigator (manages CA/400 applications)

    • Graphical Access (this is 5250 emulation in a graphical format)

    • 5250 Emulation (traditional 5250 green screen)

    • Connect Only (establishes an LU6.2 connection to the AS/400 only—this option nominates an application to be started automatically, other applications can be started as required from the AS400 Client Access Group)

  6. The Verify Connection prompt will not function, as the NetWare for SAA client has not started, so this step can be omitted at initial configuration.

Once the above configuration is complete, clicking on the <system name<.as4 icon will establish a connection to the AS/400 and start the application nominated as the default view (see Figure 13).

Figure 13: Client Access/400 Operations Navigator.

All of the configuration details that needed to be entered in previously at the workstation (such as NetWare for SAA server, link details, and so on) are now included in NDS and will be read from the user, group, or container object when the user accesses NetWare for SAA resources.

Summary

This AppNote has described how NetWare for SAA leverages NDS as a directory and how NDS contains extended information relevant to the application at hand. It has reviewed the typical configuration options for 3270 and AS/400 clients without NDS configuration, and then compared these same options to an NDS object implementation.

For more information about NetWare for SAA, visit:

http://www.novell.com/products/host

For support and technical information, visit:

http://www.software.ibm.com/network/commserver/support/

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates