Chapter 2 - Planning for the ATE Option
This chapter presents an overview of hardware and software considerations for the ATE option.
If you are using direct, dial-out, or X.25 lines, you must plan the appropriate communications hardware so that the connections in your service work properly and a peak load of user sessions can be handled through the service. This section briefly discusses the hardware items that you need and provides an example of serial communications planning.
For more detailed assistance in planning your hardware, consult the following:
|
The planning and administration guides that shipped with your software |
|
|
Managing Communications |
For server development or remote console connections, no additional hardware is necessary. These two connection types use the existing hardware (Ethernet cards and cables, for example) to communicate across the LAN. If you will use only server development or remote server console connections, skip ahead to the section "Server Connection Requirements."
To plan your hardware setup, you must know the following:
|
|
Which hosts with which you will communicate |
|
|
The maximum number of users that will connect to each host at a time |
You use that information to decide the following:
|
|
The types of serial communications lines you want to use to connect to the hosts |
|
|
How many serial communications lines and modems you need |
For direct line and dial-out communications, each user session takes up one communications line from the server to the host, whether local or remote. You can have as many user sessions with local or remote computers as you have serial lines available to the service.
A server can have only one ATE service. The maximum number of concurrent connections per server is 32 on Banyan servers. The maximum number for each type of connection varies. Figure 2-1 illustrates this.
For X.25 communications, each X.29 user session takes up one SVC from the server to the host. You can have a maximum of 32 concurrent X.29 user sessions with hosts, depending on the number of SVCs available to the service.
Table 2-1 presents modem requirements, user session limitations, and line requirements for each of the line types. Keep these guidelines in mind according to the type of line you plan to use.
Other considerations are as follows:
|
|
Connections that use direct lines can be configured to end a user's session when the carrier is lost. If the lines do not use modems, the lines must support carrier signals, and the host must assert carrier. Otherwise, user sessions remain in the waiting state during session establishment. |
|
|
Each X.29 user session over an X.25 line requires one X.25 SVC. |
|
|
For X.25 communications through a PDN, the user sessions can be with one host or divided among multiple hosts. |
With a single X.25 line, you can establish multiple concurrent X.29 user sessions with more than one host without using a PDN. However, the X.25 line must be connected to special switching equipment that you purchase from a third party.
When you set up an X.25 line, remember that the SVCs you allocate to the line can be used by applications written with the X.25 Programming Interface or by services such as Intelligent MessagingTM and StreetTalkTM.
An X.25 connection uses one X.25 line. The way the ATE service establishes, maintains, and terminates this connection with the host follows the CCITT X.3, X.25, X.28, and X.29 standards. The host must also support these standards. You can use this connection only if the X.29 option and the X.25 Server-to-Server option are installed on the server.
The ATE option supports full-duplex asynchronous modems for dial-out connections. All modems must support autodialing.
It is recommended that you use Hayes or Hayes-compatible modems.
The maximum line speed is 19200 bps for direct lines and dial-out lines, 64000 bps for X.25 lines. See the VINES X.25 Guide for X.25 modem considerations.
How many serial communications cards you need depends on how many lines you are using. Managing Communications and the VINES X.25 Guide provide planning information on the serial cards supported by the option for VINES servers.
Once you have chosen the lines, modems, and cards you need, you can install the hardware.
This following example presents a sample of serial communications planning similar to one you might encounter.
Example Serial Communications Planning
You want to connect through direct lines to a local minicomputer, through dial-out lines to a remote minicomputer and a data service, and through an X.25 PDN to another remote minicomputer. The direct lines will all use modem eliminators. You need to support the following groups of users:
|
|
Ten users for the local minicomputer |
|
|
Five users for the remote minicomputer that is reached through dial-out lines |
|
|
Three users for the data service |
|
|
Four users for the remote minicomputer that is reached through the PDN |
Figure 2-2 illustrates this.
For the local minicomputer, the data service, and the remote minicomputer that is reached through dial-out lines, you need 18 lines - one for each local minicomputer user, remote minicomputer user, and data service user - and 8 modems - one for each dial-out and data service user.
For the remote minicomputer that is reached over the PDN, you need one line and one modem, and you should contract with the PDN for at least four SVCs. You may need more depending on whether you want to communicate with other servers over the PDN using SVCs.
You can create four connections, one for each host. The local connection has ten direct lines. Two connections can share a pool of eight dial-out lines with attached modems. The X.25 connection has one line and the ability to support four concurrent X.29 user sessions.
For each line you use, find out the following information:
|
|
The number of the slot in which the serial communications card connected to the line is installed |
|
|
The number of the line on the card |
|
|
All valid speeds at which the line can operate |
|
|
Whether the line will connect to an auto-dial modem |
If the line has an auto-dial modem and is not an X.25 line, you can use it as a dial-out line. The line is then accessible through a connection name, a parameter file, or manual dial-out.
Overview of Connection Requirements
After planning the hardware but before creating an ATE service, you must gather information about how the service will be used. You use this information to plan connections.
This section discusses connection types and requirements, and provides a worksheet for your connection information.
If you are not familiar with the terminal emulation features available to users, look at Chapter 7 and Chapter 8 before proceeding.
Host Computer Connection Requirements
To provide terminal emulation to users, the ATE service must know how to communicate with the host computer or data service. This section tells you what information you must provide.
Use the Host Computer Connection Information Worksheet in Figure 2-3 to gather information about each host computer or data service to which the service will connect.
There may also be additional requirements imposed by the host computer for communication to work properly. For example, for the ATE service to establish X.29 connections with a host computer, the computer must support the CCITT X.3, X.25, X.28, and X.29 standards. Discuss any other requirements with a systems programmer or another person knowledgeable about the host computer or data service.
Once you have information about what each host requires, you can plan how to provide user access to it.
The terminal type plays a very important role in terminal emulation. With the ATE option, there is one kind of terminal types, the ATE terminal type.
ATE Terminal Types
The ATE terminal type can be one of the following types:
|
|
VT100 |
|
|
VT52 |
|
|
IBM 3101 |
|
|
TTY (general-purpose terminal) |
A full description of the ATE terminal types appears in Chapter 4. You set the terminal type for a connection. You can override the terminal type for the connection at the workstation by using the Action Menu. Chapter 7 describes the Action Menu.
If you use third-party terminal emulation software with the ATE service, specify TTY as the terminal type when you create the connection. TTY is recommended because with this terminal type the ATE service will pass data from the workstation to the server to the host without any conversion, allowing the third-party package to make its own decisions about conversion. This prevents conflict between what the third-party package is converting and what the ATE service is converting.
Enter the appropriate type on the Host Computer Information Worksheet shown in Figure 2-3.
For each direct, dial-out, or X.29 line to each host, fill in the information on the Host Computer Information Worksheet shown in Figure 2-3.
For each X.25 line to an X.25 PDN, in addition to the information described in the VINES X.25 Guide, you need to know any X.29 parameters that you agree on with the host systems programmer. Add that information to the Host Computer Information Worksheet shown in Figure 2-3.
Server Connection Requirements
In addition to connections to a host, you can also have connections to the server. The two types of connections to the server are:
|
|
The server development connection |
|
|
The remote server console connection |
The server must have both the ATE option and the Applications Toolkit option installed before you can create a server development connection. (For more information on using the VINES Applications Toolkit, see the toolkit documentation.)
To use a server development connection, users must have access to the ATE service on the server. Users then can select the server development connection as if it were a connection to a host computer. See Chapter 4 for details.
Remote Server Console Connection
The remote server console feature is most appropriate for networks where a limited number of people use this feature, or where it is possible to control who can gain access to the actual server console. You can use Access Rights Lists (ARLs) to restrict who can use the remote server console. For more information on ARLs, see Managing VINES Services.
For a server connection such as remote server console or a server development, you need only the following:
|
|
Terminal type |
|
|
Script filename (if you choose to use a script file) |
|
|
The ARL for the connection |
Use the Server Connection Information Worksheet shown in Figure 2-4 to record this information.
Planning User Access to Hosts and Servers
The ATE option lets users access host computers and servers in four ways:
|
|
Using connections that you configure as part of the ATE service. |
|
|
Using DOS parameter files that override the default settings provided by configured connections. You can create these for users or they can set up on their own. |
|
|
Using script files to automate all or part of the interaction with the host. |
|
|
Dialing out manually from the terminal emulation screens. |
All of these methods are accessible from ATE menus or from the DOS command line.
Access through the menus is easier for users than access from a DOS command line. Before deciding which methods to use, read the sections that follow to see how the menus work. "Making the ATE Service Available to Users" in Chapter 5 discusses this in detail.
Once users enter emulation, they can run script files that automate all or part of their interaction with the host. They can also load parameter files to change communications or other settings, or to access another host.
For a graphic overview of how the service uses connections, parameter files, and script files, see "How the Elements of the ATE Service Work Together" in Chapter 5.
Considerations for Third-Party Software
If you are running third-party terminal emulation software, you should verify that your script files are compatible with it. Script files are described in "Script Files" later in this chapter.
You should verify that third-party parameter files work properly when you run third-party terminal emulation software with the ATE option. Parameter files are described in "Parameter Files" later in this chapter.
Connections enable a user to select a host computer from a menu without having to know about how the connection is made.
Generally, you define one connection for each host or server your users need to access. You must use connections to provide host access through direct lines and X.25 lines.
You configure a connection as part of the service.
Host Connections
You create a host connection by giving it a name and specifying which direct lines, dial-out phone numbers, or X.25 lines it can use. The ATE service can handle a maximum of 32 concurrent sessions on a native VINES server. You do not need separate connection names for each session. In other words, if you have 32 users accessing a single host, they can all use the same connection name to access the same host at the same time.
You use Banyan service management menus and screens to create the connection. Make it easy for users to identify the host computer by creating meaningful names for the connections you set up. For example, a name like "VaxHost" is self-explanatory.
You can restrict host and server access by specifying the access rights for each connection. You specify access rights with a StreetTalk name, list, or pattern. To use a connection, a user's StreetTalk name must match the access rights.
Note: Connections use certain defaults for communicating with the host computer. If you need to change these defaults, you must create a parameter file or a script file to use with the connection. In the file, you can select an alternative value for each setting. Users can also change these settings while in terminal emulation and then save their changes into a parameter file.
Once you know what the host requires, use the list of default settings in Appendix A to identify any settings you need to change. The defaults are used when you do not explicitly override them from a parameter file or a script file. See Chapter 9 for more information on parameter files. See Chapter 10 for more information on script files.
A direct line connects the server to a host without an auto-dial modem. A dial-out line uses an auto-dial modem to connect to a host. Before you configure a connection for these types of lines, you need to know information about the line, such as:
|
|
Line speed |
|
|
Number of stop bits |
|
|
Parity |
|
|
Character size |
|
|
Whether the ATE service should end the session on carrier loss |
|
|
What ARLs, if any, you want to assign to the line |
|
|
Phone numbers (for dial-out lines) |
For a description of the preceding items, see "Overview" in Chapter 4.
Server Connections
There are two types of connections to a server:
|
|
Remote server console. This connection type is for a remote server console connection. |
|
|
Server development. This connection type allows Applications Toolkit developers to use their workstations to access the server where this ATE service resides. |
For these types of connections, you need to know only the following:
|
|
The terminal type |
|
|
What ARLs, if any, you want to assign to the line |
For a description of these parameters, see "Overview" in Chapter 4.
A parameter file is a file that contains terminal and communication settings, file transfer information, and other information applicable to asynchronous terminal emulation. You can use a parameter file to override the configured connection defaults.
A parameter file is an ASCII file, stored in a DOS directory that you choose. You can create and make changes to a parameter file using ATE menus or a DOS text editor that produces an ASCII file.
Note: Parameter files that you create with the ATE option are not compatible with third-party terminal emulation software that uses its own parameter files. You should verify that third-party parameter files work properly when you run third-party terminal emulation software with the ATE option.
To provide access to a host, the file must contain one of the following:
A connection name. If a parameter file contains a connection name, the lines or phone numbers are those configured for the connection. The connection's settings (such as the terminal type, line speed, and parity) are used unless overridden by settings in the parameter file. User access rights are controlled by the access rights list (ARL) for the connection.
A phone number for dial-out. If a parameter file contains a phone number, it must also have all the necessary settings. When the file is used to access a host, the ATE service selects a dial-out line that you assigned at the server console. The user must have dial-out access to the service.
If you want, you can omit the connection name or phone number and create a partial parameter file. Users connect to the host with a connection name and load the partial parameter file while in terminal emulation.
Chapter 9 provides detailed instructions on creating and using parameter files. If users will set up their own parameter files, they will need the information from that chapter.
A script file contains the commands that control user interaction with the host. A script file can also contain different communications settings. You can use scripts to automate user logins or other processes during terminal emulation. You can set up script files for users or allow them to create their own.
A script file is a DOS file stored in a DOS directory that you choose. You cannot create or change a script file through ATE menus. Instead, you use any DOS text editor that produces an ASCII file.
Note: If you are running third-party terminal emulation software, you should verify that your script files are compatible with it. Script files must not contain commands that conflict with the configuration of the third-party software.
When you create a connection, you can specify a script file that executes automatically every time that connection is used. Users can also load and execute script files while in terminal emulation.
Chapter 10 provides detailed instructions on creating and managing script files. If users will set up their own script files, they will need the information from that chapter.
You can allow users to dial out manually to a remote host or data service. To dial out manually, users enter terminal emulation from DOS or from ATE menus. They can optionally specify a partial parameter file to override default settings. They then use ATE menus to give a phone number and to start a connection to the host. For instructions on dialing out manually, see Chapter 8.
Note: Users of third-party terminal emulation software cannot dial out through Banyan menus.
As part of the service configuration, you specify the access rights for dial-out with a StreetTalk name, list, or pattern. To dial out manually or through a parameter file that does not name a connection, a user's StreetTalk name must match the dial-out access rights.
You can also use manual dial-out to test different settings and then save the results in a parameter file.
