Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Optimizing report summary

Status
Not open for further replies.

Ju5

Programmer
May 25, 2007
85
0
0
PH
I have been asked to create a program that will generate a summary with three report breaks. The breaks should be Field A > Field B > Field C(see below).

My problem is that the program I'm using takes up a lot of system resource and time to generate the report. I had to end the jobs before it finished its run because of the performance issues. The input file I'm using has 9000+ records and has already been sorted according to the breaks mentioned above.

This is the Input:
A B C <- column name

A11,PTM,1399 , .040-
A11,PTM,1399 , 2,220,154.090
A11,PTM,1399 , .190-
A11,PTM,1399 , .010-
E11,PTM,1554 , 42.540
E11,PTM,1554 , 11.280-
E11,PTM,1554 , 19.790
G11,PTM,1502 , .100-
G11,PTM,1502 , .080
G11,PTM,1502 , .350-
G11,PTM,1502 , .390-


Output should look like this:
A11,PTM,1380 , 176655.310
A11,PTM,1399 , 2025805.960
E11,PTM,1554 , 113.280
E11,PTM,1577 , 3392.580
G11,PTM,1411 , .010

Here's the code I'm using:
C READ input LR
/FREE
DOW NOT %EOF;
/END-FREE
C MOVE A A1
C MOVE B B1
C MOVE C C1
C Z-ADD 0 SUM
/FREE
DOW A = A1;
DOW B = B1;
DOW C = C1;
SUM = SUM + AMT;
/END-FREE
C READ input LR
/FREE
ENDDO;
EXCEPT #DET;
EXCEPT #SKIP;
/END-FREE
C MOVE C C1
C MOVE B B1
C MOVE A A1
C MOVE AMT SUM
C READ input LR
/FREE
ENDDO;
EXCEPT #DET;
EXCEPT #SKIP;
/END-FREE
C MOVE C C1
C MOVE B B1
C MOVE A A1
C MOVE AMT SUM
C READ input LR
/FREE
ENDDO;
EXCEPT #DET;
EXCEPT #SKIP;
/END-FREE
C MOVE C C1
C MOVE B B1
C MOVE A A1
C MOVE AMT SUM
C READ input
/FREE
ENDDO;
/END-FREE
*

How can I make processing faster and more efficient? Reducing the size of the input file does not seem to work.
 
Here's how I would do it:
FINPUT IF E Disk
IINPUTRF
I A L2
I B L2
I C L2
C L2 Eval Sum = *zero
C Eval Sum += Amt
CL2 Except #DET
 
Arrow is right. You should use the RPG cycle and the level control breaks to summarize the data. This would be much more accurate for this kind of processing. About 10 lines suffice to write all or at least the most part of the program.
Code:
H Option( *SrcStmt: *NoDebugIO )                             
FINPUT     IP   E           K DISK
FOUTPUT    O  A E             DISK
IINPUTRF                                                      
I                                          FldA          L1
I                                          FldB          L1 
I                                          FldC          L1 
C                   If        *InL1             
C                   Eval      Sum = 0  
C                   Endif  
C                   Eval      Sum += AMT                        
CL1                 Write     OutputRF
 
Note: If the file is already in sequence, don't use the "K" on the input line, as this will force key sequence and impact performance. If, however, this is a keyed LF or OPNQRYF result, then the "K" is needed (as these methods really only sequencethe keys).
 
Oh, and mercury2 is right - I mis-keyed. It should be IP on the F-spec, and not IF
 
I converted the whole program into Free-form and it seems to be working. I replaced the three DOW with IF statements and made the Print and Move operations into a subroutine. Free-form is awesome!
 
Weird response !
Cope with the cycle and its level breaks instead of reinventing the wheel -- just a hint though.
 
9000 + records is not a lot of records for an AS400. I have a file I routinely work with that has 1 Million plus. Run this file thru the rpg cycle, it will handle all your housekeeping. Run time of a program is not impacted by lines of code, but by I/O, that is always the limiting factor on run speed. Are you running this thru the interactive or batch Que??
 
Solving this problem is not a function of using /free or not. It is solved more easily using the cycle as posted previously.
 
How does the cycle work? I've never understood the use of the N01 indicators.
 
> How does the cycle work?
Every RPG program uses the RPG cycle. You should check the RPG manual for a full description. The cycle in very simple terms goes like this:
1. Read a record from "Primary" file.
2. If level breaks have occurred, process Total-time calcs and output (LR is turned on if out of data)
3. Process calcs
4. Process output.
5. repeat at 1.

Now, since many pgms don't have a primary (or secondary) file defined, the cycle often runs just once, then ends. But if you define one, it cycles thru once for each record. Primary files are the ideal way to process a file when the records are already in sequence (or sequence doesn't matter) and you need to process most of the records in the file. Generally it is much faster than using READ in a DO loop.

> I've never understood the use of the N01 indicators.

Nothing to do with the cycle. This just means the same as
IF *IN01 = *OFF

 
Here's a link to the RPG Programmer's Guide on IBM's website. A discussion of the cycle starts on page 10.


Editorial comment: It's too bad that knowledge of the cycle, it's uses, and it's benefits is being lost. RPG was created just for this type of report. That's why it's called Report Program Generator. [smile]
 
I understand the frustration with the use of the cycle,, now days people want to control everything by coding it themselves. The cycle is great when the application calls for it, and can be your friend, when you understand how to code it
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top