Sum Clause

This clause automatically forms totals from any other numeric field. You may also use it as a term in an arithmetic-expression in a SOURCE clause.

Sum Clause: Coding Rules

There are two ways to code the SUM clause:

• As a clause in its own right. You write the clause in place of a SOURCE, VALUE, or FUNCTION clause. For example: 05 COL 21 PIC ZZZ9 SUM OF SALE.

• As a term in an expression; for example:

    05 COL 21 PIC ZZZ9 
       SOURCE IS ((SUM OF REVENUE) + (SUM OF TAX)) / 100.
  

  This type of expression can only be used as a SOURCE operand (although, as usual, the SOURCE keyword is optional). You cannot use a SUM term as part of a condition or, for instance, as a parameter to a FUNCTION.

The item summed can be either of two things:

• The name of any numeric data item in your REPORT SECTION (other than a FUNCTION entry). To use this, you must place a data-name on the item in the REPORT SECTION you want to total. Suppose you need to form a total from the following report field: 05 COL 41 PIC 99999 SOURCE WAGES.

• Just place a data-name of your own choosing on it, such as: 05 R-WAGES COL 41 PIC 99999 SOURCE WAGES.

  and you may now write SUM OF R-WAGES in another item in your report to form a total. This is called a REPORT SECTION SUM clause. A REPORT SECTION SUM operand never has any subscripts or arithmetic symbols - you can write only: SUM OF data-name.

  The data item referred to in the SUM clause may be qualified by the report-name, as in SUM R-PAYMENT IN SUMMARY-REPORT. By default, the qualifier is the same report as the one in which the SUM is defined. So if the same data-name appears in more than one report, it may be referred to by a SUM clause in its own report without qualification. (It cannot be referred to by a SUM in a different report without a qualifier.) This means that you can duplicate a complete report description with SUM clauses without changing any of the data-names on SUM entries.

• A numeric identifier or expression from outside the REPORT SECTION.

  In this form, it is similar in appearance to the operand of a SOURCE clause. This is called a non-REPORT SECTION SUM clause.

  (Unless a naming convention is observed, there is no way of telling from the data-name whether the SUM clause references a REPORT SECTION SUM or not. In the examples in this volume, we sometimes use a prefix such as "R-" to designate a REPORT SECTION item, so that "SUM OF R-..." will be recognized as a REPORT SECTION SUM. Observing a standard like that will make your REPORT SECTION easier to follow.

• A SUM clause may total several items, and you may combine REPORT SECTION and non-REPORT SECTION items; for example: SUM OF W-BASIC, R-BONUS, R-OVERTIME

  where W-BASIC is a non-REPORT SECTION item, R-BONUS is a REPORT SECTION item in a different report group and R-OVERTIME is a REPORT SECTION item in the same report group. In this case, the total field is always the sum of the individual totals that would be formed from each of its items. You should then interpret the remarks in the remainder of this section for each of the single SUM operands individually. This is not similar to the multiple SOURCES clause (despite their syntactic similarity), since only one printable item is defined with the SUM clause.

• Your report may contain as many entries with SUM clauses as you wish, in any TYPE of group (even RH). Only elementary entries can have a SUM clause.

• If you code the UPON phrase, each group-name must be the name of a DETAIL group and should not be the same as the group you are currently defining. The group-name may be qualified. If not, the current report is assumed.

• If your SUM clause is in a DETAIL group and the operand of your SUM clause is not in the REPORT SECTION (a rare situation), your report should contain more than one DETAIL group and you should logically code the UPON phrase, in order to specify on which GENERATE you want adding to take place.

• If you code the RESET phrase, the control-id operand must be one of those defined in the CONTROL clause of your report (including REPORT, whose presence is assumed there). If you are currently defining a CONTROL FOOTING group, the level of the control in your RESET ON should be higher than the level of this group. (It may also be equal to the level of the current group, in which case resetting occurs at the normal time, and the phrase is therefore redundant.)

• The RESET phrase cannot be defined anywhere in a multiple CONTROL FOOTING group.

• You may code the SUM clause more than once in an entry. The effect of this is to add together the totals formed from each of the clauses. Hence: SUM A SUM B gives the same result as SUM A B

  (and, if A and B are non-REPORT SECTION items, SUM (A + B)). This separation is essential only if you need to use a certain UPON phrase with one but not the other, for example: ... SUM A UPON DETAIL-1 SUM B UPON DETAIL-2.

• ANS-85 note. Since a reference-modified identifier is regarded as non-numeric, you cannot SUM it, either directly as the operand of your SUM clause, or indirectly by naming a REPORT SECTION item where it is used as a SOURCE.

Sum Clause: Operation

Report writer performs the totalling, presenting, and resetting (to zero) of your totals completely automatically. These three stages are covered in the next three numbered paragraphs.

Totaling

The method used for totalling depends on whether the item referred to by SUM is a data-name on a REPORT SECTION entry (called henceforth a "REPORT SECTION SUM "), or not.

• Report Section Sum

  Whenever the originating data item named in your SUM clause is output in the report, the item it references is also added into the (internal) total field. If the REPORT SECTION data item totalled contains a SOURCE or VALUE clause, the amount added to the total is the SOURCE or VALUE operand outside the REPORT SECTION, not the intermediate REPORT SECTION field. For example, if you write:

  

  the fields added into the total will be 100 and W-PAYMENT, not the report fields R-FLD1 and R-FLD2. Thus, if W-PAYMENT has a PICTURE of 9(5)V99 rather than 9(4), the full originating value - not the truncated value that appears in the report line - will be added.

  There are two names used to distinguish two cases of REPORT SECTION SUMming:

  • Cross-Footing

    In the next illustration, the item to be totalled is in the same reportgroup as your SUM clause:

    

    The SUM entry may appear earlier in the report group than the item it is totalling and this may be carried on to any number of stages. Thus the physical order of totals and items being totalled within a single group is immaterial. Report writer decides for itself the order in which totalling must be done. Hence the correct result is obtained by coding for example:

    

    However, you must avoid circular dependencies such as:

    

  • Rolling Forward

    In the next illustration, the item to be totalled is in a different groupfrom your SUM clause:

    

    In this example, the "boxes" contain instances of the different report groups. The values to be added appear in a DETAIL, and the total is in a CONTROL FOOTING.

    You may use also this method of summing between any reasonable combination of groups, namely any of the following:

    • Lower CONTROL FOOTING to higher CONTROL FOOTING,
    • DETAIL to DETAIL,
    • Any group to a REPORT FOOTING,
    • Any body group to a PAGE FOOTING,
    • PAGE FOOTING to a CONTROL FOOTING.

    Frequently there are several items that could be rolled forward to produce the same result. For example, your YEAR totals are the total of the twelve MONTH totals; they are also the total of your fifty-two WEEK totals and your 365 DAY totals. Rolling forward the immediately-lower-level total (such as MONTH totals into YEAR totals) is the most efficient technique.

• Non-Report Section Sum

  Here totals are gradually accumulated from values held outside the REPORT SECTION. This method was much used in the earlier versions of report writer and you may possess some old programs that use it. This is usually referred to as subtotalling. Because the identifier or expression lies outside the REPORT SECTION, it is not as clear as it is with a REPORT SECTION SUM clause exactly when the values are added into the total, so the following rules are important:

  1. If SOURCE SUM correlation is in effect (see Subtotalling andSOURCE SUM Correlation), adding takes place when any DETAIL isbeing GENERATEd that contains the same identifier as a SOURCEitem as the identifier appearing in the SUM clause.

  2. If the UPON phrase is used, adding takes place when a DETAILgroup specified in that phrase is GENERATEd.

  3. If SOURCE SUM correlation is not in effect and there is no UPONphrase, adding takes place on each GENERATE that refers to thereport.

  Almost all totalling can also be accomplished by means of REPORT SECTION SUM clauses.

• Presenting the total

  When the entry containing you SUM is output, the (unedited) total to-date is used as an internal "source" for the contents of the field. Thus, if you had coded: 05 COL 5 PIC $$,$$$,$$9.99 SUM R-PAYMENT. The internal total field (which is fully described below under Use of Total Fields) is MOVEd to this report field, and edited according to the given PICTURE, according to the same rules as the SOURCE clause.

• Resetting the total

  The total is reset (cleared to zero) at the end of the processing for the report group in which it is defined, unless you override this using the RESET phrase as described below (see The RESET Phrase). Thus the total field remains available for use anywhere in the same group (within a SOURCE for instance) before its contents are erased.

• When adding a value into the total, the report writer code obeys the rules of the ADD statement. Unless you coded SUM OVERFLOW PROCEDURE IS OMITTED in the RD, a SIZE ERROR test is always done and if there is size error, a run time error is signalled at once.

• If the SUM clause appears in a multiple CONTROL FOOTING group, the SUM clause has its usual effect in the lowest level group and in the higher levels acts by rolling forward each previous level. For example, in the following structure:

    01 TYPE CF FOR STATE COUNTY CITY. 
       ... 
       05 COL 1 PIC ZZZ9 SUM OF W-PAY.
  

  the SUM clause acts like three different SUM clauses. At the lowest level (CITY), it behaves as defined (by subtotalling W-PAY). The CITY total is then rolled forward into the COUNTY total on change of CITY and the COUNTY total is rolled forward into the STATE total on change of COUNTY.

• Summing a Repeated Item

  If you wish to sum a repeating item, you may form totals along any of four different axes. These are, from minor to major:

  • Axis 1: COLUMN Axis

  • Axis 2: COLUMN-Group Axis (below LINE and above COLUMN)

  • Axis 3: LINE Axis

  • Axis 4: LINE-Group Axis (above LINE and below report group)

  Report writer will automatically total the repetitions of your field along any axes necessary to form the total. The direction of the adding depends not on the syntax of the clause you use but on where you place it. If your SUM clause has no repetitions at all (is not subject to an OCCURS clause or a multiple LINE or COLUMN clause), report writer will total all occurrences of the field. You can thus total a REPORT SECTION table of any number of dimensions. If your SUM clause is part of a repeating report field, then the item being summed must repeat the same number of times along the same axes as the SUM entry. Your field will be output along any of the axes shared and totalled along any of the axes not shared by the SUM entry. An example will make this clearer. In the following case, the field R-QUARTER has an OCCURS clause in two axes: the LINE axis and the COLUMN axis.

  

  To obtain row totals, code the SUM clause as an entry at a level within the same LINE as the items referred to in SUM. (The entry below is named ROW-TOTAL but you may choose any data-name). To obtain column totals, place the SUM clause within a separate LINE and give it the same number of horizontal repetitions as its operand. (The entry below is arbitrarily named COL-TOTAL.) The final result is as follows:

  

  Notice that the field ALL-TOTAL could also have been coded as SUM OF R-QUARTER (which is less efficient) or SUM OF ROW-TOTAL. Also notice that the data-names ROW-TOTAL and ALL-TOTAL are not referenced and could have been omitted.

• You may require just a single total of all the entries (the "corner" total in the above illustration), without any row or column totals. Just write the ALL-TOTAL entry alone:

  

• Other Axes

  The examples shown earlier cover only two out of the four possible axes. You may also SUM along the other two axes, that is: groups of COLUMNs and groups of LINEs. As an example of groups of COLUMNs, take this layout, where we total the four weeks in each month horizontally:

  

  This example also illustrates the fact that cross-foot totals need not appear to the right, or below, the figures from which they are formed.

• If your program contains more than one report, you are not restricted only to rolling forward within one report. A SUM clause in one report may refer to a named numeric data item in a different report. As with totalling in a single report, the value of the referenced field is added whenever the field is output. (This does not apply to non-REPORT SECTION summing, however, when SOURCE SUM correlation is in effect: see ALLOW clause.) Note that all total fields in a Report are cleared by the INITIATE statement for the report. Therefore, if you need to SUM from one report to another, be sure that both are INITIATEd at the start of the processing.

• A PRESENT WHEN clause may test the value of any total fields referenced in its condition-operand. However, it should then not contain within its scope either an entry with a SUM clause or an entry that is summed by a SUM clause. See Effect of PRESENT WHEN on SUM.

• Totalling Unprintable Items

  You may total unprintable items in your REPORT SECTION. This is useful when you want to print the totals only, not the unprinted individual values. In the next example, the report computes a yearly total from 12 unprinted monthly values:

  

• It is not possible to accumulate in an instant a single total all the entries in a table outside your REPORT SECTION without using an intermediate unprintable table as in the example above. However, you may use a non-REPORT SECTION SUM clause to accumulate - over time - single entries in a table into a corresponding matching number of totals, typically in a CONTROL FOOTING. Since your SUM operand is not in the REPORT SECTION, you may use subscripts with it, just as you would in the SOURCE clause:

  

  An evaluation is performed for the expression on every GENERATE, before the result is added into the total field, so the use of this technique is less efficient - and more susceptible to rounding errors - than a method using unprintable intermediate totals. (The accumulation is not affected by the status of SOURCE SUM correlation.)

Use of total fields

If you give a data-name to an entry that contains a SUM clause (not a SUM term that is part of an expression), report writer will relate the data-name to its own (internal) total field, not to the (edited) external field in the report line, as would be the case with a SOURCE, VALUE, or FUNCTION clause. (The total field is called a sum-counter in older texts, but total field is clearer as it does not conflict with the COUNT clause.) Compare these two cases:

• With Source etc...

  

• With Sum

  

The internal total field is a pure numeric, signed COMPUTATIONAL field with as many integral and fractional digits as the SUM entry. Hence, no precision will be lost when the total field is stored in the report field. If the SUM clause refers to a REPORT SECTION item, the precision of the total field is increased if necessary so that it has at least as many integral and fractional digits as the entry being totalled. Hence the total will have at least the precision of the field being totalled, rounding or truncation taking place, if indicated, when the field is output, not while it is being accumulated. Here are some examples:

Note that the total field is always signed, even if the report line field is not signed, so the adding into the total field is always algebraic.

Accessing the total fields

You may access the internal total field directly in the following four ways.

• In a Source clause

  You may capture an internal total field with a SOURCE clause, either as its single operand or as a term in an operand that is an expression. The value you obtain depends on the category of the total field you access, as follows:

  1. Source refers to total field defined in the same report group

     You will always obtain a true value of the total as specified. The position of theSOURCE clause within the group is immaterial, as report writer always computesthe totals before producing any of the group's report lines (which is whenSOURCE operands are filled in).

     This feature is useful when you wish to form an unprintable total from a non-REPORT SECTION field without loss of precision and then output itROUNDED . You might wish to form totals to cents precision and outputthem to the nearest dollar. You should then write two entries in the same reportgroup, one of which has no COLUMN clause and is therefore unprintable, as in this example:

     

     the internal total field would have the implied PICTURE S9(6) COMP, so you would lose precision each time the (truncated) value of WS-FIELD is added in. Truncation would not arise if the SUM operand were a REPORT SECTION data-name, since the precision of the summed field is then also taken into account in establishing the required precision of the sum field.

     Alternatively, you may make use of report writer's less efficient but highly accurate default PICTURE S9(12)V9(6) for SUM terms in SOURCE clauses, by coding: 05 COL 21 PIC -(6)9 SOURCE (SUM OF WS-FIELD).

     The next example uses an arithmetic expression involving total fields:

     

     It would also have been correct to code the last entry as: 05 COL + 2 PIC Z(6)9 (SUM OF INCOME) - (SUM OF TAX).

     However, the first code shown is more economical since we are printing the individual totals R-TOT-INCOME and R-TOT-TAX already elsewhere and can therefore re-use them in the expression instead of summing them again.

  2. Source refers to total field not defined in same group (snapshots)

     If the SUM total field referred to in turn refers to a non-REPORTSECTION item (subtotalling) or to an entry in a different report group(rolling forward), you will obtain at that instant the up-to-date accumulated value, a technique which is useful for obtaining brought forward and carried forward totals, as in the layout on thefollowing page:

     

     

     We reference a SUM total field in a SOURCE to capture a snapshot of the running total. The SUM entry is gradually accumulated over a certain part of the report, so we obtain any number of versions of it at any state up to the eventual total. This, incidentally, gives us an alternative to the RESET phrase for forming cumulative (running) totals.

     In the sample code we save the SUM total field procedurally in a working location (WS-TOT-CASH) after each GENERATE and use that in the SOURCE for the next cycle. This is done for two reasons:

     It is independent of whether or not the option is in effect. The (standard but "less logical") option does rolling forward and subtotalling before the page-fit test (see GENERATE Processing Cycle), so our total fields will already have been updated by the new value of CASH and we would otherwise have to subtract it again in the SOURCE to get the true total. The option corrects this anomaly, but there is a second problem:

     Whichever option is in effect, the total field is reset to zero immediately after its CONTROL FOOTING group has been output, so it cannot appear in the PAGE FOOTING beneath it (the last page in our example, since the group is a CF FINAL). Hence the use of WS-TOT-CASH which is the current total "suspended from the last GENERATE".

     If we did not wish to print a grand total field from which to "snapshot" the values, we could define the total as an unprintable item (with no COLUMN clause).

  3. In a Present When clause

     You may test the value of a total field in a PRESENT WHEN's condition to control what is produced in the report group. The effective value will be the same as for the case with SOURCE above. However, if you do this, do not code any SUM clauses or any summed entries within the scope of your PRESENT WHEN clause. This avoids a deadlock situation where summing depends on conditions and conditions depend on summing. A useful example is the common requirement to suppress zero totals. The code should be as follows:

     

     TOTAL-CASH is an unprintable SUM entry that is - as necessary - outside the scope of the PRESENT WHEN. (If your entire LINE is subject to the PRESENT WHEN, place your unprintable field in another LINE of the same group. Since it is unprintable, its placement is immaterial.)

     You may use the total field even if it is defined later in the same group because totalling is completed for each group before production of any of the report lines begins.

  4. In the Main-Line PROCEDURE DIVISION

     You may capture the contents of a subtotalled or rolled forward total field in a main-line COBOL procedural statement. As an example of the use of this property, you may move a total field into a record in a different output file. This will save you the effort and inefficiency of totalling the same field independently. However, the contents of an unconditional cross-foot total will always be zero, because it will always have been output as soon as it was totalled. (A total field is reset to zero at the end of the report group in which it is defined, unless the RESET phrase defers this action – see The RESET Phrase.)

     You may also procedurally alter (that is, ADD TO, SUBTRACT FROM etc.) the value of any named total field at any time. Of course, if you do so the results that appear in the total fields will be different from those you would expect if report writer alone were accumulating the totals. You may also need to handle any possible size errors in the total field. The values you added or subtracted will be reset with the rest of the value at the usual time.

     Total fields are cleared to zero by the INITIATE statement. They will also normally be zero after execution of the TERMINATE statement. This is because they are always cleared after being output, and the TERMINATE statement outputs all CONTROL FOOTING groups and any PAGE FOOTING and REPORT FOOTING. However, if a SUM clause was coded in another type of group, such as a DETAIL, that is not automatically output when your program issues the TERMINATE, there could be a non-zero total waiting in vain to be output. Also, if the SUM clause was conditional, the field with the SUM might have been absent on the last occasion, in which case a non-zero total might still be waiting to be output. In all these cases, report writer will issue a run time error and the total will be cleared if and when your program issues another INITIATE for the corresponding report.

  5. In a Declarative SECTION

     You may also access total fields in a USE BEFORE REPORTING Declarative SECTION for any report group. As is the case with reference to sum totals in a SOURCE, described above (see a(ii)), the state of any total fields you may access depends on whether the OSVS option is in effect or not.

     Any cross-foot totals for the group will already have been calculated in all cases.

     If OSVS is in effect, any rolling forward (from this group into a different group) and subtotalling (if this is a DETAIL group, or a PH or PF triggered by a DETAIL group) are done before entry to the Declarative SECTION. Hence you will obtain all totals fully updated. (See 4.2.4 GENERATE Processing Cycle.)

     If OSVS is not in effect, by contrast, any rolling forward and subtotalling are done after entry to the Declarative SECTION. So, especially if your group is a PAGE FOOTING (or HEADING), you will obtain an accurate value of the total at that "physical point" in the report.

  6. Precision of SUM terms

     If you use SUM or COUNT as a term in a SOURCE's expression, report writer will assign the internal total field with PICTURE S9(12)V9(6) COMP , irrespective of the PICTURE of the report field.

Subtotalling and SOURCE SUM Correlation

Subtotalling is the term used when your SUM clause or SOURCE clause SUM term specifies a non-REPORT SECTION operand, that is, an item in your FILE, WORKING-STORAGE, or LINKAGE SECTION. OS/VS and DOS/VS COBOL-IT Report Writer, which is based on ANS-68, depends on subtotalling for forming most totals. With report writer, you should rely instead on rolling forward, by giving a data-name to a DETAIL group's SOURCE entry, so that there is no need to worry about when the items are added into the total fields. However, there are still times when subtotalling might be preferred, such as when you are creating total lines in a summary report and have not coded SOURCE items in a DETAIL group to refer to. The rules of operation are as follows:

• Report writer adds the SUM operands ("addends") directly into the total field, following the normal rules of the ADD statement. If there is a size error, the same action takes place as for REPORT SECTION SUM totals, as described above.

• SOURCE SUM Correlation

  The decision as to when to add the items depends on whether SOURCE SUM correlation is in effect. This is the chief difference between the ANS-68 standard used in OS/VS and DOS/VS COBOL, which automatically applies SOURCE SUM correlation, and the ANS-74 and ANS-85 standards, which do not. You will observe a difference only when the following circumstances occur simulataneously:

  When your report has more than one DETAIL group; and

  When your program SUMs an operand that is also a non-REPORT SECTION SOURCE operand in one or more of the DETAIL groups.

  Otherwise, report writer will not apply SOURCE SUM correlation. SOURCE SUM correlation is in effect if:

  The precompiler was installed with the OSVS option set on, or

  You code an ALLOW SOURCE SUM CORR clause in your RD.

  SOURCE SUM correlation is not in effect if:

  Your system was installed with the OSVS option set off (ANS74 or ANS85), or, You code an ALLOW NO SOURCE SUM CORR clause in your RD.

• If SOURCE SUM correlation is in effect, report writer takes each non-REPORT SECTION operand specified in your SUM clause and scans the DETAIL groups of your report to establish whether the same item is coded in more than one of them as a SOURCE operand. (The SOURCE keyword may, as usual, have been omitted.) Arithmetic expressions are not examined. Redefinitions of the same item and differences in subscripts or qualifiers (apart from interchanging the words IN and OF) mean that there is no match. All your DETAIL groups are scanned in this way. The appearance of the same operand more than once as a SOURCE in the same DETAIL counts as only a single match. If a match is found, report writer will add the item into the total field only when the DETAIL or DETAILs that contain your item are GENERATEd. If no match is found, report writer will add the item into the total field on every GENERATE for that report.

• Using a dummy DETAIL group for Summary Reporting

  With the ANS-68 standard of OS/VS and DOS/VS COBOL, a corresponding SOURCE was required for every SUM. This meant that in a totals only report, a dummy DETAIL group needed to be defined, as in the following sample:

  

  Although report writer accepts this code unaltered, the dummy group is now unnecessary - even if SOURCE SUM correlation is in effect. The dummy group in the example above may be deleted and the GENERATE replaced by GENERATE report-name:

  

  More details will be found under Summary Reporting (see GENERATE statement).

• If SOURCE SUM correlation is not in effect, report writer will add every operand of the SUM clause into the total field on every GENERATE for the report.

Three methods of subtotalling

In the items just preceding, you observe that, if SOURCE SUM correlation is not in effect, adding into your total field will take place on each GENERATE for the report. This may not be suitable, especially when you have several DETAIL groups. If you have two record types, say SALARY and NAME-ADDRESS, with DETAIL groups that correspond to these, and you want the total of SALARY, you will clearly want the field SALARY to be added only when your program generates the SALARY DETAIL group. There are three ways of avoiding this problem, which are illustrated below.

The recommended method of report writer is to place a data-name on the entry to be totalled (omitting the COLUMN clause if it is not be printed), and SUM the item using that data-name.

If SOURCE SUM correlation is in effect and both the SOURCE operand and the SUM operand names are identical, the item will be added, as expected, only when the SALARY group is GENERATEd.

Using the UPON phrase. You may use this whether or not SOURCE SUM correlation is in effect, because UPON overrides its effect. By writing UPON SALARY-GRP (where SALARY-GRP is the 01-level name of your DETAIL group), you ensure that the item will be added into the total only when the SALARY-GRP DETAIL group is GENERATEd.

The next example compares these methods:

• Method Using REPORT SECTION SUM (recommended)

  

• Using SOURCE SUM Correlation

  

• Using the Upon Phrase

  

The Reset phrase

In all our examples presented earlier in this section, the total field is reset to zero at the end of the processing for the group in which it has appeared. Sometimes you will not want this to happen. Such a case is called a cumulative (or running) total. Here the total is not necessarily cleared or reset after it has been output. Values then continue to be added into the total. You will have seen above that you can capture cumulative totals by "taking a snapshot" of a higher-level total field. Another method is to use the RESET phrase. Its operand states at which (normally higher) level of control break, if any, the total field is to be cleared. If you specify RESET ON REPORT (or RESET ON FINAL), the total field will not be reset after the final control footing has been presented, during the execution of the TERMINATE.

For example, by writing: 03 COL 20 PIC ZZZ9.99 SUM OF ACC-BAL RESET ON BRANCH-CODE.

You ensure that the total field is not cleared until a new BRANCH-CODE is reached. Here is an example of a cumulative total:

Compatibility

The following features are unique to new Report Writer:

• Optional word OF after keyword,
• SUM operand can be an expression formed from non-REPORT SECTION items,
• SUM as a term in an expression in a SOURCE clause,
• SUM clause in report groups other than of TYPE CONTROL FOOTING,
• The ROUNDED phrase.

OS/VS and DOS/VS COBOL Report Writer, in common with ANS-68 and ANS-74 requires that any REPORT SECTION item whose data-name is the operand of a SUM must itself be a SUM entry, that is, only SUM entries may be rolled forward or used for cross footing. OS/VS and DOS/VS COBOL Report Writer always assumes SOURCE SUM correlation. It uses the ANS-68, not the ANS-74, rules.

The automatic check for overflow is unique to new Report Writer. A migrated program which produced truncated totals will now produce blank fields instead, plus run time error message 11. In the unlikely event that this truncation is intentional, the clause SUM OVERFLOW PROCEDURE IS OMITTED should be placed in the RD.