Re: Prototypes in Module Source

Scott:

<snip>
Hmmm... so why not have QPGMSRC and QSRVPGMSRC?

For that matter, why not have PGMSRC and SRVPGMSRC? Why begin them with the
letter Q? (Just because IBM did?)
</snip>

You are absolutely right...there is no good reason to begin the source file
name with Q...except that old habits die hard. And, you might as well take
it one step further...why have SRC at the end? The object is a *FILE of
type PF-SRC, so why use SRC?

As to QGPMSRC/QSRVPGMSRC, I used to have those as well. They contained
lists of modules to bind into *PGM and *SRVPGM objects for my own little
pre-compiler. QPGMSRC could contain RPG/400, CLP and other OPM sources that
compile directly to *PGM objects. I'm not sure what you would put into
QSRVPGMSRC...Binder source? Technically you don't compile that, although it
is used when creating the *SRVPGM object.

As to your example of needing multiple copy books with the same name, I
create copy books for each module, not just one for the service program, so
I don't run into name conflicts because my naming convention precludes it.
So, in your example, if I had a service program named ORDER, I would
probably have an RPGLE module named something like ORDERR and an SQLRPGLE
module named something like ORDERS, with corresponding copy book names. I
can't think of a situation where I have a service program with multiple
modules. And I don't do C, so the only languages I personally would have
prototypes for would be RPGLE and SQLRPGLE, which are essentially the same
language...but that's just me.

In this new application that I'm writing I won't need to worry about PGMSRC
or SRVPGMSRC as I am using CMS (Arcad) and they manage that quite nicely.
And I'll keep the QCPYSRC (yes, with the Q and the SRC...though admittedly
unnecessary).

We've gotten a bit off of the original subject, but it's good to be able to
bounce ideas off of saner minds than mine.

Thanks,
--Bruce Guetzkow