![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
On a node that is set up to allow outgoing LAT connections, a user can connect to another node in the LAT network by entering the SET HOST/LAT command. For more information, see the SET HOST/LAT command in the OpenVMS DCL Dictionary.
Figure 24-1 is an example of a LAT network. The network consists of an Ethernet cable connecting service nodes and terminal server nodes.
The three service nodes in Figure 24-1, named MOE, LARRY, and ALEXIS, each offer services to terminal server nodes on the network.
Two of the service nodes, MOE and LARRY, belong to the OFFICE cluster. (The cluster is distinguished by its computer interconnect [CI] and star coupler.) Because MOE and LARRY are clustered, their service names are the same as their cluster name. Because both service nodes offer an OFFICE service, terminal server nodes can assess the work load on both OFFICE nodes and establish a connection to a node that offers the service that is less busy.
The third service node, ALEXIS, is an independent node in the LAT network so its service name is the same as its node name.
In addition to its primary OFFICE service, node MOE offers an application service called NEWS. With this specialized service, user terminals can connect directly to the online news program, without any login procedure but also without general access to the general computer resources of the node.
The node FINANCE, shown in Figure 24-1, is a terminal server node; it supports a number of interactive terminals, a modem, and printers. The node PROCESSING allows outgoing connections; it supports several interactive terminals. The node FINANCE can accept print requests from any of the three service nodes, provided each service node has set up print queues to support remote printers on the terminal server.
Node PROCESSING is also a service node. It offers the service COMPUTE.
Figure 24-1 Components of a LAT Network
When you set up a LAT system, you need to understand the relationship between the LAT software and the network so you can configure your system to operate efficiently. The following sections contain information that will help you understand the following:
Although the LAT protocol works independently of OpenVMS Cluster software, Digital recommends that you configure a service node to complement the OpenVMS Cluster concept. You achieve this by creating a service on each node in an OpenVMS Cluster and assigning the cluster name to this service. A terminal server assesses the availability of cluster services and establishes a connection to the node that is least busy. Thus, the LAT protocol helps balance the cluster load. If one node in the cluster fails, the terminal server can transfer the failed connections to another service node within the cluster.
The LAT software does not use DECnet as a message transport facility, but instead uses its own virtual circuit layer to implement a transport mechanism. The LAT and DECnet software work independently in a common LAN environment. For compatibility, if a service node is also a DECnet node, the service node name should be the same as the DECnet node name.
If Ethernet ports will be running both DECnet and LAT, you must start the DECnet software before the LAT software. If you do not start DECnet software first, all existing LAT connections may terminate, and reconnecting to the system via LAT may not be possible.
If DECnet is configured on the system (or if the system is part of a cluster), the SCSSYSTEMID system paramater may contain a nonzero value. Normally, this is not a problem unless the system has two or more LAN controllers connected to the same logical LAN.
For example, if your system has an FDDI controller and an Ethernet controller, your site may be configured so that the FDDI ring attached to the FDDI controller and the Ethernet segment attached to the Ethernet controller are bridged by a 10/100 LAN bridge (FDDI-to-Ethernet). In this configuration, it is impossible to run LAT over both controllers.
In such a configuration, you must run LAT and DECnet over the same controller if SCSSYSTEMID is not 0. If they do not run on the same controller, DECnet starts first, which in turn causes the LAT startup on the other controller to fail. This failure occurs because LAT startup tries to use the AA-00-04-00-xx-xx address (the DECnet LAN address); however, because DECnet is already using this address on another controller, the data link layer prevents the LAT startup from using that address. (In a single logical LAN, all data link addresses must be unique. Because both controllers try to use the same address, it is no longer unique.)
Using the following command to create the LAT link also fails because the LAN driver tries to use the address based on SCSSYSTEMID:
LATCP> CREATE LINK LAT$LINK_2 /NODECNET
If SCSSYSTEMID is set to 0, configuring LAT and DECnet on different controllers is possible. However, in a cluster environment, SCSSYSTEMID cannot be set to 0.
When you use multiple LAN addresses for one LAT node, you can configure a system with multiple LAN adapters connected to the same logical LAN. The LAT software can run over each adapter simultaneously and can better maintain connections. For example, when a virtual circuit chooses a primary path and uses it for all LAT message transmissions, the LAT software can continue communications through another adapter or logical path if that original path becomes blocked.
Note
Nodes running versions of LAT software prior to Version 5.3 of the LAT protocol (included in the OpenVMS operating system beginning with Version 7.0) may exhibit some differences in behavior. Therefore, if your configuration includes earlier versions of the LAT software, such as Version 5.1 or Version 5.2, note the differences and considerations discussed in this chapter.
Although it is possible to run LAT over multiple LAN adapters, it is still not possible to route LAT from one logical LAN to another. Following are examples of supported LAT configurations for nodes running Version 5.3 of the LAT protocol (including nodes running Version 5.2 and 5.1 as well).
Figure 24-2 Multiple Address LAT Configuration: One LAN with Mixed Version LAT Nodes
This widely used configuration has an OpenVMS system running LAT Version 5.3 software over two Ethernet adapters (labeled A and B in the diagram) connected to the same physical LAN as a DECserver 200.
When a LAT connection is started between the DECserver 200 and the OpenVMS system, the LAT software determines that it is possible to use both adapters A and B for the LAT virtual circuit. One of the adapters will be chosen as the primary communications path while the other will be present in the unlikely event that the primary path fails.
For example, if a user connects to the OpenVMS system from the DECserver 200, the OpenVMS system determines that there are two paths but chooses adapter B as the primary communications path. If the user runs a program that generates a large amount of output from the OpenVMS system and adapter B fails in some manner during the output, the LAT software will attempt to continue communications from the OpenVMS system to the DECserver through adapter A.
Figure 24-3 shows two LANs bridged together. However, this configuration will have the same characteristics as the configuration shown in Figure 24-2.
Figure 24-3 Multiple Address LAT Configuration: Two LANs with Mixed Version LAT Nodes
Note
It is possible for Ethernet 2 in Figure 24-3 to be an FDDI network. The LAT software regards each adapter as a network path with equal point-to-point communications and does not treat FDDI controllers any differently. However, for large buffer support, see Section 24.3.3 for more details.
In Figure 24-4, any virtual circuit created between the two OpenVMS systems will have two paths: through controllers B and C or A and D. If one path fails, the virtual circuit will continue over the other path. If both paths fail, the virtual circuit will eventually time out.
Figure 24-4 Multiple Address LAT Configuration: Two LANs with Version 5.3 LAT Nodes
Figure 24-5 Unsupported Multiple Address LAT Configuration
Any configuration similar to this diagram will result in unpredictable results and may not function. In a network environment, LAT Version 5.1 and 5.2 nodes can have only a single logical LAN address. The configuration in Figure 24-5 violates this rule. The configuration shown in Figure 24-4 is a valid alternative.
The LAT software regards all paths as equal, point-to-point communications. The LAT software can support a maximum of eight LAN adapters simultaneously (and it is possible to connect all controllers to the same logical LAN). To get the maximum coverage over possible path failures, each logical link should be created prior to setting the LAT node state to ON in SYS$MANAGER:LAT$SYSTARTUP.COM.
For example, if a system has one Ethernet adapter (device ESA0) with two FDDI adapters (FCA0 and FCB0) and the system manager chooses to run LAT over all adapters, the LAT$SYSTARTUP.COM file would contain the following commands:
$! $! Create each logical LAT link with a unique name and $! unique LAN address (forced with /NODECNET). $! $ LCP CREATE LINK ETHERNET /DEVICE=ESA0 /NODECNET $ LCP CREATE LINK FDDI_1 /DEVICE=FCA0 /NODECNET $ LCP CREATE LINK FDDI_2 /DEVICE=FCB0 /NODECNET $! $! Turn on the LAT protocol. $! $ LCP SET NODE /STATE=ON
Caution
If the LATCP command SET NODE /STATE=ON is entered before the link is created, a random or default LAT$LINK will be created on one of the LAN adapters. There is no way to predict which LAN adapter will be chosen (it is dependent on the system configuration). Therefore, all logical LAT links should be created before LAT is started.Be sure each logical link is created with the /NODECNET qualifier. It will prevent the possibility of link creation failure if multiple adapters attempt to use the DECnet style address. Having more than one LAN adapter connected to the same logical LAN with the same address violates LAN conventions and will cause problems with LAT and other protocols.
It is possible to create logical LAT datalinks after the LAT protocol has been started. Any existing virtual circuit will attempt to find any new paths through the newly created logical datalink when it is ready for use. However, Digital does not recommend that you create links at this point because during the time it takes existing virtual circuits to discover new paths through this newly created datalink, the virtual circuit may fail before the new paths are discovered.
The OpenVMS LAT software uses a combination of the directory service and solicitation to obtain paths for each virtual circuit. To expedite path discovery at virtual circuit startup, Digital recommends that you configure a system with multiple LAN adapters to maintain a LAT service and node database, by doing the following:
An OpenVMS system running with outgoing connections disabled and no service and node database is still capable of running with multiple paths for each virtual circuit. These paths must be discovered through the LAT solicitation process and will take longer (leaving the possibility for virtual circuit failure to occur before all paths have been discovered).
In the unlikely event of a path failure, it will take the OpenVMS LAT software time (which will vary depending on the number of adapters to which the remote node has access) to locate another working path. Therefore, Digital strongly recommends that you modify the following LAT parameters on potential LAT master nodes:
Although it is possible to keep virtual circuits running through multiple adapters to LAT Version 5.1 or LAT Version 5.2 master nodes, there is still a possibility that the connections to these nodes may fail.
LAT Version 5.2 and LAT Version 5.1 master nodes do not have the ability to recognize multiple paths to LAT nodes that provide services. They can only communicate with such nodes through one remote address at a time. Therefore, if a LAN path failure occurs when a LAT master node running LAT Version 5.1 or Version 5.2 attempts to connect to a remote LAT Version 5.3 node providing services, the LAT Version 5.3 node might not discover this failure in time and the LAT master node may time out the connection. You can partially solve this problem by increasing the retransmit limit to as high a setting as possible.
In addition, if a LAT Version 5.3 node providing services views the virtual circuit as completely idle during the primary path failure, no attempt will be made to use any of the alternate paths (because of the previously described LAT Version 5.2 and 5.1 limitation). Therefore, although multiple LAN adapters will work with older LAT implementations, you might still need to upgrade to Version 7.0 or higher of the OpenVMS operating system to obtain the LAT Version 5.3 protocol, which will correct this type of problem. (Note that this type of problem affects only those connections that are idle. An example of where this situation could arise is in an office environment if all users were to leave their systems at the same time, either at lunchtime or at the end of the workday.)
The OpenVMS LAT software will attempt to use large buffers over any virtual circuit that comes in over an FDDI controller. This feature can cause problems if an alternate virtual circuit path must go through an Ethernet. Figure 24-6 is an example of the configuration that can cause problems.
Figure 24-6 LAT FDDI Ring and Large Buffers
In this diagram, it is possible for the two OpenVMS systems to communicate using large packets through the path described by controllers B and C. Large packets may exceed 1500 bytes of data (the maximum Ethernet message can contain 1500 bytes of data). If the path described by controllers B and C were to fail, it will not be possible for communication to continue through the path described by A and D.
The path described by controllers A and D pass through an Ethernet LAN segment. The messages that are routed through the 10/100 bridges cannot be larger than the maximum Ethernet message. Problems can occur because the OpenVMS LAT software cannot always detect this kind of configuration.
There are two ways to prevent problems with the previously described configuration. The first and easiest option is to create a logical LAT link using an Ethernet adapter (if either system has an Ethernet LAN adapter). This will force the message size negotiation to be no larger than the maximum sized Ethernet message.
If neither system has an Ethernet controller (thus making the first option not possible), the second option is to override the use of large buffer support (which is enabled by default) by using the new LATCP command qualifier, /[NO]LARGE_BUFFER. For example:
$ MCR LATCP SET NODE/NOLARGE_BUFFER
Digital recommends that you use the SET NODE/NOLARGE_BUFFER command after all logical LAT links have been created and before the LAT node has been turned on. For example, note the order of the commands in LAT$SYSTARTUP.COM:
$! $! Create each logical LAT link with a unique name and $! unique LAN address (forced with /NODECNET). $! $ LCP CREATE LINK FDDI_1 /DEVICE=FCA0 /NODECNET $ LCP CREATE LINK FDDI_2 /DEVICE=FCB0 /NODECNET $! $! Don't use large buffer support (force packet $! sizes to be no larger than what Ethernet can $! support). $! $ LCP SET NODE /NOLARGE_BUFFER $! $! Turn on the LAT protocol. $! $ LCP SET NODE /STATE=ON
The LAT Control Program (LATCP) utility configures and controls the LAT software on OpenVMS systems. LATCP commands let you stop and start the LAT driver (which implements the LAT protocol) and modify or display LAT characteristics of the OpenVMS node.
With LATCP, you can set up your system as a service node, which offers one or more resources (services) for access by users on other systems in the local area network (LAN).
You can also use LATCP to set up the system to allow its users to access services on other systems in the LAN. In this case, the system can act like a terminal server: it can manage multiple user sessions simultaneously for connections to services on other nodes.
You can use LATCP to set up your system to support incoming access only, outgoing access only, or both incoming and outgoing access. You can also set up your system so that it supports neither incoming nor outgoing access.
When you set up your system to support outgoing access, the LAT software manages a database of LAT services and nodes. The software builds the database when you enable outgoing access on your node. The software begins to collect LAT service announcements---multicast messages sent by LAT service nodes---and builds the database based on these service announcements. You can use LATCP to display the services and nodes in this database and to control the size of the database. Allow outgoing access on systems that can tolerate the additional overhead, such as standalone systems.
Use LATCP to do the following:
With the LAT protocol, you can set up LAT application ports on the local node so that users can access printers and other asynchronous devices that are connected to LAT terminal servers or service nodes on the LAN. The remote devices must be configured appropriately.
Enter the following command to invoke LATCP:
$ RUN SYS$SYSTEM:LATCP LATCP>
At the LATCP> prompt, you can enter LATCP commands. To exit LATCP, enter EXIT or press Ctrl/Z at the LATCP> prompt.
You can also execute a single LATCP command by using a DCL string assignment statement, as shown in the following example:
$ LCP :== $LATCP $ LCP SET NODE/STATE=ON
LATCP executes the SET NODE command and returns control to DCL.
Table 24-1 summarizes the LATCP commands.
| Command | Function |
|---|---|
| ATTACH | Transfers control from your current process to the specified process. |
| CREATE LINK | Creates LAT data links. |
| CREATE PORT | Creates a logical port on the local node. |
| CREATE SERVICE | Creates a service on a service node. |
| DEFINE/KEY | Assigns a command string to a function key on your keypad. |
| DELETE LINK | Deletes a LAT data link from a node. |
| DELETE PORT | Deletes an application port or dedicated port. |
| DELETE QUEUE_ENTRY | Deletes an incoming queued request from the local node. |
| DELETE SERVICE | Deletes a service on a service node. |
| EXIT | Returns the user to DCL command level. |
| HELP | Displays help text for LATCP commands. |
| RECALL | Recalls LATCP commands that you entered previously so that you can execute them again. |
| REFRESH | Refreshes your display screen, for example, after your display has been overwritten by output from some other source. |
| SCROLL | Allows you to retrieve information that has scrolled off the screen. |
| SET LINK | Modifies characteristics of LAT data links. |
| SET NODE | Specifies LAT characteristics for a node. |
| SET PORT | Maps a logical port on a node to either a remote device on a terminal server or a special application service on a remote LAT service node. |
| SET SERVICE | Changes service characteristics. |
| SHOW LINK | Displays the characteristics of links on your node. |
| SHOW NODE | Displays the characteristics of nodes. |
| SHOW PORT | Displays port characteristics. |
| SHOW QUEUE_ENTRY | Displays information about requests, or entries, queued on the local node. |
| SHOW SERVICE | Displays characteristics of LAT services known to your node. |
| SPAWN | Creates a subprocess. |
| ZERO COUNTERS | Resets the node counters, service counters, and link counters maintained by your node. |
For detailed information about LATCP commands and qualifiers, see the OpenVMS System Management Utilities Reference Manual.
As system manager, you start up the LAT protocol and configure your node as a service node by executing the command procedure SYS$STARTUP:LAT$STARTUP. This procedure executes the following two procedures:
How to Perform This Task
To make sure the LAT protocol is started each time the system boots, add a command to execute this procedure in the general-purpose, site-specific startup command procedure, described as follows. (See Section 5.2.1 for more detailed information about this command procedure, including the file specification used to identify it in your operating system.)
To set up your node as a LAT service node and start the LAT protocol software on your system each time the system boots, edit the general-purpose, site-specific startup command procedure to add the following line:
$ @SYS$STARTUP:LAT$STARTUP.COM
When the general-purpose, site-specific startup command procedure executes this command, it invokes LAT$STARTUP.COM, which in turn invokes the LAT$CONFIG and LAT$SYSTARTUP command procedures.
You can append any of the following arguments to the command line that invokes LAT$STARTUP to specify unique LAT characteristics for your node. The procedure will pass these arguments to LAT$SYSTARTUP.COM to define the LAT characteristics you specify.
$ @SYS$STARTUP:LAT$STARTUP "P1" "P2" "P3" "P4" "P5"
Digital recommends that you modify LAT$SYSTARTUP.COM directly, rather than passing parameters in P1 through P5. However, if you choose to use P1 through P5, the arguments have the following meanings:
| Argument | Format | Meaning |
|---|---|---|
| P1 | Service-name | Name of the service. For clustered service nodes, use the cluster alias as the service name. For independent service nodes, use the DECnet node name. LAT$SYSTARTUP.COM uses the argument P1 to assign a service name to the node (with the LATCP CREATE SERVICE command). |
| P2--P4 | Any of the following: | LAT$SYSTARTUP.COM uses the arguments to assign LAT node characteristics (with the LATCP SET NODE command). |
| /IDENTIFICATION= "string" |
Description of the node and its services that is advertised over the
local area network (LAN). The default is the string defined by the
logical name SYS$ANNOUNCE. Make sure you include five sets of quotation
marks around the identification string. For example:
"/IDENTIFICATION=" - """""Official system center"""""
|
|
| /GROUPS=(ENABLE= group-list) | Terminal server groups qualified to establish connections with the service node. By default, group 0 is enabled. | |
| /GROUPS=(DISABLE= group-list) | Removes previously enabled terminal server groups. If you are specifying the preceding qualifier to enable groups, you can combine the qualifiers into one, as shown in the example that follows this table. | |
| P5 | Any qualifiers valid with the CREATE SERVICE command |
LAT$SYSTARTUP.COM uses this argument to assign service characteristics
with the LATCP CREATE SERVICE command. You can specify the
/IDENTIFICATION, /LOG, and /STATIC_RATING qualifiers. Specify several
qualifiers as shown in the following example:
"/IDENTIFICATION=" -
|
6017P071.HTM OSSG Documentation 22-NOV-1996 14:23:01.86
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.