COBOL Printing Reports

[djflyer]

Hi!

Just curious - I'm new at COBOL - we're learning how to code reports for printing. It seems like this is ripe for automation these days. How many of you still program the printing out of reports?

[Robert Sample]

We still have several hundred production reports generated by COBOL and / or NATURAL. These reports are generated using batch JCL and then routed through a vendor product which send the reports as emails to specific users on the network. Those users can either review the email through the email client or print the report to their local printer as they want.

[djflyer]

Please bear with me as I try to understand. A report is generated by a COBOL program from some file of data. Then batch JCL takes that and sends the info to an outside vendor that formats the data into a report? So you are not doing the formatting via COBOL - putting in spaces - Line advancing etc?

[Robert Sample]

Let's clarify a bit. I am not talking about the COBOL Report Generator, which hasn't been part of IBM's Enterprise COBOL for a lot of years. I'm talking about creating a report in COBOL by reading input data, moving fields to an output line, and writing those output lines (with line spacing, page headers, sometimes page footers, and usually report totals -- sometimes control break totals are part of the report).

Once the report has been written in COBOL, it may be run for many years. The execution of the COBOL program is done via a batch job (JCL stream) which is scheduled through our scheduler to run as needed (some reports are daily or multiple times a day, some are weekly, some are monthly, some are quarterly or annually). The output of the COBOL program is then automatically fed into our vendor's software -- again running on our mainframe -- and the vendor software uses parameters established for each report to determine who to email that report to. The email comes from our mainframe and is routed through our internal network and is delivered to the person(s) designated to receive it. But the report, whether viewed on the email client or printed, still has line spacing, page totals, page breaks, and all the standard report mechanisms coded in COBOL. The vendor software treats the report as a block of data -- it merely handles the routing and delivery of the report to the appropriate person(s).

[djflyer]

Thank you for the clarification. Just learning COBOL and trying to put it all together. Doing the formatting of an output right now and am a little frustrated. Lots of tedium getting the correct formatting! I need more practice.

I appreciate the time you took to explain.

[Robert Sample]

Back when I started learning COBOL, there were line printer layout forms that had 132 columns and 60 (or so) rows so you could determine precisely what would be in each line. This vastly simplified coding the report in COBOL since one report line represented one line of the form. I don't recall the last time I saw such a form, though.

Working to create a report in COBOL is tedious, though, since you have to consider control breaks, page headers, page footers, and report totals and sometimes the details can swamp your concept for the report. For a lot of the report programs I've written, the data lines represent 60 to 80% of the lines of code since I like having a variable for each line. I've seen reports coded by using reference modification to create each line in the PROCEDURE DIVISION, but I've always found those more difficult to change.