running batch jobs from QINTER

"Never a good idea to run batch jobs in QINTER - the characteristics of the *INTER machine pool are that the jobs get a lot more priority than they should for batch work."

and

"The bigger consideration is what memory the job is using. Running in QINTER
it most likely be using shared pool *INTERACT. When run from QUSRWRK it
will use *BASE (all as defaults from IBM). I don't know how intensive this
job gets but is sounds like a better fit for QUSRWRK that QINTER."

-==============================================-

FYI: How is a batch job in QBATCH different than QINTER ?
(Many people do not know. And just for a complete explanation.)

Both of the remarks above are true.
And there are other factors that make Batch work as batch . . . .

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" .

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.
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 ). 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.

- John Voris