Skip to content

Generate Statement

The GENERATE statement is COBOL-IT Report Writer's main verb for the production of output. It passes control to report writer to allow it to perform all the necessary mechanical tasks, including any control-break and page-break processing needed before producing all the lines and fields described in your DETAIL group, if specified.

generate statement

Generate Statement: Coding Rules

  • If GENERATE detail-group-name is coded, it must be the name of a DETAIL group coded in the current program, or in a GLOBAL report defined in a containing program. (The group-name appears immediately after the 01 level-number.) You may qualify the detail-group-name with the report-name, as in: GENERATE MAIN-DETAIL IN SUMMARY-REPORT. This is necessary if your detail-group-name is not unique in the REPORT SECTION.

  • The form GENERATE report-name has a special significance and is known as summary reporting. It causes any DETAIL group to be suppressed, so do not use this form unless you require only CONTROL HEADING or CONTROL FOOTING groups in the body of the report at the point that you execute the GENERATE. If you use this form, you must have at least one CONTROL HEADING or CONTROL FOOTING group in the report.

  • GENERATE must not appear in a USE BEFORE REPORTING directive Declarative.

Generate Statement: Operation

  • The GENERATE statement causes report writer to perform three main actions in an average report:

    • It tests for control breaks, producing CONTROL FOOTING and HEADING groups where necessary,
    • It performs a page-fit test, outputting PAGE FOOTING and PAGE HEADING groups where necessary; (these may also be produced as a result of a CONTROL HEADING or CONTROL FOOTING),
    • It generates each line in the DETAIL group, unless you are doing summary reporting (GENERATE report-name).

  • Once a report has been INITIATEd, your program may execute any number of GENERATE statements for each DETAIL group in the report. If your Report Description contains several DETAIL groups, you may code a sequence of different GENERATE statements in any part of the program and, in this way, build up any required report layout. You may also write a GENERATE for the same DETAIL group in more than one place in the program.

  • Summary reporting, where you code the report-name instead of a DETAIL group-name after the GENERATE, has the following effects:

    • No DETAIL group is output.
    • Any rolling forward of SUM operands takes place as usual, except for any rolling forward from a DETAIL group.
    • Any cross-footing of SUM operands takes place as usual, except for cross-footing within a DETAIL group.

    • Any subtotalling of (non-REPORT SECTION) SUM operands is executed as follows:

      1. If SOURCE SUM correlation is in effect, all the SUM operands thatcorrespond to a SOURCE operand in a DETAIL group are added intotheir totals, as though you had GENERATEd each DETAIL group inturn. Any non-REPORT SECTION SUM operands that do notcorrespond to a SOURCE operand are added into the totals once.

      2. If SOURCE SUM correlation is not in effect, the SUM operands areadded into the totals once.

    • Testing for control breaks takes place as usual. If a control break is detected, any CONTROL FOOTING and/or CONTROL HEADING groups are output as usual, together with any PAGE FOOTING and/or PAGE HEADING groups that may be required as the result of a page advance.

    • The GENERATE report-name statement can therefore only produce output (a) on the first GENERATE after an INITIATE, and (b) after a control break. Between an INITIATE and TERMINATE, your program may execute both the GENERATE report-name and the GENERATE group-name forms of the statement. The following example illustrates the different effects of the GENERATE report-name and GENERATE group-name clauses:

    generate report name

Generate Processing Cycle

The following is a more thorough description of each stage in the execution of a GENERATE statement:

  • If the identifier form of the LAST DETAIL sub-clause is used, its value is checked and, if valid, is stored in the Report Control Area.

  • If your report is associated with a DUPLICATED file, the value of REPORT-NUMBER is examined to see whether it is the same as it was for the previous GENERATE for this report, thus checking that the correct duplicate of the report is in the main Report Control Area. If not, this is swapped in.

  • If the report has not yet been INITIATEd, run time error diagnostic 14 is logged.

  • If this is the first GENERATE since the INITIATE:

    • If there is a REPORT HEADING group, this is produced.
    • If there are any CONTROL HEADING groups, each of them is produced, from highest down to lowest, and the initial value of each control is saved.

  • If this is not the first GENERATE since the INITIATE, each control identifier is compared with the corresponding saved previous value, beginning with the highest level. If no control has changed, no special action takes place. If a difference in value (a control break) is detected, comparison ceases and the following control break action takes place:

    • The value of each control-id is temporarily altered to the value it had immediately before the control break;

    • CONTROL FOOTING groups are produced, from the lowest up to the one at the level of the control break, if any;

    • The value of each control-id is restored to its value after the control break;

    • CONTROL HEADING groups are produced from the one at the level of the control break, if any, down to the lowest.

    • Since CONTROL HEADING and CONTROL FOOTING groups are independent report groups in their own right, several of the same operations described below will be applied to them as for a DETAIL group, namely: the output of any pending REPEATED groups, page-fit test, storing of the latest value of the CODE (not done for CONTROL FOOTINGs), all types of totalling, performing of USE BEFORE REPORTING section, production of print lines and clearing of totals, plus the setting on of any PRESENT AFTER (or GROUP INDICATE) flags, when appropriate.

  • If there are any REPEATED groups in this report other than the current DETAIL, a check is made whether any have been buffered. If so, they are first output and the buffer is cleared.

  • If there are any cross-foot totals for this group, they are computed in the order implied by any inter-dependencies among them.

  • If OSVS is in effect any additional summing is now performed for the group with the following possible actions:

    • If there is any general "subtotalling" for the report (SUM clauses with non-REPORT SECTION operands, without UPON, and with no SOURCE SUM correlation), each SUM's operands are added into the total fields. If you are generating a DETAIL group which is absent because of a PRESENT/ ABSENT WHEN/AFTER clause in the 01-level entry, this general subtotalling is also skipped.

    • If there is any special subtotalling triggered by this DETAIL group due either to an UPON phrase referring to this group or to SOURCE SUM correlation that implies this group, the SUM operands are added into the total fields.

    • If there is a SUM clause in another group referring to an entry in this group, then rolling forward of values into its total field takes place.

  • If there is a USE BEFORE REPORTING section for this group in the DECLARATIVES, it is performed. If PRINT-SWITCH is non-zero as a result (meaning that printing is to be SUPPRESSed), then

    • If OSVS is in effect no further action takes place for this group;

    • If NOOSVS is in effect in effect then if no further totalling to be performed for this group, no further action takes place; otherwise the only further steps to be performed are 10 (PRESENT at 01-level), if applicable, and 8 (totalling).

  • If there is a PRESENT/ABSENT WHEN or PRESENT/ABSENT AFTER clause at the 01-level of this group, a test is made of the condition and, if the group is absent then

    • If OSVS is in effect no further action takes place for this group;

    • If NOOSVS is in effect then, if there is no general subtotalling to be performed, no further action takes place; otherwise the only further step to be performed is above (general subtotalling).

  • If there is an identifier form of a CODE clause in the RD, the contents of the identifier are moved to the CODE-VALUE location in the Report Control Area.

  • If this group has a REPEATED clause, the REPEATED buffer is prepared to receive the next instance of the group or, if this group is the last of the set, to produce the buffered groups alongside it.

  • If any lines are being produced and the report has a PAGE clause, a page-fit test is performed to test LINE-COUNTER, to establish whether or not a page advance is required before the group may be output. If the group has a MULTIPLE PAGE clause, this test is performed for the first and each subsequent line (or group of lines with NO MULTIPLE PAGE).

  • If a page advance is required, the following action takes place:

    • The PAGE FOOTING group is produced, if one exists

    • PAGE-COUNTER is incremented by 1

    • A form feed is output or, if an Independent Report File Handler is in use, a value of zero is placed in the current position location to cause this

    • The PAGE HEADING group is produced, if one exists

    • If there are any CONTROL HEADING groups specifying OR PAGE, they are produced, from highest down to lowest.

  • If NOOSVS is in effect and there is any further summing to be performed for this group, step 8 (subtotalling and rolling forward) is now executed.

  • Each report line field is stored in its report line, invoking FUNCTION routines where necessary and checking for column overlap, line overflow and any other possible error conditions, and then output. If an Independent Report File Handler is in use, it is invoked; otherwise, report writer issues a WRITE for each report line. In either case, LINE-COUNTER is first set to the target line position just before each line is produced.

  • If the group has a NEXT GROUP clause, LINE-COUNTER may be adjusted in accordance with the rules for that clause. (See NEXT GROUP clause.) In the case of NEXT GROUP absolute, this may be deferred by setting the Saved Next Group Integer.

  • All total fields defined in this group are reset to zero, unless they are not PRESENT during this GENERATE or have a RESET phrase that defers resetting to a higher control break.

  • If there are any PRESENT AFTER (or GROUP INDICATE) clauses in the group, their indicators are set off.

Compatibility

The coding rules for the GENERATE are identical for OS/VS COBOL, DOS/VS COBOL and new Report Writer. The GENERATE statement may perform many more steps, but only because of the additional functions provided by new Report Writer.

Access to a GLOBAL report is not available with OS/VS or DOS/VS COBOL.

Back to top