RE: Module source naming schemes

["Sims, Ken" <KSIMS@xxxxxxxxxxxxxxxx>]

Hi Jim -

>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?

I assume by "binder object" you mean a binding directory.

I have just one binding directory for application service programs.  My
standard H-spec copy members include the "bnddir" keyword with my
application binding directory, a binding directory for some third-party
software, and the QC2LE binding directory.

My feeling on service programs is to have any given service program only
handle related functions.  So far I have two: one providing OS/400 services
and one providing Pricing, Discounting, and Depletion Allowance services.  I
will be adding a third one that provides date services (currently I have a
dynamically callable "API" program that handles date functions).

My feeling is that generally a service program should only have one RPGLE
module.  If I have different modules providing different kinds of services,
they should almost certainly be bound into separate service programs.  If
there a lot of service programs and a program uses a lot of them, this is
going to cause a slight performance hit at program startup when all of the
service programs are activated, but unless the system is heavily loaded,
this shouldn't be noticeable.  Also, having the separate service programs
makes it easier to handle signatures.

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
+---