At 12:41 -0600 on 12/06/2013, Dyck, Lionel wrote about Something to
Think About - Optimal PDS Blocking:
We all know about system determined blksize and there have been
rules of thumb for decades about the correct/optimal blksize to use
for each type of PDS.
My question is what is the optimal blksize for a PDS based on the
member sizes?
Having a large a blksize with many small members results in many
blocks with wasted space. Having a small blksize with many large
members results in unnecessary I/O to read all the blocks of data.
The various tools available to provide a best estimate at optimal
blksize (e.g. trkcalc, blkdisk, blk3390) and even SDB all provide a
best estimate without having any awareness of the planned, or
existing, contents of the PDS.
Which is better - a BLKSIZE of 3120 with 100 members ranging from 3
to 30 records or that same set of records in a PDS with BLKSIZE of
27920. And similarly what about a PDS with BLKSIZE of 3120 and 100
members ranging from 300 to 9000 records compared to the same set of
records in a PDS with a BLKSIZE of 27920.
I imagine this will be an interesting discussion.
I feel that part of the problem with answering this issue is that IMO
FB support is BAD (Broken As Designed). FB files (as opposed to FBS
files) are allowed to have imbedded short blocks. If I write a VBS
file to DASD, the write support has the smarts to check how much room
is left on the current track and to fill it up by writing a short
segment before writing the rest to the next track(s). Why when I
declare the PDS as FB (but not FBS) can the support figure out the
remaining room on the track and write two blocks (one the size of the
remaining room and the second for the the rest of the BLKSIZE)? If
this was done this would be a non-issue since if a full sized block
would not fit on the track 2 shorter blocks would be written. The
check for remaining room is I assume done for the first block of a
member since the number of BLKSIZE records that fit on a track is not
necessarily the same as for the track with the first block of a
member due to the prior member's EOM record taking up space.
------------------------------------------------------
Lionel B. Dyck <><
BMC Software
Product Development Architect, Common Install and Services
10431 Morado Circle, Building 5, Austin, Texas 78759
Office Phone: 512-340-6031 (extension x26031)
Cell Phone: 512-739-3274
E-Mail: [email protected]
"Worry more about your character than your reputation. Character is
what you are, reputation merely what others think you are." - John
Wooden
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
