Blocking saves space?

IBM OS/370, MVS, OS/390, Linux, TPF, VM/CMS, VM/ESA, VSE/ESA, z/VM, z/VSE, z/OS, z/OS.e etc...

Blocking saves space?

Postby rskmfguy » Wed Oct 23, 2013 12:05 am

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!

Posts: 10
Joined: Mon Oct 22, 2012 11:07 pm
Has thanked: 8 times
Been thanked: 0 time

Re: Blocking saves space?

Postby enrico-sorichetti » Wed Oct 23, 2013 12:15 am

here is the link to the docs and the formulas

the manual ... 0527#COVER

the appendix with the formulas ... 0630180527
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort

These users thanked the author enrico-sorichetti for the post:
rskmfguy (Wed Oct 23, 2013 10:11 am)
Global moderator
Posts: 2957
Joined: Fri Apr 18, 2008 11:25 pm
Has thanked: 0 time
Been thanked: 159 times

Re: Blocking saves space?

Postby Robert Sample » Wed Oct 23, 2013 1:04 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)
Robert Sample
Global moderator
Posts: 3657
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 270 times

Re: Blocking saves space?

Postby steve-myers » Wed Oct 23, 2013 3:57 pm

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!
Global moderator
Posts: 2086
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 235 times

Return to Operating Systems


  • Related topics
    Last post