The LPAR currently has 19 GB of real storage, quite a bit more than when I started attacking this problem last year.
This observation comes from the gut. Or from the nose. (Is there a single nerve that connects them?): the growth in aux usage is out of proportion to any growth in LPAR usage. The pattern seemed to be that every page data set I added would get filled up to more or less the same percentage within more or less the same time period. So maybe 8 is not enough? What would happen with 16? With 32? I think that something is wrong. . . 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: Tom Marchant <m42tom-ibmm...@yahoo.com> To: IBM-MAIN@LISTSERV.UA.EDU, Date: 03/01/2013 02:46 PM Subject: Re: DFSORT Weirdness Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Fri, 1 Mar 2013 22:43:19 +0100, Vernooij, CP - SPLXM wrote: >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 If I did the arithmetic correctly, Skip has about 28 GB of page space, and it looks like he's using a bit less than half of it. -- Tom Marchant >-----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... ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
