Depending on the position of TASK ATTRIBUTES clauses in the application definition, you may not need to explicitly name the task or task group to which you assign a control characteristic. ACMS provides some defaulting of task and task group names in the application definition.

The following TASK ATTRIBUTE clause includes both the task and the task group name of the task to which the AUDIT subclause applies:

TASK ATTRIBUTE IS DATR : TASK DATR IN ADMINISTRATION_COBOL_TASK_GROUP; AUDIT; END TASK ATTRIBUTE;

In the preceding TASK ATTRIBUTE clause, there are two phrases: the task name and the task group name. In some cases, you can omit one of these phrases. If the task has the same name in the application as it has in the task group, you do not have to use the task name phrase. For example:

TASK DEFAULT IS ACCESS CONTROL LIST IDENTIFIER [100,*] ACCESS EXECUTE; END TASK DEFAULT; TASK ATTRIBUTES ARE DATR : IN ADMINISTRATION_COBOL_TASK_GROUP; EDIT : IN ADMINISTRATION_COBOL_TASK_GROUP; END TASK ATTRIBUTES;

If the task group is the same as the last one named in the immediately preceding TASK GROUPS clause, you do not have to use the task group phrase. For example:

TASK GROUP IS ADMINISTRATION_COBOL_TASK_GROUP : TASK GROUP FILE IS "ACMS$EXAMPLES:ADMRMSCOB.TDB"; END TASK GROUP; TASK ATTRIBUTE IS DATR : AUDIT; END TASK ATTRIBUTE;

If you do not specify a task group name in a TASK ATTRIBUTES clause, ACMS defaults the task group name from the last task group name in the immediately preceding TASK GROUPS clause. If you name the task group in the TASK ATTRIBUTES clause, then the TASK ATTRIBUTES clause does not have to follow the TASK GROUPS clause to which you want it to apply.

Task attribute and default values affect tasks in a task group depending on the position of the clauses in relation to each other in an application definition. The next section discusses the positioning of the TASK ATTRIBUTES and TASK DEFAULTS clauses in an application definition.

11.3.4.4 Positioning TASK ATTRIBUTES and TASK DEFAULTS Clauses

The way you place TASK ATTRIBUTES and TASK DEFAULTS clauses in an application definition affects how ACMS assigns control characteristics to the tasks in the application.

For example, Example 11-3 shows an application definition that uses multiple TASK DEFAULTS clauses to define different task control characteristics for the tasks in two task groups.

Example 11-3 Application Definition Using Multiple TASK DEFAULTS

REPLACE APPLICATION PERSONNEL_APPLICATION USERNAME IS PERSONNEL; TASK DEFAULTS ARE ACCESS CONTROL LIST IDENTIFIER [100,*] ACCESS EXECUTE, IDENTIFIER [200,*] ACCESS EXECUTE; AUDIT; END TASK DEFAULTS; TASK GROUP IS DEPARTMENT_COBOL_TASK_GROUP : TASK GROUP FILE IS "ACMS$EXAMPLES:DEPRMSCOB.TDB"; END TASK GROUP; TASK DEFAULTS ARE ACCESS CONTROL LIST IDENTIFIER [200,*] ACCESS EXECUTE; END TASK DEFAULTS; TASK GROUP IS ADMINISTRATION_COBOL_TASK_GROUP : TASK GROUP FILE IS "ACMS$EXAMPLES:ADMRMSCOB.TDB"; END TASK GROUP; END DEFINITION;

This first TASK DEFAULTS clause defines a default ACL. ADU assigns this ACL to all the tasks in the Department group. The second TASK DEFAULTS clause changes that default ACL. ADU assigns the second ACL to all the tasks in the Administration group. So, the only users who can run the tasks in the Administration task group are those who have a group UIC of 200.

The application definition also assigns AUDIT to all the tasks in the application. AUDIT applies to both task groups because the first TASK DEFAULTS clause used the AUDIT subclause and the second TASK DEFAULTS clause did not use the NOAUDIT subclause.

Defaults set in a TASK DEFAULTS clause remain in effect unless changed by a later TASK DEFAULTS clause. Any control attributes not named in a TASK DEFAULTS clause retain their ACMS-supplied defaults. You can also override a default value by assigning a control attribute in the task group definition of a task or by using the TASK ATTRIBUTES clause.

Example 11-4 shows an application definition that includes one task group and uses TASK ATTRIBUTES and TASK DEFAULTS clauses to define the control attributes of the tasks in the application.

Example 11-4 Application Using TASK ATTRIBUTES and TASK DEFAULTS

REPLACE APPLICATION PERSONNEL_APPLICATION USERNAME IS PERSONNEL; TASK DEFAULTS ARE ACCESS CONTROL LIST IDENTIFIER [100,*] ACCESS EXECUTE, IDENTIFIER [200,*] ACCESS EXECUTE; AUDIT; END TASK DEFAULTS; TASK GROUP IS ADMINISTRATION_COBOL_TASK_GROUP : TASK GROUP FILE IS "ACMS$EXAMPLES:ADMRMSCOB.TDB"; END TASK GROUP; TASK DEFAULTS ARE ACCESS CONTROL LIST IDENTIFIER [200,*] ACCESS EXECUTE; END TASK DEFAULTS; TASK ATTRIBUTES ARE DATR : IN ADMINISTRATION_COBOL_TASK_GROUP; EDIT : IN ADMINISTRATION_COBOL_TASK_GROUP; END TASK ATTRIBUTES; END DEFINITION;

In Example 11-4, all the tasks in the application take the ACMS default values for all attributes except ACCESS and AUDIT. The definition assigns ACLs for the DATR and EDIT tasks; only users with a group UIC of 100 or 200 can run these tasks. For the other tasks in the application, the definition assigns an ACL that allows all users with group UIC of 100 or 200 to run the tasks. The application also assigns AUDIT to all tasks with the AUDIT clause in the first TASK DEFAULTS clause.

When you write an application definition, use the order of TASK DEFAULTS, TASK GROUP, and TASK ATTRIBUTES clauses that lets you take maximum advantage of defaulting. Your goal is to make the application definition as simple and easy to understand as possible so that the control characteristics for your application are clear to anyone who works with the application definition.

11.3.5 Enabling and Disabling Tasks in the Application Definition

Section 11.6 describes how to enable or disable tasks on a temporary basis with the ACMS/MODIFY APPLICATION command. By using the DISABLED/ENABLED attribute in the application definition, you can specify on a permanent basis whether or not the task is available for selection by task submitters.

Example 11-5 shows this attribute in a definition.

Example 11-5 Enabling and Disabling Tasks in the Application Definition

REPLACE APPLICATION TEST_APPL USERNAME IS TPSS; TASK DEFAULTS ARE DISABLE; END TASK DEFAULTS; TASK GROUPS ARE CDUTEST_GROUP1: TASK GROUP FILE IS "CDU$:CDUTEST_GROUP1.TDB"; END TASK GROUPS; SERVER ATTRIBUTES ARE RDBLSRV1: MINIMUM SERVER PROCESSES IS 1; SERVER RDBLSRV1 IN CDUTEST_GROUP1; AUDIT; END SERVER ATTRIBUTES; TASK ATTRIBUTES ARE RDB_SINGLE_TASK; ENABLE; TASK RDB_SINGLE_TASK IN CDUTEST_GROUP1; END TASK ATTRIBUTES; END DEFINITION;

In this example, all tasks are initially disabled by default in the TASK DEFAULTS ARE clause. The RDB_SINGLE_TASK is subsequently enabled in the TASK ATTRIBUTES ARE clause. The other tasks in the task group CDU_TEST_GROUP1 remain disabled.

11.3.6 Controlling Transaction Timeouts in the Application Definition

If your application contains tasks that use distributed transactions, you might need to concern yourself with possible deadlock problems. One type of deadlock involves multiple tasks attempting to access the same server process. For example, suppose two tasks each use two servers. Each server has one active server process. The first task accesses the first server, and the second task accesses the second server. If both tasks then attempt to access the other server, they will become deadlocked waiting to use the server process being used by the other task.

If your application and databases are distributed across multiple systems that are not part of a single OpenVMS Cluster system, deadlocks can occur when multiple tasks attempt to access the same database record. The OpenVMS Lock Manager is able to detect deadlocks only within a single system or an OpenVMS Cluster system.

By specifying the TRANSACTION TIMEOUT subclause in the application definition, you can instruct ACMS to abort a transaction if it has not completed within a certain number of seconds. Example 11-6 shows this attribute in a definition.

Example 11-6 Using TRANSACTION TIMEOUT in the Application Definition

REPLACE APPLICATION AVERTZ_CDD_APPL:VR_APPL USERNAME IS AVERTZ_EXC; AUDIT; TASK DEFAULTS ARE AUDIT; TRANSACTION TIMEOUT IS 1200; END TASK DEFAULTS; SERVER CONTROL ATTRIBUTES ARE VR_READ_SERVER: SERVER VR_READ_SERVER IN VR_TASK_GROUP; AUDIT; MAXIMUM SERVER PROCESSES IS 3; MINIMUM SERVER PROCESSES IS 1; VR_UPDATE_SERVER: SERVER VR_UPDATE_SERVER IN VR_TASK_GROUP; AUDIT; MAXIMUM SERVER PROCESSES IS 1; MINIMUM SERVER PROCESSES IS 1; END SERVER ATTRIBUTES; TASK GROUP IS VR_TASK_GROUP: TASK GROUP FILE IS "AVERTZ_DEFAULT:VR_TASK_GROUP.TDB"; END TASK GROUP; END DEFINITION;

In this example, the TRANSACTION TIMEOUT subclause specifies that by default all transactions should be aborted if they do not complete within 20 minutes. Be sure to set the transaction time limit to a value higher than the amount of time it takes to complete your longest transaction when the system is at peak load. When a transaction aborts, ACMS cancels the task. For information on how to define a task definition so that the task can recover from a transaction timeout error and retry the distributed transaction, see Chapter 8.

11.4 Controlling Servers

You control servers in an application by assigning server control attributes in the application definition. These attributes determine the processing characteristics of a server, including:

• Its OpenVMS user name
• Whether the user name, UIC, and default directory of a server remain the same when the server processes tasks for different terminal users
• Maximum and minimum number of server processes the server can have
• Logical names and name tables for a server process
• Whether or not server events are audited
• Default directory for the server
• How frequently new server processes are created and deleted
• Protected workspaces
• Server process dumps

ACMS supplies default values for server control characteristics. If one or more servers in your application need control characteristics different from the defaults, you use the SERVER ATTRIBUTES and SERVER DEFAULTS clauses to override the ACMS-supplied defaults. Within these clauses, you use subclauses to describe specific server control characteristics.

11.4.1 Assigning a Server User Name

Every server has an OpenVMS user name that you assign in the application definition with the USERNAME subclause and that determines:

• How the work done by a server process is logged by the OpenVMS ACCOUNTING facility
• Privileges, priority, and quotas assigned to a server process
• Default directory assigned to a server process when the process is created

ACMS assigns the user name of the application to the server by default. However, if you use the USERNAME OF TERMINAL USER in the task group definition, ADU always assigns the server that name. Because an application requires more privileges, higher quotas, and larger working sets than a server, you should instead assign a server a user name that has only the necessary privileges, quotas, and priority for the work that server has to do. The user name must be a valid OpenVMS user name consisting of 1 to 12 alphanumeric characters, including underscores.

In many cases you want all servers handling tasks in a group to run under the same user name. For example, many of the tasks in the ACMS sample application use a server named ADMINISTRATION_SERVER. The following application definition uses the SERVER DEFAULTS clause to assign the user name PERSONNEL to this server:

SERVER DEFAULTS ARE USERNAME IS PERSONNEL; END SERVER DEFAULTS; TASK GROUP IS ADMINISTRATION_COBOL_TASK_GROUP : TASK GROUP FILE IS "ACMS$EXAMPLES:ADMRMSCOB.TDB"; END TASK GROUP;

This example uses the SERVER DEFAULTS clause and a USERNAME subclause to change the ADU default for SERVER USERNAME from USERNAME OF APPLICATION to PERSONNEL. All servers used by ADMINISTRATION_COBOL_TASK_GROUP run under the same user name. For all other attributes of servers, ADU uses the defaults in effect, which are ACMS supplied, except for the user name, which was reset in the SERVER DEFAULTS clause.

If you want a server to have the same priorities, privileges, and quotas as the Application Execution Controller, define the server to run under the same user name as the Application Execution Controller. Use the USERNAME OF APPLICATION subclause to define this type of server user name.

SERVER DEFAULTS ARE USERNAME IS USERNAME OF APPLICATION; END SERVER DEFAULTS;

If the application user name is PERSONNEL, this USERNAME subclause has the same effect as defining PERSONNEL as the user name. USERNAME OF APPLICATION is the default value for the user name.

Sometimes a task may require a server process with all the characteristics assigned to the terminal user who selected the task. For example, if a user needs to run a task under the user's own user name, the task requires a server process with all the characteristics assigned to that user. There are two ways to define this type of server for a task:

• Define a specific dynamic user name for servers. (Dynamic user names are discussed in Section 11.4.2.)
• Define a server process with all the characteristics assigned to the terminal user who selected the task, using the USERNAME OF TERMINAL USER subclause. For example:

  SERVER DEFAULTS ARE USERNAME IS USERNAME OF TERMINAL USER; END SERVER DEFAULTS; SERVER ATTRIBUTES ARE PRIVATE_UTILITY_SERVER: IN PERSONNEL_TASK_GROUP; END SERVER ATTRIBUTES;

  
  In this case, each time a task from the Personnel task group needs a server, ACMS starts a server process with all the characteristics of the terminal user's user name. When the task finishes using the server, ACMS stops the server process. The PRIVATE_UTILITY_SERVER is a DCL server.
  The USERNAME OF TERMINAL USER subclause is intended for use with DCL servers only.
  If you use the USERNAME OF TERMINAL USER subclause for a server:

  • The value of MINIMUM SERVER PROCESSES for that server must be 0
  • The server process is deleted when the task finishes using the server

Before a server can be started, the server user name must be authorized with the OpenVMS Authorize Utility. See Compaq ACMS for OpenVMS Managing Applications for information on the Authorize Utility.

11.4.2 Assigning a Dynamic or Fixed Server User Name

When a task is selected by the terminal user, you may want a server to change its OpenVMS user name to the user name of the user who selected the task if:

• The task requires access to the terminal user's files
• The task uses the terminal user's UIC to access files that are not in the default directory of the server in which the task is running

A server can change its OpenVMS user name if you assign a dynamic user name to the server with the DYNAMIC USERNAME subclause for DCL servers. Procedure servers must always have a fixed user name.

Assigning a dynamic user name to a DCL server allows each server process allocated by the server to change its user name to match the user name of the terminal user. For example:

SERVER DEFAULTS ARE DYNAMIC USERNAME; END SERVER DEFAULTS; SERVER ATTRIBUTES ARE PRIVATE_UTILITY_SERVER: IN PERSONNEL_TASK_GROUP; USERNAME IS PERSONNEL; END SERVER ATTRIBUTES;

Here you use USERNAME IS to assign an initial user name of PERSONNEL to all servers in the Personnel task group. The PRIVATE_UTILITY_SERVER is a DCL server. Each time a server is started, it has the user name, privileges, quotas, priority, and other characteristics of PERSONNEL. Because the user name is defined as dynamic, each time a server process is allocated to a task, ACMS changes the user name of the server process to match that of the user who selected the task. These changes include:

• User name set to that of the terminal user
• Default directory set to that of the terminal user
• UIC set to that of the terminal user
• SYS$LOGIN set to the user's default device and directory
• SYS$SCRATCH set to the user's default device and directory
• SYS$DISK set to the user's default device

ACMS does not change the quotas, privileges, or priority of the server process. These remain the same as they were when ACMS started the server process. If you need the server process to have the quotas, privileges, or priority of the terminal user's process, use the USERNAME OF TERMINAL USER subclause. Because a USERNAME OF TERMINAL USER subclause forces ACMS to start and stop a server process each time a task needs that server, it adds to the processing cost. A dynamic user name does not stop the server process when a task is finished using the process. Instead, the process becomes available for another task instance. Not having to start and stop a server process each time a task needs a server reduces the processing cost.

By default, server user names are fixed. If the server user name is fixed, the UIC, user name, default directory and other characteristics of the server remain the same as they were when the server process was started.

For more information about how different types of user names affect the performance of your ACMS system, see Compaq ACMS for OpenVMS Managing Applications.

11.4.3 Assigning Server Default Directories

ACMS assigns every server process a default device and directory. The values come from the device and directory assigned to the user name of each server.

Assigning the default directory for a server is necessary when you need a different default directory from the one assigned to the server's user name in the SYSUAF file. For example, you need to define server default directories when two servers need most of the same characteristics, but the servers access different databases in different directories. You also need to assign a default directory if files needed by the server, like data files or the procedure server image for a procedure server, are identified only by file name rather than by complete file specification.

You can name a default device and directory with the DEFAULT DIRECTORY subclause. For example:

SERVER DEFAULTS ARE USERNAME IS PERSONNEL; DEFAULT DIRECTORY IS ACMS$EXAMPLES; END SERVER DEFAULTS; TASK GROUP IS ADMINISTRATION_COBOL_TASK_GROUP : TASK GROUP FILE IS "ACMS$EXAMPLES:ADMRMSCOB.TDB"; END TASK GROUP;

This definition assigns the device and directory pointed to by the logical name ACMS$EXAMPLES as the default directory for the servers in the Administration task group. You can name a directory specification and device name rather than a logical name, but using logical names lets you change directory locations without redefining and rebuilding the application.

By default, ACMS assigns USERNAME DEFAULT DIRECTORY for the DEFAULT DIRECTORY clause. When the default is in effect, ACMS assigns the server process the default directory that is in the SYSUAF entry for the server user name.

11.4.4 Assigning Server Logical Names

Sometimes the image running in a server process can use logical names to refer to the data files it uses, or the definition for a procedure server can use a logical name to identify a procedure server image. In both these cases, you need to make the translation of the logical names available to the server process. There are several ways to do this:

• Define the logical names as system logicals.
• Define the logical names as group logicals. Make sure that the logical names are available to the group UIC for the server process.
• Use the LOGICAL NAMES subclause to define process logical names for the server process.
  There are two reasons for using the LOGICAL NAMES subclause:
  • If you are using servers with dynamic user names, and if users with different group UIC numbers can run tasks, group logicals available to one task instance may not be available to other task instances.
  • By using the LOGICAL NAMES subclause to define process logical names, you ensure that logical name assignments cannot conflict with logical names needed by other processes.
• Use the NAME TABLE subclause to define a list of tables that define logical names.

In the LOGICAL NAMES subclause, list each logical name and its equivalent name. For example:

SERVER DEFAULTS ARE USERNAME IS PERSONNEL; LOGICAL NAMES ACMS$EXAMPLES = "DBA7:[PERSONNEL]", PERS_FILE = "ACMS$EXAMPLES:PERSFILE.DAT"; END SERVER DEFAULTS; TASK GROUP IS ADMINISTRATION_COBOL_TASK_GROUP : TASK GROUP FILE IS "ACMS$EXAMPLES:ADMRMSCOB.TDB"; END TASK GROUP;

In this example, the LOGICAL NAMES subclause defines the logical name ACMS$EXAMPLES as the directory DBA7:[PERSONNEL]. It also defines the logical name PERS_FILE as the file name PERSFILE.DAT, in the ACMS$EXAMPLES directory. If a logical name or equivalent name does not conform to the syntax rules for ACMS identifiers, enclose it in quotation marks.

The following logical names are always assigned by ACMS:

• SYS$DISK
• SYS$LOGIN
• SYS$SCRATCH

ACMS automatically assigns the following logical names for the DCL servers you define. The logicals are assigned to either the terminal or the null device, depending on whether or not the processing step of the task uses the terminal. The logical names are assigned in supervisor mode. These logical names are:

• SYS$INPUT
• SYS$OUTPUT
• SYS$ERROR
• SYS$COMMAND
• TT

For procedure servers, if the processing step uses a terminal, ACMS assigns the following logical names:

• SYS$INPUT
• SYS$OUTPUT
• SYS$ERROR
• SYS$COMMAND
• TT