Skip to content

Migration Topics

This part is a guide to help you to move all the Report Writer code in your program sources successfully from OS/VS COBOL or DOS/VS COBOL-IT Report Writer to new Report Writer.

Other Considerations

The following situation does not result in a diagnostic message and you should be aware of it, so that you will recognize the circumstances if it occurs in any program.

Long Control Fields Truncated

  • Meaning - If NOXCAL is the option in use, there is a limit to the length of the saved control fields. This limit, which is 80 bytes as supplied, may be set to any value up to 256 bytes using the CTRLEN option. If your program contains control items longer than this limit, the effect will be an obvious truncation in the contents of the control fields whenever they are printed in your report. When the XCAL option is used, there is no such restriction.

  • Remedy - To correct this problem, if VS COBOL II is in use, alter your choice of option from NOXCAL to XCAL. Or, for either compiler, set the CTRLEN option to a size that is likely to be larger than any control used in any candidate program. If you are in doubt, a maximum value of 256 will not be harmful, albeit a little inefficient.

Physical Comparison of Report Writer Output

Once you have corrected any syntactic discrepancies in your original Report Writer code, your new Report Writer code should now produce a layout that is visibly identical to the output you obtained under the previous compiler's built-in Report Writer.

There is however one known difference that may be apparent at the physical level, for example if you use a utility program to compare the print files produced by the two Report Writer systems: the OS/VS COBOL and DOS/VS COBOL-IT Report Writer prints a blank line at the top of each page, even if there is data on LINE 1, whereas new Report Writer, like basic COBOL, implements the latter by a single WRITE at top-of-page.

If you require the print records to be identical in physical arrangement to that produced by your original programs (for example if you use special de-spooling software that reads your print file and expects the first line of data on each page to be blank), you may achieve this by adding the clause MODE IS PRNT to the SELECT statement of your report file, since the PRNT file handler is designed to emulate the previous compilers' Report Writer output routine (see Supplied File Handlers).

Unreachable Code

The precompiler generates statements to perform certain extra checks that may prove to be unnecessary in some programs and may therefore show up as code that "can never be executed" with the OPTIMIZE option of the IBM COBOL compiler and be deleted. There are sound reasons for all these cases and they do not indicate any fault in the code generation. For example, the precompiler will generate a "branch around" before the block of PERFORMed generated procedures in case there should be a "fall-through" from the preceding paragraph. Naturally, the precompiler does not examine the structure of the rest of the program to ascertain whether such a fall-through is actually possible, since this would mean duplicating a task for which the compiler itself is best suited, at the cost of a prohibitive overhead. Other extra checks which may prove unnecessary are:

  • SIZE ERROR checks during the accumulation of SUM fields

  • Checks on whether a report has been INITIATEd

Back to top