I'm sorry, but the following will not answer your immediate question about how 
to determine if a zIIP is getting maxed out. I don't know the answer to your 
specific question. These comments pertain more to a longer view of performance 
monitoring.   

In the interim though, you can always try to answer an important question when 
it comes to fighting performance related fires - What changed?  

Almost all of the fires I've worked on at various shops, some with many SLAs in 
place, were directly related to application/system changes where the 
anticipated performance impact was either underestimated, not well understood, 
or never evaluated. If your shop is big on change management that includes; 
applications, database, sysprogs, security, network, capacity planning and 
workload management, etc. then you may have available a decent record of what 
actually changed, when they took effect, and eventually how those changes 
relate to different workloads on your system.  

What kind of performance monitoring/reporting tools are available?  You may 
want to get extremely familiar with some of the daily reports and resource 
utilization values for critical workloads. The idea is to get to know your 
system, first from 50,000', then from 10,000', then 2,000' etc., until you get 
granular enough to be pointing your finger at a Natural program that has gone 
off the rails, or pig CICS transaction, or whatever. 

Until you know the performance characteristics of each workload on the system, 
how they relate, and what's changed recently, it would be pretty tough to make 
performance and tuning recommendations (of any kind), and expect positive 
results.  

Identifying and cultivating useful working relationships with SME-type 
individuals in different departments can also go a long way, then you will have 
more/less confidence in what you're hearing in the midst of some frenzied 
performance event. 

Regarding Adabas, three simple things to keep an eye on are buffer pool 
efficiency, format translations and format overwrites. These are useful CPU 
related metrics because they are usually actionable. DBAs can make adjustments 
and/or have application developers make changes to reduce CPU utilization (with 
GP and potentially zIIP impacts).  Your DBAs can execute very low overhead 
dstat commands to track these metrics at whatever interval is appropriate.     

If you aren't already familiar with them, ABCs of Systems Programming Vol 11 is 
good, as well as the z/OS RMF User's Guide and Report Analysis manuals.      

HTH, 
Mike 
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of zMan
Sent: Thursday, May 17, 2018 8:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZIIP engine utilization

Not trying to be a jerk, but you're playing with fire here. Call Cheryl Watson 
and pay for some help. Take some classes. Go to SHARE and learn. If management 
is too cheap to pay for the expertise, update your resume and go find a real 
job.

I'd explain it to them this way: If the lead engineer at one of the nuclear 
power plants retired and nobody knew how to do what he'd been doing, would they 
suggest asking for advice on a list?

Not that folks here will deliberately lead you astray, of course. But 
performance work is too highly skilled to fake your way through it: that's just 
asking for a disaster.

On Thu, May 17, 2018 at 7:40 PM, Jesse Lynch <jesse.ly...@state.mn.us>
wrote:

> Our senior performance person has retired.  We have a ZIIP on a Z13s.  
> One of our customers is using Adabase and some
> product to make maximum use of the Ziip.   They feel that the Ziip has
> maxed out from I think messages they are getting from their product 
> and response is slower.  I am getting this third hand so don't know a 
> lot of details.  Can you point me
> to the best place to see if Ziip is getting maxed out.   I am looking at
> the RMF Batch CPU report.  I see some % usages for the IIP.  Also see 
> that one Lpar (not even sure which Lpar yet they are talking about) 
> seems to say its WLM capped.
> I have looked at the Lpar definitions on the HMC and nothing jumps out 
> at me.
>
> If you have any comments I would appreciate it.  Thanks.  Jess
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
zMan -- "I've got a mainframe and I'm not afraid to use it"

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to