× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.