Re: Prototypes in Module Source

["Rory Hewitt" <roryhewitt@xxxxxxxxx>]

Scott,

I have to agree with you - I've never liked coding DEFINEs in my program
source - I like to be able to simply code COPYs. Plus, I like the fact that
if you have a separate prototype copybook, you can include lots of comments
about *how* the procedure should be called, possible return values etc.,
whilst leaving the actual procedure code as a black-box. This is especially
true for shipped software.

I've tried multiple variants of COPY, DEFINE etc. in my copybooks and my
module code and I've also ended up with a separate prototype member. The
standard I use is as follows:

 /IF NOT DEFINED(prototype-member-name)
 /DEFINE prototype-member-name
 *
 /COPY other-prototype-member
 [repeat as necessary]
 *
[actual prototypes go here]
 *
 /ENDIF

So in my module/program code, I only ever have

 /COPY prototype-member-name

and all the stuff I need is copied in.

For instance, I have separate prototype copybook members for each API and
they would themselves include the QUSEC API error code copybook as a COPY. I
also have separate copybooks for each API format structure (RCVM0100 etc.)
and each of *them* include the API copybook (which itself includes the QUSEC
copybook). So in my program, I could simply have e.g.

 /COPY RCVM0100

and the QMHRCVM API prototype and the QUSEC API are automatically included.
Because of the DEFINEs, there's no chance of duplication (as Mark points
out).

Rory
On Thu, Mar 20, 2008 at 10:25 AM, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
wrote:

> Personally, I find this to be cumbersome... coding the /IF DEFINES makes
> the code a little uglier.  Plus, any time I distribute my code, the
> developer MUST have the source for the whole she-bang, or they can't
> call it.
>
> Coding two different members (one for code, one for prototypes) isn't
> any harder or more time consuming...  and the code looks cleaner to me.
>  But, that's just an opinion.