Not for OBJECT modules. The Binder calls a routine to determine the remaining space on the track, round down to the next multplie of 1k, and writes no more than that amount on that track.
On Fri, May 3, 2019 at 5:08 AM David Spiegel <dspiegel...@hotmail.com> wrote: > > 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 -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
