A suggested procedure for installing and configuring the software for your network follows:
This chapter provides the information necessary for completing the suggested procedure.
A template configuration defines the configuration information common to a group of servers. You may want to create one or more template configurations. Each server configuration file starts with the template configuration, and can contain the few parameters required to customize the configuration for that server. This results in simplified server configuration.
The template configuration can also be used to specify configuration options that cannot be specified using response files.
For information on how to use response files and template files for configuration and installation, refer to Configuration with Template and Response Files.
Remember to accumulate totals for RAM and fixed-disk space requirements for each workstation as you gather information in the following steps. That way, you can ensure that you have adequate hardware for your users when they start using the software you have chosen for them.
If you have already determined that you can use existing servers, you need to make sure that the existing hardware has adequate memory and fixed-disk space. The existing hardware must also have the correct system units, displays, printers, keyboards, adapters, modems, and cables for the software that is going to be installed.
If you are going to acquire new servers, record the hardware on the worksheets you prepare for those users.
Refer to Quick Beginnings for storage requirements for Communications Server.
When planning the hardware for running Communications Server, it is important to assess how the server will be used in terms of capacity. Determine what type of sessions Communications Server will support. These include, but are not limited to, TN3270E sessions, SNA API client sessions, and traditional SNA sessions to a host. Based on this number, you can calculate the average load on the server and determine the correct amount of memory for the server.
|Note:||These estimates are in addition to the requirements of the base operating system (Windows NT Server or Windows 2000 Server) and any other applications running simultaneously on the same system.|
Use the following table to determine what the average load on the server
Table 32. Memory Capacity
|Client Session Type||Memory Usage per Session|
|SNA Gateway (traditional)||29.9 KB|
|SNA API client||25.2 KB|
The estimated memory consumption of an active Communications Server without
any active links or sessions is 21 MB. To minimize performance loss, it
is best to reduce the amount of paging (swapping of memory segments out to
disk) that occurs. Try to have as much real memory available in the
system as required by the running software, with an additional 5 - 10 MB left
as a buffer. For example, a Communications Server installation
supporting 1 000 TN3270E client sessions would require the following amounts
of memory (based on the values in Table 32).
|Microsoft Windows NT Server operating system||19.0 MB (estimated)|
|Communications Server for Windows NT||21.0 MB|
|TN3270E sessions (1 000 X 15.8 KB)||15.8 MB|
|Total Memory Recommended||65.8 MB|
|Note:||The 65.8 MB is not a required amount of memory for 1 000 TN3270E sessions. It is a recommendation for best performance.|
When determining the minimum processor speed required, you need to understand the average number of transactions that will have to be processed by the server each minute. A transaction is any exchange of information between the client and the host through the server, whether it is a screen refresh or a requested database entry.
When calculating the average CPU load, multiply the average number of
sessions with the average number of transactions per minute per session and
the scale factor from the following table (based on session type).
|Client Session Type||CPU Load Factor (100 Mhz)||CPU Load Factor (166 Mhz)|
|SNA Gateway (traditional)||.004||.002|
|SNA API client||.021||.011|
For example, to support 1 000 concurrent TN3270E sessions, with an average of 6.7 transactions per minute, the average load on the 166 Mhz CPU would be 1 000 X 6.7 X .006, or 40.2%. Performance degrades quickly when the CPU utilization exceeds 80%. A faster CPU would improve Communications Server and system performance. More users and transactions would be able to take advantage of the server simultaneously. While there is no maximum CPU speed supported by Communications Server, 100 Mhz is the recommended minimum.
Software applications have requirements in addition to the requirements for Communications Server. For more information, refer to the software application documentation.
Networks created with Communications Server require that you create and use numerous names for multiple objects on the network. Some of these names can be the same from server to server, but other names must be unique on the network to avoid conflicts among the servers trying to access network resources.
For example, two LANs might have some of the same domain names defined. As long as these LANs were not connected, no conflicts would occur. However, if they should be connected later to a backbone LAN, their names would then be in conflict on the LAN.
This means that you must create naming conventions. Naming conventions are rules and standards you use to assign names to the various network resources.
The following sections list the naming conventions for which you need to plan. If you already know what naming conventions you are going to use in your planning, record them while you plan for your network.
When you are creating naming conventions, you should determine:
If you are attaching a server to a host computer network, for example, you might find that most of the names you must use in your network are chosen for you by host personnel. In that case, for the physical units and logical units required by the host, you must record those given names for your server configuration files.
As another example, you might choose to name the servers of your network after the names of the people who use them. For a small network, this could be workable as long as the number of names is small and you are able to keep them unique. However, this would not work for a larger network because people's names are not generally unique. You have to create another convention for workstation names for a large network.
Whatever criteria you choose for the names, be sure to record them. That way, you can refer to the appropriate information any time you add new resources to your network.
Most names have to be unique within the network in which you use them. The following sections list the types of names you might encounter when you are planning for, installing, and configuring a network. You should preview these names before you begin planning your network so that you are familiar with them.
The following information is provided for each name:
Names used by more than one component are:
Network IDs are names given to networks and are used by all the servers and workstations (nodes) within the specific network to maintain a unique identity throughout all the connected networks. The network ID is also used in error logs and network management alerts associated with network system errors.
There are two ways of looking at networks. One way is as a physical network that consists of a "ring" in a token-ring environment or a "string" in an Ethernet or PC network environment. The other way is as a logical network that might not be the same as the physical network. Two or more physical networks (for example, two token rings and an Ethernet string) could be connected with the intent of keeping them in the same logical network.
The network IDs are unique among logical networks; otherwise the networks would be logically the same network. Within a logical network, LU names must be unique to avoid naming conflicts. Between logical networks, the network ID guarantees unique names. An LU name could be the same on two logical networks; however, the network ID for each logical network makes the fully qualified LU names unique. Even if the networks are not currently connected, the network IDs should be unique if you plan to bridge the networks in the future.
You should register your network IDs with IBM. This ensures that SNA networks can be interconnected at a later time without addressing conflicts. Contact an IBM Branch Office for more information about registering your network IDs.
The restrictions for network IDs are:
Passwords are security functions required by appropriately configured applications and services to protect data and to restrict access to resources.
Passwords do not have to be unique within the network. Passwords are user-specific.
The restrictions for LU-LU passwords are:
The restrictions for other passwords, such as those in CPI-C and AS/400 connections, are:
User IDs are unique identifying names you give to the users of your network resources so that they can access database, LAN, or host resources with emulation.
User IDs must be unique in the network.
The restrictions for user IDs are:
The types of names that you might have to specify in Communications Server are:
The control point (CP) is responsible for managing the node and its resources. In an APPN end node, the control point must communicate with the control point in an adjacent network node to obtain APPN network services. In an APPN network node, the control point must communicate with the control points in adjacent network nodes to manage the network. The control point directs such functions as adapter activation and deactivation, and link activation and deactivation, and assists LUs in session initiation and termination.
The control point name is the second half of the fully qualified CP name in the NODE definition of Communications Server.
Control point names must be unique within a network. However, a node can have multiple PU names that are defined in the connecting (LINK_STATION) definition and exchanged on XID3 to different hosts. These multiple PU names must be unique within the node and in the host being connected.
The PU and control point are not the same to subarea VTAM. A PU name for each peripheral node in a VTAM domain is defined at that VTAM, and represents the view VTAM has of the peripheral nodes. The PU names at VTAM are not known to the peripheral nodes; that is, VTAM does not send the PU names to the peripheral nodes. If you want the PU name at a peripheral node to be the same as the one defined at VTAM, you must coordinate this. It is recommended that you do this, but for SNA it is not required.
To VTAM, the control point is an LU, used for activating LU 6.2 sessions between the control point and a VTAM LU (for example, CICS). The control point name defined at the peripheral node must match an LU definition at VTAM if VTAM initiates LU 6.2 sessions to the control point. Otherwise, VTAM learns the control point name when the peripheral node initiates a session to a VTAM LU.
For Communications Server, the control point name (not including the network ID) is treated as both the local node control point name and its PU name. The only flow that contains the peripheral node PU name is an alert. However, when Communications Server (APPC/APPN) sends an alert, it includes the control point name (resource type is CP) in the alert, not a PU name. If emulators send a PU name in the alerts, the name is the same as the control point name (again, because Communications Server uses the control point name as the node PU name). Host focal point can be defined only on a link where the PU name is the same as the control point name. Further, host links with a PU name other than the control point name cannot have CP-CP sessions with the host or route APPN traffic over the link. All alerts include the control point name even if the alert is caused by a condition on a link using another PU.
The restrictions for local node names are:
Logical unit (LU) names are names given to SNA logical entities within a node that provide support functions for transaction processing. This enables them to communicate to other LUs on the network, including host applications.
The restrictions for LU names are:
The Sockets over SNA Gateway must have an LU name configured for the Gateway to successfully initialize. Sockets over SNA Gateway will dynamically define the configured LU name to Communications Server upon initialization.
Using a predefined naming convention for Sockets over SNA LU, names can help you:
For more information on mapping IP addresses to LU names, see Configuring AnyNet Sockets over SNA.
Ensure the consistency and uniqueness of the addresses within your network. Each address must be unique. The addresses that you define will depend on how you configure your network. The following sections describe the addresses for:
Record the addresses that you use to make sure, when necessary, that none of the addresses conflict and that they are consistent with the naming conventions you have chosen.
LAN adapter addresses are 12-character hexadecimal numbers encoded in the adapter card by the manufacturer (universally administered adapter address) or assigned by the network administrator (locally administered address). Each network adapter card in the workstation you are configuring for LAN communications must have a unique address.
You can use the universally administered addresses, also referred to as "burned-in addresses", for your network adapter cards, or you can assign locally administered addresses. LAN adapter addresses must be unique within the network. If you use locally administered addresses, ensure that the addresses are unique within the network.
Locally administered addresses offer a significant advantage in the event of an adapter failure that requires replacement of the adapter. You can transfer the existing address to the replacement adapter and avoid changing any of the configurations referring to this address. If you use universally administered addresses, you have to change the network adapter card address for all of the workstations that access the defective adapter card.
The limitations for configuring LAN adapter addresses are:
On the LAN, you might choose to use locally administered LAN adapter addresses. Thus, you are assigning hexadecimal numbers as the LAN adapter addresses to each of the LAN adapters instead of using the universal LAN adapter addresses built into the LAN adapters. You might decide to use a convention with the following criteria:
Universally administered addresses on Ethernet are in Ethernet format. You can specify the format type (Ethernet or Token-ring) when using locally administered addresses. When configuring the destination address in SNA connections, make sure that the address format is the same as that specified at the remote. With bridging, it is possible to be on a token-ring locally and have the remote station on an Ethernet and using an Ethernet format address (byte-swapped).
Station addresses are used to identify a secondary station to the network.
Secondary station addresses must be unique within a network. The primary station will communicate with a secondary station by using the secondary station address. The secondary will communicate with the primary by using its own address.
For point-to-point connections, if the secondary station supports the broadcast address X'FF', the primary will learn the remote secondary address. The secondary can specify any value between X'01' and X'FE'.
For primaries that do not support the broadcast address, the secondary station must be set to the same value that is defined at the primary. The value must be between X'01' and X'FE'.
|Note:||Most stations will support the broadcast address, so the secondary station address at the primary should use X'FF'.|
Negotiable stations have local secondary station addresses configured between X'01' and X'FE'. The secondary address of the station negotiated to secondary will be used.
For secondaries on a multipoint connection, the address must match the value specified at the node providing the multipoint primary server function. The address will be in the X'01' to X'FE' range.
X.25 addresses are used to identify resources communicating on X.25 networks. X.25 networks implement the CCITT recommendation defining the interface between data terminal equipment and packet-switching networks. X.25 addresses must be unique within a network. You can get these addresses from your X.25 network provider.
Internet Protocol (IP) addresses are used to route data through the network. Every TCP/IP host is assigned at least one unique IP address. The IP address assigned to the host does not define a host on the network; it defines a network interface on that host to a network.
A Communications Server node must have a unique IP address for each network interface routing TCP/IP data through the node. For example, a Communications Server node that is routing TCP/IP traffic over an SNA network (using the Sockets over SNA gateway function) needs unique IP addresses for both the SNA network and the TCP/IP network. The IP address of the TCP/IP interface identifies the Sockets over SNA Gateway connection to the IP network, while the IP address identifies the connection to the SNA network, which looks like a "virtual" TCP/IP network to the system.
An IP address consists of a 2-part, 32-bit address field:
The class of the IP address is determined by reading the first 3
(upper) bits of the address. As shown in Table 33, Communications Server supports address classes A, B, and
C. For more information, refer to Guide to Sockets over SNA.
Table 33. IP Address Classes Supported by Communications Server
of Bits for
For a dotted decimal
IP address in the form
a.b.c.d, the range of
values for a is:
8-bit network address;
24-bit host address
For example, 126.96.36.199 is a Class A IP network address.
16-bit network address;
16-bit host address
For example, 188.8.131.52 is a Class B IP network address.
24-bit network address;
8-bit host address
For example, 184.108.40.206 is a Class C IP network address.
Communications Server uses the configuration tools explained in the following sections. Refer to Quick Beginnings for more information about these tools.
The SNA Node Configuration application is a graphic window application that enables you to manage SNA configuration information. The application uses a tree view to organize the SNA configuration data to show the relationships between definitions. The user is given task assistance when building a configuration through an integrated task list, the online Tutorial, and context sensitive help. The application is responsible for building the configuration files for the user and verifying the data provided.
SNA Node Configuration can also be used to connect to a remote Communications Server and directly configure its resources. The user is able to remotely manage the configuration for a Communications Server anywhere in the network.
A remote administration client installs only the administrative applications on a client, including SNA Node Configuration. From this client, a user is able to fully administer and configure any Communications Server in the network.
Windows 95, Windows 98, Windows NT, and Windows 2000 remote administration clients use Windows NT or Windows 2000 domain security to authenticate the client connection to the server without reentering the userid and password. The client must be part of a Windows NT or Windows 2000 domain, either by participation in a Communications Server domain or logging in locally with a synchronized userid and password.
Remote administration client users outside of the Windows NT domain are required to provide the userid and password, either through a prompt or by storing these values in the client configuration file.
The authorized users for remote administration clients are maintained in the IBMCSADMIN local group, which is located either directly on the Communications Server or on the domain controller where Communications Server participates. This user group is created during installation and can be administered using the Windows NT or Windows 2000 User Manager application. Remote administration client users must be given user rights in the IBMCSADMIN group to log on locally to the server.
Communications Server SNA Node Configuration stores its configuration data into a human-readable ASCII configuration file. This enables the user to modify configuration files without using SNA Node Configuration. (Refer to the Configuration File Reference for more information about this file and its syntax.) Using this file, a network administrator can quickly make changes to the configuration using automated tasks such as scripting or software distribution services such as Tivoli TME10 or Microsoft System Management Server.
When creating configurations for a large number of servers to implement, the network administrator can create a template configuration file that represents the common configuration elements for all servers. Using a response file with only those changes necessary for each server, the administrator can distribute the template and response file and merge the two to create the target configuration. For detailed information on how to use template files and response files for configuration and installation, refer to Configuration with Template and Response Files.
Through Web administration, a user is able to modify a Communications Server configuration file by loading the file into an edit window. The changes are sent down to the server, verified, and saved for immediate use. The user can either stop and restart the server using the changes made, or apply the configuration changes to a running system.
The Communications Server template and response files enable you to create or modify a configuration using an editor. You can configure all of the Communications Server configuration keywords and parameters with response files. Both the template and response files have the same format as Communication Server configuration (.ACG) files.
|Note:||The format of the .ACG files is documented in the OCDNTS50.DAT file contained in the Communications Server installation directory (for example, C:\IBMCS). Refer to the Configuration File Reference for more information on the keywords and parameters used in the .ACG files.|
Template files can ease the mass distribution of configurations to remote servers. A template file can specify the keywords which are common to several servers. For example, if you have multiple servers to configure as SNA gateways with implicit client support, many of the keywords will be identical. You can create a template configuration file that reflects those common keywords.
You can use response files to add, modify, or delete keywords in a template file. The original template configuration file is left unchanged. A response file is merged into a template file by specifying the INCLUDE keyword at the end of the template file. For example, if a response file is named myconfig.rsp, the last line of the template file that will use the response file is INCLUDE = myconfig.rsp. When the template file and the response file are merged, you can give the resulting configuration file a name with the .ACG extension that distinguishes it from other .ACG files.
When you create configurations using template and response files, the verification utility searches directories in the following order:
To ensure that the verification utility can locate the template and response files, you should store them in the PRIVATE subdirectory. The PRIVATE subdirectory is also where the configuration (.ACG) files are stored.
The key field is the parameter in a keyword that names the keyword and uniquely identifies it from other keywords of the same type. The @KEY_NAME parameter specifies the key field for the keyword.
The key field is always the first parameter in a keyword that has a key field (for example, MODE_NAME in the MODE keyword).
Some keywords do not have key fields because they can only be specified once in a configuration file. An example of a keyword that can only be specified once is the TN3270E_DEF keyword.
When using the response file to add a new keyword definition, the entire keyword must be provided. The key field must be provided along with a unique value. If any subfields are omitted from the keyword, the defaults for those fields are used. For example, to add a MODE keyword to the configuration, the response file might contain the following keyword:
MODE=( MODE_NAME=MYMODE COS_NAME=#INTER CRYPTOGRAPHY=NONE DEFAULT_RU_SIZE=1 MAX_NEGOTIABLE_SESSION_LIMIT=8192 MAX_RU_SIZE_UPPER_BOUND=4096 MIN_CONWINNERS_SOURCE=4096 )
The content of the response file assumes that a MODE keyword with the parameter of MODE_NAME=MYMODE does not exist in the template. If it does, the parameters would have been updated with the values provided in the response file.
If the MODE_NAME parameter was omitted from the response file, an error would occur during the configuration verification because the MODE_NAME parameter could not be uniquely identified. Not all parameters available for the MODE keyword were specified in the response file. The remaining parameters use the defaults assigned by the OCDSNT50.DAT file. The resulting addition to the configuration would look like this:
MODE=( MODE_NAME=MYMODE AUTO_ACT=0 COMPRESSION=PROHIBITED COS_NAME=#INTER CRYPTOGRAPHY=NONE DEFAULT_RU_SIZE=1 MAX_NEGOTIABLE_SESSION_LIMIT=8192 MAX_RU_SIZE_UPPER_BOUND=4096 MIN_CONWINNERS_SOURCE=4096 PLU_MODE_SESSION_LIMIT=8192 RECEIVE_PACING_WINDOW=20 )
When using the reponse file to modify an existing keyword definition, the original keyword should exist in the template file. If it does not exist in the template file, the response file adds an entry to the new configuration. The key parameter must be specified in the response file to identify the target keyword. Only those parameters specified in the reponse file keyword are updated in the template file's keyword. Parameters not specified in the response file are left unchanged. For example, if the following MODE keyword is in the template file:
MODE=( MODE_NAME=#INTER AUTO_ACT=0 COMPRESSION=PROHIBITED COS_NAME=#INTER CRYPTOGRAPHY=NONE DEFAULT_RU_SIZE=1 MAX_NEGOTIABLE_SESSION_LIMIT=8192 MAX_RU_SIZE_UPPER_BOUND=4096 MIN_CONWINNERS_SOURCE=4096 PLU_MODE_SESSION_LIMIT=8192 RECEIVE_PACING_WINDOW=20 )
and the following keyword is specified in the response file:
MODE=( MODE_NAME=#INTER AUTO_ACT=10 )
the resulting configuration would have the following MODE keyword definition:
MODE=( MODE_NAME=#INTER AUTO_ACT=10 COMPRESSION=PROHIBITED COS_NAME=#INTER CRYPTOGRAPHY=NONE DEFAULT_RU_SIZE=1 MAX_NEGOTIABLE_SESSION_LIMIT=8192 MAX_RU_SIZE_UPPER_BOUND=4096 MIN_CONWINNERS_SOURCE=4096 PLU_MODE_SESSION_LIMIT=8192 RECEIVE_PACING_WINDOW=20 )
When using the response file to delete a keyword from the template, the key parameter and value that identify the keyword must be specified, along with the keyword DELETE. For example, if the template file specifies the following keyword:
MODE=( MODE_NAME=#INTER AUTO_ACT=0 COMPRESSION=PROHIBITED COS_NAME=#INTER CRYPTOGRAPHY=NONE DEFAULT_RU_SIZE=1 MAX_NEGOTIABLE_SESSION_LIMIT=8192 MAX_RU_SIZE_UPPER_BOUND=4096 MIN_CONWINNERS_SOURCE=4096 PLU_MODE_SESSION_LIMIT=8192 RECEIVE_PACING_WINDOW=20 )
and the response file contains the following keyword:
MODE=( MODE_NAME=#INTER DELETE )
the resulting configuration does not contain the #INTER mode definition.
The DELETE keyword can appear after a parameter=value specification or on a line by itself, either preceding or following the parameter. For example, the following uses of the DELETE keyword are valid:
MODE=( MODE_NAME=#INTER DELETE ) MODE=( DELETE MODE_NAME=#INTER ) MODE=( MODE_NAME=#INTER DELETE )
The DELETE keyword can not appear in front of a parameter=value specification on the same line. For example, the following use of the DELETE keyword is not valid:
MODE=( DELETE MODE_NAME=#INTER )
To delete all keywords of a particular type, or to delete one keyword that does not have a key field, only the keyword and the DELETE keyword are necessary. For example,
TN3270E_DEF=( DELETE )
The supported features for Communications Server are described below. Some or all of these functions might be supported for your connection type:
Communications Server supports DLUR for both local sessions and devices, as well as downstream sessions and devices. In either case, the local node must be configured to connect into an APPN network.
The AnyNet SNA over TCP/IP Gateway must be configured as an APPN network node. This will enable APPC sessions to be routed to appropriate SNA peer nodes.
SNA API clients give you the ability to run SNA applications without having to install an SNA communications stack, such as the Communications Server for Windows NT, on the same machine. Smaller, less powerful machines can thus be used to run the SNA applications while a centralized, more powerful machine can be dedicated as the SNA server for these SNA API clients.
SNA API clients support two types of applications: APPC (independent LU 6.2) applications and LUA API applications, such as 3270 emulators.
Review your applications to be sure you comply with any requirements they have. Specifically, check requirements for:
You need to determine how Communications Server will be configured and installed on your user's servers. You can:
If you choose to use response file configuration and installation, refer to Configuration with Template and Response Files.
After you have planned for your network and determined how you are going to implement your plan, you need to create user materials. This means that you should prepare documentation for installation, configuration, and daily use, and prepare backup procedures.
Prepare a set of customized documentation to assist your users in installing, configuring, and using Communications Server and local applications for their particular needs. The following sections contain suggestions for the kind of information you should include.
Quick Beginnings and online installation helps are available to assist your users in installing Communications Server. Your instructions should tell the user which of the following steps to perform when installing software:
You might need to provide network information, such as LAN adapter addresses, network names, and so forth.
If necessary, provide your users with the appropriate documentation.
The following materials are recommended for using Communications Server functions and APIs:
For the procedure to start or stop Communications Server, refer to Quick Beginnings.
If you have different instructions for starting or stopping, supply these instructions to your users.
Contact your host personnel.
Your instructions should include any special requirements for logging off systems or applications. This information can be obtained from your host personnel.
You should provide your users with procedures and other information for the application programs you might use on your network. Generally, you should provide:
Contact the application programmer for the preceding information.
For the procedures on problem determination and reporting, refer to Quick Beginnings.
Occasionally, your users might erase or change the configuration files, registry, file system, application programs, and other locally created programs or files. Also, your servers might experience erasures or unacceptable changes as well, especially when many users are accessing your server workstations throughout the workday.
Because of this, you need to prepare and document the backup procedures for your network. You might also want to change the attributes of selected files on your servers to Read-Only so your users cannot change them.
When you have completed planning for, installing, and configuring your network, and it is running on a daily basis, your remaining task is maintenance. You must plan for adding, changing, or deleting resources and users in your network, and plan for problem-solving.
You need to perform the same level of planning and implementation steps for the changes to your network that you performed for initial setup. You should follow the same steps for these changes to your network that you used for the initial planning, installation, and configuration.
Communications Server provides these tools to help you monitor the day-to-day performance of your network:
The following products can also assist you in daily management of your network: