Page 1 of 1

FB or FBA for a COBOL report writing program.

Posted: Thu Nov 19, 2015 1:48 pm
by Sanyukta Agarwal
Hi,

They asked this question...it is not exact question but based on what I can recall - If you need to write a new report using a COBOL program, what would you prefer FB or FBA for the new COBOL report writing program?

I have always used FB, so I have answered FB/133 or FB/80 should work and if there are otehr specifications for the report they should be taken care. But I read now that in FBA is A is carriage Control as the First character and this will be used for Printer. That means my answer can be wrong but most of the report program in my current company seemto use FB.

Re: FB or FBA for a COBOL report writing program.

Posted: Thu Nov 19, 2015 2:59 pm
by William Collins
When printers used of have a fixed number of columns on a page, one of the standards (for Mainframes anyway) was 132 columns.

If you notice your 133, you have the extra byte for your control-code,

It is slightly better to use FBA (or FBM, look it up) as "some things" automatically distinguish between the control-code and the data if you specify FBA.

There is nothing to stop you coding FBA if necessary on a DD statement used later, even if you coded it originally with FB.

This is not the answer the interviewer "expects" :-)

Re: FB or FBA for a COBOL report writing program.

Posted: Thu Dec 31, 2015 12:20 pm
by Sanyukta Agarwal
William Collins wrote:This is not the answer the interviewer "expects" :-)
Exactly, in fact I did not also expect that. :)

FBA should be a thing if yesteryears. Today we have printers which can print without the "A" of FBA or I have understood it all wrong?

Re: FB or FBA for a COBOL report writing program.

Posted: Thu Dec 31, 2015 2:42 pm
by William Collins
Well, if your site tells you you don't need to use it, then fine. Otherwise strange and unexpected things will happen. How would any printer (new or old) know how you want something printed unless you tell the printer how you want it printed?

Of course, you could take your 30,000-page output and code it all in RTF or PCL or Postscript (or XML or whatever). Year, it'll be slower to produce from a program, and take more storage space. But, it'll save you having to not do anything at all to use that pesky one byte in the output, so go for it.