# Compaq ACMS for OpenVMS
Managing Applications

Previous | Contents | Index

### 2.12.2.5 Terminal Setup

Once a dedicated service port has been created, its terminal type should be identified on the node to which it will connect. For example, if LTA1 is a VT300, the following command should be entered:

    $ SET TERMINAL LTA1: /DEVICE=VT300/PERMANENT

This should be done for all dedicated service ports when they are created in LATCP. It is possible (and most probably desirable) to create dedicated service ports, associate them with a service, and set the terminal type using DCL command procedure(s).

### 2.12.2.6 Using a Dedicated Service Port

Before a dedicated service port can be used as an ACMS-controlled terminal, the user must connect to the correct service. When the connect command has been issued at the "Local>" prompt, one of three responses should occur. If the connection is possible, the following message will be displayed:

    Local -010- Session 1 to ACMS_CT on node ORANGE established

This assumes that this is the user's only current connection and that the service name is ACMS_CT on node ORANGE.

At this point, TSC will begin listening for a keystroke at the terminal. When one is detected, the process of signing the terminal in to ACMS will proceed in the same way as it does for application ports.

If the service is known but a connection could not be established, the following message will be displayed:

    Local -011- Connection to ACMS_CT not established
                Insufficient Node resources

This message is displayed when there are no channels open to the dedicated service port on the node with which LAT attempted to establish a connection. In some cases, it is normal to see this message after a hangup occurs; this is because of a necessary delay in opening a new channel to the terminal.

If repeated attempts to connect result in this message, the ACMS terminal subsystem may need to be started on that node. Because the message can be displayed for a variety of reasons, the system manager or person in charge of managing the ACMS application should be notified.

If the connection cannot be connected because the service has not been created, the following message will be displayed:

    Local -711- Service ACMS_CT not known

If this occurs, refer to the instructions for creating services with LATCP.

A dedicated service port user signs out of ACMS exactly as if using an application port. The only difference is that a dedicated service port will return the user to the "Local>" prompt; with an application port, TSC would display a logout message and immediately begin listening again.

The following example illustrates all the steps involved in setting up dedicated service ports for use as ACMS-controlled terminals. A new service is created for controlled terminal connections, and three ports dedicated to the new service are created. Terminal output from LATCP and ACMSDDU is omitted.

Note that with the exception of the ACMSDDU portion, all of these actions need to be taken each time the system is booted. As a result, it is recommended that they be included in a system startup command procedure, such as the following:

        $!
        $! Create service and ports in LATCP
        $!
        $ RUN SYS$SYSTEM:LATCP
        LCP> CREATE SERVICE /APPLICATION ACMS_CT
        LCP> CREATE PORT LTA101: /DEDICATED
        LCP> SET PORT LTA101: /DEDICATED/SERVICE=ACMS_CT
        LCP> CREATE PORT LTA102: /DEDICATED
        LCP> SET PORT LTA102: /DEDICATED/SERVICE=ACMS_CT
        LCP> CREATE PORT LTA103: /DEDICATED
        LCP> SET PORT LTA103: /DEDICATED/SERVICE=ACMS_CT
        LCP> EXIT
        $!
        $! Define terminal device type
        $!
        $ SET TERM LTA101: /DEV=VT300/PERM
        $ SET TERM LTA102: /DEV=VT300/PERM
        $ SET TERM LTA103: /DEV=VT300/PERM
        $!
        $! Authorize terminals in ACMSDDU
        $!
        $ RUN SYS$SYSTEM:ACMSDDU
        DDU>ADD LTA101: /CONTROLLED
        DDU>ADD LTA102: /CONTROLLED
        DDU>ADD LTA103: /CONTROLLED
        DDU>EXIT
        $!
        $! Terminals LTA101:, LTA102: and LTA103: are now ready for use
        $!

The following is an example of what the user sees when using a dedicated service port as an ACMS-controlled terminal.

If the terminal is not logged in to the terminal server, the user should press `[Return]` twice. A display similar to this will appear:

    DECserver 200 Terminal Server V3.0 (BL31) - LAT V5.1
    Please type HELP if you need assistance
    Enter username>

At the username prompt, the user should enter a string (this is not subject to any verification) and press `[Return]`.

If the autoconnect attribute has been enabled for the user's port, the terminal server will immediately attempt to connect to any preferred service that may have been defined; otherwise, the user must connect to the appropriate service (in this example, we assume that the service name for ACMS sign-ins is ACMS_CT).

If ACMS_CT is the preferred service, the following will suffice:

    Local> CONNECT

If ACMS_CT is not the preferred service, the user must enter:

    Local> CONNECT ACMS_CT

The connection will be established or fail, accompanied by the messages detailed earlier.

Between the time the LAT connection is established and when the user signs out of ACMS, there is no visible difference between the types of LAT terminals. In both cases, the user presses any typing key in order to begin signing in to ACMS. A prompt for user name and password may or may not follow, depending on how the user's account and ACMS authorization are defined.

When the user signs out of ACMS, control will be returned to the terminal server's "Local>" prompt.

# 2.13 Enabling Automatic User Sign-ins

Use the /AUTOLOGIN qualifier with the ADD, COPY, DEFAULT, MODIFY or RENAME commands to allow users of ACMS-controlled terminals to sign in directly to ACMS without typing a user name. When a user presses `[Return]` on an ACMS-controlled terminal with Autologin enabled, ACMS retrieves the user name for that terminal from the device authorization file. If no password is required, the user is signed in automatically.

The /AUTOLOGIN qualifier enables automatic sign-ins for controlled terminals only. If a terminal has the Not Controlled sign-in characteristic, the Autologin characteristic has no effect; users must use the ACMS/ENTER command for access to ACMS from DCL as usual.

You can disable automatic sign-ins by using the /NOAUTOLOGIN qualifier. The /NOAUTOLOGIN qualifier is the default.

# 2.14 Summary of DDU Commands and Qualifiers

DDU commands allow you to display, create, modify, and remove device definitions stored in the DDU device authorization file. Table 2-3 lists the DDU commands and qualifiers and provides a brief description of each command. For more detailed information on a DDU command, see Chapter 17.

Table 2-3 Summary of DDU Commands
Commands and Qualifiers | Description
--- | ---
ADD /[NO]AUTOLOGIN=username /[NO]CONTROLLED /PRINTFILE[=print-file-spec/spooled-device-name] | Authorizes and assigns sign-in characteristics to ACMS terminals by adding DDU definitions to the device authorization file. If you omit qualifiers, the new definition takes information from the DDU default definition.
COPY /[NO]AUTOLOGIN=username /[NO]CONTROLLED /PRINTFILE[=print-file-spec/spooled-device-name] | Authorizes and assigns sign-in characteristics to ACMS terminals by copying information from an existing DDU definition.
DEFAULT /[NO]AUTOLOGIN=username /[NO]CONTROLLED /PRINTFILE[=print-file-spec/spooled-device-name] | Changes information in the DEFAULT definition. If you omit qualifiers from the ADD command, the new definition takes information from the existing DDU default definition.
EXIT | Ends the DDU session and returns you to the DCL prompt.
HELP /[NO]PROMPT | Displays information about DDU commands, qualifiers, and parameters.
LIST /BRIEF /OUTPUT[=file-spec] | Writes DDU definitions to ACMSDDU.LIS in your default directory, or to the output file you specify.
MODIFY /[NO]AUTOLOGIN=username /[NO]CONTROLLED /PRINTFILE[=print-file-spec/spooled-device-name] | Changes information in DDU definitions.
REMOVE | Removes DDU definitions from the device authorization file.
RENAME /[NO]AUTOLOGIN=username /[NO]CONTROLLED /PRINTFILE[=print-file-spec/spooled-device-name] | Changes the device name and, optionally, the sign-in characteristic information in DDU definitions.
SHOW /BRIEF | Displays DDU definitions at your terminal.

# Chapter 3
Authorizing Users

This chapter describes how to use the ACMS User Definition Utility (UDU) to create or change user definitions that UDU stores in the user authorization file (ACMSUDF.DAT). Section 3.6 provides a summary of UDU commands and qualifiers. For reference information on the commands described in this chapter, refer to Chapter 18.

# 3.1 How UDU Works

Use UDU commands and qualifiers to create a database user authorization file (ACMSUDF.DAT) that contains records of individual user information. Using UDU is similar to using the OpenVMS Authorize Utility. With UDU, you define the characteristics under which a user signs in to ACMS. These characteristics include:

- The name of the user
- Whether or not a user name can submit tasks to ACMS for other users
- Whether or not the user runs an initial task when signing in
- What the terminal screen displays upon sign-in: either a menu and a selection prompt, or just a selection prompt
- Which menu ACMS should display if the initial sign-in screen displays a menu
- Whether or not the user runs a final task when signing out

When a user tries to sign in to ACMS, ACMS checks the user authorization file for a definition with that user name. If the authorization file does not contain a definition for that user name, ACMS checks for a $ALL definition to see if all OpenVMS user names are authorized for ACMS access. If there is no $ALL definition, ACMS denies access to the user.

# 3.2 How to Run UDU

Before using UDU to authorize ACMS users, you must authorize users to log in to the OpenVMS operating system. ACMS users must first be authorized OpenVMS users because their OpenVMS user names and passwords are verified against the OpenVMS SYSUAF.DAT file. See the OpenVMS documentation on the Authorize Utility for information about authorizing OpenVMS users.

When you run UDU to authorize users, UDU creates the user authorization file in your current default directory. By default, at run time ACMS looks in SYS$SYSTEM to find the user 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 location by defining an EXEC mode system logical name, called ACMSUDF, to point to that directory.

For example:

    $ DEFINE/SYSTEM/EXEC ACMSUDF DEVDISK:ACMSUDF.DAT

Run UDU by entering either of the following commands:

    $ RUN SYS$SYSTEM:ACMSUDU
    UDU>

or

    $ MCR ACMSUDU
    UDU>

When you see the UDU prompt (UDU>), you can begin entering UDU commands. If you enter a UDU command and want to include several qualifiers, you can include all the qualifiers on one line, for example:

    ADD user-name /MDB=ACMS.MDB /MENU=EMPLOYEE /AGENT

The same command can be entered on several lines if you use the hyphen (--) to indicate a continuation line. For example:

    UDU> ADD user-name -
    _UDU> /MDB=ACMS.MDB /MENU=EMPLOYEE /AGENT

You can recall each UDU command you enter by pressing `[Ctrl/B]`. UDU also supplies a keypad of UDU commands. Press `[PF1]` and `[PF2]` to see the keypad display. Type EXIT or press `[Ctrl/Z]` to exit from UDU.

Chapter 18 contains information about each UDU command and its qualifiers. You can also get information by using the UDU HELP command followed by the command name:

    UDU> HELP ADD

General information about UDU is available at the DCL prompt by typing:

    $ HELP @ACMSUDU

# 3.3 Running UDU the First Time

ACMS creates a default definition the first time you run UDU, or when you create a new user authorization file. At run time, ACMS assigns the top-level menu and selection prompt, the menu database file specification ACMS$DIRECTORY:ACMS.MDB, and a blank menu path name to the DEFAULT definition.

When you use the ADD command to create a new UDU definition, the new definition takes the default information defined in the DEFAULT definition. You can use qualifiers with the ADD command to override information from the DEFAULT definition.

Before authorizing multiple new users, it might be convenient to change the initial values in the DEFAULT definition. For example, if you plan to authorize 10 users, all of whom use the menu database PERS_MENU.MDB, you can change the name of the menu database using the UDU DEFAULT or MODIFY command. For example:

    UDU> DEFAULT /MDB=PERS_MENU
    UDU> ADD $ALL

When you authorize the 10 users with the ADD command, you do not need to use the /MDB qualifier because the ADD command uses the default value from the UDU DEFAULT definition.

When you specify a menu database with the /MDB qualifier, ACMS assumes the default menu database is in the directory that the logical ACMS$DIRECTORY points to. However, if the database is in another location, you must include in the DEFAULT command the device and directory name where the file is stored. For example:

    UDU> MODIFY DEFAULT /MDB=DISKNAME:[GORDON]ACMS.MDB

If you do not specify a file type, UDU assumes the .MDB file type by default.

# 3.4 Authorizing New Users

The following sections show several different approaches to take when authorizing users. For example, if you have few users to authorize, you may want to write individual authorizations for each user. If you have many users to authorize, you may want to take advantage of the DEFAULT authorization and the $ALL user name.

The next six sections describe the UDU commands you use to authorize new ACMS users and give examples of how to use these commands.

## 3.4.1 Authorizing Users with ADD, COPY, DEFAULT, and $ALL

Use the ADD or COPY commands to create definitions that authorize ACMS users. Using the ADD command, you create a new definition by either allowing the user information to come from the UDU DEFAULT definition, or typing in the necessary qualifier information yourself. This example adds the user name RICHARDS to ACMSUDU.DAT, taking all information from the UDU DEFAULT definition except the menu database file:

    UDU> ADD RICHARDS /MDB=DISK02:[USERMENUS]ADDTASKS

When a definition already exists with characteristics similar to one you want to create, you can use the COPY command to create a new definition based on information from the existing UDU definition. This example copies information from the RICHARDS user definition to create the new GORDON definition:

    UDU> COPY RICHARDS GORDON

You can quickly create authorizations for all OpenVMS users by specifying $ALL as the user name with the ADD or COPY command. A $ALL definition authorizes all users at once, assigning them the same sign-in display, default menu, and menu database file.

If the user authorization file does not contain a $ALL definition, each ACMS user must have a separate user definition. With separate user definitions, you can restrict some OpenVMS users from signing in to ACMS.

Depending on how many users you are authorizing and the characteristics you want to assign them, you might want to use a $ALL definition to provide generic definitions for all users. Then, you can create separate definitions for those users who need characteristics that most other users do not, such as the agent qualifier.

You must create at least two user definitions: one to authorize the ACMS user (or a $ALL definition to authorize all OpenVMS users), and one to authorize the user name of the ACMS Command Process (see Section 3.4.6 for information on authorizing the Command Process).

## 3.4.2 Defining User Initial and Final Tasks

As system manager, you can specify that a user runs a specific task when signing in to ACMS and that the user runs a specific task when signing out of ACMS. For example, you can specify that whenever a user signs in, a task asks for the user's name and telephone number. Or, if a user only runs one particular task all the time, you can specify that that task runs whenever the user signs in without having to select that task from a menu. When the user signs out, you can specify that an accounting task runs to log the user's work for the day --- sign in and sign out time, number of files created, amount of disk space used, and so forth.

To specify an initial or final task for a user, use the /INITIAL or /FINAL qualifier with the UDU ADD, COPY, MODIFY, DEFAULT, or RENAME commands. The /INITIAL qualifier specifies the name of a task the user runs when signing in. The /FINAL qualifier specifies the name of a task the user runs when signing out.

The following command specifies that a user runs the task BOOKING_INFO in the application RESERVATIONS whenever signing in to ACMS:

    UDU> ADD FORRESTER/INITIAL=(APPLICATION=RESERVATIONS,TASK -
    _UDU> =BOOKING_INFO)

This command specifies that a user runs the task ACCOUNTING in the application CLERK_REC whenever signing out of ACMS:

    UDU> ADD KNUTH/FINAL=(APPLICATION=CLERK_REC,TASK=ACCOUNTING)

You can use keywords to the /INITIAL and /FINAL qualifiers to specify how errors are handled if an error occurs in an initial or final task. By default, if the specified initial task fails, UDU displays an error message describing the reason for the failure, records the task's status in the Audit Trail Log, and signs the user out of ACMS. The final task (if one is specified) does not execute. You can specify that ACMS ignore errors in an initial task by specifying the IGNORE_ERROR keyword with the /INITIAL qualifier. When an error occurs in the initial task, the user remains signed in. For example:

    UDU> ADD EINSTEIN/INITIAL=(APPLICATION=RESOURCES,TASK=ACCT, -
    _UDU> IGNORE_ERROR)

If an error occurs in a final task, ACMS displays the error message "Final task failed" and records the reason for the error in the Audit Trail Log. You can use the IGNORE_ERROR keyword with the /FINAL qualifier to specify that ACMS ignore an error in the final task. For example:

    UDU> ADD PLATO/FINAL=(APPLICATION=REC_APPL,TASK=UPDATE,IGNORE_ERROR)

When you use the IGNORE_ERROR keyword for a final task, ACMS does not issue an error message or record the error in the Audit Trail Log when an error occurs.

Specify a parameter (such as a file name) with an initial or final task, by using the SELECTION_STRING keyword. The following command specifies that a user run the final task SHOW_TRANSACTIONS whenever signing out of ACMS. SHOW_TRANSACTIONS displays a file containing a record of the day's events. TRANSACTION_OUTPUT.DAT is the log file displayed:

    UDU> ADD TOLSTOY/FINAL=(APPLICATION=ACCOUNTING,TASK= -
    _UDU> SHOW_TRANSACTIONS, SELECTION_STRING="TRANSACTION_OUTPUT.DAT")

You can display the initial and final tasks defined for a user by using the SHOW command. For example:

    UDU> SHOW TOLSTOY
    User Name:        TOLSTOY          DISPLAY MENU
    Default Menu:
    Default MDB:      INVENTORY
    Initial Task:                       IGNORE ERROR
      Application:    RESOURCE
      Task:           ACCT
      Selection:
    Final Task:                         IGNORE ERROR
      Application:    ACCOUNTING
      Task:           SHOW_TRANSACTIONS
      Selection:      TRANSACTION_OUTPUT.DAT
    Language:
    Printfile:

ACMS has a special menu called ACMS$EXIT to use when no menu processing should be performed for a user. For example, if users have an initial task established that performs menu control for those users, you can assign the ACMS$EXIT menu to those users to perform an exit from ACMS whenever they exit from the initial task. For example:

    UDU> MODIFY LAO/MDB=ACMS /MENU=ACMS$EXIT/INITIAL= -
    _UDU> (APPLICATION=RESERVATIONS,TASK=RESERVE_MENU)

This example defines an initial task for user LAO that serves as a menu control task. When this task exits, user LAO does not have a menu displayed at the terminal. Instead, the user is signed out of the ACMS system.

The TDMS request for the ACMS$EXIT menu returns "Exit" as if it were typed by the user at the selection prompt, but does this without terminal interaction.

Previous | Next | Contents | Index