Re: Module source naming schemes

 >> What are the advantages/disadvantages to either scheme?

I think you are probably doing it the right way - although I would have
combined the protos into a single file (i.e. I think the protos should be
grouped to match the Service Programs (SP)).

SP design is a balancing act between too many SPs (one per module is just
plain pointless in my view) and SPs that are too large.

If the SP is _only_ used in interactive work, it really doesn't matter how
big it is as most routines will get used at some time during the day.
However that same huge routine would not be a good idea if used in Batch
jobs as a lot of resource will be wasted loading and initializing routines
that will never be used.  For that reason I've come across some folks who
bind their modules two ways.  One into a set of SPs for batch work and a
second set used for on-line.

I normally start from the perspective that I will have at least two basic
types of SP.  One type consists of routines that are used across the
system.  The other consists of routines that are application specific.  In
some cases there is a third group of "shared" components for example there
would be common routines between Payables and Order Entry.

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