Chapter 3. Subtask creation and control
Creating the task
A new task is created by issuing an ATTACH, or, if your program runs in access register ASC mode, an ATTACHX macro. The task that is active when the
ATTACH or ATTACHX issued is the originating task; the newly created task is the subtask of the originating task. The subtask competes for control in the same manner as any other task in the system, by priority (both address space priority and task priority within the address space) and the current ability to use a processor. The address of the task control block for the subtask is returned in register 1.
If the ATTACH or ATTACHX executes successfully, control returns to the user with a return code of 0 in register 15.
The entry point in the load module to be given control when the subtask becomes active is specified as it is in a LINK or LINKX macro, that is, by using the EP,
EPLOC, and DE parameters. The use of these parameters is discussed in Chapter 4,
“Program management,” on page 33. You can pass parameters to the subtask using
the PARAM and VL parameters, also described under the LINK macro. Additional parameters deal with the priority of the subtask, provide for communication between tasks, specify libraries to be used for program linkages, and establish an error recovery environment for the new subtask.
Priorities
The control program creates one task in the address space as a result of initiating execution of the job step task. You can create additional tasks in your program.
However, if you do not, the job step task is the only task in the address space being executed. The benefits of a multiprogramming environment are still available even with only one task in the job step; work is still being performed for other address spaces when your task is waiting for an event, such as an input operation, to occur.
The advantage in creating additional tasks within the job step is that more tasks are competing for control. When a wait state occurs in one of your tasks, it is not necessarily a task from some other address space that gets control. It can be one of your tasks, a portion of your job.
The general rule is that you should choose parallel execution of a job step (that is, more than one task in an address space) only when a significant amount of overlap between two or more tasks can be achieved. You must take into account the amount of time that is taken by the control program in establishing and controlling additional tasks, and your increased effort to coordinate the tasks and provide for communications between them.
This information considers three priorities: address space priorities, task priorities, and subtask priorities.
© Copyright IBM Corp. 1988, 2017
27
Address space priority
When a job is initiated, the control program creates an address space. All successive steps in the job execute in the same address space. The address space has a dispatching priority, which is normally determined by the control program.
The control program selects, and alters, the priority to achieve the best load balance in the system. This makes the most efficient use of processor time and other system resources.
You might want some jobs to execute at a different address space priority than the default priority assigned. The active workload management (WLM) service policy determines the dispatching priority assigned to the job. For additional information, see z/OS MVS Planning: Workload Management.
Task priority
Each task in an address space has a limit priority and a dispatching priority associated with it. The control program sets these priorities when a job step is initiated. When you use the ATTACH or ATTACHX macro to create other tasks in the address space, you can use the LPMOD and DPMOD parameters to give them different limit and dispatching priorities.
The dispatching priorities of the tasks in an address space do not affect the order in which the control program selects jobs for execution. The order is selected based on the work unit (WEB) that is at the top of the work unit queue (WUQ). The dispatcher not longer selects from within an address space the top priority task awaiting execution. Thus, task priorities cannot affect processing within an address space.
Note:
In a multiprocessing system, task priorities might not be in the order of which the tasks run. More than one task might be running simultaneously in the same address space on different processors. Page faults can alter the order in which the tasks run.
Subtask priority
When a subtask is created, the limit and dispatching priorities of the subtask are the same as the current limit and dispatching priorities of the originating task except when the subtask priorities are modified by the LPMOD and DPMOD parameters of the ATTACH and ATTACHX macro. The LPMOD parameter specifies the signed number to be subtracted from the current limit priority of the originating task. The result of the subtraction is assigned as the limit priority of the subtask. If the result is zero or negative, zero is assigned as the limit priority. The
DPMOD parameter specifies the signed number to be added to the current dispatching priority of the originating task. The result of the addition is assigned as the dispatching priority of the subtask, unless the number is greater than the limit priority or less than zero. In that case, the limit priority or 0, respectively, is used as the dispatching priority.
Assigning and changing priority
Assign tasks with many I/O operations a higher priority than tasks with little I/O because the tasks with much I/O are in a wait state for a greater amount of time.
The lower priority tasks are executed when the higher priority tasks are in a wait state. As the I/O operations are completed, the higher priority tasks get control so that more I/O can be started.
28
z/OS MVS Assembler Services Guide
You can change the priorities of subtasks by using the CHAP macro. The CHAP macro changes the dispatching priority of the active task or one of its subtasks by adding a positive or negative value. The dispatching priority of an active task can be made less than the dispatching priority of another task. If this occurs and the other task is dispatchable, it would be given control after execution of the CHAP macro.
You can also use the CHAP macro to increase the limit priority of any of an active task's subtasks. An active task cannot change its own limit priority. The dispatching priority of a subtask can be raised above its own limit priority, but not above the limit of the originating task. When the dispatching priority of a subtask is raised above its own limit priority, the subtask's limit priority is automatically raised to equal its new dispatching priority.
Stopping and restarting a subtask (STATUS macro)
To stop a subtask means to change its dispatch-ability status from ready to not ready. You might need to stop a subtask that is ready or running, and then to restart, or make ready, that subtask. Stopping a subtask is a programming technique to control the dispatch-ability of other related tasks or subtasks in a multitasking environment when the tasks are in problem state.
To stop all subtasks of an originating task, issue the STATUS macro with the STOP parameter. To stop a specific subtask, issue the STATUS macro with the STOP, TCB parameter, which identifies a specific subtask.
To restart the stopped subtask or subtasks, issue STATUS START. As with STATUS
STOP, use the TCB parameter to restart a specific subtask.
Task and subtask communications
The task management information is required only for establishing communications among tasks in the same job step. The relationship of tasks in a
job step is shown in Figure 8 on page 30. The horizontal lines in Figure 8 on page
30 separate originating tasks and subtasks. They have no bearing on task priority.
Tasks A, A1, A2, A2a, B, B1, and B1a are all subtasks of the job-step task; tasks A1,
A2, and A2a are subtasks of task A. Tasks A2a and B1a are the lowest level tasks in the job step. Although task B1 is at the same level as tasks A1 and A2, it is not considered a subtask of task A.
Task A is the originating task for both tasks A1 and A2, and task A2 is the originating task for task A2a. A hierarchy of tasks exists within the job step.
Therefore, the job step task, task A, and task A2 are predecessors of task A2a, while task B has no direct relationship to task A2a.
Chapter 3. Subtask creation and control
29
Job
Step
Task
Task A Task B
Task A1 Task A2 Task B1
Task A2a Task B1a
Figure 8. Levels of Tasks in a Job Step
All of the tasks in the job step compete independently for processor time; if no constraints are provided, the tasks are performed and are terminated asynchronously. However, since each task is performing a portion of the same job step, some communication and constraints between tasks are required, such as notifying each other when a subtask completes. If a predecessor task attempts to terminate before all of its subtasks are complete, those subtasks and the predecessor task are abnormally terminated.
Two parameters, the ECB and ETXR parameters, are provided in the ATTACH or
ATTACHX macro to help communication between a subtask and the originating task. These parameters are used to indicate the normal or abnormal termination of a subtask to the originating task. If you coded the ECB or ETXR parameter, or both, in the ATTACH or ATTACHX macro, the task control block of the subtask is not removed from the system when the subtask is terminated. The originating task must remove the task control block from the system after termination of the subtask by issuing a DETACH. If you specified the ECB parameter in the ATTACH or ATTACHX macro, the ECB must be in storage addressable by the attaching task and control program so that the issuer of ATTACH can wait on it (using the WAIT macro) and the control program can post it on behalf of the terminating task. The task control blocks for all subtasks must be removed before the originating task can terminate normally.
The ETXR parameter specifies the address of an end-of-task exit routine in the originating task, which is to be given control when the subtask being created is terminated. Therefore, the end-of-task routine is given control asynchronously after
30
z/OS MVS Assembler Services Guide
the subtask has terminated and must be in virtual storage when it is required.
After the control program terminates the subtask, the end-of-task routine that is specified is scheduled to be executed. It competes for CPU time using the priority of the originating task and of its address space and can receive control even though the originating task is in the wait state. Although the DETACH does not have to be issued in the end-of-task routine, this is a good place for it.
The ECB parameter specifies the address of an event control block (discussed under “Task Synchronization”), which is posted by the control program when the subtask is terminated. After posting occurs, the event control block contains the completion code specified for the subtask.
If you specified not the ECB or the ETXR parameter in the ATTACH or ATTACHX macro, the task control block for the subtask is removed from the system when the subtask terminates. Its originating task does not have to issue a DETACH. A reference to the task control block in a CHAP or a DETACH macro in this case is as risky as task termination. Since the originating task is not notified of subtask termination, you can refer to a task control block that is removed from the system, which would cause the active task to be abnormally terminated.
Note:
The originating task is abended if it attempts to normally terminate when it has active subtasks.
Chapter 3. Subtask creation and control
31
32
z/OS MVS Assembler Services Guide
