The ACMS software helps you develop, use, and maintain online applications. Once you define and test an ACMS application, you can make it available to users. Before users can run tasks in the application, you must authorize the users and their terminals for access to ACMS. You can also optionally authorize ACMS applications and the users who can install them. Finally, you can start the ACMS system and applications.

These activities are all part of managing ACMS applications. Other aspects of managing ACMS applications include:

• Maintaining the security of applications
• Controlling their day-to-day operation
• Monitoring applications
• Managing ACMS task queues and queued task elements
• Tuning the ACMS system

This guide discusses the work involved in managing ACMS applications and the tools ACMS provides for this work. Practice using the ACMS management tools discussed in this book by installing and running the ACMS sample application.

See Chapter 9 for information about how to install and manage ACMS applications.

This manual does not discuss using the ACMS Remote Manager to manage ACMS systems remotely across a network. For information about managing ACMS systems remotely across a network, see the Compaq ACMS for OpenVMS Remote Systems Management Guide in the ACMS documentation set.

1.1 ACMS Authorization Tools

When many users share one OpenVMS system, it is important for the ACMS system manager to control the facilities to which each user has access. For example, some users' jobs require access only to ACMS, while others require access to OpenVMS as well as ACMS.

The five tools that the system manager uses to authorize access to ACMS are:

• The OpenVMS Authorize Utility authorizes users to log in to OpenVMS. All ACMS users must be authorized OpenVMS users, whether they log in to OpenVMS or directly in to ACMS.
• The ACMS User Definition Utility (UDU) controls who can sign in to ACMS and whether a user receives a menu or just a selection prompt after signing in. The system manager must also use UDU to define the user name of ACMS processes. See Chapter 3 for information about UDU.
• The ACMS Device Definition Utility (DDU) authorizes the terminals at which users can sign in to ACMS and controls whether a user signs in directly to ACMS, or logs in to OpenVMS and then ACMS. See Chapter 2 for information about DDU.
• The system manager can use the ACMS Application Authorization Utility (AAU) to authorize users to install applications in the directory associated with the logical name ACMS$DIRECTORY. See Chapter 4 for information about AAU.
• The Access Control List (ACL) subclause, used in the application definition, specifies by User Identification Code (UIC) or identifier which users can run certain tasks in an application. See Compaq ACMS for OpenVMS ADU Reference Manual for information on the ACCESS application-task subclause.

Controlling the overall operations of an ACMS system includes using the ACMS operator commands to:

• Install ACMS applications
• Set up terminals as ACMS operator terminals
• Control the ACMS system, including starting and stopping the system, and changing system characteristics
• Control the queued task initiator (QTI) and ACMS task queues
• Control ACMS applications, including starting and stopping applications
• Enable and disable tasks
• Enable and disable application auditing
• Control the terminals from which users can sign in to ACMS by starting and stopping the terminal subsystem controller (TSC)
• Cancel tasks when necessary
• Cancel users when necessary
• Display system and application information

Most ACMS operator commands require the OpenVMS OPER privilege. The only commands that do not require the OPER privilege are the ACMS/SHOW commands and ACMS/INSTALL. See Chapter 8, Chapter 9, and Chapter 21 for more information on the ACMS operator commands.

1.3 Monitoring an ACMS System

ACMS supplies several monitoring tools to help observe the system and its users:

• The Audit Trail Logger gathers information about an active ACMS system (for example, system and application starts and stops, user sign-ins and sign-outs, processing errors, user task selections, task completions and task cancellations) and generates records of ACMS user and application activity. Use the Audit Trail Report (ATR) Utility to produce reports containing audit trail information. See Chapter 12 for information about the ATL and the ATR Utility.
• The ACMS/SHOW commands display information about an active ACMS system and its applications. See Chapter 21 for information about the ACMS/SHOW commands.
• The Software Event Logger (SWL) reports internal software errors that occur during run time. Use the Software Event Log Utility Program (SWLUP) to generate reports containing SWL information. See Chapter 13 for information about SWL and SWLUP.

Normally, you set OpenVMS and ACMS system parameters and ACMS run-time process quotas after an installation or an upgrade, or when the ACMS system load changes with, for example, additional applications or users. Use the ACMSPARAM.COM and ACMEXCPAR.COM command procedures to set parameters and quotas.

After you are familiar with the requirements of your system, you might need to change some of the default system parameter values. For example, you might need to change the value set for the maximum number of users who can sign in to ACMS. You can make system parameter changes with the ACMSPARAM and ACMEXCPAR command procedures.

You can also use the ACMSGEN Utility to set or change ACMS parameters. However, the use of ACMSPARAM.COM is preferred because this command procedure automatically changes other parameters related to the ones you modify. ACMSGEN changes values of ACMS parameters similar to the way the OpenVMS SYSGEN Utility lets you change OpenVMS parameters.

You can use ACMSGEN parameters to control the ACMS TSC, the ACC, the CP, the EXC, and the QTI, as well as ACMS message services and workspace pools. These components start and control other ACMS components.

Chapter 14 discusses tuning considerations, monitoring tools, and ACMS components that affect ACMS performance. It also provides a tuning checklist. Chapter 10 and Chapter 11 describe the ACMS system parameters in detail and explain how to change their values using the ACMSPARAM.COM and the ACMEXCPAR.COM procedures and the ACMSGEN Utility.

1.5 ACMS Application Management Tools

ACMS has several application management tools. Table 1-1 lists the ACMS application management tools and tells you where you can find further details on each tool in this book.

Table 1-1 ACMS Application Management Tools

Management Tool	Function
ACMS Operator Commands	Perform standard operator functions such as starting and stopping the ACMS system, the TSC, and the QTI. Other operator commands allow you to start and stop ACMS applications and display application and system information. See Chapter 8 , Chapter 9 , and Chapter 21 for information.
ACMSGEN Utility	Changes the values of ACMS parameters. See Chapter 11 and Chapter 22 for information.
ACMSPARAM.COM and ACMEXCPAR.COM procedures	Change the values of OpenVMS and ACMS system parameters, and ACMS run-time process quotas. See Chapter 10 for information.
Application Authorization Utility (AAU)	Authorizes applications to be installed in the directory associated with the logical name ACMS$DIRECTORY. See Chapter 4 and Chapter 19 for information.
Audit Trail Report (ATR) Utility	Returns records of application and user activity. See Chapter 12 and Chapter 23 for information.
Device Definition Utility (DDU)	Authorizes ACMS terminals and, optionally, defines terminals to sign in directly to ACMS. See Chapter 2 and Chapter 17 for information.
Queue Manager Utility (ACMSQUEMGR)	Creates and manages ACMS task queues and queued task elements. See Chapter 5 and Chapter 20 for information.
Software Event Log Utility Program (SWLUP)	Creates reports of selected events recorded by the Software Event Logger. See Chapter 13 and Chapter 24 for information.
User Definition Utility (UDU)	Authorizes users to sign in to ACMS and assigns sign-in displays, including default menus, to ACMS users. See Chapter 3 and Chapter 18 for information.

1.6 Learning to Manage an ACMS System

While running the sample applications, you learn to authorize users and terminals and how to start and stop the ACMS system by using ACMS operator commands. In addition, the sample applications help you learn how to:

• Perform other functions with the operator commands, such as enabling and disabling ACMS operator terminals or the Audit Trail Logger.
• Run the ATR Utility to examine an ACMS log report and to familiarize yourself with the LIST command and its qualifiers.
• Run the ACMSPARAM.COM and ACMEXCPAR.COM command procedures to familiarize yourself with ACMS system parameters and run-time process quotas.

It is recommended that you run the ACMS sample applications if you are a new ACMS user.

Authorized ACMS users must sign in from terminals that have been authorized for access to ACMS. This chapter describes how to use the ACMS Device Definition Utility (DDU) to authorize terminals by creating DDU device definitions. See Section 2.14 for a summary of DDU commands and qualifiers. For reference information on the commands described in this chapter, refer to Chapter 17.

2.1 How DDU Works

System managers use DDU commands and qualifiers to create a device authorization file (ACMSDDF.DAT) that contains authorizations for ACMS terminals. This information includes:

• Device name of the terminal. Use physical device names or group device names to authorize terminals. Table 2-1 lists the DDU group device names.
• Terminal sign-in characteristics.

When a user tries to sign in to ACMS from a terminal, ACMS checks the ACMSDDF.DAT for a device definition for the user's terminal. If the authorization file does not contain a definition for that device, ACMS then checks for the group device name $ALL to see if all devices are authorized for ACMS access. If there is no $ALL definition, ACMS denies access to the terminal. See Table 2-1 for more information about the $ALL group device name.

When the TSC is started, or when the ACMS operator command ACMS/RESET TERMINALS is issued, ACMS reads the device authorization file and establishes the sign-in characteristics for terminals. You can assign the following sign-in characteristics to ACMS terminals:

• Controlled or Not Controlled
  Users at application port terminals with the Controlled sign-in characteristic sign in directly to ACMS. Users at dedicated service port terminals sign in either directly to ACMS or not, depending on the node they connect to at the "Local>" prompt. See Section 2.11 for a description of application ports and dedicated service ports. A terminal with a Not Controlled characteristic has access to both OpenVMS and ACMS. See Section 2.10 for information on how to assign the /[NO]CONTROLLED sign-in characteristic.
• Autologin or No Autologin
  A terminal with the Autologin characteristic allows users to sign in without typing a user name. A terminal with the No Autologin characteristic requires that the user enter a user name before gaining access to ACMS. See Section 2.5.1 for information on how to assign the Autologin or No Autologin characteristic.

You can start DDU from DCL level by using either of the following commands:

$ RUN SYS$SYSTEM:ACMSDDU DDU>

or

$ MCR ACMSDDU DDU>

When you start DDU, ACMS displays the DDU prompt (DDU>). You can then enter any DDU command (including the DDU command HELP to get online help information) or press [PF1] and [PF2] for access to a keypad of DDU commands. Use [Ctrl/B] to recall each DDU command you enter. To exit from DDU, use the DDU command EXIT.

DDU stores device definitions in the device authorization file ACMSDDF.DAT. When you run DDU to authorize terminals, DDU searches for the device authorization file in your current default directory. If ACMSDDF.DAT does not exist, ACMS creates it and places it in your current default directory.

At run time, ACMS looks in SYS$SYSTEM by default to find the device authorization file. If you choose to place the authorization file in a directory other than SYS$SYSTEM, you must direct the ACMS system to that directory location by defining the executive mode system logical name ACMSDDF. You can define ACMSDDF as an executive mode system logical name with the DCL DEFINE command and the /SYSTEM and /EXECUTIVE qualifiers. The following command defines ACMSDDF to be the directory DISK1:[SMITH]. You need the SYSNAM privilege to execute this command.

$ DEFINE/SYSTEM/EXECUTIVE ACMSDDF DISK1:[SMITH]ACMSDDF.DAT

When you run DDU for the first time, ACMS creates a new device authorization file and assigns all devices the characteristics defined by the DDU DEFAULT definition. The initial DEFAULT definition contains the sign-in characteristics Not Controlled and No Autologin. Because of this default, if you use the DDU command ADD without qualifiers after running DDU for the first time, all new terminals have access to both OpenVMS and ACMS.

Since DDU only contains the default definition when you run DDU for the first time, you must authorize a terminal name or a group device name before users have access to the ACMS system.

You can change the sign-in characteristics in the DDU default definition by using the DDU command DEFAULT. The DEFAULT command is described in Section 2.8.

2.3 Creating a DDU Definition

Authorize terminal access to ACMS by creating a DDU definition in the ACMSDDF.DAT. To create a new DDU definition, use the DDU command ADD and specify a device name. The ADD command creates a new DDU definition for the device in the device authorization file. Do not specify a colon at the end of device names. The following command authorizes terminal TTE6. When this command executes, DDU displays a message confirming that the device has been added to the device authorization file.

DDU> ADD TTE6 Device TTE6 has been added to the database

Instead of specifying a physical device name like TTE6 when you use the ADD command, you can quickly create authorizations for all terminals by specifying the group device name $ALL. The $ALL device name is described in Table 2-1, with other DDU group device names.

Table 2-1 DDU Group Device Names

Device Name	Description
$ALL	Authorizes all terminals. If you create a $ALL definition, you do not need to create any LT, PT, RT, or VT definitions. The $ALL definition authorizes all of those types of terminals as well as any unauthorized local terminals. Restrict terminal access to ACMS by creating individual definitions instead of using the $ALL device name.
LT	Authorizes all LAT terminals. You can authorize individual LAT terminals.
PT	Authorizes all pseudoterminals. You should only use pseudoterminals when you run DEC/Test Manager (DTM) sessions. You must authorize the PT device name if you want to run ACMS tasks from DTM. You cannot authorize individual pseudo terminals.
RT	Authorizes all remote terminals. You cannot authorize individual remote terminals.
TT	Authorizes all local terminals. You can authorize individual local terminals.
VT	Authorizes all virtual terminals. You assign virtual terminals for your system with the OpenVMS SYSGEN Utility. You cannot authorize individual virtual terminals.

Display the device names and sign-in characteristics for authorized devices by specifying the DDU SHOW command. See Section 2.9 for information on the SHOW command as well as an example of the output from the SHOW command.

2.4 Copying DDU Definitions

When a definition already exists with characteristics similar to a definition you want to create, you can use the DDU command COPY to create a new definition based on information in an existing DDU definition. The following command authorizes all local terminals using the device definition for terminal TTB6. When this command executes, DDU displays a message confirming that the device definition has been copied.

DDU> COPY TTB6 TT Device TTB6 has been copied to device TT

The first device name you specify with the COPY command is the name of the device in the existing device definition. The second device name is the name of the new device. A device name can be a logical name, a physical device name, or a group device name. See Table 2-1 for a list of DDU group device names. See Chapter 17 for more information on the COPY command.

2.5 Modifying DDU Definitions

Use the DDU MODIFY command to change the login characteristics in a device definition. The following subsections explain how to enable Autologin and how to use the /PRINTFILE qualifier.

2.5.1 Enabling Autologin Terminals

The following command modifies terminal TTE6 so that it is an ACMS-controlled terminal with Autologin enabled. TURKLES is the user name used for automatic login. When this command executes, DDU displays a message confirming that the device definition has been modified.

DDU> MODIFY TTE6 /CONTROLLED /AUTOLOGIN=TURKLES Device(s) has been modified

When users press the [Return] on terminal TTE6, they are prompted for a password (if a password is required) and are logged in to ACMS under the user name TURKLES. The device name you specify with the MODIFY command can be a logical name, a physical device name, or a group device name.

2.5.2 Using the /PRINTFILE Qualifier

The /PRINTFILE qualifier feature provides hardcopy capability for DECforms panels. In other words, DECforms allows users to send a copy of one or more panel displays to a printer or to a file for subsequent printing. Using DDU, you can specify a Printfile device or file for a terminal. If you specify a device, then it must be a spooled device. (Specifying a Printfile for a user is explained in Chapter 3).

To use the /PRINTFILE qualifier to specify a device or a file name:

1. Use a DECforms PRINT response step in a form source IFDL file wherever a response step can be used; for example, you can place it in a field exit response or in a panel exit response. You can also define a key that the user can press to issue the PRINT response. See DECforms Reference Manual for details about response steps and key definitions.

   Note If you do not enter a /PRINTFILE qualifier either for a device (using DDU) or for a user (with UDU), DECforms nevertheless creates a file if a user presses the key associated with the PRINT response. DECforms names the file form-name.TXT and places it in the default directory of the agent program.

2. To use the /PRINTFILE qualifier to specify a printfile name or a spooled device, you use the DDU MODIFY command, the device name, the /PRINTFILE qualifier, and the name of the spooled device or printfile specification:

   DDU> MODIFY <device-name> /PRINTFILE=<spooled-device-name>

   
   or

   DDU> MODIFY <device-name> /PRINTFILE=<print-file-spec>

   
   Following is an example of how you might enter the command for a spooled device:

   DDU> MODIFY TTE5 /PRINTFILE=SPOOLDEV::TXA0:

   
   According to the instructions in the preceding example, ACMS modifies the record for the terminal TTE5 in ACMSDDU.DAT to specify that DECforms panel screens are to be output on spooled device SPOOLDEV::TXA0:.

3. After you modify an ACMSDDU.DAT record, use the SHOW command, followed by the device name. DDU displays the /PRINTFILE specification that you have entered, for example:

   DDU> SHOW TTE5 Device Name: TTE5 NOT CONTROLLED No Autologin Printfile: SPOOLDEV::TXA0:

See Table 2-1 for a list of DDU group device names. See Chapter 17 for more information on the MODIFY command.