I think we all have similar environments, differing in the details. >From what I read from Anne and from you, looks to me like an undersized paging configuration. You don't state the size of the LPARs memory, but if the system can make your page configuration leap from 0 to 55%, this sounds to me like an unbalance between memory size and page configuration size. See my previous statement for large, solid page configurations with growing LPAR size.s
Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Friday, March 01, 2013 22:26 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFSORT Weirdness I'm following this thread with rapt attention. We have what I believe to be the same problem. I never before associated it with DASD architecture nor with a particular product like DFSORT. Our development system gets IPLed every Sunday around 02:00. Throughout Sunday and into Monday, local page usage stays at 0%. Sometime Monday it rises, not creeping but leaping. Now on Friday afternoon to it looks like this. All data sets are the same size at 5,008 cylinders, half of a 3390-9. LOCAL 55% OK 1208 SYS1.PAGELOC0 LOCAL 34% OK 1208 SYS1.PAGELOC1 LOCAL 51% OK 1308 SYS1.PAGELOC2 LOCAL 32% OK 1308 SYS1.PAGELOC3 LOCAL 53% OK 1207 SYS1.PAGELOC4 LOCAL 37% OK 1207 SYS1.PAGELOC5 LOCAL 53% OK 1218 SYS1.PAGELOC6 LOCAL 35% OK 1218 SYS1.PAGELOC7 I don't know when it started, but quite some time ago, our DB2/CICS folks complained that they could not take console dumps because of aux shortage. We since added some of these page data sets and several GB of memory to this LPAR. We seem to stay under the DUMP limit, but usage still looks unreasonably high. I can remember (but not pinpoint) when usage stayed very low all week long. We take mostly defaults for DFSORT. Those we override do not appear storage related. Not sure how to correlate with 'DS8' terminology, but these volumes respond to DS QD with SCUTYPE DEVTYPE 2107951 2107900 I would be most curious to hear from anyone who has a similar environment but does *not* see a problem with page data set usage... . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: "Adams, Anne (DTI)" <anne.ad...@state.de.us> To: IBM-MAIN@LISTSERV.UA.EDU, Date: 03/01/2013 06:58 AM Subject: Re: DFSORT Weirdness Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> Perhaps they don't have all the information. This occurs even when AUX subsystem is at 0%. The first time it occurred, the AUX subsystem was indeed at greater than 50%, and so the current explanation fits. However, the problem immediately repeated itself after an IPL when the AUX subsystem stands empty (to be fair, it's about 36 hours after the IPL, but the AUX subsystem is still empty). So the explanation doesn't quite make sense, but perhaps I'm missing something. Anne R. Adams DTI, Systems Engineering State of Delaware -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Betten Sent: Friday, March 01, 2013 9:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFSORT Weirdness I've been working on the ETR with our L2 support and waiting for some doc to confirm my assumptions. But I figure I better update this thread since so many seem to be speculating. I believe what happened is this. One of the things DFSORT looks at is the values returned from SYSEVENT STGTEST. Some time back, STGTEST was updated so that the B and C values returned took into account available aux slots. Here is the text from APAR OA20116 Additionally the logic in IRAEVREQ ensures that the value returned in words 2 and 3 do not drive the system into an auxiliary storage shortage. The value returned in words 2 and 3 will only fill the AUX subsystem up to 50%. Examples: If the AUX subsystem is filled by 25% and the return value 1 contains 1000 frames. Then the return value 2 and 3 are set to 1000 frames + 25% of the AUX slots. >From the RMF I looked at, it appears when the page data sets were moved to the new dasd, they were also increased. This led to an increase in the value returned from STGTEST which led to DFSORT allocating more storage for sorting in memory. If you change the DFSORT default to EXPOLD=0, DFSORT will only factor in the A-value returned from STGTEST making it less likely to cause page stealing from other workloads. But again, I want to stress that we're still waiting for additional doc to verify all this so I don't want to encourage further speculation. I will update this thread when we confirm things. Have a nice day, Dave Betten DFSMS Performance Engineer IBM Corporation email: bet...@us.ibm.com DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/ IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> wrote on 03/01/2013 07:23:30 AM: > From: "Adams, Anne (DTI)" <anne.ad...@state.de.us> > To: IBM-MAIN@listserv.ua.edu, > Date: 03/01/2013 08:23 AM > Subject: Re: DFSORT Weirdness > Sent by: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> > > The LPAR has 14GB of memory and the six page data sets have (yikes!) > five different sizes (1000, 1000, 1500, 2000, 2500, and 3000 > cylinders). Apparently the statement, we didn't change anything, > really meant, we didn't change anything that should affect you. > > Anne R. Adams > DTI, Systems Engineering > State of Delaware > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU ] > On Behalf Of Vernooij, CP - SPLXM > Sent: Friday, March 01, 2013 2:17 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFSORT Weirdness > > Anne, > > Just for the picture: how much memory do you have in your LPAR and > what is the total size of the page datasets.? > > Kees. > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU ] > On Behalf Of Adams, Anne (DTI) > Sent: Thursday, February 28, 2013 18:29 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFSORT Weirdness > > Ok - this is EXACTLY what we're seeing now. The one issue is that when > the page data sets fill up, they never get emptied and we end up > having to add new ones. What do people do? We can't IPL every week or > go on adding page datasets indefinitely. > > Anne R. Adams > DTI, Systems Engineering > (302) 298 - 3196 > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU ] > On Behalf Of Vernooij, CP - SPLXM > Sent: Thursday, February 28, 2013 10:59 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFSORT Weirdness > > I have seen DB2 utilities with large sorts (reorgs of partitioned > table spaces, which does a lot in parallel), that consumed 6 - 8 GB > memory of the 16GB in the LPAR. Nobody was really harmed by it, only > you could see RMS paging out heavily old stuff to make room for the > utilty. On these moments, you should have a page configuration ready > for these page outs. There was no heavy page ins, so performance was > not harmed. This is real memory management of modern, large machines, > which should not be undervalued (correct English?) > > Kees. > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU ] > On Behalf Of Elardus Engelbrecht > Sent: Thursday, February 28, 2013 16:51 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFSORT Weirdness > > Kees Vernooij wrote: > > >Again: the fact that DFsort acts differently on the new device > could be caused by CFW. With CFW dfsort could decide to use SORTWKs, > without CFW DFSORT could decide that this is too slow and use memory. > > Very true! Will the DFSORT gurus answer on your statement this or next > month? ;-D > > I'm watching this thread, because my own DFSORT + ICETOOL jobs are > grabbing and eating everything - CPU, Inits, Memory and DASD space, > name it, like there is no tomorrow... ;-D > > Groete / Greetings > Elardus Engelbrecht > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ******************************************************** > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee only. > If you are not the addressee, you are notified that no part of the > e-mail or any attachment may be disclosed, copied or distributed, and > that any other action related to this e-mail or attachment is strictly > prohibited, and may be unlawful. If you have received this e-mail by > error, please notify the sender immediately by return e-mail, and > delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/ or > its employees shall not be liable for the incorrect or incomplete > transmission of this e-mail or any attachments, nor responsible for > any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > ******************************************************** > > > > ---------------------------------------------------------------------- > 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 > ******************************************************** > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee only. > If you are not the addressee, you are notified that no part of the > e-mail or any attachment may be disclosed, copied or distributed, and > that any other action related to this e-mail or attachment is strictly > prohibited, and may be unlawful. If you have received this e-mail by > error, please notify the sender immediately by return e-mail, and > delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/ or > its employees shall not be liable for the incorrect or incomplete > transmission of this e-mail or any attachments, nor responsible for > any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > ******************************************************** > > > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
