There was an interesting post from John Eells (March 24, 2006; item 1614 in March 2006's archive) in reply to a thread with the subject "3380-3390 Conversion - DISAPPOINTMENT".
(Wanted to post URL and tinyurl here when I realised that my mail address would be part of the cgi string thereby rendering the URLs useless) Partial quote from John's post: <quote><note: he is quoting John Chase> > IBM has been recommending BLKSIZE=32760 for load libraries for at least > a decade. <snip> Absolutely true for system software load libraries. I don't recall that we ever recommended a specific block size for other load libraries, except perhaps by thoughtlessly omitting the "for system software target libraries" phrase in an informal setting (say, here in IBM-MAIN). For example, using 32760 for other load libraries can cause some head-scratching and extra work during device conversions...which, oddly enough, is the current topic! That's one reason we never recommended it in the general case. Another is that system software target libraries tend to be built on the device types from which they will be used, and tended by sysprogs who might remember to reblock them during a conversion effort. Application libraries, by contrast, might bounce around among different device geometries under DFSMShsm control or be moved by storage administrators who are moving *so* much stuff at once that fine-tuning isn't a reasonable option. For these libraries, a reasonable submultiple of the track lengths of the different devices--that is, one that yields reasonable space utilization on each one--might well be better choice of block size. (Ever wonder where all those 6K-ish block sizes came from? Now you know.) In any case, for block sizes that are not reasonable submultiples of the two track lengths in question, you should always move load libraries between different device types using IEBCOPY COPYMOD, *not* COPY. Otherwise, particularly for data sets with large block sizes, the difference in track lengths will result in truly abysmal space utilization for those data sets having load modules with lots of long text blocks and less-than-optimum space utilization for most of the rest. Also, to avoid RC4s from COPYMOD that would make a duly diligent sysprog from looking at (and up) messages that don't matter, always use PARM=SPCLCMOD with COPYMOD. John Eells z/OS Technical Marketing IBM Poughkeepsie </quote> Robert Bardos Ansys AG, Zurich, Switzerland ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
