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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Patrick Falcone Sent: Monday, March 04, 2013 03:09 To: IBM-MAIN@LISTSERV.UA.EDU 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 <d10j...@us.ibm.com> To: IBM-MAIN@LISTSERV.UA.EDU 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 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
