IBM Mainframe Forum

Hi Moderators,

I'm not sure if I'm posting this topic under right topic . Sorry if I'm not.

Hi All,

I found below in publib

FB (Fixed Blocked)
This format designation means that several logical records are combined into one physical block. This format can provide efficient space utilization and operation. This format is commonly used for fixed-length records.

I knew that blocking improves performance by reducing the time required to read and write a DASD file. But I couldn't understand how blocking helps in space utilization. Can someone please help me to understand this?

Thank you in advance!

Regards,
rskmfguy

here is the link to the docs and the formulas

the manual
http://publibz.boulder.ibm.com/cgi-bin/ ... 0527#COVER

the appendix with the formulas
http://publibz.boulder.ibm.com/cgi-bin/ ... 0630180527

These users thanked the author enrico-sorichetti for the post:

rskmfguy (Wed Oct 23, 2013 10:11 am)

A useful reference for you would be the GX26-4577 manual of 3390 capacity. Google gx26-4577 to find it. The basic issue is that as bytes in the block go down, the number of blocks per track (and hence records per track) go down as well.

These users thanked the author Robert Sample for the post:

rskmfguy (Wed Oct 23, 2013 10:12 am)

Blocking saves space? Usually, but not always. For example, the "optimal" DCB parameters for a 3390 are usually thought to be RECFM=FB, LRECL=80, BLKSIZE=27920. Well, if BLKSIZE=27920 is good, isn't BLKSIZE=28000 better? Or maybe BLKSIZE=32720? Well, no. BLKSIZE=27920 permits two physical records per track, for 698 80 byte records per track. BLKSIZE=28000 permits one physical record per track, for 350 80 byte records per track. The remainder of the track is not used.

What about a load module data set with RECFM=U, BLKSIZE =32760? It does not look good! Actually, it's OK, sort of, for several reasons.

• The Binder, for reasons I won't document here, rarely writes 32760 byte blocks. Even when it does write a very large block, it never writes two consecutive very large blocks. A large block is always followed by at least one, and usually several, very short blocks.
• Just to confuse the issue more, when the Binder thinks it is ready to write a very large block, it determines if the block it wants to write will fit on the current output track. If not, it writes the largest block that will actually fit on the track. The next short record becomes the first record on the next track. This sounds good, and it is good until the data set is copied. This complicated record structure may not work well on the new device. Then again long, short, ..., long, short, ... may not work well on any device!