| Previous | Contents | Index |
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.
| 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. |
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:
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 |
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 |