![]() |
![]() HP OpenVMS Systems Documentation |
![]() |
Compaq ACMS for OpenVMS
|
Previous | Contents | Index |
Defines one or more task control attributes on a task-by-task basis.
task-given-name
The name you create for the task in the application definition and in any menu definitions pointing to the task. For each task you describe, you must include its given name. The task given name must be a valid ACMS identifier and must be unique in the application definition.group-task-name
The name of the task as defined in the task group. ADU uses the task given name as the default.task-group-name
The name of a task group associated with the application you are defining. This name must correspond to the unique name assigned to the task group in the TASK GROUPS clause of the application definition. It is not a CDD path name or task group database file name. This task group name defaults to the last task group name in the immediately preceding TASK GROUPS clause. If you have not yet defined a TASK GROUPS clause in the application source file, you must include this parameter.task-subclause
The subclauses that describe the tasks of a task group. Refer to Section 5.3 for information about the subclauses in this group.
See the Notes section to learn about the defaults ACMS assigns. This clause is optional.
You can define many tasks in one TASK ATTRIBUTES clause.You can include many TASK ATTRIBUTES clauses in one application definition.
You must include at least one subclause for each task you name.
If you do not include a task in a TASK ATTRIBUTES clause, its default name is the one you give it in the task group definition.
Sometimes two or more tasks from different task groups have the same task name. For this reason, the task given name in the application definition must be unique.
When deciding what value to assign for each task control attribute for each task, ADU looks at the following:
- TASK ATTRIBUTES clause in the application definition
If a task attribute is explicitly defined for a task in a TASK ATTRIBUTES clause, ADU always takes that value for the attribute for that task. The subclauses used in a TASK ATTRIBUTES clause apply only to one task.- TASKS clause in the task group definition
If a task attribute is not explicitly defined for a task in a TASK ATTRIBUTES clause, and if the attribute is one that can be assigned in a task group definition, ADU looks in the task group database that defines implementation attributes for that task. The control attributes that can be defined in a task group definition (as well as an application definition) are DELAY, WAIT, LOCAL, GLOBAL, and CANCELABLE.- TASK DEFAULTS clause in the application definition
For any attribute not explicitly defined in the application or the task group definition of the task, ADU uses the defaults that are in effect when the task is defined in the application.- ACMS-supplied defaults
ADU uses the default value supplied by ACMS only if a value is not assigned to that attribute in the application definition TASK ATTRIBUTES clause, task group definition TASKS clause, or application definition TASK DEFAULTS clause that applies to that task.
USERNAME IS PERSONNEL; TASK GROUP IS PERSONNEL_GROUP : TASK GROUP FILE IS "SYS$SAMPLE:PERSONNEL.TDB"; END TASK GROUP; TASK ATTRIBUTES ARE EMPLOYEE: TASK TASK_EMPLOYEE; ACCESS CONTROL IS (ID=[PERSONNEL,*], ACCESS=EXECUTE); WAIT; RESTORE: TASK TASK_RESTORE; ACCESS CONTROL IS (ID=[PERSONNEL,*], ACCESS=EXECUTE); DELAY; END TASK ATTRIBUTES; END DEFINITION; |
This TASK ATTRIBUTES clause changes attributes for two tasks in the PERSONNEL_GROUP task group. See Section 5.3 for a list of the subclauses you use with the TASK ATTRIBUTES clause.
Changes the default values for one or more task control attributes in an application definition.
task-subclause
A set of subclauses. These subclauses let you change defaults for one or more task control attributes. See Section 5.3 for a list of these task subclauses.
ACMS assigns a default to each task control attribute you can define with the TASK DEFAULTS clause. This clause is optional.
The TASK DEFAULTS clause applies to any task or task groups named after this clause in the definition. You can include more than one TASK DEFAULTS clause in a definition. If you do, each TASK DEFAULTS clause uses the default values assigned in previous TASK DEFAULTS clauses, changing only those defaults that it explicitly names. A TASK DEFAULTS clause does not discard all previous TASK DEFAULTS clauses in the definition.Any defaults you change with the TASK DEFAULTS clause can be overridden on a task-by-task basis with a TASK ATTRIBUTES clause. If an attribute is not explicitly defined in the application or the task group definition of the task, ADU uses the defaults that are in effect when the task is defined in the application.
If a task is named in a TASK ATTRIBUTES clause, the definition is explicit and ADU uses the defaults that are in effect when that ATTRIBUTES clause appears in the application definition. Otherwise, ADU uses the defaults in effect when it processes the TASK GROUPS clause for the task group containing the task.
TASK DEFAULTS ARE ACCESS CONTROL IS ( (ID=[PERSONNEL,JONES], ACCESS=NONE), (ID=[PERSONNEL,*], ACCESS=EXECUTE) ); DELAY; END TASKS DEFAULTS; TASK GROUP IS PERSONNEL_GROUP : TASK GROUP FILE IS "SYS$SAMPLE:PERSONNEL.TDB"; END TASK GROUP; END DEFINITION; |
This clause changes the default access rights to tasks in the task group PERSONNEL_GROUP. The defaults you set in the TASK DEFAULTS clause apply to any task groups that you define after it. This rule applies if you do not define another TASK DEFAULTS clause, changing the same control attributes you changed in previous TASK DEFAULTS clauses.
Example 5-4 shows how to include multiple TASK DEFAULTS clauses in your application definition.
Example 5-4 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; |
The first TASK DEFAULTS clause defines a default access control list. ADU assigns this access control list to all the tasks in the department group. The second TASK DEFAULTS clause changes that default access control list. ADU assigns the second access control list to all the tasks in the administration group. The only users who can run the tasks in the administration task group are those who have a group UIC of 200.
Names the task groups containing the tasks associated with an application. You must include at least one TASK GROUPS clause in each application definition.
task-group-given-name
A valid ACMS identifier that names the task group in the application. You must include a name for each task group in an application. This name serves as a link between the attributes you set in the SERVER ATTRIBUTES and TASK ATTRIBUTES clauses and the task group for which you are assigning attributes. Include the name in the SERVER ATTRIBUTES and the TASK ATTRIBUTES clauses to identify the task group for the task or server you are defining.task-group-file
A file specification that points to a task group database file that you produce when you build a task group definition. For each task group name, you must include the name of the task group database file. The default file type for a task group database file is .TDB.
You must include at least one TASK GROUPS clause in each application definition. This clause is required.
You can include more than one TASK GROUPS clause in an application definition.The location of the TASK GROUPS clause can affect the attributes you assign to the tasks and servers in a task group. You must put the TASK DEFAULTS and SERVER DEFAULTS clauses before the TASK GROUPS clause with which you want to associate task and server defaults.
ACMS uses this clause when you build the application and when you start the application to find the name of the task group file.
#1 |
---|
USERNAME IS PERSONNEL; TASK GROUPS ARE PERSONNEL_GROUP : TASK GROUP FILE IS "SYS$SAMPLE:PERSONNEL.TDB"; WORK_GROUP : TASK GROUP FILE IS "SYS$SAMPLE:WORK.TDB"; END TASK GROUPS; END DEFINITION; |
You must include at least one TASK GROUPS clause in each application definition. For each task group, you must create a task group given name. The name must be unique in the application definition. The names created in this application are PERSONNEL_GROUP and WORK_GROUP. A task group given name lets you use the TASK ATTRIBUTES and SERVER ATTRIBUTES clauses to assign defaults to the task group. The TASK GROUP FILE clause defines the binary file that results from building the task group definition with the BUILD command. End the TASK GROUPS clause with the keywords END TASK GROUPS.
#2 |
---|
USERNAME IS PERSONNEL; TASK GROUPS ARE PERSONNEL_GROUP : TASK GROUP FILE IS "SYS$SAMPLE:PERSONNEL.TDB"; WORK_GROUP : TASK GROUP FILE IS "SYS$SAMPLE:WORK.TDB"; END TASK GROUPS; TASK ATTRIBUTE IS ADD_EMPLOYEE : TASK ADD_EMPL IN PERSONNEL_GROUP; ACCESS CONTROL IS (ID=[PERSONNEL,*], ACCESS=EXECUTE); END TASK ATTRIBUTE; END DEFINITION; |
In this example, you use the task group given name in the TASK ATTRIBUTES clause. The task group given name, PERSONNEL_GROUP, identifies the task group containing the task for which you are setting control attributes. If you do not include the task group given name in the TASK ATTRIBUTES clause, ADU uses as the default task group the last task group in the TASK GROUPS clause just preceding the TASK ATTRIBUTES clause. In this case, the default task group is WORK_GROUP. Include the task group given name each time you use the TASK ATTRIBUTES clause.
Places a limit on how long a distributed transaction can remain active.
[ NO ] TRANSACTION TIMEOUT IS seconds;
The TRANSACTION TIMEOUT subclause is optional. If you do not specify TRANSACTION TIMEOUT, ACMS does not abort a distributed transaction because of a timeout error.
seconds
The number of seconds a distributed transaction can remain active before ACMS aborts it.
Use the TRANSACTION TIMEOUT subclause to place a limit on how long a distributed transaction can remain active. It is possible that a distributed transaction cannot complete because a server deadlock or database deadlock problem has occurred. You can use the TRANSACTION TIMEOUT subclause to resolve the deadlock.When a distributed transaction exceeds the specified timeout limit, ACMS aborts the distributed transaction, raises a transaction exception, searches for an exception handler, and stores the ACMS$_TRANSTIMEDOUT exception code in the ACMS$L_STATUS field of the ACMS$PROCESSING_STATUS system workspace. If the task does not handle the timeout exception in an exception handler, ACMS cancels the task.
The maximum timeout value you can specify is 65535 seconds.
TASK DEFAULT IS TRANSACTION TIMEOUT IS 60 END DEFAULT; |
This example places a one-minute limit on the length of a distributed transaction.
Defines the user name under which the server process runs.
TERMINAL USER
Assigns to a server process the user name of the terminal user.APPLICATION
Assigns to the server processes the OpenVMS user name under which the application runs. Assign an OpenVMS user name to the application with the APPLICATION USERNAME clause.
username
A valid OpenVMS user name consisting of 1 to 12 alphanumeric characters and underscores (_). This parameter identifies the user name under which a server process runs.
The ACMS-supplied default is USERNAME OF APPLICATION. If you do not assign a user name in the task group definition, USERNAME OF APPLICATION is the default. However, if you assign a user name in the task group definition, ACMS uses that assignment. This subclause is optional.
If you use the USERNAME subclause with the SERVER ATTRIBUTES clause, you override any user name defined with the SERVERS clause of the task group definition.If you define a server to have the user name of the terminal user, that server cannot have a dynamic user name. Also, the user must be an authorized OpenVMS user.
A system manager can set up a special account with special quotas and privileges required for a task. The system manager can assign the server handling the processing for that task to the user name of that account using the USERNAME server subclause.
If you use the ACMS/INSTALL command to move an application database file to ACMS$DIRECTORY, the server user names in that application database must match the ones authorized for the application in the application authorization file ACMSAAF.DAT. Using the /DYNAMIC_USERNAME qualifier in the Application Authorization Utility (AAU) authorizes both the user names of terminal users and dynamic user names. For more information on AAU, see the Compaq ACMS for OpenVMS Managing Applications.
The REUSABLE server subclause in the task group definition is the default for both DCL and procedure servers. However, using the clause USERNAME OF TERMINAL USER in application or task group definitions overrides this default and creates servers that are not reusable. Every time a new terminal user logs in, a separate server process is created for that user. For best performance, your application should run as few servers as needed to do the work of the application.
SERVER ATTRIBUTE IS PRIVATE_SERVER: USERNAME OF USER; END SERVER ATTRIBUTE; |
The user name of PRIVATE_SERVER is the same as the user name of the terminal user.
Controls whether or not ACMS displays a message prompting users to press [Return]. Pressing [Return] clears the terminal screen and displays the previously displayed ACMS menu.
[ NO ] WAIT ;
The ACMS-supplied default is NO WAIT. This subclause is optional.
If you do not set the wait attribute in the TASK ATTRIBUTES clause, ACMS uses the setting you assign in the task group definition. If you do not make an assignment there, ACMS uses the NO WAIT default.You cannot use the WAIT subclause and the DELAY subclause in the same definition.
You can define WAIT and DELAY in the application definition and in the TASKS clause of the task group definition. WAIT and DELAY are the only task control attributes that you can define in task group definitions as well as application definitions.
The WAIT and DELAY subclauses determine how quickly ACMS returns user control to a menu when a task ends. For example, if a user runs a task that displays the time of day with the SHOW TIME command, ACMS displays the time but immediately clears the screen and returns the user to the menu. Both subclauses let you delay the time interval between the task ending and the selection menu redisplay.
WAIT and DELAY subclauses specified for a task in a task, task group, or application definition are overridden by menu definition WAIT and DELAY clauses.
#1 |
---|
USERNAME IS FRIDAY; TASK DEFAULT IS WAIT; END TASK DEFAULT; TASK GROUP IS PERSONNEL_GROUP : TASK GROUP IS "SYS$SAMPLE:PERSONNEL.TDB"; END TASK GROUP; END DEFINITION; |
The WAIT subclause in this TASK DEFAULTS clause changes the ACMS default from NO WAIT to WAIT. This example changes the default for the tasks defined in the PERSONNEL_GROUP task group. After processing for each of these tasks stops, ACMS prints a message telling the user to press [Return] to have ACMS return control to the menu.
#2 |
---|
USERNAME IS FRIDAY; TASK DEFAULT IS WAIT; END TASK DEFAULT; TASK GROUP IS PERSONNEL_GROUP : TASK GROUP IS "SYS$SAMPLE:PERSONNEL.TDB"; END TASK GROUP; TASK ATTRIBUTE IS ADD_EMPLOYEE : TASK ADD_EMPLOYEE IN PERSONNEL_GROUP; NO WAIT; END TASK ATTRIBUTE; END DEFINITION; |
In this example the default changes from NO WAIT to WAIT. The default also changes for the ADD_EMPLOYEE task back to NO WAIT. For all tasks in the PERSONNEL_GROUP task group except the ADD_EMPLOYEE task, the default is WAIT. Any default you set with the TASK ATTRIBUTES clause overrides any you set either in the task group definition or in the application definition with the TASK DEFAULTS clause.
Previous | Next | Contents | Index |