On the zIIP point assume most of DB2 DBM1 in V10 and nearly all in V11 is zIIP-eligible. (And, yes, SMF 30 gives you the actual numbers.)
And thereby hangs another tale... :-) Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Cloud & Systems Performance, IBM +44-7802-245-584 email: [email protected] Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/category/mpt/ From: Neil Duffee <[email protected]> To: [email protected] Date: 02/05/2016 20:20 Subject: Re: WLM issue with a proposed solution Sent by: IBM Mainframe Discussion List <[email protected]> Caveat: as a daily digester, responses are implicitly delayed... Tracy: among other good advice you got, I'll emphasize that the Importance for your Databases (DB2, etc) must be higher than your Applications (Cics, etc) to avoid [some of] these time-out/deadlock scenarios. I strongly suggest reading the WLM RedBook. [1] It has specific chapters on Cics, DB2, etc. Secondly, I'd avoid strangling WLM but, rather, tend to suggest loosening the rules. If WLM has this leeway, it is more able to balance the workload and, after all, that's the whole point of a WorkLoad Manager. I use the concept where the rules are, "what can you tolerate when things go south?" vs. "how do I want things to perform normally?" [2] When there's sufficient resources, all your classes will over-perform. By bumping up the Cics minimum you're forcing WLM to deprecate others of the same Importance (or less; such as DB2 from your message). Rather, by loosening the restrictions, DB2 is allowed to breath some. In fact, you'll see below [5] that our Online-Hi is 75% in 1 second but our typical Cics response is 0.3 seconds and 0.8 on bad days. Third, you might consider removing your long-running Cics transactions to a different Transaction group because they can skew the accumulated WLM results. Below [5], you'll see I have a group LONGRUN that encompasses monitoring tasks which, essentially, never end; meaning *bad* response times. Instead, because we cycle our production Cics each workday, they're shunted to the ONLINELG service class with 75% in 1 second so they don't pollute the ONLINEHI stats. Lastly, tho' I believe it is the default, make sure you have I/O Priority management [3] set to YES. It will encourage WLM to promote lower classed work such as Batch to a higher DP (temporarily) to clear the blockage. It will repeat the process if necessary and results can be seen in the RMF reporting [4] under LCK. (LCK or ENQ?) The Dynamic alias tuning management will let WLM manage your hyper-volSer UCB allocations as well. (can't remember the real name at the moment.) A zIIP was suggested but, unless you're doing Java in Cics, it won't *directly* help your Cics/DB2 problems. However, depending on your z/OS & DB2, more things are becoming zIIP-able ie. tcp/ip, system XML services, DRDA, etc. Plus, it's not included in your 4hr cap or licencing. ps. the DB2 velocity goal can be a small, red herring. It applies to activities that are not assigned to specific enclaves such as Dasd I/O & lock management. Your Batch work will be in a Batch class enclave (SRB) within DB2 and be dispatched as such. This is one of the places where you will see promotion by WLM occur due to enqueues/locks. [1] System Programmer’s Guide to: Workload Manager SG24-6472-03 [2] The latter is from the old Dispatching Priority mentality that needs to be dropped. Instead, DP is employed by WLM to achieve the minimum goals you have defined. [3] WLM samples: Service Coefficient/Service Definition Options: I/O priority management . . . . . . . . YES Dynamic alias tuning management . . . . YES [4] RMF reporting --PROMOTED-- BLK 0.062 ENQ 52.084 CRM 21.455 LCK 654.084 SUP 0.000 [5] WLM samples: Transaction Name Group LONGRUN - Long running CICS transactions Qualifier Starting name position Description --------- -------- -------------------------------- B11R BETA93 C* CICS supplied transactions OSEC Omegamon OSRV Omegamon -from the Cics monitor: CSSY, CSTP, CSNC, CSZI, CEX2, CSHQ, CSNE, OSRV, & OSEC all have elapsed/response times in days Subsystem Type CICS - CICS transactions Classification: Default service class is ONLINELO Default report class is CICS Qualifier Qualifier Starting Service # type name position Class - ---------- -------------- --------- -------- 1 SIG CICSPRD1 ONLINEHI 2 . TNG . LONGRUN ONLINELG Service Class ONLINELG - Long running transactions Base goal: CPU Critical = NO I/O Priority Group = NORMAL # Duration Imp Goal description - --------- - -------------------------------- 1 3 50% complete within 00:00:01.000 Service Class ONLINEHI - High priority production Base goal: CPU Critical = NO I/O Priority Group = NORMAL # Duration Imp Goal description - --------- - -------------------------------- 1 2 75% complete within 00:00:01.000 --------> signature = 8 lines follows <-------- Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee “How *do* you plan for something like that?” Guardian Bob, Reboot “For every action, there is an equal and opposite criticism.” “Systems Programming: Guilty, until proven innocent” John Norgauer 2004 "Schrodinger's backup: The condition of any backup is unknown until a restore is attempted." John McKown 2015 -----Original Message----- From: Tracy Adams [mailto:[email protected]] Sent: April 29, 2016 08:55 Subject: Re: WLM issue with a proposed solution Thank you all for chiming in! Yeah the bottom line... figure out why those sub second transactions get stalled! Hard to tune your way out of a locking condition :-) I will check out the SYSSTC actual velocity... that is a good bench mark to what my max achievable would be around. Happy Friday Martin, sounds like you have written the book on this! Gotta go read about resource groups. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Scott Chapman Sent: Friday, April 29, 2016 6:40 AM To: [email protected] Subject: Re: WLM issue with a proposed solution >If your batch jobs are running Dicretionary at a DP lower than CICS, it >is very unlikely that they are causing significant CICS delays. True from a CPU perspective. But the batch jobs could be locking resources in DB2 that are delaying the CICS transactions. And if the batch jobs holding those locks are progressing very slowly due to running in discretionary when there's little CPU available, the locks may persist for an extended period of time, elongating CICS transaction response time. Or I saw a similar situation once where some batch queries exhausted the RID pool, which caused sub-second CICS transactions to start taking over 60 seconds. That's fortunately harder to do on the later versions of DB2. In short, while adjusting the goals very well may be in order, I'd be inclined to first look into the apparently unusually long running CICS transactions to identify why those particular transactions are taking a long time. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
