One thing that's worth pointing out - and is relevant to DFSORT and memory in general but possibly not this situation in particular - is that Flash Express capacity is not regarded as free or otherwise for the purposes of STGTEST SYSEVENT.
This is, to me, a significant benefit of Flash Express for the "DFSORT chases online address spaces into Aux" category of behaviour - and one I mentioned in https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker/entry/flash_saviour_of_the_universe?lang=en just last week. I checked with z/OS Development specifically on how STGTEST SYSEVENT treated Flash Express. Hoping this is useful to some of you, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: [email protected] Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Jim Mulder <[email protected]> To: [email protected], Date: 03/03/2013 09:19 PM Subject: Re: DFSORT Weirdness Sent by: IBM Mainframe Discussion List <[email protected]> > 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 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
