Job Selection Algorithm for WLM-Managed Initiators

When a job in a WLM-managed job class group has completed processing in MDS, the job is placed in the queue of jobs waiting to be selected for execution by service class. This queue is ordered by main service arrival time (i.e. when the job completed C/I processing). Unlike jobs in JES-managed groups, priority is not used to order the jobs on the queue, because priority is one of the many criteria that can be used to assign a service class for a job. Because jobs are ordered by main service arrival time and not priority, the time the job completes setup processing does not determine its place in the queue.

When a request for work arrives from a WLM-managed initiator, the source of the request narrows the choice in two ways:
  1. The service class identification of the initiator limits the choice to jobs with that service class.
  2. The processor on which the initiator is started limits the choice to jobs that can run on that processor.
Note: Even though WLM management operates at a job class group level, WLM-managed initiators select work by service class and not by job class group like JES-managed initiators. Therefore, the queue of work for a particular service class can have jobs from different job class groups.
Unlike job selection for JES-managed groups, the following job selection parameters are ignored for selecting jobs in WLM-managed groups.
  • IORATE on the CLASS statement
  • CHOICE on the SELECT statement
  • JOBMIX on the SELECT statement
  • LSTOR on the SELECT statement
  • JSPAN on the GROUP statement
  • BAR on the GROUP statement
Note: Workload balancing parameters, such as CHOICE, JOBMIX, and LSTOR are ignored because workload balancing functions are left to WLM and SRM.
When a WLM-managed initiator requests a job, each job in the service class queue is examined until a job is found that is eligible to be selected for execution or until no jobs are left to run. JSPAN and BAR are not used to limit the number of jobs examined. The following job characteristics are examined when selecting a job:
  • Is job selection suspended because a WLM service definition change has occurred, and JES3 is busy reclassifying jobs?
  • Can the job run on the system on which the initiator is started?
  • Is the system on which the initiator is started, connected and online?
  • Is the job's group and class enabled on the system on which the initiator is started? Is the job held as a result of an operator command or because it is part of a DJC network?
  • Is there available spool space in the spool partition that is assigned to the job? The spool partition that is examined is one of the following:
    • The spool partition specified by the SPART parameter
    • The spool partition assigned to the job class using the SPART parameter on the CLASS initialization statement
    • The spool partition assigned to the system using the SPART parameter on the MAINPROC initialization statement
    • The default spool partition
  • Are any of the class limits exceeded as defined using the TDEPTH, MDEPTH, TLIMIT, and MLIMIT parameters on the CLASS initialization statement?
  • If the job has a scheduling environment, is the scheduling environment available on the system on which the initiator is started?