Sharing Simplifies Source Code
May 11, 2011 Ted Holt
|
I hate huge programs. For one thing, I’m not smart enough to wrap my mind around a big program. And it seems that modifying one part of the program invariably causes something to go amiss elsewhere. Dividing a program into subprocedures, modules, and multiple programs is a good way to manage large tasks. But what do you do when you’ve divided a program into two or more modules and/or programs, and more than one of them needs to contribute to a single report? You share. Suppose you have a program that builds a report of accounts receivable. It’s a manageable program. Then one day someone asks you to add a recap to the end of the report. Adding the recap adds complexity to the program. Here’s another way to tackle the challenge. First, here’s DDS for a printer file that defines the report:
A R PAGEHDR SKIPB(01) SPACEA(1)
A 1'A R Summary Report'
A +10DATE EDTWRD(' - - ')
A +4TIME EDTWRD(' : : ')
A +8'Page'
A +1PAGNBR EDTCDE(4)
A
A R DETAIL01 SPACEB(1)
A NAME 12A 1
A STATE 2A 15
A BALDUE 9 2 18EDTCDE(J)
A
A R RECAP01 SPACEB(1)
A STATE 2A 1
A BALDUE 9 2 18EDTCDE(J)
Here’s the first RPG program, AR101R, which prints the detail lines:
H dftactgrp(*no) actgrp(*caller)
Fqcustcdt if e disk usropn prefix('C_')
Far100p o e printer usropn prefix('P_')
F oflind(Overflow)
F ignore(Recap01)
D Overflow s n
/free
open qcustcdt;
open ar100p;
write PageHdr;
dow '1';
read cusrec;
if %eof();
leave;
endif;
if Overflow;
write PageHdr;
Overflow = *off;
endif;
P_Name = %trim(C_lstnam) + ', ' + C_init;
P_State = C_State;
P_BalDue = C_BalDue;
write Detail01;
enddo;
return;
Here’s program AR102R, which prints the recap.
H dftactgrp(*no) actgrp(*caller)
Far100p o e printer usropn prefix('P_')
F oflind(Overflow)
F ignore(Detail01)
D Overflow s n
D RecapData ds qualified inz
D State 2a
D BalDue 9p 2
/free
exec sql
declare Recap cursor for
select c.state, sum(c.baldue)
from qcustcdt as c
group by c.state
order by c.state;
exec sql
open Recap;
open ar100p;
write PageHdr;
dow '1';
exec sql
fetch Recap into :RecapData;
if SqlState >= '02000';
leave;
endif;
if Overflow;
write PageHdr;
Overflow = *off;
endif;
P_State = RecapData.State;
P_BalDue = RecapData.BalDue;
write Recap01;
enddo;
return;
Here’s the CL procedure AR101C, which runs the show. pgm ovrprtf ar100p share(*yes) call ar101r call ar102r dltovr ar100p endpgm And here’s the report, all nice and together in one spool file. A R Summary Report 5-11-11 13:42:51 Page 1 Henning, G K TX 37.00 Jones, B D NY 100.00 Vine, S S VT 439.00 Johnson, J A GA 3,987.50 Tyron, W E NY .00 Stevens, K L CO 58.75 Alison, J S MN 10.00 Doe, J W CA 250.00 Thomas, A N WY .00 Williams, E TX 25.00 Lee, F L NY 489.50 Abraham, M T MN 500.00 A R Summary Report 5-11-11 13:42:51 Page 2 CA 250.00 CO 58.75 GA 3,987.50 MN 510.00 NY 589.50 TX 62.00 VT 439.00 WY .00 To make this happen, the two programs must share one open data path. The Override with Printer File (OVRPRTF) command in the CL procedure makes this happen. Second, the first RPG must not close the printer file. If the first program closes the printer file, the second RPG program opens another spool file. That’s why the first program doesn’t set on the LR indicator. (The second one doesn’t set on LR either, but it doesn’t matter.) To make the system clean up the active programs, I compiled the CL program to run in a *NEW activation group and the RPG programs to run in the caller’s activation group. When the job ends, the system cleans up everything nicely by destroying the activation group. This method is not the only possibility. I’ve illustrated sharing with two programs that run sequentially, but sharing also works when one program calls another. It is not necessary for all code that builds a report to reside in the same module. Dividing a big program into smaller, more manageable ones is feasible, even when more than one module has to help build a report.
|
