Re: [Bulk] running batch jobs from QINTER

John:

See embedded remarks below.

Mark S. Waterbury

> On 8/29/2014 9:20 AM, Voris, John wrote:

...(snip)...
The characteristics of Batch work (besides RUNPTY and the *BASE memory pool) is timeslice and PURGE *YES *NO also differentiates them . . . i.e. how much work gets done in a "chunk" .

With the RISC-based PowerPC hardware on the AS/400s, and especially with the much larger real main storage sizes commonly seen in use nowadays, the "time-slice" and "PURGE(*YES)" have little influence on overall performance.

For Batch work, after running for a while, the entire job is usually paged out into disk. When brought back into memory, it has to re-establish where it was in Calcs.

CPF and OS/400 have always been "pure paging" systems. So, unlike early Unix or MVS or z/OS, there is no "swapping" where an entire job's address space is "swapped out to disk". What happens is, if a job goes ":inactive" (e.g. into a "long wait") other jobs might"steal" real memory pages that were formerly occupied by data used by that job, but only if no other real main storage (memory) page frames are available for use. This is just normal virtual memory paging behavior. If any pages are 'dirty" (have been updated) when they are about to be "stolen", then the SLIC automatically ensures they are written back out to disk again before the underlying real memory frame is "stolen" and assigned to some other job's data (pages).

There used to be something called the "PAG" (Process Access Group) that was intended to keep certain job related data together, so it could be more easily paged in again, in case those pages had been "stolen." Note that the pages are only paged in again when (if) they are actually needed (used, referenced) by a job. The PAG was eliminated as of V6R1. (IBM announced the intention to eliminate the PAG in the V5R3 and V5R4 Memo To Users.)

This means that all the open files and Spool-Files of the RPG pgm get re-established, and usually these are "bigger/more" than interactive jobs. Re-establishing the handles to these takes time, is expensive, and once the job is cranking up, it SHOULD get a long timeslice to get a big chunk of work done, and not get Purged out at any little file-wait (since interactive jobs are always waiting for user input, and will be purged out of memory while the job waits on EXFMT ).

With "single-level storage" there is no need to "re-establish" files, file handles, etc. . if that page was "stolen", just page-fault the page so it is loaded back into real main storage again, and the job can continue from that point. If you are running on a machine that is severely storage constrrained, especially with respect to the total size of real main storage available, you might see more "stealing" of pages when jobs go into a "long wait" and then you might notice some delay when that job resumes, while the system pages that stuff back into memory once again.

Note also that you can create "shared pools" of memory in OS/400 or IBM i, and assign different jobs to run in different subsystems with certain pools assigned to those subsystems. If you do this, and the pools you have created are "too small" you can force the system to do extra work, paging data in and out of these artificially constrained main storage pools. Beware.

That is why Batch jobs are batch jobs . . . and the characteristics of the the USER CLASS
DSPCLS CLS(QBATCH) stipulate these differences.

You see this (the CLS) controlling work in DSPSBSD. Use option 7 to see the Display Routing Steps. This is how attributes of the job are assigned when it is initiated.