Admin Alert: When Batch Meets Interactive

November 19, 2008 Joe Hertvik

I was recently reviewing i5/OS performance data when I spotted an analysis message that said I should Separate batch from interactive jobs. This prompted me to investigate where batch jobs can intersect with interactive jobs and why it’s bad to run the two of them together in the same subsystem. Here’s what I discovered and what you can do if your batch work starts contaminating your interactive subsystem.

Where the Problem Develops

To ensure that critical batch jobs are not held up in a single threaded job queue, some administrators and programmers routinely submit batch jobs that need immediate execution to the interactive subsystem, QINTER. Batch jobs can be submitted from applications, menus, Windows-based interfaces, the i5/OS job scheduler, the Advanced Job scheduler, or through a third-party job scheduler, such as Help/Systems’ Robot/SCHEDULE. Each submission technique generally allows you to submit jobs to any system job queue, including the QINTER job queue.

From a system viewpoint, there really isn’t any reason that you can’t submit batch work to an interactive subsystem. A job queue is a job queue and the QINTER subsystem does not discriminate between batch jobs and interactive jobs. It will gladly accept and run both types of jobs.

Good Technique or Bad Technique?

But just because you can do something doesn’t mean that you should do it. Should you run batch jobs in the QINTER interactive subsystem? My answer is an emphatic NO!!!! Here’s why.

First, batch jobs can degrade QINTER performance by stealing storage pool memory and activity levels away from interactive jobs using the *INTERACT storage pool. *INTERACT is the default storage pool that QINTER uses when you segment different subsystems to use different storage pools. If a batch job is rebuilding a large index for example, it can cause a lot of memory paging that may slow down performance for interactive users. An active batch job running in QINTER will also consume a storage pool activity level, which can be better used by an interactive job.

Second, batch jobs running in QINTER execute with the same run priority as interactive jobs. As you know, all system jobs are assigned run priorities from 0-99. The lower the run priority number, the higher priority the system assigns the job. When a batch job runs in its regular QBATCH subsystem, the job is assigned a run priority of 50. By system design, interactive jobs run at priority 20 in QINTER so that they aren’t slowed down by long running and disk intensive batch and server work. In mixed workload environments, i5/OS provides a definite advantage to interactive users who need quick response time.

However, if you submit batch jobs to the QINTER subsystem, i5/OS will execute those jobs under run priority 20. This means that a batch job running in QINTER will get the same amount of resources and attention from i5/OS that an interactive job gets. If a QINTER batch job is performing some high CPU function, such as reorganizing a large sale files, that job can choke your entire system because a high CPU process is running at a high system priority.

This isn’t the optimum way to maximize system performance.

The Right Way To Run High-Priority Batch Jobs

So outside of submitting batch jobs to QINTER, what can you do if you want to ensure that a critical batch job always runs the instant that you submit it to the system? Here are a couple of ideas that are much less destructive than submitting the job to QINTER.

1. Create a separate job queue in QBATCH just for immediate batch work–By default, the QBATCH job queue is single threaded, meaning that the QBATCH subsystem will only run one job at a time from that job queue. For batch jobs that must always run immediately after they are submitted to the system, you can set up a separate QBATCH job queue called IMMEDIATE. When set up correctly, QBATCH will immediately accept and run any amount of work that is submitted to IMMEDIATE. To create the IMMEDIATE job queue and to assign it to the QBATCH subsystem, run the following Create Job Queue (CRTJOBQ) and Add Job Queue Entry (ADDJOBQE) commands.

CRTJOBQ JOBQ(QGPL/IMMEDIATE) TEXT('Batch job queue for immediate jobs)

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

Note the xx in the Sequence Number (SEQNBR) parameter of the ADDJOBQE command should be filled in with the next available sequence number for QBATCH’s job queue entries. To view QBATCH’s job queue entries, run the Display Subsystem Description command (DSPSBSD) for QBATCH, like this:

DSPSBSD SBSD(QBATCH)

Select option 6, Job Queue Entries from the Display Subsystem Description screen. Here, you can determine the next available sequence number to assign to the IMMEDIATE job queue entry. Sequence numbers must be unique.

The CRTJOBQ command physically creates the IMMEDIATE job queue on your system. The ADDJOBQE command logically attaches IMMEDIATE to the QBATCH subsystem, so that QBATCH will run all jobs that are submitted to IMMEDIATE. The key to using IMMEDIATE for instantly running critical jobs is to set its Maximum Active Jobs parameter (MAXACT) to *NOMAX. With MAXACT equal to *NOMAX, QBATCH will accept and simultaneously run every job that is submitted to IMMEDIATE. Unlike the single-threaded QBATCH job queue, there is no limit to the number of batch jobs that QBATCH will simultaneously run from the IMMEDIATE job queue.

For more information on adding job queue entries to a subsystem, see my previous articles on Better Subsystem Throughput Via Multiple Job Queues, Part One and Part Two.

Once created, you can reprogram your system to always submit urgent batch work to IMMEDIATE, instead of QINTER.

2. If you only have one or two batch jobs that must always run immediately, consider running these jobs in the QSYSWRK subsystem–QSYSWRK is a special IBM subsystem that is used to run i5/OS server jobs, including many of the system’s TCP/IP servers. If you code your system to submit immediate batch jobs to the QSYS/QSYSNOMAX job queue, those jobs will automatically start running in QSYSWRK at priority 50. While I can’t recommend running tons of batch jobs in QSYSWRK, it does come in handy for those one or two oddball batch jobs that you need to run as soon as they enter the system. For more information on submitting jobs to QSYSNOMAX, see my earlier article on the Hidden Secrets of the Submit Job Command.

About Our Testing Environment

Configurations described in this article were tested on an i5 550 box running i5/OS V5R4. Many of the commands are also available in earlier versions of the operating system running on iSeries or AS/400 machines. If a command is present in earlier versions of the i5/OS or OS/400 operating systems, you may notice some variations in the pre-V5R4 copies of these commands. These differences may be due to command improvements that have occurred from release to release.