Should QINTER subsystem be used to submit critical batch jobs?

In order to ensure critical batch jobs are not held up, some administrator, programmer and system operator submit batch jobs to QINTER subsystem. Now, the question is should we do this and is this the best solution to ensure critical batch jobs are not held up.

From system point of view, QINTER treats the batch job as any other interactive job and runs them without any concern. All the job scheduler including System native job scheduler, AJS and ROBOT allows to change the job queue of any job. You can change the job queue to any job queue including QINTER job queue. Once, the job queue has been changed to QINTER job queue, the job gets submitted to QINTER subsystem and runs like any other interactive job.

However, batch jobs can affect the interactive jobs by hampering their performance. Once, batch job is run in QINTER, it takes up memory pool that is assigned for interactive jobs. It now used *INTERACT memory pool.

If a batch job is building a large file, then it will take up a large piece of memory from *INTERACT memory pool and there by can cause slow down of other interactive jobs.Usually, batch jobs have run priority of 50 and interactive jobs run priority of 20. This is because, interactive jobs should get the result faster and as you know the lesser the run priority number the higher the priority the system assigns.

So, if a batch job is processed in QINTER, by default the run priority would be 20. So, if a batch job running in QINTER is performing higher CPU functions then it can choke the entire system.

Instead, we can achieve better system performance and run the batch job in a different job queue that feeds to QBATCH subsystem. When you as an administrator see the job waiting for other batch jobs to process before, it you can immediately change the job queue and  let this job feed to QBATCH before other jobs.

Now, lets create a job queue named ABATCH in QBATCH subsystem. The QBATCH subsystem has QBATCH job queue associated with it.

CRTJOBQ JOBQ(QGPL/ABATCH) TEXT('Batch job queue for critical batch jobs)

ADDJOBQE SBSD(QBATCH) JOBQ(QGPL/ABATCH) MAXACT(*NOMAX) SEQNBR(xx)

Note :- The xx in SEQNBR is the next sequence number available and must be unique. You can check this by

DSPSBSD SBSD(QBATCH)

Take option 6 for job queue entries. 

Subsystem description:   QBATCH         Status:   ACTIVE                     
                                                                             
 Seq  Job                       Max   ---------Max by Priority----------     
 Nbr  Queue       Library     Active   1   2   3   4   5   6   7   8   9     
  10  QBATCH      QGPL             1   *   *   *   *   *   *   *   *   *     
  20  QS36EVOKE   QGPL        *NOMAX   *   *   *   *   *   *   *   *   *     
  50  QTXTSRCH    QGPL        *NOMAX   *   *   *   *   *   *   *   *   *     

Now, CRTJOBQ command creates the job queue physically and ADDJOBQE add this job queue to the subsystem logically.

Now, the MAXACT set to *NOMAX allows all the jobs that are feed into this job queue to simultaneously be run in QBATCH subsystem. 

This ensures better performance and enables to run all critical batch jobs.