Kees, In my case, and during a data migration event, we were transitioning to the new aux. subsystem. from the old with delete/drain and it appeared as if your below explanation applies. It appeared that the aux. subsystem slot usage, on whole, was artificially inflated. This was relatively early in the transition process and on a DB2 related LPAR, I didn't look at the others, about 20, to see effects, just don't have the time but I'm interested. I have also seen, as Barbara states, what looks like creep on DB2 LPAR's where it also appears that aux. creeps over time on infrequently IPL'd DB2 related LPARs. Again, I just don't have time to drill down but I may try to find some to look at this more closely. I appreciate IBM's time, Jim's, in explaining some of the behavior on behalf of STGTEST which kind of jogged the memory a bit in remembering this. It only happened a few weeks ago, so much goes on but so little time to handle...
________________________________ From: "Vernooij, CP - SPLXM" <[email protected]> To: [email protected] Sent: Monday, March 4, 2013 3:44 AM Subject: Re: DFSORT Weirdness Yes! Page dataset utilization is not what you expect (i.s.o. saying unreliable) if you execute a series of PAGEDEL/PAGEADDs. I found out 1 or 2 years ago and the explanation from IBM was (if I remember correctly), that ASMVT slots are being reused/manipulated etc. in such a way, that pages look to remain in the old pagedataset but are in fact pointed through to the new one. You don't see this after a pagedel, but if you do a pageadd and the same slot is reused for the new pagedataset, these pointers obscure the metrics reported for this pagedataset. Like: add a new pagedataset and it is immediately full for 20%. So, were the page datasets moved with pagedel/pageadd? Then the utilization figures should be seen in a completely different light. However, not the page rates of course. Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Patrick Falcone Sent: Monday, March 04, 2013 03:09 To: [email protected] Subject: Re: DFSORT Weirdness Hmm...I've been following this as well. So I'm wondering what affect dynamically cutting over the disk subsystem by delete/draining from old aux. while adding new aux. might have on STGTEST, prior to the IPL to cleanup/cutover. I saw some strangeness during this type cutover on a DB2 LPAR where aux. took a jump, aux. datasets were very uneven in slot allocation and we were facing an aux. storage shortage. This could have been WAD but we almost painted ourselves into a corner with this one. I'm wondering how STGTEST looks at a delete/drain status of an aux. storage volume in his scheme of things. Thanks for your input Jim. ________________________________ From: Jim Mulder <[email protected]> To: [email protected] Sent: Sunday, March 3, 2013 4:19 PM Subject: Re: DFSORT Weirdness > Yes Jim, that pretty much sums it up. We essentially plugged in a new > disk drive and suddenly DFSORT didn't work the way it used to. > Despite everything everyone says, something else is influencing > DFSORT's decisions on how much storage to use and where it's going to > get it. We do know that if we reconfigure our page datasets to be of > uniform size, we get different results (different amount of memory > being used, different amount of memory objects being used for > work) even if the total amount of slots doesn't change. I cannot > believe that the speed of the drives and the availability of DASD Fast > Write, Cache Fast Write, and even PAVs aren't playing some part. I have reviewed your PMR, and I would suggest that most effective way to continue the investigation would be to work with DFSORT support via your PMR by providing the SORTDIAG data they have requested, from both the original page data set configuration and the the new page data set configuration. The RMF data provided in your PMR suggests that your old page data set configuration provided 4218MB of local space, and your new page data set provided 9140MB of local space. This change could have a direct effect on word 2 of the results returned by STGTEST, which in turn has a direct effect on the DFSORT storage decisions. This remains by far the most likely explanation for the change in DFSORT behavior. The STGTEST Sysevent does not know anything about things like "the speed of the drives and the availability of DASD Fast Write, Cache Fast Write, and even PAVs", so those things cannot directly the results returned by STGTEST. To the extent that those things might reduce the elapsed time needed for other jobs and processes in the system, they could possibly affect real and aux storage occupancy for other things in your workload, and this could indirectly affect the things that STGTEST does look at (like available real storage, UIC buckets, available aux storage), and thus indirectly affect the results of STGTEST. But those would be second order effects, while the total amount of available local aux space is a first order effect. With regard to your assertion that "We do know that if we reconfigure our page datasets to be of uniform size, we get different results (different amount of memory being used, different amount of memory objects being used for work) even if the total amount of slots doesn't change.", I have not seen any data in your PMR to support that assertion. STGTEST does not know anything about the sizes of individual page data sets, so that cannot figure directly into its results. While the size distribution could affect paging performance (not paging capacity) and thus indirectly storage occupancy, that would again be a second order effect. 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: INFO IBM-MAIN
