HP OpenVMS Systems Documentation

Content starts here

OpenVMS System Manager's Manual

Previous Contents Index

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

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.

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, 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:

$ LCP :== $LATCP

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.

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 about the LATCP commands CREATE PORT and SET PORT, refer to the OpenVMS System Management Utilities Reference Manual.


Compaq 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 about the SET NODE/DEVICE_SEED command, refer to the OpenVMS System Management Utilities Reference Manual. Setting Up Printers

If you set up a port for a printer, you must also perform the following tasks:

  1. Create a spooled output queue for the printer.
  2. Add a command to start the queue to the startup command procedure that starts your queues, or to the general-purpose, site-specific startup command procedure.

These tasks are described in Chapter 14. Setting Up Special Application Services

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

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. Setting Up Limited Services

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

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.

26.6.3 Queuing Incoming Requests

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:

  • Use the LATCP command SHOW SERVICE to determine whether the service has queuing enabled or disabled.
  • If queuing is disabled, use the SET SERVICE /QUEUED command to enable queuing.
  • Use the SET NODE /QUEUE_LIMIT=n command on the local node to control the number of free queue slots (where n is between 0 and 200).
  • Use the SHOW QUEUE_ENTRY [queue-entry-id] command to view entries in the local queue.
  • Use the DELETE QUEUE_ENTRY [queue-entry-id] command to delete an entry from the local queue.

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:

$ LCP :== $LATCP


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.

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:

  • Create more than one service on a node
  • Create special application services
  • Set up LAT printers
  • Enable outgoing LAT connections (to allow a node to act as a terminal server node)
  • Tailor node characteristics; for example, to assign special service announcements or connections to the LAN

26.6.5 Sample Edited LAT$SYSTARTUP.COM Procedure

The following example 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
$!                    $ @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.
$!   """""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)
$! ** 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 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
$ prev_privs = f$setprv(prev_privs)
$ exit
$ write sys$output "Insufficient privileges to execute LATCP commands."
$ write sys$output "Requires ",required_privileges," privileges."
$ goto exit

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:

%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:

  • Reduce the size of the database by reducing the node limit. Use the LATCP command SHOW NODE to display the node limit; use the command SET NODE/NODE_LIMIT to change it. For more information, refer to the OpenVMS System Management Utilities Reference Manual.
  • Reduce the size of the database by reducing the user group codes that are enabled on the node. Use the LATCP command SHOW NODE to display the enabled user group codes; use the command SET NODE/USER_GROUPS=DISABLE to disable some of them. For more information, refer to the OpenVMS System Management Utilities Reference Manual.
    If you choose this step, you must also edit your startup procedures to change the user groups that are enabled each time the system reboots. For more information, see Section 26.6.
  • Extend the size of the database by increasing the value of the system parameter CTLPAGES. As a general rule, note that every unit of CTLPAGES that you increase is roughly equivalent to six additional nodes or services that will be stored in the database.
    After you change CTLPAGES, you must reboot the system for the changed value to take effect. Make sure you add the increased value of CTLPAGES to the AUTOGEN parameter file MODPARAMS.DAT. For more information about changing values of system parameters, see Section 15.2.

Chapter 27
Managing DECdtm Services

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.


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.

Information Provided in This Chapter

This chapter describes the following tasks:

Task Section
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:

Concept Section
Understanding transaction logs Section 27.1
Understanding transaction groups Section

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 .LM$JOURNAL.

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:

Task Section
Deciding the size of a transaction log Section 27.2.1
Deciding the location of a transaction log Section 27.2.2

27.2.1 Deciding the Size of a Transaction Log

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.
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.


Make sure that the disk has enough contiguous space to hold the transaction log. A discontiguous transaction log leads to poor transaction performance.

Previous Next Contents Index