When the iSeries™ server 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.
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.
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 iSeries server 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.