I'm not sure that was ever true for the LE, although it took IEBCOPY a while to catch up.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of David Spiegel <dspiegel...@hotmail.com> Sent: Friday, May 3, 2019 6:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Crazy concatenation mystery Hi Greg, If someone uses BLKSIZE=32760, isn't it true that only one physical block fits on a (emulated) 3390 track, thereby definitely wasting (2*27998)-32760=23236 bytes per track (regardless of any Program Binder considerations)? Thanks and regards, David On 2019-05-03 03:41, Greg Price wrote: > On 2019-05-03 12:15 PM, David Spiegel wrote: >> Steve said: "... but the received wisdom is that all load libraries >> should >> have blksize=32K-8. ..." >> >> For optimal space usage, however, the BLKSIZE should be 27998 (i.e. >> half-track blocking). > > You might think that, but for load modules, you have to realize that > in-between the text blocks (which could be 27998 bytes long in your > scenario) there are RLD and/or CTL records which means that no single > track could contain 2 full-sized text blocks. > > Because of the "random" sizes of CSECTs and RLD usage (where "random" > means not really knowable at load library data set creation time) it > is not possible to know the best block size to use to minimize the > disk space used by a set of programs without doing some sort of > analysis on the load modules to be housed in that library. > > I mention CSECT because once a text block has some data to the end of > a section, the next section will not be started in that block unless > the whole section will fit in that block. That is why you see short > text blocks even though there is plenty more object text that follows on. > > And even though the linkage editor may make good use of remaining > track space, what happens when the blocks a shifted around by a data > set copy or a compress? > > So, it may be that BLKSIZE=32760 really is the best advice. At least > you could reasonably hope to minimize the amount of disk space wasted > on inter-block gaps. (Of course, inter-block gaps may well be > emulated away these days, but they still exist for 3390 CKD accounting > purposes.) > > And as for PDSE program object libraries - how about this? > > If the BLKSIZE value doesn't matter in terms of how programs are > stored in the PDSE and fetched at run time, what about using > BLKSIZE=4096 for PDSE load libraries? > > Why? Because if you browse a program object in a PDSE and scroll > right, you will notice that all of the blocks end at column 4096. So > to read that member you have acquired 32760-byte buffers when > 4096-byte buffers would have sufficed. > :) > > In practice, 32760 for all program libraries is probably the best > choice to remove any block size hassles even if occasionally it causes > more storage to be used. After all, I keep hearing that storage is cheap. > > Just my thoughts, of course... > > Cheers, > Greg > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
