|
HP OpenVMS Systems Documentation |
|
Compaq ACMS for OpenVMS
|
| Previous | Contents | Index |
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.
Specifies that a task is available for selection by task submitters.
The ENABLE subclause is optional. Tasks are enabled by default.
You can modify the ENABLE 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 the server are those associated with the user name under which the server process starts.
FIXED USERNAME ;
The ACMS-supplied default is FIXED USERNAME. This subclause is optional.
If you do not set the DYNAMIC/FIXED USERNAME 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 FIXED USERNAME as the default.If you define a server to have a fixed user name, the server always keeps the user name, UIC, and default directory under which it starts.
SERVER ATTRIBUTE IS
PERSONNEL_SERVER: FIXED USERNAME;
END SERVER ATTRIBUTE;
|
In this example, PERSONNEL_SERVER is a server with a fixed user name.
Specifies that you can select a task from a menu, call it from an agent, or call it from another task.
GLOBAL ;
The GLOBAL subclause is optional. If no GLOBAL or LOCAL attribute is specified in either the task definition or the application definition, a task is global by default. You can select the task from a menu, call it from an agent, or call it from another task.
TASK ATTRIBUTES
ADD_EMPLOYEE:
ENABLE;
TASK ADD_EMPLOYEE;
LOCAL;
REVIEW_UPDATE:
DISABLED;
TASK REVIEW_UPDATE;
GLOBAL;
END ATTRIBUTE;
|
In this example, the TASK ATTRIBUTES clause specifies that REVIEW_UPDATE is global and can be selected from a menu, called by an agent, or called by another task, but ADD_EMPLOYEE is local and can be called by another task, but not selected from a menu or called from an agent.
Specifies that a task can be called by or chained to another task, but not selected from a menu or called by an agent.
LOCAL ;
The LOCAL subclause is optional. If no GLOBAL or LOCAL attribute is specified in either the task definition or the application definition, a task is global by default and can be selected from a menu, called by an agent, or called by another task.
A local task can call or chain to another local task or global task.
TASK ATTRIBUTES
ADD_EMPLOYEE:
ENABLE;
TASK ADD_EMPLOYEE;
LOCAL;
REVIEW_UPDATE:
DISABLED;
TASK REVIEW_UPDATE;
GLOBAL;
END ATTRIBUTE;
|
In this example, the TASK ATTRIBUTES clause specifies that REVIEW_UPDATE is global and can be selected from a menu, called by an agent, or called by another task, but ADD_EMPLOYEE is local and can be called by another task, but not selected from a menu or called from an agent.
Defines a set of process logical names for one or more server processes.
logical-name
A 1- to 255-character logical name. If it contains nonalphabetic characters or exceeds 31 characters, enclose the string in quotation marks (" ").equivalence-name
The 1- to 255-character equivalence name for the logical name in the logical name table. If it contains nonalphabetic characters or exceeds 31 characters, enclose this parameter in quotation marks (" ").logical-string
A 1- to 255-character logical string.equivalence-string
The 1- to 255-character equivalence string for the logical name in the logical name table.
This subclause is optional. ACMS does not set up any server process logical names by default, other than the standard ones. The following logicals are always defined unless the job logical name table LNM$JOB is excluded in the SERVER NAME TABLES clause in the application definition:
- SYS$LOGIN
- SYS$SCRATCH
SYS$DISK is always defined.
ACMS automatically assigns a set of logical names for the DCL servers you define:
- SYS$INPUT
- SYS$OUTPUT
- SYS$ERROR
- SYS$COMMAND
- TT
However, if you define NO TERMINAL I/O for a DCL server, you must redefine the above logicals for that server.
For procedure servers, if the processing step uses a terminal, ACMS defines:
- SYS$INPUT
- SYS$OUTPUT
- SYS$ERROR
- SYS$COMMAND
- TT
ACMS sets up the process logical names when each server process is started.The logical names are available only to the server for which they are defined.
You can include more than one LOGICALS subclause in a definition. ADU assigns all the logicals you name.
If an ACMS user wants a permutation of DATATRIEVE to run an ACMS DTR procedure, a server logical must be assigned that equates DTR32 to the new image DTR32xx.EXE, where xx represents the letters you choose to make the file name unique.
For example:
SERVER ATTRIBUTE IS SAMPLE_SERVER: LOGICAL NAME IS DTR32 = "SYS$SYSTEM:DTR32FM.EXE"; END SERVER ATTRIBUTE;After debugging your server, you can improve the speed at which it maps the workspaces it uses by defining the ACMS$PROTECT_WORKSPACES logical name. For example:
SERVER ATTRIBUTE IS UPDATE_SERVER: LOGICAL NAME IS ACMS$PROTECT_WORKSPACES = "NO"; END SERVER ATTRIBUTE;When this logical name is defined as "NO", ACMS maps the entire task instance workspace pool during the first procedure call to the server. The workspaces then stay mapped until the server runs down. Use this option carefully. Since it maps the entire task instance workspace pool for the task group, a procedure in one task can accidentally write over workspaces belonging to another task in the same group.
The default definition of ACMS$PROTECT_WORKSPACES is "YES", which causes ACMS to map only the portion of the task instance workspace pool used by the current task. The portion is mapped at the start of each processing step and unmapped at the end of each step. This ensures that one task's workspaces are protected from accidental corruption by another task, but requires additional processing overhead.
Note
You can achieve the same functionality as the ACMS$PROTECT_WORKSPACES logical by using the PROTECTED WORKSPACES subclause. In general, it is more efficient to use the PROTECTED WORKSPACES subclause than the ACMS$PROTECT_WORKSPACES logical.
| #1 |
|---|
LOGICAL NAME IS A_EMPLOYEE = "ACMS$SAMPLE:EMPLOYEE.ADF";
|
This example defines A_EMPLOYEE so you can use it in place of the equivalent name ACMS$SAMPLE:EMPLOYEE.ADF.
| #2 |
|---|
LOGICAL A_EMPLOYEE = "ACMS$SAMPLE:EMPLOYEE.ADF",
G_EMPLOYEE = "ACMS$SAMPLE:EMPLOYEE.GDF";
|
This example defines the application and task group definition files so they are easier to use. The LOGICALS subclause allows more than one entry. Place a comma (,) at the end of each entry and a semicolon (;) at the end of the clause. The keywords NAME IS are optional.
| Previous | Next | Contents | Index |