Re: Compiler directive

"Steve Richter" <stephenrichter@xxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
08/09/2006 10:24 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
Re: Compiler directive






On 8/9/06, rob@xxxxxxxxx <rob@xxxxxxxxx> wrote:

Another rule I follow that simplifies things and eliminates the need
for conditional compilation is "PR include source members themselves
dont include other PR source members".

If I have a common utility that is used by both the service program, and
the main program, I may not have the prototype in the PR for the main
program but I may have it in the main program member itself.  I suppose,
if I've just added the use of the service program and now when I compile
it I start getting duplicate definitions on the PR I could delete it 

from

the main program.  The problem with that is it leaves a bad taste in the
mouth of other developers and they'll rewrite the service program to get
their own function or not use the PR member for the service program, but
instead copy/paste what they need from the PR member for the service
program directly.  Again, the boss says I am not allowed to kneecap
anyone.

where is the PI code for the common utility? If the PI code is
anywhere but in a module that has been bound into a srvpgm, then start
kneecapping.  Maybe people are getting in trouble with includes
because they are including both the PI and PR code of the common
procedure?

You have a common procedure named core_CrackPath. It takes an IFS path
and cracks it into its directory path, file name and file extension
parts. That procedure belongs in the COREPROCS srvpgm and its
prototype is found in the PRCORE srcmbr. Whenever a module contains
code that calls the core_CrackPath proc, that module has to include
the PRCORE srcmbr.
+> It's more when you get to prototyping external programs as a 
replacement for *ENTRY PLIST and CALL PARM garbage.

When the PR srcmbr of an
application srvpgm references a data element that is defined in
another PR srcmbr ( like( custref.custnbr )), then the module that
included the application PR srcmbr also has to include that 2nd PR
srcmbr.
This nesting gets rather intense.

not really. You end up putting a lot of prototypes in the PRCORE
srcmbr but the compiler seems to blast right thru such includes even
on the typical geared down 520.  I have a PRAPI srcmbr for system api
prototypes. then there is PRCORE for common procs that handle string
primitives like parsing a comma delimeted string. If you build XML
procedures you would have an XMLPROCS srvpgm and PRXML srcmbr.

+> I agree that the compiler burns right through it, it's the human stuff 
that gets in the way.
1 - The more anal tend to really dislike anything defined that they do not 
use directly.
2 - Sharing deep nesting via the internet is difficult.

-Steve