# | Name | Location | Type | Details | Index | Description |
---|---|---|---|---|---|---|
.01 | box-volume pair(+) | 0;1 | FREE TEXT | B | Your answer should be the volume set name concatenated with ":" concatenated with the name of the CPU. The value for the current process can be found by doing GETENV^%ZOSV and checking the fourth ^-piece of Y. This allows the TaskMan site parameters to be applied extremely precisely, depending both upon which volume set and cpu which is affected. | |
1 | reserved | 0;2 | BOOLEAN | Y:YES N:NO | Answer YES to activate response time monitoring for processes using this pair of resources. | |
2 | log tasks? | 0;3 | BOOLEAN | Y:YES N:NO | If you answer YES, then tasks will gerenarate entries in the sign-on log file. | |
3 | default task priority | 0;4 | NUMERIC | Your answer will set the default Kernel priority assigned to tasks. This value will be overridden only for special options, devices, and tasks. If this value is too low, jobs started by TaskMan will be unable to process tasks fast enough to keep up with demand. 7-10 are good values, depending on whether interactive users' priorities are set higher or lower on the local system. | ||
4 | task partition size | 0;5 | NUMERIC | Under MSM only, this field will be used to change the maximum partition size for a JOB. It will be used by both interactive and Tasked jobs. The answer is in K bytes to pass into MSM's %PARTSIZ utility. Check with the 486 team for the latest recommendations. | ||
5 | submanager retention time | 0;6 | NUMERIC | Answer will determine how long submanagers wait for new tasks, in seconds. The goal of this field is to reduce the number of JOB commands needed to process a site's tasks. By keeping old submanagers around to run new tasks, new process creation is severely reduced. Good values are 300-600 seconds for VAX sites, and 10-50 for others. | ||
6 | taskman job limit(+) | 0;7 | NUMERIC | If there are more active processes on the system than this number, TaskMan will not create new submanagers to handle tasks. Task processing will be left to existing submanagers until the number of processes falls back below this number. This number should be slightly lower than the Max Signons field of the Kernel Site Parameters file, so that the system manager still has room to sign on when TaskMan is using its greatest number of partitions. | ||
7 | taskman hang between new jobs | 0;8 | NUMERIC | Answer will set a delay between the creation of new submanagers, in seconds. Such a delay is necessary where the Retention Time is low and task creation cost is high. This prevents the creation of many new submanagers in quick succession from causing a perceivable delay to users. The number should be the lowest value that prevents the problem. | ||
8 | mode of taskman(+) | 0;9 | SET OF CODES | G:GENERAL PROCESSOR P:PRINT SERVER C:COMPUTE SERVER O:OTHER NON-TASKMAN | This field describes how TaskMan should act. It takes over many of the 486 configuration functions handled by the Out of Order and Replacement Volume Set fields in versions 6.5 and 7.0. General Processor: The Manager on a G type will usually send tasks back to the volume set where they were created, except that tasks that explicitly request a different volume set will be sent where they ask. (Explicit volume set requests are made by using 1) the ZTCPU input variable to the %ZTLOAD entry point, 2) the CPU (VOL SET) field of the Device file, or 3) the Queued to What Volume Set field of the Option file.) To transfer tasks TO a G type, TaskMan will use extended global references to copy the task to the destination Task and Schedule files, and will then remove the task from this side. Submanagers started on a G type will process tasks in the Partition Waiting List and the Busy Device Waiting Lists. Print Server: On a P type, the Manager will run any task it finds unless the task explicitly requests a different volume set. Tasks are transferred TO a P type the same as to a G type, and Submanagers behave the same. Compute Server: The Manager will not start on a C type. Tasks are transferred to a C type by placing the tasks in the Link Waiting List and jobbing a Submanager across to that volume set. Submanagers started on a C type will only process tasks in the Link Waiting List for their volume set. Other Non-TaskMan: Neither the Manager nor the Submanager will run on O types. Tasks sent from or to a O type will be rejected. Because of the field's crucial role in guiding TaskMan's behavior, the field is required. | |
9 | vax enviroment for dcl | 0;10 | FREE TEXT | This field only has meaning on OpenVMS systems.
If this field is empty, then the M JOB command will be used.
If this field has a value, it will cause TM to SUBMIT submanagers
to run from a VMS batch queue with a name of TM$ | ||
10 | out of service(+) | 0;11 | BOOLEAN | 0:NO 1:YES | This field is used by the TASK Manager to control if any new sub-manager jobs are sent to this Box-Volume Pair. If the manager gets an error when jobbing to another CPU it will change the flag to mark the Box-Volume as Out of Service. | |
11 | min submanager cnt | 0;12 | NUMERIC | This field sets a value that free submanagers will check and not stop if there count doesn't exceed. The manager will check this and start new submangers if the free count is below this value. If this field is left blank a default value of 1 is used. | ||
12 | tm master | 0;13 | POINTER | 14.7 | This field is holds a pointer to the TaskMan Master Box-Volume. This is only needed if this Box-Volume is mounted on an other configuration and shares the library account with that other configuration. | |
13 | balance interval | 0;14 | NUMERIC | This field sets the time interval in seconds that the Task Manager will wait before running the "LOAD BALANCE ROUTINE". If this field in empty a value of 30 will be used. A lower value will cause more resources to be used calculating the balance. A large value will allow a node to pick-up a lot of work before balancing. | ||
21 | load balance routine | 2;E1,75 | FREE TEXT | This field holds the name of a Function, Extrinsic function or External routine call that returns a load rating. If this field contains a value, TaskMan will use this name in preforming Load Balancing. Only use Load Balancing if you have two or more CPU's running TM that share the same %ZTSCH global. The Load Balancing function must return a value between 1 and 256. Where: 1 represents a CPU with no capacity for any more work. 256 represents a CPU that is Idle. The only included functions are For VAX DSM it is '$$VXD' and its algorithm is: Capacity left= Available jobs - Active jobs - (4 * Computable jobs) For Cache/NT it is '$$CACHE1(constant)' its algorithm is: Capacity left= Available jobs + constant For Cache/VMS it is '$$CACHE2(@com-file,logical-name)'. If the com-file value is set, that com-file will be run each time taskman wants to get the balance value. The logical-name will default to "VISTA$METRIC" or us the value entered. The normal way would be to have $$CACHE2() in the field and use the two scripts. A script "GET_METRIC.COM" will set the logical "VISTA$METRIC". This can be run by taskman or from the TM$node batch queue with the script "METRIC_SCHEDULE.COM". | ||
31 | auto delete tasks | 3;1 | BOOLEAN | 0:No 1:Yes | This Field is used by the Sub-manager to control if the Sub-manger should set the ZTREQ variable to "@" so a task will be killed when it finishes unless the application modifies ZTREQ. Unless there is a need to save the enties in the ^%ZTSK global set this field to YES. If you are researching task errors you should set to NO untill you have the data you need. This data will still be cleaned up by the XUTMK option. | |
32 | manager startup delay | 3;2 | NUMERIC | This field is used by the Task Manager to control the delay (hang) the manager will do during a START. This field is not used with a RESTART. The Manager Startup Delay was hard set at 60 before. After requests to change the delay it has been made a parameter. I would think that 5 to 30 would be OK. If you get errors because jobs start running before DDP/Cluster is up that use a larger number. |