Welcome back. In this unit we'll be covering task management. Now, the way work gets done may not concern you just as long as it gets done, but when we're trying to maximize performance and make sure that resources are optimized so things run as quickly and smoothly as possible, especially on a system where everything is shared between programs and users, you simply got to be able to see things at a deeper level. You've most likely submitted a job before, either through JCL, through a start command, or from the TSO logon command. When a job is submitted, JCL and SYSIN input datasets are spooled by JES. The job is assigned a job number and then placed on the job queue to wait execution. A batch job is scheduled by JES when an initiator address space of the appropriate class is available to process work. When the job is the highest priority job, that class gets ready to execute. During execution, SYSIN data is read from the spool, and SYSOUT data is written to the spool for later processing. When the job terminates, JES then writes the SYSOUT data to the appropriate hard copy device based on output class and the device and setup characteristics. Finally the job is purged from the system, including spool and job queue information. Back to execution. When a job is scheduled for execution, the job step becomes a task or work for z/OS to complete. If there's a multiple step job, each step will become a task which executes after the previous tasks complete. Dispatching a task involves determining which unit of work to process next. In z/OS, this is done on a priority basis, and as you might imagine, the work with the highest priority gets picked first. The dispatcher searches a systems work unit Q or WUQ, looking for SRBs or TCBs. These are service requests blocks or task control blocks. You'll be hearing a lot about those. Once the dispatcher has selected an address space with a task to be dispatched, it has to set things up so that the CP knows which task and address space it's working with. When the task gets dispatched or re-dispatched, its status must be restored. Hardware control registers get loaded with these specific values for the execution environment. For example, CR1, 7, and 13 will point to segment tables or region tables for the address space. A single hardware instruction can do that near the end of the dispatcher code, load address space control, or LASP. Status to be restored includes registers, floating point registers, and access registers, which were saved when the dispatchable unit lost control the last time. When that happens status was saved in some control blocks. Finally, the dispatcher ends with an instruction which loads the PSW or program status word into the CPU. The next instruction executed on that CPU will then be the instruction pointed to by the PSW, the one which was loaded by the dispatcher code. See how it all comes back around? Now, normally when we talk about task control and how the operating system works, we'll be talking about TCBs. But as you know there are also SRBs. SRB mode is a special programming environment which is not used by normal user programmers like you and I. A non-preemptable unit of work will get special priority handling in case of an interrupt, and after an interrupt it will always return to the non-preemptable unit of work. The system will not go to the dispatcher looking for more work to dispatch, because this is the priority. Since they run until completion and there is no need to save their status, there is a very limited required control block setup. In the next section we'll talk about enclaves, prism, and CPU management.
