Re: Job system values

Hello Rob,

again, I'm missing the question in your message. :-)


Am 07.02.2020 um 18:30 schrieb Rob Berendt <rob@xxxxxxxxx>:

I suspect some of my job system values have been carried over from v1.2 on our initial B model.

Wow, that's a long time. :-) I thought it to be good habit to review system values when upgrading to a newer release.

Got some recommendations from IBM Lab systems

These can just reflect some general assumptions. After I waded through all the help texts for system values years ago, I decided to only adjust QTOTJOB and QACTJOB to a rounded-up value of jobs visible in WRKACTJOB. I noticed a certain increase of IPL speed from that change.

If you have a very busy system which spawns new jobs in parallel and in fast succession, I'd recommend to increase QADLACTJ and QADLTOTJ to have the system allocate a bigger pool of "empty" slots for new jobs with each internal derived need to increase job count.

The following returns 73,068 total jobs:
SELECT COUNT(*) FROM TABLE(QSYS2.JOB_INFO(JOB_USER_FILTER => '*ALL')) X;

Check if this is a true number of jobs or "dead" ones which are kept in the system because of associated spool files. Having many such "dead" jobs is said by IBM "to affect performance", because of a resulting huge job table which is frequently gnawed through by the system.

Immediate Solution: Get rid of unneeded spool output, change QSPLFACN to *DETACH. Read the help text to understand what your change does.

Afterwards, look at DSPJOBTBL. If you feel that the all entries value is *much* higher than the entries in use value, I'd recommend to note down the current value of CPRJOBTBL, do a a CHGIPLA CPRJOBTBL(*NEXT) and IPL. Afterwards restore CPRJOBTBL to what was in there before. I ususally put in *ABNORMAL. Because an abnormal IPL is always taking longer, I can make the system clean up at that point in time, anyway. Your mileage may vary.

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc