![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
Note that if you want to do any of the following LAT network tasks, you must edit LAT$SYSTARTUP.COM (described in Section 24.6):
For a full description of LATCP commands and qualifiers, see the OpenVMS System Management Utilities Reference Manual.
Example
The following command creates the service OFFICE on the service node MOE, which is part of the OFFICE cluster (refer to Figure 24-1):
$ @SYS$STARTUP:LAT$STARTUP OFFICE
To define special LAT characteristics for your node, edit the site-specific command procedure SYS$MANAGER:LAT$SYSTARTUP.COM. This command procedure contains LATCP commands that define LAT characteristics. LAT$SYSTARTUP.COM is invoked when you execute the LAT$STARTUP command procedure. As explained in Section 24.5, you typically execute LAT$STARTUP.COM from the general-purpose, site-specific startup command procedure.
If you want your node to be a LAT service node that only supports incoming connections from interactive terminals, editing LAT$SYSTARTUP.COM is not necessary. You can assign a service name and other characteristics by specifying parameters when you invoke the command procedure SYS$STARTUP:LAT$STARTUP, as described in Section 24.5.
However, you can edit LAT$SYSTARTUP.COM to add LATCP commands that customize LAT characteristics for your node, for example:
| Task | For More Information |
|---|---|
| Create more than one service | Section 24.6.1 |
| Create logical ports for special application services and printers | Section 24.6.2 |
| Enable queued incoming requests | Section 24.6.3 |
| Enable outgoing LAT connections to support the SET HOST/LAT command | Section 24.6.4 |
| Tailor node characteristics¹ | Section 24.6.5 |
Caution
Do not edit the command procedures LAT$STARTUP.COM and LAT$CONFIG.COM. These are procedures supplied by Digital to perform functions necessary for the LAT protocol to run correctly. Edit only LAT$SYSTARTUP.COM to define LAT characteristics specific to your site.
If you edit LAT$SYSTARTUP.COM, you should add only LATCP commands. In addition, you should conform to the order of commands in the template file SYS$MANAGER:LAT$SYSTARTUP.TEMPLATE. Section 24.6.5 provides a sample edited LAT$SYSTARTUP procedure. The OpenVMS System Management Utilities Reference Manual contains full descriptions of all the LATCP commands you can include in LAT$SYSTARTUP.COM.
The LAT$SYSTARTUP.COM procedure provided by Digital creates one service. This can be a primary service, one through which users can access the general computing environment. It can also be a special application service, such as a data entry program or an online news service.
You can also create a limited service with a fixed number of LTA devices, as described in Section 24.6.2.3.
The LAT$SYSTARTUP.COM procedure creates the service with the same name as that of your node, unless you specify a unique service name as an argument to the @SYS$STARTUP:LAT$STARTUP.COM command, as explained in Section 24.5.
How to Perform This Task
To create services in addition to the one provided in LAT$SYSTARTUP.COM, use the CREATE SERVICE commands, which you can add to LAT$SYSTARTUP.COM. Note that if you create an application service, Digital recommends that you assign the name of the application program. For more information on the LATCP command CREATE SERVICE, see the OpenVMS System Management Utilities Reference Manual.
Example
The following example creates the application service NEWS on the local node:
$ LCP :== $LATCP $ LCP CREATE SERVICE /APPLICATION NEWS
The LAT$SYSTARTUP.COM file provided by Digital includes sample commands to create logical ports on the service node and associates them with physical ports or services on the terminal server node. These ports can be used for application services and remote printers.
How to Perform This Task
To create ports, enable the sample commands by removing the exclamation points (!) that precede them in the LAT$SYSTARTUP.COM file, or add similar CREATE PORT and SET PORT commands to that file to meet your needs. For information on the LATCP commands CREATE PORT and SET PORT, see the OpenVMS System Management Utilities Reference Manual.
Note
Digital strongly recommends that you create application ports and dedicated ports after the LATCP command SET NODE/STATE=ON is executed. This minimizes nonpaged pool memory usage and eliminates the possibility of creating duplicate ports.
Note that you may encounter the following error when attempting to create an application port (with a command such as LCP CREATE PORT LTA5001:/APPLICATION, for example):
%LAT-W-CMDERROR, error reported by command executor -SYSTEM-F-DUPLNAM, duplicate name
This error indicates that the LAT application port you are trying to create is already created by some other application. This application could be LATCP itself (LATCP's port, LATCP$MGMT_PORT, is used to communicate with LTDRIVER).
To avoid this error, make sure the SET NODE/STATE=ON command is executed before any commands that create application ports or dedicated ports. You can also use the LATCP command SET NODE/DEVICE_SEED. For more information on the SET NODE/DEVICE_SEED command, see the OpenVMS System Management Utilities Reference Manual.
If you set up a port for a printer, you must also perform the following tasks:
These tasks are described in Chapter 13.
To establish a special application service, include the /DEDICATED qualifier when defining a LAT port. The application program to which the service connects must define the same dedicated port. For example, the following commands set up ports for an application service called NEWS:
$ LCP :== $LATCP $ LCP CREATE PORT LTA333:/DEDICATED $ LCP SET PORT LTA333:/SERVICE=NEWS
Before application services can be available to user terminals on the LAT network, you must start the application program. You usually add commands to SYLOGIN.COM to do this.
Application services with dedicated ports allow you to create a predetermined number of LTA devices (LAT terminals, for example) that are under the control of a process supplied by the system. In that environment, however, the user cannot log in to the service because no way exists for dedicated LTA devices to run the system login image (LOGINOUT.EXE).
You can create a limited service that allows users to log in to a predetermined number of LTA devices associated with that limited service. When all those devices are in use, the LAT software will reject additional connection requests to that service, as indicated by "service in use" error messages. Creating a limited service in this way allows you to control the number of LAT users on your system. (Note, however, that you cannot control which LTA device will be assigned when a user connects to the limited service.)
The following example sets up a limited service with two predetermined LTA devices:
$ LCP :== $LATCP $ LCP CREATE SERVICE /LIMITED RESTRICTED $ LCP CREATE PORT LTA100 /LIMITED $ LCP CREATE PORT LTA101 /LIMITED $ LCP SET PORT LTA100 /SERVICE=RESTRICTED $ LCP SET PORT LTA101 /SERVICE=RESTRICTED
When a user attempts to connect to the limited service named RESTRICTED, the LAT software will choose either LTA100 or LTA101 (whichever is available first) and complete the user connection. The user can then log in to that system. If another user connects to the service, that second connection attempt will be assigned to the remaining LTA device. The user can then log in to that second system. When the two devices associated with the limited service named RESTRICTED are both in use, any subsequent attempts to connect to that service will be rejected, as indicated by the "service in use" error message.
When a user logs out of the system (LTA100 or LTA101), that LTA device is not deleted. Instead, it is reset to accept the next connection request to the limited service.
By default, incoming requests to limited or application services are queued. This means that if you attempt to connect to a limited or application service (by using a terminal server port with forward queuing enabled or by entering the DCL command SET HOST/LAT/QUEUE), the LAT software will queue, rather than reject, this connection request if the service has no available ports.
How to Perform This Task
You can set up and manage a service that queues incoming connect requests as follows:
See the OpenVMS System Management Utilities Reference Manual for more detailed descriptions of the LATCP commands and qualifiers you use to support queued requests.
Example
The following example shows how to enable queuing on your system:
$ LCP :== $LATCP $ LCP SET SERVICE /QUEUE
Note
If a system is configured to handle queued connect requests, that system must be set up as follows to avoid possible queue connection failures:
- Incoming and outgoing connections must be enabled.
- User group codes and service group codes must be identical.
By default, outgoing LAT connections are disabled on a node. To allow users to use the SET HOST/LAT connection to establish LAT connections from the node, you must edit LAT$SYSTARTUP.COM to enable outgoing connections. For more details on using the SET HOST/LAT command for outgoing LAT connections, see the description of that command in the OpenVMS DCL Dictionary.
Commands to enable outgoing connections are included in the LAT$SYSTARTUP.COM file provided by Digital. Enable the command of your choice by removing the exclamation point (!) that precedes it, or add a similar command to meet your needs. For more information, see the /CONNECTIONS and /USER_GROUPS qualifiers to the LATCP command SET NODE in the OpenVMS System Management Utilities Reference Manual.
To attain optimal SET HOST/LAT performance and forward port performance, you should set the system parameter TTY_ALTYPAHD to 1500 and reboot.
If you want to set up your node only as a service node with incoming connections enabled, editing LAT$SYSTARTUP.COM is not necessary. However, you might edit LAT$SYSTARTUP.COM to do one or more of the following tasks:
The following is a sample of an edited LAT$SYSTARTUP.COM procedure that creates services, creates and sets ports, and sets nodes to allow incoming and outgoing connections.
$! $! LAT$SYSTARTUP.COM -- LAT Startup Commands Specific to Site $! $! Use this command procedure to customize the LAT characteristics for $! the local node. These commands, which should serve as examples, $! will set up a LAT service name SYS$NODE and default identification $! SYS$ANNOUNCE. The LAT service name and identification will default $! to SYS$NODE and SYS$ANNOUNCE unless you specify a service name and $! identification as arguments to the command line that invokes $! LAT$STARTUP.COM: $! $ @SYS$STARTUP:LAT$STARTUP $! $! You can specify other node and service characteristics (such as group $! codes) as arguments to this command line, as shown below. $! $! Argument Function $! --------- -------- $! $! P1 Name of the service to be created. If not supplied, a $! service will be created with the same name as the node. $! $! P2,P3,P4 Parameters and qualifiers to the SET NODE command. $! $! P5 Parameters and qualifiers to the SET SERVICE command. $! P5 is only used if P1 is specified. More than one $! argument may be supplied by enclosing the string in $! quotes. $! $! Example: $ @SYS$STARTUP:LAT$STARTUP HAWK "/IDENTIFICATION=" - $! """""Development node""""" $! $! Please review and edit this file for possible additions and deletions $! that you wish to make. Future software updates will not overwrite the $! changes made to this file. $! $ required_privileges = "OPER" $ prev_privs = f$setprv(required_privileges) $ if .not. f$privilege(required_privileges) then goto no_privileges $ lcp := $latcp $! $! --------------------- Modify Node Characteristics ------------------------ $! $ lcp set node 'p2' 'p3' 'p4' $! $! Some examples: $! $! ** Allow incoming connections only $! $! lcp set node /connections=incoming /groups=(enable=(12,40,43,73),disable=0) $! lcp set node /connections=incoming /groups=enable=(0-255) $! $ LCP SET NODE /CONNECTIONS=INCOMING /GROUPS=(ENABLE=(12,40,43,73),DISABLE=0) $! $! ** Allow outgoing connections only $! $! lcp set node /connections=outgoing /user_groups=enable=(24,121-127) $! lcp set node /connections=outgoing /user_groups=(enable=0-255) /node_limit=50 $! $! ** Enable incoming and outgoing connections $! $! lcp set node /connections=both /group=enable=(43,73) /user=enable=(44,56) $! lcp set node /connections=both /group=enable=(0-255) /user=enable=(0-255) $! $! $! -------------------- Modify Service Characteristics ---------------------- $! $ if p1 .eqs. "" $ then $ lcp create service $ else $ lcp create service 'p1' 'p5' $ endif $! ------------------------- Start LAT Protocol ----------------------------- $! $ lcp set node /state=on $! $! $! ------------------------- Create and Map Ports --------------------------- $! $! Some examples: $! $! lcp create port lta101: /dedicated $! lcp create port lta102: /application $! lcp create port lta103: /application $! lcp create port /nolog/logical=(name=ln03$mgmt, table=system, mode=executive) $ $ LCP CREATE PORT LTA1: /NOLOG $ LCP CREATE PORT LTA20: /NOLOG $ $! lcp set port lta101: /dedicated /service=graphics $! lcp set port lta102: /node=server_1 /port=port_1 $! lcp set port lta103: /node=server_2 /service=laser $! lcp set port ln03$mgmt: /node=server_3 /service=ln03_printers $! $ LCP SET PORT LTA1: /APPLICATION/NODE=TERM_SERVER_1 /PORT=PORT_6 $ LCP SET PORT LTA20: /APPLICATION/NODE=TERM_SERVER_2 /PORT=PORT_6 $! $exit: $ prev_privs = f$setprv(prev_privs) $ exit $! $no_privileges: $ write sys$output "Insufficient privileges to execute LATCP commands." $ write sys$output "Requires ",required_privileges," privileges." $ goto exit
On OpenVMS nodes, another component of the LAT software, the LAT Ancillary Control Process (LATACP), maintains the database of available nodes and services. The nodes and services can be those that are multicast from remote LAT nodes, or they can consist of the local node and one or more local services that you create on your own system. The maximum size of this database is dependent on the value of the system parameter CTLPAGES.
After you enter a LATCP command, you might get the following response:
%LAT-W-CMDERROR, error reported by command executor -LAT-F-ACPNOCTL, insufficient resources - ACP CTL/P1 space limit reached
If so, this signifies that the database size has reached the CTLPAGES limit. You can correct the situation in one of three ways:
This chapter describes what you must do if you want to run software that uses DECdtm services, such as ACMS, DECintact, Oracle Rdb, and RMS Journaling.
Information Provided in This Chapter
This chapter describes the following tasks:
| Task | Section |
|---|---|
| Planning transaction logs | Section 25.2 |
| Planning for a DECnet-Plus network | Section 25.3 |
| Creating transaction logs | Section 25.4 |
| Monitoring transaction performance | Section 25.5 |
| Checking whether a transaction log is too small | Section 25.6 |
| Changing the size of a transaction log | Section 25.7 |
| Moving a transaction log | Section 25.8 |
| Dismounting a disk | Section 25.9 |
| Adding a node | Section 25.10 |
| Removing a node | Section 25.11 |
| Disabling DECdtm services | Section 25.12 |
| Enabling DECdtm services | Section 25.13 |
The map in Figure 25-1 shows the tasks, and the order in which to do them.
This chapter explains the following concepts:
| Concept | Section |
|---|---|
| Understanding transaction logs | Section 25.1 |
| Understanding transaction groups | Section 25.3.2.2 |
Figure 25-1 Managing DECdtm Services
Before a node can execute DECdtm transactions, you must create a transaction log for the node. In an OpenVMS Cluster, create a transaction log for each node in the cluster. Use the Log Manager Control Program (LMCP) utility to create and manage transaction logs.
DECdtm services use the logical name SYS$JOURNAL to find transaction logs. You must define SYS$JOURNAL to point to the directories that contain transaction logs.
The size and location of a transaction log can affect transaction performance. Before you create a transaction log, decide the size and location of the transaction log.
Later, you can change the size of a transaction log, or move it. However, careful planning at this stage reduces the need for future changes.
This section describes:
| Task | Section |
|---|---|
| Deciding the size of a transaction log | Section 25.2.1 |
| Deciding the location of a transaction log | Section 25.2.2 |
When you create a transaction log, you can specify its size. The default size is 4000 blocks; this gives acceptable performance on most systems.
If you know the expected rate of transactions, Digital suggests the
following formula to calculate the transaction log size:
size = 40
* rate
where:
| size | is the size of the transaction log in blocks. |
| rate | is the average number of transactions executed per second. |
If you do not know the rate of transactions, accept the default size of 4000 blocks.
| Fast | Achieve speed by using a high--performance disk, such as a solid--state disk, that is not heavily used. |
| Highly available |
Achieve high availability by having multiple access paths to the data.
In an OpenVMS Cluster, use a disk that can be accessed by the other nodes in the cluster. This ensures that if one node fails, transactions running on other nodes are not blocked. |
| Reliable |
Achieve reliability by keeping multiple copies of the data.
Using a shadowed disk is more reliable than using a nonshadowed disk, but may be slower because transaction logs are almost exclusively write--only. |
You may need to choose between speed and either availability or reliability. For example, if the node is a workstation, you may choose to sacrifice speed for availability and reliability by putting the node's transaction log on a shadowed HSC--based disk, instead of on a faster disk attached to the workstation.
In a cluster environment, try to distribute the transaction logs across different disks. Having more than one transaction log on a disk can lead to poor transaction performance.
Note
Make sure that the disk has enough contiguous space to hold the transaction log. A discontiguous transaction log leads to poor transaction performance.
This section contains the followinginformation to help you plan for using DECdtm in a DECnet-Plus network:
DECdtm does not support multiple DECnet-Plus namespaces.
This means that if you want to use software that uses DECdtm services, you cannot use both a local namespace and a DECdns namespace.
SCSNODE is a system parameter that defines the name of the computer. You must follow certain rules when choosing SCSNODE names if you have a DECnet-Plus network and you want to perform DECdtm transactions that span either different OpenVMS Clusters or different standalone computers.
A transaction group is a group of computers involved in DECdtm transactions whose SCSNODE names must obey the rules described in Section 25.3.2.1.
A transaction group conforms to the following guidelines:
Figure 25-2 shows an example of a transaction group.
Figure 25-2 Transaction Group
All nine computers shown in the picture are in the same transaction group because:
Before a node can perform DECdtm transactions, you must create a transaction log for the node. In an OpenVMS Cluster environment, create a transaction log for each node.
Caution
Removing a node from a cluster after you have created the transaction logs can lead to data corruption. For instructions on how to remove a node safely, see Section 25.11.
How to Perform This Task
DEFINE/SYSTEM/EXECUTIVE_MODE SYS$JOURNAL dirspec[,...]where dirspec is the full specification of a directory in which you want to create one or more transaction logs. List all the directories that will contain transaction logs. You can list the directories in any order.
CREATE LOG [/SIZE=size] dirspecSYSTEM$node.LM$JOURNALwhere:
| size | is the size of the transaction log in blocks. By default, the size of the transaction log is 4000 blocks. |
| dirspec | is the full specification of the directory in which you want to create the transaction log. |
| node | is the name of the node. |
| Step | Action | ||||
|---|---|---|---|---|---|
| a. |
Check whether the logical SYS$DECDTM_INHIBIT is defined:
$ SHOW LOGICAL SYS$DECDTM_INHIBIT
|
||||
| b. |
Is SYS$DECDTM_INHIBIT defined?
|
6017P072.HTM OSSG Documentation 22-NOV-1996 14:23:03.30
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.