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
