Chapter 4 - Planning a 3270/SNA Service

A 3270/SNA service consists of programs that run on both the PC and a VINES server. The service enables PCs to act as 327x terminals with IBM, or compatible, hosts that support Systems Network Architecture (SNA).

The service communicates with software in the user's PC to establish and manage communications sessions with the host. To enter emulation, the user runs the software through VINES menus or from the DOS command line.

The service uses a serial communications line or a Token-Ring LAN to transmit data to the host. All user sessions through a given service share the same communications line or LAN.

Each session uses at least one logical unit (LU). You can have as many user sessions with the host as you have LUs available to the service. Once a session is established, a user can log in and use applications and programs running on the host computer directly through the PC.

When a PC emulates a terminal, specific LUs, several concurrent sessions, a specific set of PC keyboard mappings, or a specific set of display colors and print settings are available to the user. These settings can be specified on the DOS command line, or in the VINES user profile. Settings made in the user profile take effect when the user enters emulation from the VINES menus. Settings specified from the DOS command line override any corresponding settings in the user profile.

As a network administrator, you plan, create and manage the service, and make it available to users. This chapter explains how to plan the service. The service you create must use the proper communications parameters and other information expected by the host computer and its controller. The sections that follow explain these aspects of planning the service configuration:

	Planning the number of LUs for the service.
	Planning the station characteristics of the entire service, which involves gathering information about the LAN and serial line used by the service.
	Planning the LU characteristics of the entire service, which includes information about the LUs such as type (display or printer) and security information.

This chapter assumes that you have completed all installation steps for 3270/SNA, as detailed in Chapter 3.

See Chapter 5, "Managing a 3270/SNA Service," for information on creating and managing the service, and making it available to users.

Planning the Number of Logical Units

The total number of LUs that you can configure for all the 3270/SNA services on a server depends on the number of LUs you purchase and the capacity of your server. For example, if you purchase the 3270/SNA option with 96 LUs, you can configure 96 LUs per server.

Some 3270/SNA options allow you to distribute the LUs among multiple services. With a purchase of 64 LUs, you can distribute the LUs between two services. With a purchase of 96 LUs, you can distribute the LUs among three services. You can distribute the LUs among these services any way you want. For example, if you purchase 96 LUs, you can configure 46 LUs for one service, and 25 LUs each for two other services.

Because you can allocate LUs to services in a flexible manner, reserve as many LUs as you need for all the required services to communicate with a specific host. This eliminates the need for creating multiple services to ensure that enough LUs are available for communication with a single host.

When you plan the number of LUs you want to configure for a service, ask yourself the following questions:

	How many LUs have you purchased for your server?
	Can you distribute the LUs among multiple services?
	How many users need to use the service at once?

Record the number of LUs that each service requires on either the Token-Ring Station Worksheet (see Figure 3-2) or the 3270/SNA Service Serial Line Configuration Worksheet (see Figure 4-2), depending on whether the service uses a Token-Ring card or a serial line.

Examples of LU Distribution

This section presents two examples of LU distribution. The first example presents a simple LU distribution problem. The second example presents a complex LU distribution problem.

In the first example, you have purchased 32 LUs for your server and you are responsible for 25 users who need simultaneous access to a single IBM host over a Token-Ring LAN. To meet this need, you must create one 3270/SNA service and configure 25 or more LUs.

In the second example, a server is connected to a Token-Ring LAN and a leased telephone line. The server communicates with two IBM hosts at the same site on the LAN, and with one remote IBM host on the leased line. A maximum of 96 LUs can be configured on the server.

To communicate with the hosts, the administrator creates one 3270/SNA service for each host - cics@sna@corp, tso@sna@corp, and db@sna@corp. The users for whom the administrator is responsible have the following needs:

	40 LUs to communicate with the host associated with cics@sna@corp. This host resides on the Token-Ring LAN.
	30 LUs to communicate with the host associated with tso@sna@corp. This host also resides on the Token-Ring LAN.
	26 LUs to communicate with the remote host.

Thus, the administrator configures 40 LUs for cics@sna@corp, 30 LUs for tso@sna@corp, and 26 LUs for db@sna@corp, as shown in Figure 4-1.

Planning the Station Characteristics

The station characteristics you assign to a 3270/SNA service depend on whether the service acts as a station on a serial line or as a station on a Token-Ring LAN. The next two sections help you to plan the appropriate station characteristics for a 3270/SNA service.

When you plan station characteristics, you must make the following considerations:

	Identify the serial line or Token-Ring card the service uses.
	Identify the LUs in the service.
	Decide whether each LU is a display or printer.
	Decide which users will have access to which display LUs.
	For each display LU, decide if the LU should send the TERMSELF signal to the host controller.
	Evaluate which users will need access to 3270/SNA, how often they will use the service, and what the host applications expect from the 3270/SNA service.

To make these decisions, you will need the assistance of a systems programmer or mainframe administrator at the host computer. Many of the station characteristics you assign to a 3270/SNA service must have matching characteristics in the host computer's configuration. It is a good idea to consult a systems programmer or mainframe administrator at the beginning of the planning process.

Planning Serial Line Characteristics

Before you begin creating a 3270/SNA service that acts as a station on a serial line, you should have information described in the next four sections.

Line Information

You need the slot and line number, type, (switched or leased), speed coding (NRZI (Non-Return-to-Zero Inverted) or no NRZI), and RTS value (Request to Send) (constantly high or not) of the serial port that the service will use. RTS affects line turnaround speed. See your systems programmer for the proper values.

Station Address

You need the SDLC station address (from 01 to FE hexadecimal) that the host system will use to transmit data to the server. The value you specify must equal the ADDR parameter that identifies the service in the VTAM configuration at the host. See your mainframe administrator or systems programmer for this information.

Device Type

You need the device type (3174, 3274 or 3276) of the controller that the service will emulate. If the service emulates a 3174 or 3274 controller and uses a switched line, the systems programmer at the host should code the VTAM IDBLK parameter for the service as 017 (hex). If the service emulates a 3276 controller, and uses a switched line, the systems programmer should code IDBLK as 018 (hex).

Consult the mainframe administrator or systems programmer to determine which type of controller the service should emulate.

Station ID

For a switched line, you must enter the station ID (XID) of the server as it is defined in the VTAM configuration of the host system. The XID must be in the range from 00000 to FFFFF hex. The value you specify in this field must equal the VTAM IDNUM parameter for the service in the VTAM configuration at the host. See your mainframe administrator or systems programmer for this information.

Figure 4-2 is a worksheet for setting up the configuration of services that use serial lines. Use a copy of it to record the necessary information.

Planning Token-Ring Characteristics

When you plan Token-Ring characteristics for a 3270/SNA service, keep in mind the following restrictions:

	For each Token-Ring card, you must configure one link station for each service that uses the card. See the section, "Configuring a Token-Ring Card," in Chapter 3 for more information on link stations.
	Try to avoid having multiple 3270/SNA services use the same Token-Ring card to communicate with the same host simultaneously. However, if you want to do this, the host must be configured with at least two Token-Ring cards and you must specify the remote address of a different card in each 3270/SNA service configuration.

Remember that if you have purchased 64 LUs or 96 LUs, you can distribute the LUs among your 3270/SNA services any way you want.

Before you begin creating a 3270/SNA service that acts as a station on a Token-Ring LAN, you should have information about the service's station characteristics at hand. These characteristics are as follows:

	Slot number of the Token-Ring card
	Transmit buffer size
	Logical link station (LLS) transmit window size
	Receive buffer size
	LLS receive window size
	MAXOUT increment
	Retry count
	Response timer
	Inactivity timer
	Receiver acknowledgment timer
	Station ID
	Remote address

Record the characteristics above on the Token-Ring Station Worksheet (see Figure 3-2). You should have already recorded the slot number of the Token-Ring card.

The Token-Ring characteristics are described in detail in the following sections. For all the characteristics except slot number, consult the systems programmer or mainframe administrator at the host for the proper values.

Slot Number

You must specify the slot number of the Token-Ring card that the 3270/SNA service uses for communication.

Transmit Buffer Size

The transmit buffer is an area in memory used for formatting Token-Ring packets that the service sends to the host. A Token-Ring packet contains user data and control information. The maximum length of the transmit buffer is expressed in bytes. Valid settings range from 265 to 2042. The default is 521.

The transmit buffer size includes the amount of memory needed to handle the transmission header (6 bytes), the request unit header (3 bytes), and request unit data (up to 2033 bytes) in the packet.

The transmit buffer size that you specify must be big enough to handle the largest Token-Ring packets the service sends to the host. Consult your mainframe administrator or systems programmer to determine the appropriate transmit buffer size.

Keep in mind that the transmit buffer size you specify for the service cannot exceed the maximum packet size you specify for the Token-Ring card that the service uses. (See Chapter 3 for details.)

The receive buffer size in the NCP configuration on the host must be either greater than or equal to the transmit buffer size for the service. The receive buffer size is the maximum length (in bytes) of the receive buffer, which is an area in memory used for receiving Token-Ring packets.

LLS Transmit Window Size

The Logical Link Station (LLS) transmit window size sets the upper limit for the working window size. The working window size is the value the Token-Ring card uses to determine the maximum number of Token-Ring packets it can send from the service to the host before requiring a receive acknowledgment. The LLS transmit window size is a constant. The working window size is adjusted whenever nodes with which the card communicates become congested. Valid settings range from 1 (the default) to 7.

When no congestion problems exist, the working window size equals the LLS transmit window size. For example, if you specify 2 as the LLS transmit window size, the working window size also equals 2. This means that the Token-Ring card can send two packets before requiring an acknowledgment. If the card receives no acknowledgment, it solicits status from the host.

However, the working window size is set to 1 when the Token-Ring card receives indication of congestion from other nodes. At this point, the server implements dynamic window allocation, which is an algorithm that slows the transfer of data from the card to the other nodes. This enables the other nodes to alleviate congestion.

Using the algorithm, the card gradually increments the working window size by one until it equals the transmit window size. The rate at which the card increments the working window size is determined by the MAXOUT increment parameter. See the description of this parameter for more information.

For example, the server receives indication from the host that congestion problems exist. The server's LLS transmit window size equals 4. The dynamic window allocation algorithm is invoked, and the working window size is decreased from 4 to 1. The working window size is then gradually increased to 4 as congestion dissipates.

The LLS transmit window size value must be reflected in the VTAM MAXIN parameter for the service in the host configuration. The MAXIN value sets an upper limit on the number of Token-Ring packets the host receives before sending an acknowledgment.

Receive Buffer Size

The maximum length of the receive buffer is expressed in bytes. The receive buffer must be big enough to handle the largest packets the service receives from the host. Valid settings range from 265 to 2042. The default is 2042.

The receive buffer size includes the amount of memory needed to handle the transmission header (6 bytes), the request unit header (3 bytes), and request unit data (up to 2033 bytes) in the packet.

The receive buffer size must be greater than or equal to the transmit buffer size for the service in the NCP configuration on the host.

LLS Receive Window Size

The LLS receive window size determines the maximum number of Token-Ring packets the card can receive for the service before the card must send an acknowledgment to the host. Valid settings range from 1 to 7. The default is 2.

This value must be reflected in the VTAM MAXOUT parameter for the service in the host configuration. The MAXOUT parameter sets the maximum Token-Ring packets the host can send to the service before requiring a receive acknowledgment from the card on the server.

MAXOUT Increment

The MAXOUT increment determines the rate at which the card increments the working window size for the service. MAXOUT increment specifies the number of packets the card must send to solicit a response from the host. When the card receives this response, it increments the working window size by 1.

This process continues until the value of the working window size equals the LLS transmit window size. Valid settings range from 1 (the default) to 7.

For example, the card receives an indication from the host that congestion problems exist. The card's LLS transmit window size equals 6 and MAXOUT increment equals 2. The dynamic window allocation algorithm is invoked, and the working window size is decreased from 6 to 1. The card then transmits 2 packets, and receives a response from the host. When the response is received, the card increments the working window size from 1 to 2. Another 2 packets are transmitted, another response is received, and the working window size is increased from 2 to 3. This process continues until 6 is reached.

The card uses this value when network congestion depletes the communication nodes of sufficient buffer space to receive Token-Ring packets. When the other nodes inform the card of this situation, the Token-Ring card invokes the Token-Ring dynamic window algorithm. See the description of the LLS transmit window size, above, for more information on the dynamic window algorithm.

Retry Count

The retry count specifies the number of retry attempts the card makes when errors occur. Valid settings are 1 to 255. The default is 8. Once the card exceeds the limit set in this parameter, the Token-Ring card attempts to reinitialize the connection with the host.

If the host with which the service communicates is on the same Token-Ring LAN, set the retry count to a low value (for example, 20). Error rates tend to be low on a single LAN. However, you might consider setting the retry count to a high value (for example, 200) if the service and host are on different Token-Ring LANs, and must communicate through a bridge. In this case, error rates tend to be higher than on a single LAN.

Response Timer

The response timer determines the amount of time the card waits for a receive acknowledgment from the host once the LLS transmit window size has been reached. When this timer expires, the card solicits status from the host. Valid settings range from 1 to 60.

For example, the card sends two packets and the LLS transmit window size is 2. The response timer was set to five seconds. The card waits five seconds before it attempts to solicit status from the host.

Inactivity Timer

The inactivity timer determines the number of seconds the connection can be idle before the card solicits status. Valid settings range from 1 to 60. The default is 30.

Receiver Acknowledgment Timer

The receiver acknowledgment timer determines the number of seconds the card waits to send an acknowledgment after receiving a Token-Ring packet. If this timer expires before the card sends an acknowledgment, the card forces the transmission of an acknowledgment to the host. Valid settings range from 1 to 60. The default is 5.

Station ID

You must enter the station ID (XID) of the service. The XID must be in the range from 00000 (the default) to FFFFF hex. Use the default unless the mainframe administrator or systems programmer tells you otherwise.

Remote Address

The remote address is the Token-Ring LAN address of the controller, such as a 3174-1L controller, that the host uses to communicate with the service. Valid settings range from 0 to FFFFFFFFFFFE (hex).

Planning Logical Unit Displays

If you don't specify otherwise, the service uses a series of defaults for the display of colors when host applications run on the PC. You can override the defaults by using an adapter file created by the GA3270 program.

For all displays, the default status line display is text. An adapter file can specify that symbols should be used instead of text.

If you don't use an adapter file and the PC has a monochrome display, all intensified fields are highlighted. Other fields are in normal intensity.

For CGA displays, an unprotected normal field is green by default. Other defaults are red for an unprotected intensified field, blue for a protected normal field, and white for a protected intensified field.

For EGA and 3270/PC displays, the defaults for monochrome and CGA are used, depending on the type of display. For example, a color EGA defaults to the CGA settings without an adapter file.

If your site has special requirements for color display or underlining, you can set up adapter files to control color, status line, and print capture settings for the PC. See the section, "Using Adapter Files," in Chapter 2 for more information.

Planning Logical Unit Security

If you require strict control over access to individual LUs, you can provide LU security settings. LU security settings fall into two categories:

	Access rights entry is a StreetTalk pattern, list name, or item name that controls who can access the LU.
	LU location entries confine access to LUs to specific locations in the VINES network.

None of the features mentioned in this section go into effect unless you use them. You can specify settings for an individual LU, or do nothing and keep the defaults. When you keep all the defaults for an LU, it can be accessed by any VINES user from any PC in the VINES network.

An access rights entry may consist of any valid StreetTalk pattern, list name, or item name. See Planning a Banyan Network and Managing Users and StreetTalk for information on StreetTalk naming conventions.

LU location entries are divided into three levels. Figure 4-3 shows a sample VINES network that illustrates the use of these entries. The entries are as follows:

Server-level entries means that users can access an LU from links attached to a specified server only. All PCs on all LANs and serial lines attached to the server are valid locations from which to access the LU. For example, you can create a server-level entry that forces users to access LU number 2 from any link attached to Server A only. This means that users can access this LU only from any PC on LAN1, LAN2, or LAN3, and the dial-in link SERIAL1.

Link-level entries confine access to an LU to PCs on a particular link. For example, if you create a link-level entry to confine access to LU number 3 to "Server A, LAN1," users can access this LU only from PCs on LAN1.

Workstation-level entries indicate that an LU can be accessed from a specific PC. The PC is identified by its LAN address. Ways in which you can obtain the address include using the DISPLAY Neighbors function in the VINES Network Management option, and by examining the LAN cards themselves. Keep in mind that the address you specify is the link-level node address of the workstation, and cannot be validated at this time. You must determine this address, and specify it only if it is relevant for the LAN type. For example, if you create a workstation-level entry that forces users to access LU number 4 from "Server A, LAN1, PC3," users can access this LU from PC3 only.

You can specify several valid LU location settings for a single LU. For example, you could set link-level entries to allow access to LU number 5 from "Server A, LAN1" and "Server A, LAN2." Users can then access the LU from any PC on either LAN. However, they cannot access the LU from a PC on LAN3 or SERIAL1.

When planning how to use this feature, be sure not to create redundant entries. This happens if you create a server-level entry, then a link-level entry for a link on that server. When you create redundant entries, only the first entry takes effect.

For example, you need not create an entry that permits access to an LU from any link on Server A, and then create an entry that permits access from LAN1 on that server. In such a case, the server-level entry takes effect because it is specified first. The link-level entry has no effect.

You can use both access rights entries and LU location entries in conjunction to secure LUs. For example, the PCs on LAN1 are used exclusively by all the users in group snausers@finance. These users need access to LUs 4, 5, and 6, which lets them retrieve sensitive data from a CICS database application on the host. When you configure each LU, you can specify:

snausers@finance

as the access rights entry and

servera,lan1

as the LU location entry.