What is the difference between FB and F and spanned records.

[Subhash Chander]

Hi,

I searched but I didn't get an answer to tell the differnce between FB/F as a COBOL programmer. When should we use which?

I looked at http://publibz.boulder.ibm.com/cgi-bin/ ... 0312141355" onclick="window.open(this.href);return false; but the confusion remains.

For that matter what is FBS, I mean what is the practical use of it? Do we really use this format in COBOL applciations? I've just seen using FB, not even F.

Thanks for any help on this.

[Robert Sample]

One way to look at it is that F and FB files are the same -- the only difference is that F files are restricted to one record per block, instead of multiple records per block for FB. From a COBOL standpoint, F versus FB is a non-issue; from the system standpoint, however, FB is VASTLY preferred over F. Using a 3390 disk drive, half-track blocking, you will get 349 80-byte records per block of 27920 bytes or 698 records per track. If you use F instead, you get 78 records per track -- a reduction of 620 records per track. This will impact how much space your data set requires.

FBS means to use standard blocks -- which means every block of the data set, except possibly the last, will be exactly the block size. The difference only comes into play when a data set is extended (DISP=MOD); with FB the new data will be written into another block (leaving possibly a short block in the data set each time the data set is extended) whereas with FBS the last block will be filled to the block size before a new block is written. Again, from a COBOL standpoint it makes no difference which you use but the system overhead will be less with FB versus FBS.

Note that VBS is completely different in meaning from VBS versus VB. VBS is variable blocked spanned and means the LRECL may be longer than the block size, and the system fills each block as full as possible.

The bottom line for a COBOL programmer is to ALWAYS use FB or VB for your data set, which if the data set is managed by SMS you won't have any control over that, anyway.

[Quasar Chunawala]

The crux of the concept is, on the mainframe data is transferred to/fro between the system and I/O devices in blocks.

Assume you had to buy 100 apples from the market place. If you buy just one apple every time, you'd have to make 100 trips. Transportation cost would be too high. Instead, if you bought in bunches of ten, you'd have to make just 10 trips. Also, carrying all of the 100 apples in just a single visit may be too heavy. So, there's a trade-off.

Think of the records in 1 block as apples in a bunch. You'd have to choose the optimum block-size(BLKSIZE) for you dataset.

[Mr Awasthi]

These are excellent explanations. Thanks Robert and Quasar.

[Subhash Chander]

I had been keeping away from forums but this helps.

[ApexNC]

... but the system overhead will be less with FB versus FBS.

Found this forum topic while googling info on FBS. An excellent, detailed answer except for this little bit. According to "DFSMS: Using Datasets"
http://publibz.boulder.ibm.com/cgi-bin/ ... A0/3.1.2.1 - "A sequential data set with standard format records (format-FS or -FBS) sometimes can be read more efficiently than a data set with format-F or -FB records. This efficiency is possible because the system is able to determine the address of each record to be read, because each track contains the same number of blocks."

FBS can give you less overhead, but at the risk of "losing" data if the file is ever written to with DISP=MOD.

[William Collins]

True, but COBOL can't make any use of that directly. C/C++, Assembler, can. It allows "seek" type access, "find me the 30,291st record on the file, please". With F/FB, that requires reading from the start of the file (due to possibility of short blocks) with FBS (and must not have short blocks, except the last, no DISP=MOD) the position can be calculated.

[Robert Sample]

ApexNC, the key word in your quote is "sometimes". The context of the original post was COBOL and hence the efficiency gain by direct addressing is not possible. Furthermore, the FBS system overhead I mentioned is that of determining if the last block is a short block and how many records will be added to complete the block -- none of which is necessary (or done) for FB.

[William Collins]

Actually, where I said F/FB, I doubt I was correct for F. There can hardly be a short-block there. Obviously there would be a different issue with using F, which would slow down the fast access anyway.

[Subhash Chander]

... but the system overhead will be less with FB versus FBS.

.
.
FBS can give you less overhead, but at the risk of "losing" data if the file is ever written to with DISP=MOD.

Sumbled upon on this topic again and I wonder what "overhaeads" we talk here, all the times?

[Robert Sample]

There is system CPU time involved in doing an I/O -- moving the data from the buffer in memory to the disk / tape device, determining where to write data when DISP=MOD is used, and blocking / deblocking data just for 3 examples (there is more done by the system but I'm not going to provide an exhaustive list).