Long ago I had a theory regarding blksize=32K load module libraries
that I could demonstrate on paper but never attempted to demonstrate
for real due to the amount of work involved. Consider that the
linkage editor writes however much program text as fits on the rest of
the track. IEBCOPY to a new data set copies members in membername
order, not physical order from the original data set. It is
theoretically possible to construct a degenerate case where due to the
above, the IEBCOPY'd data set will actually take _more_ space than the
original! You could have two members originally linked to different
areas of the original PDS, decently utilizing 32K blocks. Now you
IEBCOPY the data set and those two members end up one following one
another in the target, and the second member's 32K block doesn't fit
after the first member's 32K block, and the short noise blocks in load
modules come nowhere close to using up that space. So in certain
degenerate cases, you could waste maybe 1/3 of the space when
IEBCOPYing a blksize=32K load module library. I suspect that some
number a bit below half track is optimum to allow for the small
overhead blocks plus 2 long text blocks.
OTOH, why isn't everybody using PDSEs instead of wasting brain power
on this?
/Leonard
Mike Schwab wrote on 11/23/2022 10:22 AM:
[...]
Load module PDSs have members with a symbol dictionary in text and
blocked together to start, then repeating a very short block then the
program machine code in multiples of 1K to the blocksize or fill the
rest of the track if less until the load module is complete.
When adding or updating the data is added to the end of the dataset.
When updating or deleting a member the references to the space
previously used is removed but can’t be reused. Eventually you
compress the PDS in place. The program reads the directory,
determines where unreferenced space is, then moves up the next block
to the unreferenced space. The COPY command doesn’t reblock the data,
so if you have a 31K empty space but the next block is 32K, you don’t
use that space. COPYMOD does reblock, but may not be used very often.
So, a research idea is to write a program that reads the C part of
each CKD record, and calculate a fake R255 for the Key/Blocksize that
could fill the track. K8/D256 would be the directory blocks, K0/Dx
would be text, K0/Dnk would be program code. Counts of each key /
block size in a dataset would give insight to that dataset or
collection of text datasets and collection of load module datasets.
Experiments to help determine optimal blocksizes would be to create a
test library with 32K blocksize, copy with reblock into the test
library, analyze blocksizes, delete first member, compress in place,
reanalyze blocksize especially the unused space at end of track.
Repeat until empty. Reduce by 1K, repeat with copy with reblocking,
analyzing, deleting, compressing until empty.
My predictions of what could be optimal is a 4K blocksize. And VSAM
and PDSE datasets usually use this physical block size. And might
have advantages in the I/O occurring in a single frame.
On Wed, Nov 23, 2022 at 11:35 AM Seymour J Metz <sme...@gmu.edu> wrote:
No, sometimes a smaller block size is more efficient. Also, a 32K block size
doesn't mean that all blocks are 32K; both the linkage editor and IEBCOPY can
write short blocks to pad out a track.
________________________________________
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Paul
Gorlinsky <p...@atsmigrations.com>
Sent: Wednesday, November 23, 2022 12:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bytes in a 3390 track
John, The simple view is that with DASD, the bigger the block as a multiple of
the track size, the more data you can store on a track.
It almost like an IBG on the older tapes.
Best allocation or space calc is to use 1/2 track if possible, for QSAM, and
PDSs. For PDSEs using 32760 is fine because I believe they like linear VSAM
files with 4K blocks.
Remember for DASD, the maximum block size ( physical record ) is 32760. But
this means on a 3390 you waste about 24K per track. Where as, using something
near 27998 or less, you will get 2 blocks per track with about 1% overhead.
It looks like PDSEs have about 13% overhead per track assuming a 4K (PAGE)
track record size ... BUT no compression needs..
For the most part, let the OS handle the allocation by using BLKSIZE=0 where
you can. It will calc the optimized track record size ( blksize ) for the
specific device, including tapes.
Do not expect 100% track utilization with MVS/VSE/VM ...
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
