This could also be done for PDSes, when copying/compressing, as well as PDSEs. First copy the directory to a work space, then sort entries in the work space by last update, copy directory to output file, copy members by oldest update instead of alphabetical order, and update each directory entry for where that member begins as its corresponding member starts being rewritten. This assumes that the date of last update is saved somewhere. And do not update the date of last update when copying/compressing. Just one of many possible ways to speed up IEBCOPY for old style PDSes.
Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: [email protected] * w: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Mike Schwab Sent: Thursday, February 14, 2013 8:59 AM To: [email protected] Subject: Re: Change in PDSE Architecture (Was: SMPPTS Spill Data Set) 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
