Re: external subprocedures setting on LR: performance impact?

Thanks guys!  Nothing like hearing from the voices of experience!

We're still doing the baby steps into modular programming.  Talk of AG's around 
here stirs up the
sentiment that we've not had the experience working with them and we "don't 
have time right now"
to do the research.  PLEASE - NO LECTURES HERE!  This is by far the best shop 
I've worked at in
terms of involving "new" technology.  We are getting there.  We will get there.

As far as the decision of how we are breaking up our modules, one of the 
biggest determinators is
the QA factor.  Once our Estimate module has been coded, tested, QA'd 
(including code review) and
is put in production, we never have to test that again, even though something 
else in the
application that uses the Estimate module may change.  Since QA testing is a 
significant
undertaking in this shop, anytime we can plug in discrete modules into a new 
application, or
modify one module in an application that uses several modules, makes for easier 
and faster
testing.  Does that adequately answer your "foot in mouth" argument, Buck? <g>  
Just to fill out
the scenario, we have a driver module that, for each customer job, calls the 
Estimate procedure,
the Revenue procedure, the Hours procedure, the Accruals procedure, and the 
Open P.O. procedure. 
Each of these procedures has its own discrete set of business rules.  Each 
module is fully
documented, both technically and user-oriented, and this is part of the code 
review, i.e., is the
code doing exactly what the technical documentation says it is doing?

Actually, I made a push to get commission calculations to be its own procedure, 
for two reasons,
one was that the same function was being used in both the Estimate & Revenue 
modules, and two, it
was a complex set of code.  But the performance issue made the decision to go 
against it and
duplicate the logic into the Estimate & Revenue modules.  I had even suggested 
that I could pass
the file record structures and their data from the calling modules, since they 
were retrieved
there anyway.  But that didn't fly; something to do with future use of stored 
procedures.  The
only plus I see from this decision is that the business rules for commission 
haven't changed in 15
years and are unlikely to do so anytime soon.  But I will include a note in the 
commission
subroutine header to keep the two copies the same.

AGs:  There are no AG keywords in the H-specs and no AG parameters overridden 
in the compile
commands, so I assume that this uses ACTGRP(*NEW).  This is the default world 
as we know it in our
shop.  Joe's suggestion of compiling the top program as ACTGRP(*NEW) and all 
the called modules as
ACTGRP(*CALLER) is intriguing, but I will have to put off trying that until our 
next project so I
have a chance to play with it.  Is this technique usually not used when the end 
of the application
execution also marks the end of the job?

Joe, the file pointers will not be an issue.  Everything in the called modules 
is either chained
to, or SETLL/READE.  We are not doing shared opens.  While I'm sure that would 
have an impact,
just the fact that if I stop using LR in the subprocedures means that, for each 
of the customer
jobs after the first one, I will eliminate approximately 50 file opens/closes 
for anywhere between
100 and 500 customer jobs that will call these modules.  I gotta think that if 
I eliminate 25,000
opens and closes, we'll see a significant performance benefit.

Carel, while *INZSR can be EXSR'd, why bother?  I made it explicit, renaming it 
to PROC_INIT, and
EXSR'ing it at the top of the mainline.

Again, thanks to all!

- Dan

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com