Re: Module source naming schemes

Hmm... very good point.

I see then I should have 2 service programs right now then.

The one for the CARTAGE module (Cartage is a specific application 
on our system) and the other one with the DATETIME and SYSTEM modules,
which could be called by any application.

Thanks!

Regards,

Jim Langston

Jon.Paris@hal.it wrote:
> 
>  >> 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
+---