![[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.
23.5.5 Multiple Controllers Configured But Not All Attached to Media (Alpha Only)
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.
23.5.7 Startup Restrictions: SYSMAN
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.
23.5.8 User Account Requirements
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.
23.5.9 System Parameter MAXBUF Requirement
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.
23.6 Understanding LADCP Utility Functions
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.
23.6.2 LADCP Command Summary
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.
23.6.3 Making InfoServer Devices Available Automatically
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.
24.1.1 How the LAT Protocol Works
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.
24.1.2 Advantages of the LAT Protocol
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.)
24.2.1 Service Nodes
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.
24.2.1.1 Types of Services
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.
24.2.1.2 Service Announcements
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.)
24.2.1.3 Print Requests
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.
24.2.2 Terminal Server Nodes
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.
24.2.2.1 Locating Service Nodes
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.
24.2.2.2 Setting Up Connections
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.
24.2.2.3 Servicing Nodes
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.
24.2.3 Nodes Allowing Outgoing Connections
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.