27
Fri, Dec
0 New Articles

RPG Control Break Fundamentals

RPG
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

The feature I like most about RPG is its handling of certain business-oriented tasks with a minimal amount of coding. One common business task is presenting information in groups-for example, grouping items sold by store or grouping items returned by item type. In programming terms, these are known as control groups.

RPG handles control groups with very little programming effort. In the paragraphs to follow, I will discuss the concepts behind control break processing and show you a method of writing clean, easy-to-understand RPG code that takes advantage of RPG's built-in control break processing feature.

Control Break Basics

A control break occurs when the value of a certain field changes from one record to the next as a file is being read sequentially. Fields checked for changes are called control fields. An example of a control field might be a department number field.

Data read by control break programs should be sequenced by the control fields. Control breaks don't absolutely require a sorted file, but it rarely makes sense to check for a control break on unordered data. The most common ways to order the data on the AS/400 are through access paths created by logical files, the Open Query File (OPNQRYF) command, and the Format Data (FMTDTA) command.

Take a look at the file of returned goods in 1. If reason returned is a control field, there are four control breaks in this series of records. The first control break occurs when the first record is read, because the reason returned changes from nothing to 1. The first record read always triggers a control break-this is part of the definition of control breaks. The second control break occurs between records 5 and 6, when the reason returned changes from 1 to 2. The third control break is between records 11 and 12. The last control break occurs after the last record has been read, when the reason returned changes from 3 to nothing.

Take a look at the file of returned goods in Figure 1. If reason returned is a control field, there are four control breaks in this series of records. The first control break occurs when the first record is read, because the reason returned changes from nothing to 1. The first record read always triggers a control break-this is part of the definition of control breaks. The second control break occurs between records 5 and 6, when the reason returned changes from 1 to 2. The third control break is between records 11 and 12. The last control break occurs after the last record has been read, when the reason returned changes from 3 to nothing.

Hitting the end of the file needs to trigger a control break so that the processing for the current control field value can occur. The records that share common control field values are called control groups. In the example just given, there are three control groups-one for each reason returned code.

In 2, you can see a report generated from the returned goods data. (The order of the detail records is slightly different from their order in the file because the item number was specified as a secondary sort key.) Notice the clear break between each reason code.

In Figure 2, you can see a report generated from the returned goods data. (The order of the detail records is slightly different from their order in the file because the item number was specified as a secondary sort key.) Notice the clear break between each reason code.

Multilevel Control Breaks

Sometimes there is a need to summarize information within other summaries. We could summarize returns by item number for each reason. This would not only tell us how much merchandise (in dollars) was returned for a given reason, but how much each item accounted for. Item number would be a minor break within the major break by reason code. We could break the data down even further by making store a control field subordinate to item number. This would give us summary information by store.

The report in 3 shows subtotals within subtotals. The sum of the first two detail records yields a subtotal for the Batesville store. The Batesville and Vicksburg subtotals added together produce a subtotal for brooms (item 101). Since only brooms and dusters were returned because they were broken or damaged, their subtotals add up to the total for reason code 1 (item was broken or damaged). All three reason subtotals add up to the grand total for all returned goods.

The report in Figure 3 shows subtotals within subtotals. The sum of the first two detail records yields a subtotal for the Batesville store. The Batesville and Vicksburg subtotals added together produce a subtotal for brooms (item 101). Since only brooms and dusters were returned because they were broken or damaged, their subtotals add up to the total for reason code 1 (item was broken or damaged). All three reason subtotals add up to the grand total for all returned goods.

A change in a control field forces all subordinate breaks. Look again at the returns report in 3. The control fields are reason code, item number, and store (in major to minor order). There is no change in store between the last two records, yet there is a control break in store at that point because of the change in reason code.

A change in a control field forces all subordinate breaks. Look again at the returns report in Figure 3. The control fields are reason code, item number, and store (in major to minor order). There is no change in store between the last two records, yet there is a control break in store at that point because of the change in reason code.

When a control break occurs, you carry out some kind of special action. Common things you might do are:

o Retrieve additional information about the control field from another file.

o Leave an extra blank line on a report to separate the previous control group from the next one.

o Print totals for the previous control group.

o Print headings for the next control group.

RPG Syntax for Control Breaks

The RPG cycle has built-in logic to handle control breaks. To indicate a control field, assign a level indicator, L1-L9, to the field in the input specs (as illustrated by the statement at label A in 4). L1 is the lowest in the hierarchy of the level indicators, and L9 is the highest. For a discussion of the basics of the RPG cycle, see the sidebar, "A Brief Overview of the RPG Cycle."

The RPG cycle has built-in logic to handle control breaks. To indicate a control field, assign a level indicator, L1-L9, to the field in the input specs (as illustrated by the statement at label A in Figure 4). L1 is the lowest in the hierarchy of the level indicators, and L9 is the highest. For a discussion of the basics of the RPG cycle, see the sidebar, "A Brief Overview of the RPG Cycle."

Program RTN003RG, in 4, defines reason code as a control field. Any level indicator would be acceptable, but I've used L1. When the value of REASN changes from one record to the next, indicator L1 will turn on. It will be on during the total calculations and total output sections of the cycle for the group just ending, and it will remain on through the detail calculations and detail output for the new control group.

Program RTN003RG, in Figure 4, defines reason code as a control field. Any level indicator would be acceptable, but I've used L1. When the value of REASN changes from one record to the next, indicator L1 will turn on. It will be on during the total calculations and total output sections of the cycle for the group just ending, and it will remain on through the detail calculations and detail output for the new control group.

RPG has an easy way to distinguish between the beginning and end of a control group. If you want to carry out a calculation when starting a new control group, use the level indicator in the detail calculations (there is no level indicator in columns 7-8 of the calculation spec). If you want to perform the operation at the end of a control group, code the level indicator in positions 7-8 of the calculation spec.

In RTN003RG, the statements labeled B in 4 are executed at the beginning of a group of records with a common reason code. This first clears out counters and accumulators for the group; second, looks up the description of the reason code in an array; and third, sets indicator 71 on for group indication.

In RTN003RG, the statements labeled B in Figure 4 are executed at the beginning of a group of records with a common reason code. This first clears out counters and accumulators for the group; second, looks up the description of the reason code in an array; and third, sets indicator 71 on for group indication.

Group indication means that control field information only prints at the beginning of a group. Group indicated fields are often printed after a page break, as well. You would normally use the level indicator (L1-L9) for group indication, but here, since I'm using an external printer file in which level indicators are invalid, I must use an indicator between 01 and 99.

The statements labeled D in 4 are executed at the end of each control group. The first task that must be done is to add the totals for the group into grand totals and then print a summary line for the group.

The statements labeled D in Figure 4 are executed at the end of each control group. The first task that must be done is to add the totals for the group into grand totals and then print a summary line for the group.

The statements labeled C in 4 are the regular detail calcs, which are executed for each input record.

The statements labeled C in Figure 4 are the regular detail calcs, which are executed for each input record.

We have already seen the report produced by this program in 2. I've included the DDS for the printer file in 5.

We have already seen the report produced by this program in Figure 2. I've included the DDS for the printer file in Figure 5.

A Multilevel Control Break Example

6 shows another program, RTN004RG, which is a variation of RTN003RG. This program differs in that there are three control levels. Reason is still the major control break, but I assigned L3 to it because of the two subordinate breaks I added. Indicator L2 is assigned to the intermediate break on item number, and L1 to the minor break on store.

Figure 6 shows another program, RTN004RG, which is a variation of RTN003RG. This program differs in that there are three control levels. Reason is still the major control break, but I assigned L3 to it because of the two subordinate breaks I added. Indicator L2 is assigned to the intermediate break on item number, and L1 to the minor break on store.

RPG always forces the lower level indicators on for a control break. When the value of reason code changes, the program will set on the L3, L2, and L1 indicators, even if there is no change in item number or store. If the reason code is the same, but the value of the item number changes, the program will turn on L2 and L1. If the reason code and item number remain the same, but the store number changes, only L1 will turn on.

During the first cycle, there is no prior control group to force any type of control break. For this reason, RPG forces indicators L1 through L9 on during the first cycle. If these indicators were not forced on, the program would process the first control group before any level indicators came on. Control heading output, or any detail calculations that must be done before the group begins, would not be executed for the first control group.

At end of job, when there is no next control group, the RPG cycle will force all level indicators on when it sets on LR. This executes total calculations and generates total output for the last control group.

The statements labeled A in 6 are executed only during the first record of each control group. The calculations run in major to minor order. That is, the L3 calcs precede the L2 calcs, which precede the L1 calcs.

The statements labeled A in Figure 6 are executed only during the first record of each control group. The calculations run in major to minor order. That is, the L3 calcs precede the L2 calcs, which precede the L1 calcs.

At each level, the first task to be done is to clear out the accumulator variables for that level. Once that is done, we carry out the one-time calculations for the group. For reason code, this means looking up the reason description in an array. For item number, it means retrieving the item's description from its record in the item master file. The final task is to turn on the appropriate indicator to cause group indication.

The detail calcs are marked as label C in 6. Here we calculate the extended sales amount, XAMT, which is based on data from one input record. Then we accumulate the quantity returned and the extended amount into the first level of accumulators.

The detail calcs are marked as label C in Figure 6. Here we calculate the extended sales amount, XAMT, which is based on data from one input record. Then we accumulate the quantity returned and the extended amount into the first level of accumulators.

Before printing the detail line (label D in 6), we check for page overflow at label B. If we've reached the end of the page, we set the detail line for group indication (by setting on the indicators) and print the page headings.

Before printing the detail line (label D in Figure 6), we check for page overflow at label B. If we've reached the end of the page, we set the detail line for group indication (by setting on the indicators) and print the page headings.

The total calculations, label E in 6, are executed when the control groups end. The calculations run in minor to major order, with LR considered the highest level control break indicator. The only tasks to be done here are to add the accumulators into the next highest level and to print the subtotals.

The total calculations, label E in Figure 6, are executed when the control groups end. The calculations run in minor to major order, with LR considered the highest level control break indicator. The only tasks to be done here are to add the accumulators into the next highest level and to print the subtotals.

I've included parts of the printer file in 7 for your reference. The generated report is the one we saw earlier in 3.

I've included parts of the printer file in Figure 7 for your reference. The generated report is the one we saw earlier in Figure 3.

It's just as easy to condition output specifications at the beginning or end of a control group. Header and detail lines in a program described printer file ('H' or 'D' in column 15 of the output spec) with a level indicator will be printed at the beginning of the control group. Total lines ('T' in column 15) are generated at the end of the control group. The example program doesn't show this, since I chose to use an externally described printer file, so I've included an example of output specs in 8.

It's just as easy to condition output specifications at the beginning or end of a control group. Header and detail lines in a program described printer file ('H' or 'D' in column 15 of the output spec) with a level indicator will be printed at the beginning of the control group. Total lines ('T' in column 15) are generated at the end of the control group. The example program doesn't show this, since I chose to use an externally described printer file, so I've included an example of output specs in Figure 8.

Another common type of report is the summary report. In this type of report, no detail lines are generated. Instead, all lines are subtotals. Writing a summary report program is no harder than writing the detail reports we've already looked at. All you have to do is not print any detail output.

Give Me a Break!

I have summarized how I write control break programs in Figures 9 and 10. These ideas are intended to be taken as principles, not rules. There are other ways of doing the same thing. For example, I suggest you clear accumulators before beginning a control group. An alternative is to clear them at the end of a control group, after they have been written to an output file and/or accumulated into the next highest level. Another alternative is to use the blank-after feature in output specs, but I have traced so many bugs to blank- after that I wouldn't recommend using it.

Control breaks have been around since the earliest days of data processing. They will always be with us because people need to see subtotals and summary information. I encourage you to adopt a clean, consistent methodology for working with control breaks.

Next month, I'll show you how to write procedural code to handle control breaks. I hope you'll find it useful.

Ted Holt is an associate technical editor for Midrange Computing.

REFERENCE RPG Reference Manual (SC09-1817, CD-ROM QBKAQV00).

A Brief Overview of the RPG Cycle

Report Program Generator (RPG) was designed to handle typical data processing tasks, primarily file processing and report generation. It's not a language you'd use to write a compiler or to calculate rocket trajectories, but it was never intended to be.

The feature that most distinguishes RPG from other programming languages is that it includes logic to do the things most data processing programs require. For example, since the typical data processing job requires the use of files- which have to be opened, closed, read, updated, and added to-RPG has built-in logic to handle these things. Using the RPG cycle, the programmer does not have to do any of these.

Unlike procedural languages, such as COBOL, which require the programmer to provide step-by-step instructions to bring about an intended result, RPG allows the programmer to work at a slightly higher level of abstraction. That is, the RPG programmer describes the results he wants, and the compiler fills in many of the details required to get them.

For instance, the programmer might specify that a certain heading record is to be printed at the top of each page of a report by conditioning the line to the 1P (first page) and OF (overflow) indicators. This frees him from having to determine when his program is about to write across a page break (usually by counting lines as he prints them) and from explicitly having to write the headings.

Among the things the RPG cycle will do are:

o Open and close files. o Read from files. o Write to files (add new records, update and delete existing ones). o Check for page overflow. o Check for control breaks. o Process files in parallel by matching record fields.

A programmer who understands the RPG cycle can write programs with fewer calculations by conditioning parts of the program to specific points in the cycle. The cycle logic can be summarized as illustrated in A1.

A programmer who understands the RPG cycle can write programs with fewer calculations by conditioning parts of the program to specific points in the cycle. The cycle logic can be summarized as illustrated in Figure A1.

A complete description of the RPG cycle is given in the RPG Reference Manual. The flowchart of the detailed logic may seem overwhelming, but if you wish to understand the cycle, you might first look at the general flowchart, which includes only seven steps.

One problem the cycle has is that its built-in logic is not appropriate for all data processing tasks. An example is with interactive programs. It is possible to write good code to process workstation files using the cycle (I have seen such programs), but most midrange RPG programmers, myself included, find it easier to write cleaner code for interactive programming by bypassing the cycle.

Early RPG programmers had no choice but to make the cycle fit. Today's programmers have the alternatives of exception output and procedural reads.

Some say the cycle is obsolete, that the programmer should always write procedural code. The problem with procedural code is that any intelligence built into the compiler is ignored.

The computer languages of the future will very likely allow people (who will probably not have to be programmers) to describe to the computer the results they are seeking, rather than the steps required to get them. Instead of saying to the computer, "Follow these steps precisely, and I will get the output I desire," a person will say, "This is the output I desire; you figure out how to get it for me." RPG never got anywhere near this ideal, but it was a step in that direction away from the purely procedural code of assembler languages, FORTRAN, and COBOL. In this sense, RPG, because of its cycle, was ahead of its time.


RPG Control Break Fundamentals

Figure 1 Returned Goods Data

 Trans. Trans. Item Quantity Unit Reason number date number Store sold price returned 1 78333 94/12/02 101 BAT -4 10.00 1 2 78338 94/12/02 101 BAT -2 10.00 1 3 78363 94/12/02 101 VIC -1 10.50 1 4 78327 94/12/02 103 BAT -50 .80 1 5 78315 94/12/01 103 VIC -1 9.50 1 6 78319 94/12/01 109 BAT -500 1.50 2 7 78314 94/12/01 109 NAT -75 1.25 2 8 78348 94/12/02 109 OXF -250 1.25 2 9 78388 94/12/03 109 OXF -300 1.50 2 10 78321 94/12/02 114 NAT -100 .25 2 11 78392 94/12/03 114 NAT -50 .25 2 12 78311 94/12/01 109 NAT -250 1.50 3 
RPG Control Break Fundamentals

Figure 2 Single-level Report Produced by Program RTN003RG

 12/16/94 Returned Goods Page 1 Store --Transaction--- Unit Extended ------Reason------- -----Item----- nbr nbr date Qty price price 1 Broken/damaged 101 BROOM BAT 78333 94/12/02 4 10.00 40.00 101 BROOM BAT 78338 94/12/02 2 10.00 20.00 101 BROOM VIC 78363 94/12/02 1 10.50 10.50 103 DUSTER VIC 78315 94/12/01 1 9.50 9.50 103 DUSTER BAT 78327 94/12/02 50 .80 40.00 Total reason 1 58 120.00 2 Not as expected 109 TOWELS BAT 78319 94/12/01 500 1.50 750.00 109 TOWELS NAT 78314 94/12/01 75 1.25 93.75 109 TOWELS OXF 78348 94/12/02 250 1.25 312.50 109 TOWELS OXF 78388 94/12/03 300 1.50 450.00 114 BAGS NAT 78321 94/12/02 100 .25 25.00 114 BAGS NAT 78392 94/12/03 50 .25 12.50 Total reason 2 1275 1643.75 3 Other 109 TOWELS NAT 78311 94/12/01 250 1.50 375.00 Total reason 3 250 375.00 Grand totals 1583 2138.75 
RPG Control Break Fundamentals

Figure 3 Multilevel Control Break Report Produced by RTN004

 12/16/94 Returned Goods Page 1 Store --Transaction--- Unit Extended ------Reason------- -----Item----- nbr nbr date Qty price price 1 Broken/damaged 101 BROOM BAT 78333 94/12/02 4 10.00 40.00 78338 94/12/02 2 10.00 20.00 Total store BAT 6 60.00 VIC 78363 94/12/02 1 10.50 10.50 Total store VIC 1 10.50 Total item 101 7 70.50 103 DUSTER BAT 78327 94/12/02 50 .80 40.00 Total store BAT 50 40.00 VIC 78315 94/12/01 1 9.50 9.50 Total store VIC 1 9.50 Total item 103 51 49.50 Total reason 1 58 120.00 2 Not as expected 109 TOWELS BAT 78319 94/12/01 500 1.50 750.00 Total store BAT 500 750.00 NAT 78314 94/12/01 75 1.25 93.75 Total store NAT 75 93.75 OXF 78348 94/12/02 250 1.25 312.50 78388 94/12/03 300 1.50 450.00 Total store OXF 550 762.50 Total item 109 1125 1606.25 114 BAGS NAT 78321 94/12/02 100 .25 25.00 78392 94/12/03 50 .25 12.50 Total store NAT 150 37.50 Total item 114 150 37.50 Total reason 2 1275 1643.75 3 Other 109 TOWELS NAT 78311 94/12/01 250 1.50 375.00 Total store NAT 250 375.00 Total item 109 250 375.00 Total reason 3 250 375.00 Grand totals 1583 2138.75 
RPG Control Break Fundamentals

Figure 4 RPG program RTN003RG

 * Returned goods report, version 1 * * Indicator summary * 71 - Group indicate reason * 88 - Page overflow * 91 - General indicator * FRTN002PFIP E K DISK FITM001PFIF E K DISK FRTN003P1O E PRINTER * Reason codes & descriptions E RC 1 3 3 0 RD 15 IRTNS I REASN L1 C *INL1 IFEQ *ON C MOVE *ZERO QTY#R C MOVE *ZERO XAMTR C Z-ADD1 RX 30 C REASN LOKUPRC,RX 91 C *IN91 IFEQ *ON C MOVELRD,RX REASND C ELSE C MOVE *BLANKS REASND C ENDIF C MOVE *ON *IN71 C ENDIF * C ITEM# CHAINITM001PF 91 C *IN91 IFEQ *ON C MOVE *ALL'?' ITEMDS C ENDIF * C QTY MULT PRICE XAMT C ADD QTY QTY#R C ADD XAMT XAMTR * C *IN88 IFEQ *ON C MOVE *ON *IN71 C WRITEPAGEHDR C MOVE *OFF *IN88 C ENDIF * C WRITEDTLLINE C MOVE *OFF *IN71 * CL1 ADD QTY#R QTY#G CL1 ADD XAMTR XAMTG CL1 WRITERSNTOTAL * CLR WRITEGRDTOTAL ********** C *INZSR BEGSR * C WRITEPAGEHDR * C ENDSR ** Reasons 001Broken/damaged 002Not as expected 003Other 
RPG Control Break Fundamentals

Figure 5 Printer file RTN003P1

 A REF(RETURNS) A R PAGEHDR SKIPB(4) A 1DATE EDTCDE(Y) A 33'Returned Goods' A 80'Page' A +0PAGNBR EDTCDE(4) SPACEA(2) A 36'Store' A 42'--Transaction---' A 73'Unit' A 85'Extended' SPACEA(1) A 1'------Reason-------' A 21'-----Item-----' A 36'nbr' A 42'nbr date' A 63'Qty' A 72'price' A 88'price' SPACEA(1) A R DTLLINE SPACEB(1) A 71 REASN R 1 A 71 REASND 15 5 A ITEM# R 21 A ITEMDS 10 25 A STORE# R 36 A XACT# R 42 A XACTDT R 50 A QTY R 61EDTCDE(4) A PRICE R 68EDTCDE(3) A XAMT R +3 82REFFLD(PRICE) EDTCDE(4) A R RSNTOTAL SPACEB(2) SPACEA(1) A 42'Total reason' A REASN R +1 A QTY#R R +1 60REFFLD(QTY) EDTCDE(4) A XAMTR R +1 81REFFLD(XAMT *SRC) EDTCDE(4) A R GRDTOTAL SPACEB(1) A 42'Grand totals' A QTY#G R +1 60REFFLD(QTY) EDTCDE(4) A XAMTG R +1 81REFFLD(XAMT *SRC) EDTCDE(4) 
RPG Control Break Fundamentals

Figure 6 RPG program RTN004RG

 * Returned goods report, version 2 * * Indicator summary * 71 - Group indicate reason * 72 - Group indicate item * 73 - Group indicate store * 88 - Page overflow * 91 - General indicator * FRTN002PFIP E K DISK FITM001PFIF E K DISK FRTN004P1O E PRINTER * Reason codes & descriptions E RC 1 3 3 0 RD 15 IRTNS I REASN L3 I ITEM# L2 I STORE#L1 C *INL3 IFEQ *ON C MOVE *ZERO QTY#R C MOVE *ZERO XAMTR C Z-ADD1 RX 30 C REASN LOKUPRC,RX 91 C *IN91 IFEQ *ON C MOVELRD,RX REASND C ELSE C MOVE *BLANKS REASND C ENDIF C MOVE *ON *IN71 C ENDIF * C *INL2 IFEQ *ON C MOVE *ZERO QTY#I C MOVE *ZERO XAMTI C ITEM# CHAINITM001PF 91 C *IN91 IFEQ *ON C MOVE *ALL'?' ITEMDS C ENDIF C MOVE *ON *IN72 C ENDIF * C *INL1 IFEQ *ON C MOVE *ZERO QTY#S C MOVE *ZERO XAMTS C MOVE *ON *IN73 C ENDIF * C QTY MULT PRICE XAMT C ADD QTY QTY#S C ADD XAMT XAMTS * C *IN88 IFEQ *ON C MOVE *ON *IN71 C MOVE *ON *IN72 C MOVE *ON *IN73 C WRITEPAGEHDR C MOVE *OFF *IN88 C ENDIF * C WRITEDTLLINE C MOVE *OFF *IN71 C MOVE *OFF *IN72 C MOVE *OFF *IN73 * CL1 ADD QTY#S QTY#I CL1 ADD XAMTS XAMTI CL1 WRITESTRTOTAL * CL2 ADD QTY#I QTY#R CL2 ADD XAMTI XAMTR CL2 WRITEITMTOTAL * CL3 ADD QTY#R QTY#G CL3 ADD XAMTR XAMTG CL3 WRITERSNTOTAL * CLR WRITEGRDTOTAL ********** C *INZSR BEGSR C WRITEPAGEHDR C ENDSR ** Reasons 001Broken/damaged 002Not as expected 003Other 
RPG Control Break Fundamentals

Figure 7 Printer file RTN004P1

 A REF(RETURNS) A R PAGEHDR SKIPB(4) A 1DATE EDTCDE(Y) A 33'Returned Goods' A 80'Page' A +0PAGNBR EDTCDE(4) SPACEA(2) A 36'Store' A 42'--Transaction---' A 73'Unit' A 85'Extended' SPACEA(1) A 1'------Reason-------' A 21'-----Item-----' A 36'nbr' A 42'nbr date' A 63'Qty' A 72'price' A 88'price' SPACEA(1) A R DTLLINE SPACEB(1) A 71 REASN R 1 A 71 REASND 15 5 A 72 ITEM# R 21 A 72 ITEMDS 10 25 A 73 STORE# R 36 A XACT# R 42 A XACTDT R 50 A QTY R 61EDTCDE(4) A PRICE R 68EDTCDE(3) A XAMT R +3 82REFFLD(PRICE) EDTCDE(4) A R RSNTOTAL SPACEB(2) SPACEA(1) A 42'Total reason' A REASN R +1 A QTY#R R +1 60REFFLD(QTY) EDTCDE(4) A XAMTR R +1 81REFFLD(XAMT *SRC) EDTCDE(4) A R GRDTOTAL SPACEB(1) A 42'Grand totals' A QTY#G R +1 60REFFLD(QTY) EDTCDE(4) A XAMTG R +1 81REFFLD(XAMT *SRC) EDTCDE(4) A R STRTOTAL SPACEB(2) SPACEA(1) A 42'Total store' A STORE# R +1 A QTY#S R +1 60REFFLD(QTY) EDTCDE(4) A XAMTS R +1 81REFFLD(XAMT *SRC) EDTCDE(4) A R ITMTOTAL SPACEB(1) SPACEA(1) A 42'Total item' A ITEM# R +1 A QTY#I R +1 60REFFLD(QTY) EDTCDE(4) A XAMTI R +1 81REFFLD(XAMT *SRC) EDTCDE(4) 
RPG Control Break Fundamentals

Figure 8 Using Level Indicators in Output Specs

 *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ... O* This line is printed at the beginning of a control group OQSYSPRT H 205 L1 O* or OQSYSPRT D 205 L1 ... O* This line is printed at the beginning of a control group O* or upon page overflow OQSYSPRT H 205 OFNL1 O OR L1 ... O* Field REASN and REASND will only be printed for the first O* record of a control group (group indicated) OQSYSPRT D 1 01 O L1 REASN 3 O L1 REASND + 1 ... O* This line is printed at the end of a control group OQSYSPRT T 2 L1 *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ... 
RPG Control Break Fundamentals

Figure 9 Order of Calculation Specs for Typical Control Bre

 1. First time only calcs that can't go in *INZSR 2. Highest level detail calcs through lowest level detail calcs (i.e., L9-L1 order) 3. Detail calcs (for 1 record only) 4. Lowest level total calcs through highest level total calcs (i.e., L1-L9 order) 5. Last record (LR) calcs 
RPG Control Break Fundamentals

Figure 10 Control Break Methodology

 Tasks to do at the beginning of a control group: - Clear accumulators and counters that will summarize the control group. - Perform any operations that need to be done only once for the group, such as reading information about the control field from another file. - Print control headings. Tasks for each record in the input file: - Carry out operations that apply to only one data record. - Accumulate totals for the lowest level control group. - Print a detail line (unless your program is producing summary information only). Tasks to do at the end of a control group: - Do any tasks that should be done only once for the group, but couldn't be done before the group began. - Output any accumulators or summary figures for the control group. - Add accumulators to the next highest control group. 
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: