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.