Re: Module source naming schemes

[Jim Langston <jimlangston@xxxxxxxxxxxxxxxx>]

Hmm.. this brings up a good point.  I have 3 modules, which I currently
call CARTAGE, DATETIME and SYSTEM.  These are built from the source files
located in QMODSRC called CARTAGE and CARTAGEPR, DATETIME and DATETIMEPR,
 and SYSTEM and SYSTEMPR.

I then created one service program that included all three of these modules.
Then I created one binder object that contained this one service program.

It sound to me, however, that other people would build 3 service programs,
CARTAGE, DATETIME and SYSTEM and then link these together in one binder object.

What are the advantages/disadvantages to either scheme?

Regards,

Jim Langston

"Sims, Ken" wrote:
> 
> Hi Jim -
> 
> >What naming schemes has everyone else settled on?  So far
> >there are no modules on the system at all, nor are there
> >any service programs, so whatever naming schemes I start
> >with we will most likely go with.
> 
> I'm just getting started with service programs myself.  I keep the name of
> the main module in the service program to be the same as the service program
> itself.  If there are other modules, they have the same name with a suffix.
> 
> I have one prototype per service program, not per module.  The name of the
> prototype source member is the same as the service program, but resides in
> source file QRPGLECPY, as do other non-prototype copy members.  The name of
> the binder source is the same also, but resides in QSRVSRC.
> 
> My service programs and their modules all start with @_.  For example, my
> OS/400 services service program is @_OSSRV.  It consists of RPGLE module
> @_OSSRV and CLLE module @_OSSRVCP.  (It doesn't provide very many services
> yet; I'm sure there will be more CLLE modules before it is done.)
> 
> My intention is for all exported procedures to be in the RPGLE module.  I
> use the binder source to keep the CLLE procedure from being exported.  The
> RPGLE module will do parameter validation and call the CLLE procedures or
> call APIs or whatever is needed for the function requested.
> 
> The other service program that I have created so far consists of just one
> RPGLE module.  That will probably be typical of my service programs.
> 
> Just as a side note, at this point in time I do not intend to have any
> multi-module programs that are not service programs; subject to change
> without notice.
> 
> Ken
> Southern Wine and Spirits of Nevada, Inc.
> Opinions expressed are my own and do not necessarily represent the views of
> my employer or anyone in their right mind.
>
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---