How work gets processed
When the system is started, a subsystem monitor job begins running. The subsystem monitor job controls the jobs within subsystems. It also starts and ends work, as well as manages the resources for work in the subsystem.
Work (or jobs) enters a subsystem through work entries where it becomes active and eligible to run. Work can only be completed when the subsystem has allocated memory to run. Memory is allocated to the subsystem by a memory pool.
How the subsystem description helps process work
Like a job, a subsystem has a description, called a subsystem description. The subsystem description contains important information that tells how, where, how much work can be active in a subsystem at one time, and which resources it can use to perform the work.
- Routing entry
- A routing entry exists within the subsystem description and tells the subsystem what program to run for the job, what memory pool to run the job in, and which class object to use to run the job.
- Class Object
- The Class object defines the run priority, default wait time, time slice, and other attributes. The run priority is important because it determines when a job will get processor time in order to run. The run priority scale goes from 0 to 99, with 0 being the highest priority. (Only system jobs are given priority of 0 because they are the jobs that run the system.)
When a job enters the subsystem, the subsystem tries to match the routing data with the compare value in the routing entry. If the routing data and the compare value in a routing entry match, the routing entry is assigned to the job. If a match is not made in any routing entry, the job ends.
Another factor that affects when a job runs in the subsystem is the number of jobs that are allowed to be active in the subsystem at one time (also known as maximum active jobs in the subsystem). When the maximum number of active jobs in a subsystem has been met, no more jobs can enter the subsystem until existing active jobs complete running. Memory has to be allocated to the subsystem for a job to run. Memory pool activity levels tell the system how many threads can be active within a memory pool. Remember, an active job contains at least one thread. When the memory pool activity level has been reached, the job has to wait for another thread to give up its use of the activity level. Thus, a job can be active in a subsystem and not be running.
Do not confuse the subsystem maximum active jobs with the memory pool activity level.
Parent topic:
How work gets doneRelated concepts
What work is What happens before work enters the system How work enters the system How work leaves the system