-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Jim Mulder
Sent: Saturday, March 02, 2013 01:03
To: [email protected]
Subject: Re: DFSORT Weirdness

>   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. 

>>>
I think the 30% rule was the performance-related reason to keep page
datasets at the same size. The 30% rules was derived from block-paging
performance recommendations, which said that if a page dataset was
filled for more than 30%, it became more difficult for block-paging to
find sufficient contiguous slots to do block paging. Since ASM creates
groups of page datasets, where the first order is based on device type
and speed, it prefers the group that performs best and distributes
page-outs equally distributed over the page datasets in that group. If
they are not of the same size, some might reach the 30% limit, which
hinders ASM to page out in the most efficient way. Keeping all page
datasets at the same size will guarantee that all will remain under 30%
until they all reach 30%, which should be avoided anyway according to
those recommendations.

Since block-paging has been abandoned, I and others have tried to get
new recommendations about page dataset utilization (see the archives of
2012), but IBM has not updated its, in my opinion outdated, ROTs.

Kees.

********************************************************
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 [email protected] with the message: INFO IBM-MAIN

Reply via email to