Joined: 28 Aug 2007 Posts: 1737 Location: Tirupur, India
Just thought of sharing an year old article, but came across only today.
At first glace about IIPHONORPRIORITY option, it might be a no brainer to set it as NO.
IIPHONORPRIORITY is a parameter in the IEAOPTxx member of the z/OS data set called SYS1.PARMLIB. The value of the parameter can be set to NO or YES. Essentially, those two settings have the following meanings:
YES - Honor the priority of zIIP-eligible tasks (per the z/OS LPAR's workload manager policy), so that in the event that such a task is ready for dispatch and the LPAR's zIIP engines are busy, allow the task to be dispatched to a general-purpose engine so that wait-for-dispatch time for the task will not be too high.
NO - Regardless of the priority of zIIP-eligible tasks, limit the processing of such tasks to zIIP engines. If a zIIP-eligible task is ready for dispatch and the LPAR's zIIP engines are busy, require that the task wait until a zIIP engine becomes available.
We have just set the IIPHONORPRIORITY=NO for our production system, because we wanted to stop the zIIP eligable work going to GP's (and thereby driving up our 4HRA MSUs), when we run the weekly RUNSTATS and the DB2 REORGS.
This caused an additional hour elapsed time running our DB2 RUNSTATS and no additional elapsed time for the DB2 REORGS. We found that the REORGS did not use the zIIP engine over 30%, while the RUNSTATS maxed it out for about 1 1/2 hours.
We're happy with this result as we are looking to reduce 4HRA MSU for software license cost reduction on our small operation.
The REORGS and RUNSTATS run on weekends when no additional work is scheduled to run (on Sunday morning). We have plenty of time to complete that work. (It should be completed by Monday start of business (06:00 am).
We're running z/OS 2.3, with DB2 v12 on a z14ZR1 with 3 GPs and one zIIP.