Problem solve Get help with specific problems with your technologies, process and projects.

Take control of the jobq

Learn how to submit jobs to a multi-stream job queue or run several jobs in parallel.

There are times when you'd like to submit jobs to a multi-stream job queue or run several jobs in parallel. How do you do that? In this tip originally posted in the .hmzhabFzGFj.0@.ee84636!viewtype=&skip=&expand=> Programmer Discussion Forum, member Carolyn Kelly says it's a simple matter of changing some parameters.

If you look at the parameters for the SBMJOB command you'll find that by default, the jobq the job is submitted to and the priority of the job in the jobq are based on the job description in the user profile. You can override the default parameters at submit time or you can change the job description of the user profile.

To run batch jobs in a parallel mode, change the jobq to allow more than one active job. Be sure, however, that the jobq you change is NOT the standard jobq that your jobs are running through -- otherwise you could have a real mess on your hands.

Your best bet is to create a new jobq and add it to your batch subsystem -- call it QBATCH2 or something like that.

OS/400 has many ways of controlling how many jobs run in a subsystem. MAX ACTIVE for a *JOBQ is just one of them. You can further define this by using "Max by priority" on your job queue entries. Using this you can run certain priority jobs concurrently while running other priority jobs serially.

For example:

Job 1 to JOBQ QBATCH job priority 3

Job 2 to JOBQ QBATCH job priority 3

Job 3 to JOBQ QBATCH job priority 4

Job 4 to JOBQ QBATCH job priority 4

Job 5 to JOBQ QBATCH job priority 4

Job 6 to JOBQ QBATCH job priority 4

Max active for the QBATCH job queue entry = 4

Max active for Priority 3 = 1

Max active for Priority 4 = 4

                           Display Job Queue Entries

                                                             System:   S02

 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             4   *   *   1   4   *   *   *   *   *  

* = *NOMAX, which means jobs at this priority will execute immediately if there isn't more than the MAX Active for that job queue entry.

Job 1 starts, but Job 2 won't start until Job 1 finishes (Max priority for Priority 3 = 1. In essence, single threaded.)

Jobs 3, 4 & 5 start because MAX Active for priority 4 = 4. However, Job 6 won't start because max jobs for the entire queue is only 4.

Job 6 will start running when either Job 1 and Job 2 finish or one of the following jobs finish (Job 3, 4 or 5). Again, that's because you can never have more that 4 active at a time.


  • Performance issue in the batch job execution
    What do you do if you have a CL program that submits (SBMJOB command) a batch job in a user-defined subsystem but there's a performance issue in the batch job execution? Site expert Tim Granatir has a few possible solutions.
  • Who's movin' my batch jobs?
    A member asks, "Is there any way on the iSeries to see who is moving batch jobs to different job queues? Someone keeps moving jobs out of one job queue and putting them in other job queues, and that is creating havoc because certain jobs can't run against others." The solution is simple, says site expert Richard Belles.
  • Debug batch job with STRISDB
    Did you know that you can use the interactive source debugger to debug RPG programs submitted in batch jobs? Here are the steps.

Dig Deeper on iSeries CL programming