Re: Question about prototyping

All,

As a response to the "...procedures should _not_ go in copybooks..." line.

There are occasions where I include both a prototype and the procedure code
itself within a single copybook. For instance, I have a sndPgmMsg()
procedure (doesn't everyone?) which appears in a service program. However,
sometimes I'd like to be able to press F9 on the message details and see the
program from which this message was sent, rather than know that it was sent
from a service program. Therefore, in these cases, I use the following
copybook:

/IF NOT DEFINED(SNDPGMMSG)
/DEFINE SNDPGMMSG

D sndPgmMsg PR 10I 0
D MsgID 7A Const
D MsgDta 7A Const
D qMsgf 20A Const

/ELSE

P sndPgmMsg B
D PI 10I 0
D MsgID 7A Const
D MsgDta 7A Const
D qMsgf 20A Const
...procedure code goes here...
P sndPgmMsg E

/ENDIF

I have two instances of the /COPY statement for the SNDPGMMSG copybook in my
program - one at the top, in the global D-specs and one at the bottom,
before any compile-time arrays. This works perfectly - the prototype is
added to the global D-specs and the procedure is included in the program,
and any calls to SndPgmMsg() go to my inline procedure, rather than to the
service program procedure. Plus, there's no need for those ugly DEFINE
statements in my program code!

I have a few examples of this. Sure, it's not as modular as having a single
instance of the procedure in a service program, but there are times when
there are benefits to doing it this way (totally stand-alone programs where
you don't want to rely on service programs, such as CGI programs, for
example.).

Rory