> That's just crazy talk. While there might be some load balancing > related motivations for using similar sized page data sets, ASM most > certainly uses the full capacity of all of the data sets when > calculating auxiliary storage shortage thresholds. >
> It might be obsolete talk. (Now I feel as old as some other on this > list :) It wasn't always crazy talk and I don't think it is now. > Keeping page datasets the same size was a "good idea" not that long > ago. (sometime last decade :) > Today, I still think for consistency and grins and easier space > management, they should be the same size. > > So I don't have to keep my local page datasets all the same size anymore ? > > > > (Like many this was a rule I had ingrained to always have all local pages > > datasets the same size) The point I was making about "crazy talk" was to dispel the notion that was presented in two posts that ASM takes the size of the smallest data set, and uses only that amount in larger data sets. That is an incorrect notion. ASM is quite willing to use all of the slots in any page data set regardless of its relative size, and the total number of slots from all data sets is used for doing calculations related to auxiliary storage shortages, regardless of the distribution of page data set sizes. So, there is no (and has never been any) *functional* requirement for page datasets to be the same size. That said, there may have been (and may still be) *performance-related* reasons for using similar sized paged data sets. Capacity planning and system tuning of that nature is not my area of expertise. When expanded storage came along in the mid '80s, IBM's focus became more on reducing paging by using increasing processor storage that on creating optimal page data set configurations. So since then, I have seen very little being done in the way of measuring paging performance for page data sets (other than recent measurements to demonstrate potential performance improvements from using Flash Express on the EC12 machines for paging instead of page data sets). The original question was about how a move from one model of DASD subsystem to another might induce a change in DFSORT's storage usage. The point is that the DASD model, and the distribution of sizes of page data sets, should have no effect on that. However, the total number of page data set slots from all of the page data sets (plus the number of Flash Express paging slots configured to the LPAR in question on an EC12 machine) could very well have an effect on DFSORT's decisions about how much storage to use, and increasing the total number of slots could affect the output of the STGTEST SYSEVENT, which in turn could induce DFSORT to decide to use more storage. 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
