Why Are My Batch Jobs Running at Priority 20?

I’m looking at my work management setup on one of my System i boxes. I noticed that all the jobs in my QBATCH subsystem are executing at run priority 20, the same priority as my interactive jobs. What’s going on, here, and how do I reset my batch jobs to run priority 50 where they belong?

–Henry

In three steps, here’s what I think is happening and how you can change your batch run priorities.

Step 1: Your job and its routing data

Each submitted job has its own routing data. Job routing data can easily be viewed through the Routing Data (RTGDTA) parameter in the Submit Job (SBMJOB) command, like this one.

SBMJOB CMD(command) JOBQ(QBATCH) RTGDTA(QCMDB)

QCMDB is the default RTGDTA value for the SBMJOB command. There are many possible RTGDTA values your jobs can use. The most commonly used values are QCMDB and QCMDI, which are used by many subsystems to execute job commands through the CL QCMD command processor job.

The key point is that each subsystem uses job routing data to determine job settings (including run priority) for its submitted jobs.

Step 2: Your subsystem’s routing entry

Before a subsystem starts running a newly submitted job, it uses the job’s routing data to check its routing entries to determine what run time parameters the incoming job should have. To display the routing entries for your QBATCH subsystem, enter the following Display Subsystem Description (DSPSBSD) command.

DSPSBSD SBS(QBATCH)

Take option 7, Routing entries, and you’ll see a screen similar to this one. These are the routing entries assigned to my QBATCH subsystem.

Each routing entry has a compare value associated with it. The operating system matches the incoming job’s routing data with the compare value on its subsystem routing entries to determine which routing entry to use when running the job. If the job’s routing data doesn’t match the compare data in any of the subsystem’s routing entries, it uses the routing entry with a compare value of *ANY (Routing entry 9999, in this case).

So in this example if my RTGDTA parameter equaled QCMDI or QCMDB, the subsystem will use the routing entry at sequence number 9999 (*ANY) to retrieve the job’s routing data. If I tab down to sequence number 9999 and place a ‘5’=Display in front of it, I’ll see that the following routing parameters will be assigned to my job.

The Program (PGM) parameter tells the operating system which program to use when processing the submitted commands in the job. The Maximum active routing steps tells i OS how many routing steps (jobs) can be active at the same time through this entry. The Storage Pool Identifier (POOLID) tells i OS which subsystem storage pool to use to provide memory for the job. And the Thread resources affinity (THDRSCAFN) parameter provides information about how threads work in this job.

Notice, there is no run priority parameter in this routing entry. That’s where the Class (CLS) parameter comes in. This routing entry points to the specific name and library of an operating system class object that submitted jobs matching this routing entry will use for their runtime parameters. In this example, the *ANY routing entry uses the QBATCH class in the QSYS library.

Step 3: The Class Object

Since my *ANY routing entry specifies that it will be using the QGPL/QBATCH class object, the operating system will retrieve the job’s runtime environment parameters from that object. To view these parameters, I can run the following Display Class (DSPCLS) command.

DSPCLS CLS(QGPL/QBATCH)

And I’ll get a display that looks like this.

And right there is the run priority that my subsystem will assign the submitted job to run at. In my case, it’s priority 50, which is the standard batch job priority. I bet if you look at the Class object your jobs are using in your matching routing entry, your object will specify the jobs run at priority 20. And that’s where your problem will be.

If you find this is the issue, you can change the run time priority for your QBATCH jobs in one of the following ways:

1. Change your subsystem routing entry to use a different class object for runtime priorities, one that specifies a higher run priority. Do this by running the Change Routing Entry (CHGRTGE) command to change the name of the class object that your routing entry is pointing at.
2. Change the run priority in the Class object identified in your routing entry by running the Change Class (CHGCLS) command. Be careful doing this, however, because this class may be used in other subsystem routing entries on your system.
3. Make a copy of the class object you’re using for the routing entry, change the run priority setting in the new object by using CHGCLS, and then use the CHGRTGE command to point the subsystem routing entry to the new class object. This way, the only changes you’ll make will be to the run priority and it will only affect your designated routing entry.

So if you follow these simple steps, you should easily be able to figure out where your jobs are getting their low run priority and change it.

HTH

–Joe

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot