IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU> wrote on 04/17/2008 01:05:29 AM:
> thanks for fixing the time stamp! The thanks for that one should go to Ralph Sharpe. > I looked at RMF M3, at the storage statistics, in particular the > working set size: > 18:36:30 234 > 18:37:00 19097 (60%delay, of this 27%common, 33% locl, 33% other) > 18:37:30 70784 (57%delay, of this 57% locl, 53% other) > 18:38:00 no delay (capture phase is done), WSS is 72xxx In addition to the page-in delays, they may be delays waiting for page-out I/O to make frames available. > PGIN Rate at 18:37:00 33 for GRS > 18:37:30 50 for GRS, 433 for NDM and 63 for VTAM > 18:38:00 52 for VTAM, 18 for GRS > > From the top of my head, I have no real clue how we can drop the > time the global capture phase takes, well, other than turning off > GRSQ completely (or setting this slip trap: sl set,c=0c4,j=NDM, > a=nodump,e; which probably wouldn't do much good as this is a dump > scheduled by VTAM:-) ) > > That lpar has 8704M real with the local page ds's normally at 10%. > Should IMS ever decide to take a dump, chances are good that it will > be useless as we have to run q=no with these capture times in order > not to hit the TCPIP timeouts. There isn't much you can do other than spend real money to buy more real storage to avoid paging, and spend real money to buy to fastest DASD boxes and attach them to the fastest channels (if you aren't already doing that). There are some things z/OS development could do, the most important of which for your needs would be to move GRSQ processing to occur after system nondispatchabilty has been reset, which might allow you to use q=yes without TCPIP timeouts. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
