HP OpenVMS Systems Documentation

This example declares a workspace that can be used by the tasks in the DEPARTMENT task group. The given name of the workspace is DEPT_WORKSPACE. The default workspace type is TASK.

WORKSPACE IS DEPT_WORKSPACE WITH TYPE GROUP ACCESS UPDATE LOCK;
      

This example also declares a workspace that can be used by the tasks in the DEPARTMENT task group. However, in this example, CDD$DEFAULT is set to DISK1:[CDDPLUS]ACMS$DIR.ACMS$EXAMPLES_RMS. Therefore, you use only the given name of the workspace in the WORKSPACES clause.

Because DEPT_WORKSPACE is a group workspace, all the tasks in the group can use the contents of the workspace and can lock the workspace from use by other tasks. In addition, each task can update the contents of the workspace.

An application definition consists of a set of clauses that define control attributes for tasks, servers, and the application execution controller that manages the server processes in which tasks run.

Two application definition clauses are required. The TASK GROUPS clause names the task group or groups that define the tasks of an application. The APPLICATION USERNAME clause defines the user name with which the execution controller runs. The other clauses in the application definition are optional.

Four application definition clauses use two sets of keywords, one set beginning the clause and the other set ending it. These four clauses are: SERVER ATTRIBUTES, SERVER DEFAULTS, TASK ATTRIBUTES, and TASK DEFAULTS. Between the keywords, you put subclauses that define the control characteristics of servers or tasks:

SERVER  ATTRIBUTES ARE
  <server-subclauses>
END SERVER  ATTRIBUTES;

When ADU begins processing an application definition, it assigns default values to all characteristics of tasks and servers. You can change these default values by assigning different task characteristics to the tasks of an application with the TASK ATTRIBUTES or TASK DEFAULTS clause, and by assigning different server characteristics to the servers of an application with the SERVER ATTRIBUTES or SERVER DEFAULTS clause. Figure 5-1 shows the full syntax of the application definition.

Figure 5-1 Application Definition Syntax

Example 5-1 shows an example of a complete application definition.

USERNAME IS PERSONNEL;

SERVER DEFAULTS ARE
  DEFAULT DIRECTORY IS SYS$SAMPLE;
  MAXIMUM SERVER PROCESSES IS 10;
  MINIMUM SERVER PROCESSES IS 1;
END SERVER DEFAULTS;

TASK DEFAULTS ARE
  ACCESS CONTROL IS (ID=ACCOUNTING, ACCESS=NONE);
END TASK DEFAULTS;

TASK GROUP IS
  PERSONNEL_GROUP : TASK GROUP FILE IS "SYS$SAMPLE:PERSONNEL.TDB";
END TASK GROUP;

TASK ATTRIBUTES ARE
  ADD_EMPLOYEE  : TASK ADD_EMPLOYEE IN PERSONNEL_GROUP;
                  ACCESS IS (ID=PERSONNEL, ACCESS=EXECUTE);
  DATR          : TASK DATR IN PERSONNEL_GROUP;
                  ACCESS IS (ID=PERSONNEL, ACCESS=EXECUTE);
END TASK ATTRIBUTES;

SERVER DEFAULTS ARE
  MINIMUM SERVER PROCESSES IS 2;
END SERVER DEFAULTS;

SERVER ATTRIBUTES ARE
  PERSONNEL_SERVER : SERVER PERSONNEL_SERVER IN PERSONNEL_GROUP;
                     USERNAME IS PERSONNEL;
                     DYNAMIC USERNAME;
  UTILITY_SERVER   : SERVER UTILITY_SERVER IN PERSONNEL_GROUP;
                     DYNAMIC USERNAME;
                     USERNAME IS DEPART;
END SERVER ATTRIBUTES;

END DEFINITION;

Table 5-1 describes the application clauses you use to write application definitions.

The SERVER ATTRIBUTES and SERVER DEFAULTS clauses use the same subordinate clauses to define one or more application servers. The SERVER ATTRIBUTES clause defines the processing characteristics of a single server, while SERVER DEFAULTS can affect a group of servers. Table 5-2 contains a brief description of these subclauses.

Figure 5-2 shows the syntax for the SERVER ATTRIBUTES clause.

Figure 5-2 SERVER ATTRIBUTES Clause Syntax

Figure 5-3 shows the syntax for the SERVER DEFAULTS clause.

Figure 5-3 SERVER DEFAULTS Clause Syntax

Example 5-2 shows an example of how to use the SERVER ATTRIBUTES and SERVER DEFAULTS clauses.

USERNAME IS DEPART;
SERVER DEFAULTS ARE
  DEFAULT DIRECTORY IS SYS$SAMPLE;
  MAXIMUM SERVER PROCESSES IS 10;
  MINIMUM SERVER PROCESSES IS 1;
END SERVER DEFAULTS;
TASK GROUP IS
  PERSONNEL_GROUP : TASK GROUP FILE IS "SYS$SAMPLE:PERSONNEL.TDB";
END TASK GROUP;
SERVER ATTRIBUTES ARE
  PERSONNEL_SERVER : SERVER PERSONNEL_SERVER;
                     USERNAME IS PERSONNEL;
  UTILITY_SERVER   : SERVER UTILITY_SERVER;
                     DYNAMIC USERNAME;
END SERVER ATTRIBUTES;
END DEFINITION;

Table 5-3 contains brief descriptions of the subclauses you use to define TASK ATTRIBUTES and TASK DEFAULTS clauses.

Figure 5-4 shows the syntax for the TASK ATTRIBUTES clause.

Figure 5-4 TASK ATTRIBUTES Clause Syntax

Figure 5-5 shows the syntax for the TASK DEFAULTS clause.

Figure 5-5 TASK DEFAULTS Clause Syntax

Example 5-3 shows an example of using the TASK DEFAULTS and TASK ATTRIBUTES clauses.

TASK DEFAULT IS
  ACCESS CONTROL IS (ID=[INVENTORY,*], ACCESS=EXECUTE);
END TASK DEFAULT;
TASK GROUP IS
  WORK_GROUP : TASK GROUP FILE IS "SYS$SAMPLE:WORK.TDB";
END TASK GROUP;
TASK ATTRIBUTES ARE
  UPDATE_INVENTORY : TASK UPDATE_INVENTORY IN WORK_GROUP;
      AUDIT;
  DATR             : TASK DATR IN WORK_GROUP;
      ACCESS CONTROL IS (ID=[INVENTORY,SMITH], ACCESS=EXECUTE);
END TASK ATTRIBUTES;

Defines who can and who cannot select a task.

Format

Keywords

EXECUTE

Lets users select and run a task.

NONE

Prevents users from selecting and running a task.

Parameter

acl-identifier

A legal OpenVMS User Identification Code (UIC) or OpenVMS identifier.

You can use the following:

• Alphanumeric UIC identifiers, numeric UICs, general identifiers, and system identifiers, or a combination of any of these.
• Wildcards for both group and member elements of a numeric or alphanumeric UIC. You can also enclose a UIC identifier in square ([ ]) or angle (< >) brackets.
• General and system identifiers set up by your system manager. Do not enclose general and system identifiers in brackets.

Clause Default

The ACMS-supplied default is ACCESS CONTROL IS (ID=[*,*], ACCESS=EXECUTE), which means any user who can log in to ACMS can run tasks. This subclause is optional.

Notes

The ACCESS subclause creates an ordered list of one or more identifier entries. Each identifier entry is called an access control list entry (ACE), and the list of all entries is called an access control list (ACL). You can specify multiple ACEs in a single ACCESS subclause, and you can specify multiple ACCESS subclauses.

ACMS uses ACEs and ACLs the way the OpenVMS operating system uses them. See OpenVMS DCL Dictionary for further information on identifiers, ACEs, and ACLs.

ACMS searches an ACL from the first to the last ACE and stops searching at the first match between an identifier on the list and an identifier on a process's rights list. A process's rights list includes a UIC, system-defined identifiers, and any general identifiers assigned to that user by the system manager.

You can use the DCL command SET RIGHTS_LIST to dynamically modify a process or system rights list. This means that you can dynamically allow and deny access to tasks, without making users log out and log back in. See OpenVMS DCL Dictionary for further information on the SET RIGHTS_LIST command.

User rights lists are maintained in the rights database using the Authorize Utility. See Guide to Setting Up a VMS System for further information on the rights database and the Authorize Utility. The rights database is an optional feature of the OpenVMS operating system designed to increase the scope and flexibility of operating system object security.

Multiple ACCESS clauses in a TASK ATTRIBUTES task entry or in a TASK DEFAULTS clause are matched in the order that they appear. If ACMS does not find a match before it reaches the end of an access control list, it denies access to the task.

If one task chains to another, ACMS does not check the access control list for the second task before starting the second task.

Examples

ACCESS CONTROL IS (ID=[PERSONNEL,JONES], ACCESS=EXECUTE);
      

A user with UIC [PERSONNEL,JONES] can access this task or set of tasks.

ACCESS CONTROL IS (ID=[PERSONNEL,*], ACCESS=EXECUTE);
      

Any users in group PERSONNEL have access to this task or set of tasks.

ACCESS ID [300,*] ACCESS NONE;
      

No users in group 300 can access this task or group of tasks.

ACCESS CONTROL IS (ID=ACCOUNTING, ACCESS=EXECUTE);
      

Users who have the general identifier ACCOUNTING on their rights lists can access this task or group of tasks.

ACCESS CONTROL IS (ID=[300,*]+ACCOUNTING, ACCESS=EXECUTE);
      

Users who have the general identifier ACCOUNTING on their rights lists and who belong to group 300 can access this task or group of tasks.

ACCESS CONTROL IS ( (ID=[350,11],          ACCESS=NONE),
                    (ID=ACCOUNTING,        ACCESS=EXECUTE),
                    (ID=[PERSONNEL,JONES], ACCESS=EXECUTE),
                    (ID=[PERSONNEL,*],     ACCESS=NONE)     );

      

This example specifies that:

• Any user with a UIC of [350,11] cannot access the task.
• All users who hold the ACCOUNTING general identifier can access the task.
• Any user with a UIC of [PERSONNEL,JONES] can access the task, but all other users in the PERSONNEL group cannot access the task.

Assigns a default device and directory for the process in which an application execution controller runs.

Format

Keyword

USERNAME DEFAULT DIRECTORY

Assigns to an application execution controller the default directory of the user name under which the application runs. ACMS derives the default directory for the execution controller from the SYSUAF entry of the application user name.

Parameter

default-directory

The disk and directory you want ACMS to use as the default for the execution controller. Include an OpenVMS file specification or assign a logical name. If you use a file specification or a logical name longer than 31 characters, enclose it in quotation marks (" ").

Clause Default

The clause APPLICATION DEFAULT DIRECTORY IS USERNAME DEFAULT DIRECTORY is the default. When the default is in effect, ACMS assigns to the application execution controller the default directory it finds in the SYSUAF entry for the application user name. This clause is optional.

Notes

If you are using a logical name, ACMS checks and translates the logical name only when the application is run, not when you are creating the definition or building the application.

Use the DCL DEFINE or DCL ASSIGN command, or the APPLICATION LOGICALS clause to create any logical names that you assign with the APPLICATION DEFAULT DIRECTORY clause. If you use DEFINE or ASSIGN, the logical names must be either system logicals or group logicals in the same group as the application execution controller. You can also use the APPLICATION LOGICALS clause, in which case they are process logicals.

The APPLICATION DEFAULT DIRECTORY clause applies to the default directory of the application execution controller. The application execution controller uses this default directory if device and directory are not named for these files: task group database files (.TDB) named in the application definition, request libraries (.RLB), DECforms form files (.FORM and.EXE), and message files (.EXE) named in the task group definitions for that application.

Examples

DEFAULT DIRECTORY IS SYS$SAMPLE;
USERNAME IS PERSONNEL;
TASK GROUP IS
  PERSONNEL_GROUP : TASK GROUP IS "SYS$SAMPLE:PERSONNEL.TDB";
END TASK GROUP;
END DEFINITION;
      

This application definition uses the logical name SYS$SAMPLE for the default device and directory that ACMS uses for the application execution controller process. When you use a logical name such as SYS$SAMPLE, be sure to use the DCL ASSIGN or DCL DEFINE command to define the logical name. Also, make sure you set up a system or group logical name.

DEFAULT DIRECTORY IS "DBA2:[ACMS.EMPLOYEE]";
USERNAME IS EMPLOYEE;
TASK GROUP IS
  EMPLOYEE_GROUP : TASK GROUP IS "SYS$SAMPLE:EMPLOYEE.TDB";
END TASK GROUP;
END DEFINITION;
      

In this example, the DEFAULT DIRECTORY clause assigns the physical device DBA2 and the directory ACMS.EMPLOYEE to the application execution controller process.