Compaq ACMS for OpenVMS
Managing Applications


Previous Contents Index

Part 1
Managing the ACMS System and ACMS Applications

This part of the manual contains information about managing the ACMS system and its components. Part 1 also contains information about authorizing, installing, running, and monitoring ACMS applications. In addition, it provides information on system tuning and describes how to set up your ACMS system for distributed processing.


Chapter 1
Introduction to Application Management

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:

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:

1.2 Controlling ACMS Operations

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

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:

1.4 Tuning an ACMS System

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:

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


Chapter 2
Authorizing and Controlling Terminals

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:

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:

2.2 How to Run DDU

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.


Previous Next Contents Index