If you define in the PCEDEF initialization statement that your MAS is to have only one converter processor (CNVTNUM=1), then you force the JES2 system to convert and execute jobs in the order of their reader (job number) sequence. Although this setup controls the order of job conversion and execution, it has the following implication and disadvantages:

• JES2 is limited to processing your workload in a serial manner without respect to the types of jobs that are being submitted. Large batch jobs and TSO logons are treated in a similar way.
• Each of the job's resources are required when the job executes. As such, any migrated libraries and data sets that the job needs, must be restored before the job can execute. The time spent waiting for these migrated resources can backup other jobs in the queues.
• System hangs and deadlocks can occur in the system. When jobs are waiting for resources that have been migrated, the migration program needs to run and restore these resources. The migration program is often a job that needs JES2 conversion before it running. Since only "1" JES2 converter processor is defined to do the conversion and it is waiting, the migration cannot occur and the system becomes deadlocked. As an example, this condition can occur for jobs that need JCLLIB data sets, which have been migrated by a product like DFHSM.
• If a job has an exclusive ENQ on a JCLLIB data set and another job needs that JCLLIB data set, the job must wait till the ENQ is released.