HP OpenVMS Systems Documentation
OpenVMS System Manager's Manual
26.6.1 Creating Additional Services
The LAT$SYSTARTUP.COM procedure provided by Compaq 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 18.104.22.168.
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 26.5.
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, Compaq recommends that you assign the name of the application program. For more information about the LATCP command CREATE SERVICE, refer to the OpenVMS System Management Utilities Reference Manual.
The following example creates the application service NEWS on the local node:
26.6.2 Setting Up Ports
The LAT$SYSTARTUP.COM file provided by Compaq 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.
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 about the LATCP commands CREATE PORT and SET PORT, refer to the OpenVMS System Management Utilities Reference Manual.
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):
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 about the SET NODE/DEVICE_SEED command, refer to the
OpenVMS System Management Utilities Reference Manual.
If you set up a port for a printer, you must also perform the following tasks:
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:
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:
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.
Refer to the OpenVMS System Management Utilities Reference Manual for more detailed descriptions of the LATCP commands and qualifiers you use to support queued requests.
The following example shows how to enable queuing on your system:
26.6.4 Enabling Outgoing LAT Connections
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, refer to 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 Compaq. 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, refer to 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:
26.6.5 Sample Edited LAT$SYSTARTUP.COM Procedure
26.7 Managing the LATACP Database Size
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:
If so, this signifies that the database size has reached the CTLPAGES limit. You can correct the situation in one of three ways:
On OpenVMS Alpha systems, unpredictable results can occur if DECdtm services are used in a multithreaded environment. Do not make calls to DECdtm services in kernel threads other than the initial thread because much of the work performed by DECdtm uses the context of the calling process.
This chapter describes the following tasks:
|Planning transaction logs||Section 27.2|
|Planning for a DECnet-Plus network||Section 27.3|
|Creating transaction logs||Section 27.4|
|Monitoring transaction performance||Section 27.5|
|Checking whether a transaction log is too small||Section 27.6|
|Changing the size of a transaction log||Section 27.7|
|Moving a transaction log||Section 27.8|
|Dismounting a disk||Section 27.9|
|Adding a node||Section 27.10|
|Removing a node||Section 27.11|
|Disabling DECdtm services||Section 27.12|
|Enabling DECdtm services||Section 27.13|
The map in Figure 27-1 shows the tasks, and the order in which to do them.
This chapter explains the following concepts:
|Understanding transaction logs||Section 27.1|
|Understanding transaction groups||Section 22.214.171.124|
Figure 27-1 Managing DECdtm Services
27.1 Understanding Transaction Logs
A transaction log is a file that stores information
about DECdtm transactions performed on a node. It is of file type
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.
27.2 Planning 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:
|Deciding the size of a transaction log||Section 27.2.1|
|Deciding the location of a transaction log||Section 27.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, Compaq suggests the
following formula to calculate the transaction log size:
size = 40 * rate
|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.
27.2.2 Deciding the Location of a Transaction Log
If possible, choose a disk that is:
|Fast||Achieve speed by using a high--performance disk, such as a solid--state disk, that is not heavily used.|
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.
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.
Make sure that the disk has enough contiguous space to hold the transaction log. A discontiguous transaction log leads to poor transaction performance.