Re: Compiler directive

On 8/8/06, Barbara Morris <bmorris@xxxxxxxxxx> wrote:

Lim Hock-Chai wrote:
>
> Let me be a bit more specific:
>
> Let say I've a program that needs to use proc1 and proc3 of MYSVC
> service program, the first method will allow me to copy just the proc1
> and proc3 prototypes that I needed but it requires three line of code to
> do the copy:
>
> /Define proc1
> /Define proc3
> /Include Qrpglesrc,MYSVCPRO
>
> The second method only requires one statement but the proc2 prototype
> will also be included:
> /Include Qrpglesrc,MYSVCPRO
>
> Any pros and cons for the above two?



I'm not suggesting that the entire set of all possible procedures be
available with a single /copy; just that once you have decided to use a
particular set of procedures, you should be able to get them all just by
coding the /copy.

Why a "set of procedures"? I prefer to let the service program be the
application element that decides a lot of these organizational things.
Each srvpgm has a single corr PR source member. If the module being
compiled directly uses an export from a srvpgm, then include the PR of
that srvpgm in the module source.

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".  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.

The key is structuring your srvpgms in a hierarchy that makes sense.
There is a COREPROC srvpgm that all modules reference. All the
includes for the COREPROC srvpgm are in the PRCORE include srcmbr.

Something like the ORDER application and INVENTORY application, where
there is some cross referencing going on, can be tricky to organize.
In an ORDER module that does not call any INVPROC procedures you dont
want to have to include the PRINV srcmbr simply to get the definition
of ITEMNBR that some of the procs in PRORDER reference.  There are
ways around this without the complications of conditional compilation.
ITEMNBR could be defined in PRCORE, which ORDER and INV modules always
include. Or there could be a PR srcmbr that defines the data elements
that ORDER and INV have in common - PRCOM_ORIN. Or just cheat and
duplicate the definition of the common data elements in both the
PRORDER and PRINV srcmbrs.

-Steve