| Previous | Contents | Index |
Specifies whether or not a task can be canceled by a terminal user or task submitter while the task is executing. Use a CANCELABLE subclause to control how a terminal user or task submitter can exit a task. If a task is defined as NOT CANCELABLE, it cannot be canceled with a [Ctrl/Y] or [Ctrl/C] while it is executing.
The CANCELABLE subclause is optional.All tasks can be canceled by default. If you do not specify a cancelable attribute or default in either the task or the application definition, a task can be canceled by a task submitter.
When a task calls another task using the task-call-task feature, the cancelable attribute of the currently executing task determines whether the tasks can be canceled.If a task that cannot be canceled calls a task that can be canceled, both tasks are canceled if you press [Ctrl/Y] or [Ctrl/C] while the cancelable task is executing. If a cancelable task calls a task that cannot be canceled, neither task is canceled if you press [Ctrl/Y] or [Ctrl/C] while the task that cannot be canceled is executing.
TASK DEFAULTS ARE
CANCELABLE;
LOCAL;
END DEFAULTS;
|
This TASK DEFAULTS clause specifies that tasks in the application can be canceled unless they are explicitly specified as not cancelable in their task definitions or in a TASK ATTRIBUTES clause.
Controls how long ACMS waits before beginning to create new server processes when tasks are waiting for a server process.
CREATION DELAY IS seconds ;
seconds
The number of seconds ACMS waits before beginning to create new server processes. The minimum value is 0 seconds.
If the CREATION DELAY clause is not specified, ACMS uses the default creation delay value of 10 seconds.
If there are tasks waiting for server processes and fewer than the maximum number of server processes are running, ACMS waits a certain time and then begins to create server processes to satisfy the need.ACMS does not monitor the queue of waiting tasks continuously; there is a monitoring interval that is set with the SERVER MONITORING INTERVAL application clause. The actual range of the creation delay at run time includes the monitoring interval. For example, if the definition specifies a creation delay of 10 seconds, and the monitoring interval is 5 seconds, the actual delay is between 10 and 15 seconds.
If you use a CREATION DELAY parameter of 0 seconds, ACMS creates a server process whenever it detects a waiting task.
SERVER DEFAULTS ARE
NO AUDIT;
MAXIMUM SERVER PROCESSES ARE 5;
MINIMUM SERVER PROCESS IS 5;
CREATION DELAY IS 15;
CREATION INTERVAL IS 0;
END SERVER DEFAULTS;
|
In this example, the CREATION DELAY subclause is used in the SERVER DEFAULTS clause; all servers defined in the task use the CREATION DELAY value of 15 seconds. ACMS waits 15 seconds before beginning to create new server processes.
Controls the intervals at which ACMS creates new server processes.
CREATION INTERVAL IS seconds ;
seconds
The number of seconds ACMS waits between new server process creations. The minimum value is 0 seconds.
If the CREATION INTERVAL clause is not specified, ACMS uses the default creation interval value of 10 seconds.
If tasks are waiting for server processes and fewer than the maximum number of server processes are running, ACMS creates server processes one by one until either of the following occurs:
- No tasks are waiting
- The maximum number of server processes is reached
ACMS does not monitor the queue of waiting tasks continuously; a monitoring interval is set with the SERVER MONITORING INTERVAL application clause. The actual range of the time between server process creations at run time includes the monitoring interval. For example, if the definition specifies a creation interval of 10 seconds, and the monitoring interval is 5 seconds, the actual interval is between 10 and 15 seconds.
If you specify a creation interval of 0 seconds, ACMS creates as many servers as are needed to serve all tasks waiting, up to the maximum, at the instant it discovers servers are needed.
SERVER ATTRIBUTES ARE
PERSONNEL_SERVER: CREATION DELAY IS 15;
CREATION INTERVAL IS 5;
MAXIMUM SERVER PROCESSES IS 4;
END SERVER ATTRIBUTES;
|
In this example, the CREATION INTERVAL subclause is used in the SERVER ATTRIBUTES clause; PERSONNEL_SERVER uses the CREATION INTERVAL value of 5 seconds. ACMS creates new instances of PERSONNEL_SERVER every 5 seconds until either no tasks are waiting for server processes, or the number of instances of PERSONNEL_SERVER reaches the maximum server processes value.
Defines the application database file (.ADB) that ACMS uses when you do not name an application database file with the BUILD command.
DEFAULT APPLICATION FILE IS application-database-file;
application-database-file
The file specification of the file that the BUILD command uses for the application database. You can define a full file specification, an identifier, or a logical name. Enclose a full file specification or a logical name that exceeds 31 characters in quotation marks (" "). The default file type is .ADB. If you do not include a device or directory, ADU uses your default device and directory when you build the application.
If you name an application database file on the BUILD command when you build an application, ACMS uses that name instead of an application database file you name with the DEFAULT APPLICATION FILE clause. This clause is optional.If you do not name an application database file on the BUILD command when you build an application, and you do not name a database file with the DEFAULT APPLICATION FILE clause, ACMS uses the full given name, including dollar signs ($) and underscores (_), for the default database file name.
Do not include more than one DEFAULT APPLICATION FILE clause in an application definition.
| #1 |
|---|
DEFAULT APPLICATION FILE IS "EMPLOYEE.ADB";
USERNAME IS EMPLOYEE;
TASK GROUP IS
PERSONNEL_GROUP : TASK GROUP FILE IS "SYS$SAMPLE:PERSONNEL.TDB";
END TASK GROUP;
END DEFINITION;
|
By naming the application database file EMPLOYEE.ADB, you do not have to include the output file specification for the application database file when you build the application. If you include the file type, you must enclose the file specification in quotation marks (" ").
| #2 |
|---|
APPLICATION FILE DEPART;
USERNAME IS DEPART;
TASK GROUP IS
DEPARTMENT_GROUP : TASK GROUP FILE IS "SYS$SAMPLE:DEPART.TDB";
END TASK GROUP;
END DEFINITION;
|
This example is similar to the first example, except here you shorten the DEFAULT APPLICATION FILE clause by leaving out the keywords DEFAULT IS. They are optional keywords. Also, DEPART is a valid identifier, which means you do not need to enclose it in quotation marks.
Assigns a default device and directory for each of the server processes that are associated with a server.
USERNAME DEFAULT DIRECTORY
Assigns the default directory associated with the user name under which server processes run.
default-directory
The disk and directory names you want ACMS to use as defaults for the server processes of an application. You can include an OpenVMS file specification or assign a logical. If you use a file specification or a logical name longer than 31 characters, enclose it in quotation marks (" "). See OpenVMS DCL Dictionary for information about creating valid directory names.
The ACMS-supplied default is DEFAULT DIRECTORY IS USERNAME DEFAULT DIRECTORY. When ACMS takes this default, it uses the default directory it finds in the SYSUAF entry for the user name of the server. This subclause is optional.
If you are using a logical name, ACMS checks and translates the logical only when the server process is started, not when you create the definition or build the application.When you use the DYNAMIC USERNAME subclause and ACMS runs a processing step in a server, ACMS redefines any default directory previously defined.
USERNAME IS DATA;
SERVER DEFAULT IS
DEFAULT DIRECTORY IS SYS$SAMPLE;
END SERVER DEFAULT;
TASK GROUP IS
DATA_GROUP : TASK GROUP IS "SYS$SAMPLE:DATA.TDB";
END TASK GROUP;
END DEFINITION;
|
In this example, the default disk and directory for the servers in this application are identified by the logical name SYS$SAMPLE.
Controls whether or not ACMS waits 3 seconds after a task finishes running before clearing the screen and displaying the ACMS menu.
[ NO ] DELAY ;
The ACMS-supplied default is NO DELAY. This subclause is optional.
When you use the WAIT subclause, you cannot use the DELAY subclause in the same definition.If you do not set the delay 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 DELAY default.
The DELAY subclause always delays clearing the screen for 3 seconds. You cannot change the time of the delay.
This clause differs from the WAIT subclause, which requires users to press [Return] to have ACMS redisplay the menu.
The WAIT and DELAY subclauses determine how quickly ACMS returns user control to a menu when a task ends. If a user runs a task that displays the time of day, for example with the SHOW TIME command, by default ACMS displays the time but then immediately clears the screen and returns the user to the menu. Both subclauses let you delay the time between the end of a task and the return to the selection menu.
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 |
|---|
DELAY;
|
You can have ACMS clear the screen and then redisplay a menu by including the DELAY subclause in your application definition.
| #2 |
|---|
NO DELAY;
|
Because the NO DELAY subclause is the default, you do not need to include the clause in your application definition, unless you changed the default.
Controls how long ACMS waits before deleting inactive server processes.
DELETION DELAY IS seconds ;
seconds
The number of seconds ACMS waits before beginning to delete inactive server processes. The minimum value is 0 seconds.
If the DELETION DELAY subclause is not specified, ACMS uses the default deletion delay value of 30 seconds.
If there are inactive server processes and more than the minimum number of server processes are running, ACMS waits for the time specified as the DELETION DELAY and then begins to delete server processes.ACMS does not monitor the queue of waiting tasks continuously; there is a monitoring interval that is set with the SERVER MONITORING INTERVAL application clause. The actual range of the deletion delay at run time includes the monitoring interval. For example, if the definition specifies a deletion delay of 10 seconds and the monitoring interval is 5 seconds, the actual delay is between 10 and 15 seconds.
SERVER DEFAULTS ARE
NO AUDIT;
MAXIMUM SERVER PROCESSES ARE 5;
MINIMUM SERVER PROCESSES ARE 5;
DELETION DELAY IS 15;
DELETION INTERVAL IS 5;
END SERVER DEFAULTS;
|
In this example, the DELETION DELAY subclause is used in the SERVER DEFAULTS clause; all servers defined in the task use the DELETION DELAY value of 15 seconds. ACMS waits 15 seconds before beginning to delete inactive server processes.
Controls the intervals at which ACMS deletes inactive server processes.
DELETION INTERVAL IS seconds ;
seconds
The number of seconds ACMS waits between server process deletions. The minimum value is 5 seconds.
If the DELETION INTERVAL clause is not specified, ACMS uses the default deletion interval value of 15 seconds.
If more than the minimum number of server processes are running, but not all are active, ACMS deletes server processes one by one until one of the following occurs:
- All server processes are active
- The minimum number of server processes is reached
ACMS does not monitor the queue of waiting tasks continuously; there is a monitoring interval that is set with the SERVER MONITORING INTERVAL application clause. The actual range of time between server process deletions at run time includes the monitoring interval. For example, if the definition specifies a deletion interval of 10 seconds and the monitoring interval is 5 seconds, the actual interval is between 10 and 15 seconds.
SERVER ATTRIBUTES ARE
PERSONNEL_SERVER: CREATION DELAY IS 15;
CREATION INTERVAL IS 5;
DELETION DELAY IS 30;
DELETION INTERVAL IS 10;
MAXIMUM SERVER PROCESSES IS 4;
MINIMUM SERVER PROCESSES IS 0;
END SERVER ATTRIBUTES;
|
In this example, the DELETION INTERVAL subclause is used in the SERVER ATTRIBUTES clause; PERSONNEL_SERVER uses the DELETION INTERVAL value of 10 seconds. When instances of PERSONNEL_SERVER are inactive, ACMS deletes instances of PERSONNEL_SERVER every 10 seconds until either no servers are inactive or it has reached the MINIMUM SERVER PROCESSES value of 0.
Specifies that a task is not available for selection by task submitters.
The DISABLE subclause is optional. Tasks are enabled by default and can be selected by task submitters.
You can modify the DISABLE attribute by using the ACMS/MODIFY APPLICATION command. See Compaq ACMS for OpenVMS Managing Applications for information about modifying active applications.
TASK ATTRIBUTES
ADD_EMPLOYEE:
ENABLE;
TASK ADD_EMPLOYEE;
LOCAL;
REVIEW_UPDATE:
TASK REVIEW_UPDATE;
DISABLED;
END ATTRIBUTE;
|
This TASK ATTRIBUTES clause specifies that ADD_EMPLOYEE is enabled and available for selection by task submitters, but REVIEW_UPDATE is disabled and not available for selection by task submitters.
Specifies that the user name, UIC, and default directory of a server change to match those of the user each time the server process is allocated for a task.
DYNAMIC USERNAME ;
The ACMS-supplied default is FIXED USERNAME. This subclause is optional.
The DYNAMIC USERNAME clause is not valid for procedure servers. If you use the clause with a procedure server, ADU accepts the clause. However, the user name is not changed at run time when users select tasks that run in that server. Instead, the server keeps the user name under which the server was started.If you do not set the dynamic/fixed attribute in the SERVER ATTRIBUTES clause, ACMS uses the setting you assign in the task group definition. If you do not make an assignment there, ACMS uses the FIXED USERNAME subclause as the default.
If you define a server to have a dynamic user name, ACMS changes the user name, UIC, and default directory to those of the user who selected the task. In addition, the logical name SYS$LOGIN is defined to be the default directory and the logical name SYS$SCRATCH is defined to be the default directory.
Servers defined with the DYNAMIC USERNAME subclause do not restore the initial user name before running down. Therefore, the OpenVMS accounting facility charges the resources used by the server to the last terminal user who selected a task in that server instance. However, the correct ACCOUNT field is used because ACMS does not modify that field in the process header.
If you do not assign a user name to the server in the application definition, but use the APPLICATION USERNAME clause, ACMS assigns the user name of the application to each server process when it starts up. If you assign a user name to the server with the USERNAME clause in the application definition, ACMS assigns that user name to each server process when it starts up. In both of these cases, the user name changes when the server process is allocated to a task if you define the server to have a dynamic user name.
When a server process is created, it uses the group logical name table for the UIC that corresponds to the user name with which the server is created. This group logical name table remains in use for the life of the server process. For servers with dynamic user names, the group logical name table does not change if the user name changes and the corresponding UIC is in a different group.
If you use the ACMS/INSTALL command to move an application database file to ACMS$DIRECTORY, the server user names in the application database must match the ones authorized for the application in the application authorization file, ACMSAAF.DAT. The /DYNAMIC_USERNAME qualifier in the Application Authorization Utility (AAU) authorizes both dynamic user names and user names of terminal users. For information on the AAU, see Compaq ACMS for OpenVMS Managing Applications.
SERVER ATTRIBUTE IS
PERSONNEL_SERVER: IN UTILITY_GROUP;
DYNAMIC USERNAME;
END SERVER ATTRIBUTE;
|
In this example, the server given name PERSONNEL_SERVER is defined to have a dynamic user name.
| Previous | Next | Contents | Index |