IBM Mainframe Forum Index
Log In
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register


IBM Mainframe Forums -> DB2
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message

Global Moderator

Joined: 28 Aug 2007
Posts: 1737
Location: Tirupur, India

PostPosted: Thu Jul 02, 2020 10:25 pm
Reply with quote

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.

But after reading more detail into it from this link -
when IIPHONORPRIORITY=NO is in effect, "Db2 does not allow system tasks to become eligible for zIIP processing."
Back to top
View user's profile Send private message
Rohit Umarjikar

Global Moderator

Joined: 21 Sep 2010
Posts: 3038
Location: NYC,USA

PostPosted: Thu Jul 02, 2020 10:52 pm
Reply with quote

Only if needs to do more deeper drives on this and related subject.

We converted most of our Cobol-Stored Procedures to Native to get advantage of zIIP processing as WLM set it up that way.
Back to top
View user's profile Send private message

New User

Joined: 06 Mar 2018
Posts: 1
Location: USA

PostPosted: Wed Oct 06, 2021 12:24 am
Reply with quote



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.


Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> DB2


Similar Topics
Topic Forum Replies
No new posts zIIP usage for IIB components Testing & Performance 0
No new posts COBOL DB2 program - zIIP eligible COBOL Programming 7
No new posts Run stats processing on zIIP Engine DB2 9
No new posts Ziip processor for SORT JCL & VSAM 2
Search our Forums:

Back to Top