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. Scott ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
