With an LRECL of 7000 and a max BLKSZ of 32760, there are only four possible FB
block sizes to choose from:
28000 permits one block per track for a total of 4 records.
21000 permits two blocks per track for a total of 6 records.
14000 permits three blocks per track for a total of 6 records.
7000 permits seven blocks per track for a total of 7 records.
For LRECL 6135:
24540 yields 8 records per track
18405 yields 9 records per track
For LRECL 3681:
25757 yields 14 records per track
18405 yields 15 records per track
It depends on what you mean by optimized. SDB is designed to minimize track
usage and not maximize throughput. At the time SDB was developed, customers
(or at least their bean counters) where primarily concerned with the cost to
store date, not retrieve it. Maybe because it was easier to understand and
measure. Maybe because any time waiting for the I/O to complete would not be
idle but the OS would dispatch other tasks.
The fact that half-track blocking is frequently best for both concerns is only
a general rule. Obviously, there are exceptions.
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
> Behalf Of Bill Ashton
> Sent: Sunday, January 15, 2017 5:13 AM
> To: [email protected]
> Subject: Re: Friday SDB puzzle
>
> For fun I created some files. It seems that files with LRECL=7000 through
> 10796 create a SDB BLKSZ equal to the LRECL, rather than half track
> blocking. There are many other LRECLs that also create SDB BLKSZ that seems
> less than optimal. Does anyone know why this might be? For instance LRECL
> 3681 and 6135 both create a BLKSZ of 18405 when I expected 25767 and 24540,
> respectively.
>
> This seems quite peculiar, unless there is another "target" size other than
> 27998 used in certain cases.
>
> What do you think?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
