The longer since the last update of a member, the less likely it is to be replaced. Store by last update. Copying to a new PDS is alphabetical, and makes the first few compresses particulaly inefficient (lots of members to be moved).
On Thu, Feb 14, 2013 at 8:37 AM, John Gilmore <[email protected]> wrote: > Edward Jaffe wrote: > > | But would that not require "active" data movement/cleanup > | whenever a block is freed? > > and of course it would. How much of this would be required appears to > depend upon what kind of member-replacement process is going on. > > There is some evidence---my sample is from six shops but for only 113 > PDSEs---that an 80-20-like process is frequent, i.e., that 80 percent > of the replacement activity is with only 20 per cent of the members. > If this is common then keeping a list with counts of the last n > replacement operations weighted for duplications would make it > possible to use a very small amount of this sort of thing to great > advantage. > > Shane's point merits comment too. PDSEs were radically > under-instrumented at the beginning and still are; for this reason > discussion of their deficiencies quickly degenerates into competitive > anecdotage. One of the largest contributions IBM could make just now > would be to greatly improve optional SMF-based instrumentation for > PDSEs, > > We all understood the deficiencies of PDSs, and PDSEs were a laudable > initiative, but they were also a half-hearted or, perhaps better, > underbudgeted one. > > John Gilmore, Ashland, MA 01721 - USA -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
