> 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
