![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
If the InfoServer client must be started at this point, the LASTport transport can be started with the Last Control Program using the following command:
$ MCR ESS$LASTCP LASTCP> START
This command will start the transport. You may now execute the InfoServer client startup:
$ @SYS$STARTUP:ESS$STARTUP DISK
Because the transport is already started, the startup will run successfully.
If you have multiple Ethernet and FDDI controllers configured on your OpenVMS Alpha system, you might experience problems with the InfoServer client transport (LASTport) under either of the following conditions:
Problems can range from not being able to access all the services available on the network, if you have four or more controllers configured, to a system crash.
To avoid these problems, specify only the controllers that are attached to media. Digital recommends that you do this by first editing your SYS$STARTUP:ESS$LAST_STARTUP.DAT data file to specify only the controllers that are attached and then restarting your system.
With certain controller configurations, if you specify controllers that are not attached, your system might crash when you issue the following command sequence:
$ MC ESS$LASTCP LASTCP> STOP
An example of how to edit the SYS$STARTUP:ESS$LAST_STARTUP.DAT file follows. The unedited file is shown first, followed by an edited file.
!++
! This file will be used to set the appropriate LASTCP qualifiers. The following
! LASTCP qualifiers: ALL_CONTROLLERS, CHECKSUM, TRANSMIT_QUOTA, or SLOW_MODE
! can be set by using the following statement format:
! LASTCP qualifier = 1 to enable e.g. SLOW_MODE = 1 enables SLOW_MODE
! LASTCP qualifier = 0 to disable e.g. SLOW_MODE = 0 disables SLOW_MODE
! The remaining LASTCP qualifiers will require the appropriate value settings.
! DEVICE = (list-of-devices)
! TIMEOUT = n minimum interval in seconds
! CIRCUIT_MAXIMUM = n maximum number of nodes
! GROUP = n Group number
! NODE_NAME = name Node name
! CONTROLLERS = ([{controller letter,}...]) Controller list
! TRANSMIT_QUOTA = n Number of transmit buffers
!--
ALL_CONTROLLERS = ON
The edited SYS$STARTUP:ESS$LAST_STARTUP.DAT file follows. This example assumes you have ESA, ETA, EXA, EZA controllers configured on your system and that only the ESA controller is attached to the Ethernet wire.
!++
! This file will be used to set the appropriate LASTCP qualifiers. The following
! LASTCP qualifiers: ALL_CONTROLLERS, CHECKSUM, TRANSMIT_QUOTA, or SLOW_MODE
! can be set by using the following statement format:
! LASTCP qualifier = 1 to enable e.g. SLOW_MODE = 1 enables SLOW_MODE
! LASTCP qualifier = 0 to disable e.g. SLOW_MODE = 0 disables SLOW_MODE
! The remaining LASTCP qualifiers will require the appropriate value settings.
! DEVICE = (list-of-devices)
! TIMEOUT = n minimum interval in seconds
! CIRCUIT_MAXIMUM = n maximum number of nodes
! GROUP = n Group number
! NODE_NAME = name Node name
! CONTROLLERS = ([{controller letter,}...]) Controller list
! TRANSMIT_QUOTA = n Number of transmit buffers
!--
ALL_CONTROLLERS = OFF
DEVICE = (ESA)
Note
The default ESS$LAST_STARTUP.DAT file is stored in SYS$COMMON:[SYS$STARTUP]. You might want to put the edited file in SYS$SPECIFIC:[SYS$STARTUP]. Otherwise, other system roots might be affected.
If PATHWORKS or Remote System Manager (RSM) or both are installed, the InfoServer Client for OpenVMS startup must be run before the startup for PATHWORKS or RSM, or both. For example:
$ @SYS$MANAGER:STARTNET . . . $ @SYS$STARTUP:ESS$STARTUP DISK TAPE $ @SYS$STARTUP:PCFS_STARTUP $ @SYS$STARTUP:RSM$SERVER_STARTUP
InfoServer Client for OpenVMS software provides device drivers and control programs that are shared by both the PATHWORKS and RSM products. All InfoServer Client for OpenVMS components are prefixed with ESS$. The drivers and control programs supplied with InfoServer Client for OpenVMS software provide all necessary support for both PATHWORKS and RSM in addition to InfoServer Client support. You must execute the InfoServer Client for OpenVMS startup in the site-specific startup before executing either the PATHWORKS or RSM startup procedure.
You cannot start InfoServer Client for OpenVMS from a subprocess. Because the OpenVMS System Management utility (SYSMAN) uses subprocesses to complete its tasks on remote nodes, SYSMAN cannot be used to execute the SYS$STARTUP:ESS$STARTUP procedure.
To work with InfoServer Client for OpenVMS software, user accounts on your system must have the following privileges and quotas:
See the AUTHORIZE section in the OpenVMS System Management Utilities Reference Manual for an explanation of how to verify and change account privileges and quotas.
To use all the LASTport Control Program (LASTCP) utility's SHOW functions, you must set the value of the system parameter MAXBUF to 32000 or greater.
Use the LAD Control Program (LADCP) utility to configure and control the LASTport/Disk and LASTport/Tape protocols on OpenVMS systems. OpenVMS systems that use LASTport/Disk and LASTport/Tape services are called client systems. You can use LADCP to do the following:
You can control service access by using a service access password. You can also write-protect services. In this case, local OpenVMS users of a DADn: or MADn: device unit receive an error if they attempt a write operation to the unit.
The protocols allow you to access storage devices that reside on an InfoServer system as though they are locally connected to your OpenVMS system. Thus, several OpenVMS client systems can share the same read-only media, eliminating the need for duplicate drives and media.
DADn: and MADn: device units are also referred to as virtual device units. They represent the local OpenVMS context for a volume that resides on a remote server. The OpenVMS driver that controls the DADn: units is called ESS$DADDRIVER. The OpenVMS driver that controls the MADn: units is called ESS$MADDRIVER.
The LASTport/Disk and LASTport/Tape protocols depend on the LASTport transport. The ESS$STARTUP.COM command procedure in SYS$STARTUP automatically loads ESS$DADDRIVER and ESS$MADDRIVER as well as ESS$LASTDRIVER, the LASTport transport driver.
Note
Your site-specific startup command procedure must include a call to ESS$STARTUP.COM. If you are using DECnet software, you must place the call after the @SYS$MANAGER:STARTNET.COM command that starts DECnet software. See Section 23.5.3.
To invoke LADCP, enter the following command:
$ RUN SYS$SYSTEM:ESS$LADCP LADCP>
You can enter LADCP commands at the LADCP> prompt.
You can also execute a single LADCP command by using a DCL string assignment statement, as shown in the following example:
$ LADCP :== $ESS$LADCP $ LADCP BIND CD_DOC_00661 /NOWRITE
LADCP executes the BIND command and returns control to DCL command level.
To exit LADCP, enter EXIT or press Ctrl/Z after the LADCP> prompt.
Table 23-3 summarizes LADCP commands and their functions.
| Command | Function |
|---|---|
| BIND | Establishes a service binding and creates a device unit |
| DEALLOCATE | Terminates any active connection to a service without deleting the unit control block (UCB) |
| EXIT | Returns the user to DCL command level |
| HELP | Displays help text for LADCP commands |
| SHOW SERVICES | Displays services offered by InfoServer systems on the LAN |
| UNBIND | Terminates an established service binding |
LADCP provides a Help facility that contains information about each LADCP command, including parameters, qualifiers, and examples of its use. For detailed descriptions of LADCP commands, refer to the InfoServer Client for OpenVMS LASTCP and LADCP Utilities manual.
You can make remote InfoServer devices available on your system each time the system boots. To do so, add to SYSTARTUP_VMS.COM a series of LADCP BIND commands. For more information about the BIND command, see the InfoServer Client for OpenVMS LASTCP and LADCP Utilities manual.
How to Perform This Task
@SYS$STARTUP:ESS$STARTUP DISK TAPE
$ RUN SYS$SYSTEM:ESS$LADCP
BIND [/QUALIFIER,...] service-name
BIND/TAPE [/QUALIFIER,...] service-name
MOUNT/SYSTEM/NOASSIST device-name volume-label
Example
The following commands, executed in SYSTARTUP_VMS.COM, start the InfoServer Client software and make available to client systems the InfoServer device DAD$OPENVMSv71.
. . . $ @SYS$STARTUP:ESS$STARTUP DISK $ RUN SYS$SYSTEM:ESS$LADCP BIND OPENVMSV71 EXIT $ MOUNT/SYSTEM/NOASSIST DAD$VMS055 VMS055 . . .
In this example, the OpenVMS Version 7.1 consolidated distribution (CONdist) compact disc loaded in a compact disc drive connected to an InfoServer system, is made available on the server as a virtual device unit and mounted as a public device.
This chapter describes how the LAT software works and the tasks you must perform to implement and manage the LAT software on your system.
Information Provided in This Chapter
This chapter describes the following tasks:
| Task | Section |
|---|---|
| Starting up the LAT protocol | Section 24.5 |
| Customizing LAT characteristics | Section 24.6 |
| Creating a service | Section 24.6.1 |
| Setting up ports | Section 24.6.2 |
| Setting up printers | Section 24.6.2.1 |
| Setting up special application services | Section 24.6.2.2 |
| Enabling queued incoming requests | Section 24.6.3 |
| Enabling outgoing LAT connections | Section 24.6.4 |
| Managing the LATACP database size | Section 24.7 |
This chapter explains the following concepts:
| Concept | Section |
|---|---|
| LAT protocol | Section 24.1 |
| LAT network | Section 24.2 |
| LAT configurations | Section 24.3 |
| LAT Control Program utility | Section 24.4 |
The operating system uses the LAT (local area transport) software to communicate with terminal servers and other systems within a local area network (LAN). Terminal servers are communication devices dedicated for connecting terminals, modems, or printers to a LAN. They offer the following features:
With the LAT software, which implements the LAT protocol, the operating system can offer resources, or services, that the terminal servers can access. A system that offers LAT services is called a service node. In addition, nodes can access LAT services by enabling outgoing connections (using LATCP) and using the DCL command SET HOST/LAT. (In the remainder of this chapter, "servers" refers both to dedicated terminal servers and to nodes that allow outgoing access to other LAT services.)
A LAT service can consist of all the resources of a computer system, or it can be a specific resource on a computer system, such as an application program. You can set up your system as a general timesharing service, meaning that all of its resources are available to users in the LAN, or you can restrict access to a specific service (application program) on the system. This chapter and the OpenVMS I/O User's Reference Manual outline the procedure you use to set up access to a dedicated application program.
The LAT protocol allows the terminal servers and computers to communicate within a LAN, such as the Ethernet or the Fiber Distributed Data Interconnect (FDDI). The LAT protocol matches terminals and other devices to the computing resources (services) of the LAN. Because LAT terminals are not connected directly to the computer (service node) they are accessing, the local server must listen for service requests from its terminals and be able to match the terminals with computers that provide the desired services.
Using the LAT protocol, then, the operating system announces its available services over the LAN. Servers listen to the LAN announcements and build a database of service information so that they can locate an appropriate system when a user terminal requests computing services. For example, a user terminal might request general processing service or a data entry program on the operating system. A server uses the LAT protocol to establish and maintain a connection between the requesting terminal and the operating system.
Sometimes the operating system can request services from a terminal server. The LAT protocol allows systems to ask for connections to printers or other devices attached to a terminal server.
Using the LAT protocol on your system has many advantages:
A LAT network is any local area network where terminal servers and operating systems use the LAT protocol. A LAT network can coexist on the same LAN with other protocols. The LAT protocol, which operates on both terminal servers and the operating systems, is designed to ensure the safe transmission of data over the LAN.
The LAT network consists of the following components:
| Component | For More Information |
|---|---|
| Service nodes | Section 24.2.1 |
| Terminal server nodes | Section 24.2.2 |
| Nodes allowing outgoing connections | Section 24.2.3 |
| LAN cable | Section 24.2.4 |
Service nodes supply computing resources for the local network, while terminal server nodes (or nodes allowing outgoing connections) port their terminals, modems, or printers to those resources upon request from a user terminal or an application program.
Note that in a LAT network, nodes that access services are often referred to as master nodes, which distinguishes them from nodes that only provide services.
You can use the LAT Control Program (LATCP) to configure the LAT characteristics for your system. LATCP allows you to set up your system to support:
The systems that support incoming LAT connections are service nodes. (Using LATCP, you can also set up your system so that it supports neither incoming nor outgoing access.)
A service node is one type of node in a LAT network. (Nodes that are not running an OpenVMS operating system can also be used along with the OpenVMS nodes in a LAT network.) A service node is an individual computer in a LAN that offers its resources to users and devices. Because the OpenVMS operating systems contain the LAT protocol, any OpenVMS system can be configured as a service node within a LAT network.
Each node offers its resources as a service. Often, a node offers a general processing service, but it can offer limited services or special application services as well. Any or all of the services can be specialized applications.
For example, your service node might offer services for the following:
The general processing service would allow the use of the general computing environment. The data entry and stock services, on the other hand, would be restricted environments, with connections to the application service but to no other part of the service node.
Each service is distinguished by the name the system manager assigns to it. In an OpenVMS Cluster, Digital recommends that the service name be the same as the cluster name. In an independent node, Digital recommends that the service name be the same as the node name. With special service applications, the service holds the name of the application.
A service node announces its services over the LAN at regular intervals so that terminal servers (and OpenVMS systems that allow outgoing connections) know about the availability of these network resources. The service announcement provides the physical node name, the service names, a description of services, and a rating of service availability. Servers listen to the LAN announcements and record information in a database. On nodes allowing outgoing connections, this database is maintained by the LAT Ancillary Control Process (LATACP). (See Section 24.7 for more information about managing the LATACP database.)
Whenever a user terminal or application program requests a service, the server node connects to the appropriate service node.
Note that you can disable a local node from multicasting service announcements by using the /NOANNOUNCEMENTS qualifier with the LATCP command SET NODE. However, because remote nodes must rely on the LAT service responder feature in the LAT protocol Version 5.2 (or higher) to connect to the local node, Digital recommends that you use this qualifier only in a networking environment where newer model terminal servers and hosts are present (all LAT hosts, terminal servers, and PCs are running at least Version 5.2 of the LAT protocol). Otherwise, systems running versions of the LAT protocol prior to Version 5.2 (for example, DECserver 100, 200, and 500 systems) will be unable to connect to any of the systems that have LAT service announcements disabled.)
In some cases, service nodes can request services from terminal servers. The most common situation is when the system wants to use a printer that is connected to a terminal server port. The system submits the print request to the terminal server print queue that is set up and initialized in the OpenVMS startup procedure. Then the LAT symbiont (the process that transfers data to or from mass storage devices) requests the LAT port driver to create and terminate connections to the remote printer.
For information about setting up queues for printers connected to LAT ports, see Section 13.1.3 and Section 13.2.2.4.
A terminal server node is the second type of node in a LAT network. A terminal server node is usually located near the terminals and printers it supports. The terminals and printers are physically cabled to the terminal server; the terminal server is physically connected to the LAN cable.
Terminal servers build and maintain a directory of services from announcements advertised over the network. Then, when terminal servers receive requests from terminal users, they can scan their service databases and locate the computer that offers the requested service.
Terminal servers not only look for the node that provides the requested service, but they can also evaluate the service rating of that node. If a requested service is offered by more than one node, then the service rating is used to select the node that is least busy. A server establishes a logical connection between the user terminal and the service node.
One logical connection carries all the data directed from one terminal server node to a service node. That is, the server combines data from all terminals communicating with the same node onto one connection. A terminal server establishes a logical connection with a service node only if a logical connection does not already exist.
If a connection fails for any reason, a terminal server attempts to find another node offering the same service and rolls over the connection so users can continue their computing sessions.
Even though terminal connections are bundled together, each terminal can be uniquely identified by its name. A terminal name consists of two parts: the first part is the name of the port on the terminal server that the terminal line plugs into; the second part is the name of the terminal server node.
Although terminal servers are usually the requesting nodes in a LAT network, sometimes service nodes request service from terminal servers. Most commonly, a service node queues print requests to remote printers connected to terminal servers.
Nodes can be set up to allow incoming connections, outgoing connections, or both. Nodes (excluding those that offer incoming connections only) such as terminal server nodes can locate service nodes and set up connections. The database of information about available nodes and services is maintained by the LAT Ancillary Control Process (LATACP). (See Section 24.7 for more information about managing the LATACP database.)
6017P070.HTM OSSG Documentation 22-NOV-1996 14:23:00.49
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.