Hi,
Thanks for all your feedback.
You confirmed my opinion. The main arguments of my colleague are IBM does it in the same way (even though they have different service programs), DLL files and JAR files are built in the same way and there is only a single activation. Everything runs in the QILE activation group, that means the service program is created with activation group *CALLER. Normally I use named activations groups for service programs that can be used from where ever, for example a service program that contains Date functions or String functions.
IMHO having only a single service program, will stop or at least reduce modularity, because instead of adding a new (exported) procedure source code will be copied (because it is faster). To recreate the service programs all modules to be bound must be created and added to a binding directory (if not yet inserted), the binder language member must be upgraded manually and finally a CL-Program that binds all modules must be updated (if a new module gets added) or at least called. IMHO several steps too much!
Long time ago I wrote a small compile tool/command, that can create programs, service programs and modules with a single call. The modules or service programs even can be added to a binding directory and the binder language member can be built automatically or updated if it already exists. But ... this tool only works for a single source or generic sources (for example bind everything that starts with DATE* to a single Service Program), but won't work to create service programs from members with different names. In either way creating a service program with this command is as easy and fast as creating an OPM program.
But being new in a company it will be a hard way to convince the colleagues.
Mit freundlichen GrÃÃen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them and keeping them!"
-----UrsprÃngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Pete Hall
Gesendet: Wednesday, 20. May 2009 00:00
An: midrange-l@xxxxxxxxxxxx
Betreff: Re: Procedures, Modules, Service Programs
Birgitta Hauser wrote:
Currently Iâm using several procedures within a single module (grouped
according functionality).
To make it easy I normally create a service program for each module
(exceptionally I also bind several modules with generic names for example
Date* into a service program).
Into a program only a single module gets bound and I never export procedures
from a program module.
An colleague argues having a lot of service programs is not good, he insists
in having a single service program with all modules for the whole
application, because there will be only a single activation.
I donât like this idea, because: If I only want to use a string function for
my batch program all display and printer file and what else functions must
be activated.
I just like to know how you handle it and why.
We've tried all three. The single service program with generally
applicable methods (like AR or GL) didn't work out very well because
someone always wants to work on something that's in there. Even with
multiple modules that's been a problem because of conflicts with
copybooks, binding directories and binder language.
Multiple modules in a single service program seems to work ok if the
service program is part of a single application function, and multiple
people need to develop concurrently. I have one billing program that was
built that way. It was written by 3 different people, but that's my
area, so now nobody else wants to mess with it very much.
I find the single module, multiple related function method much easier
to control. We have several like that, and since a project usually
involves several related methods, that's worked well. Since it's easy to
have related methods call each other inside the service program, you can
expose some of the functionality, like status values by day, or value
ranges that are mainly used within the service module, but might also be
useful to external code, especially if you use an incremental approach
to removing redundant methods from multiple programs. I also find it
very helpful to construct the methods so they cache their results
internally and return cached data deterministically based on the request
arguments. That permits related methods to call each other without
concern for data retrieval and calculation overhead, really does allow a
method to be the sole source for whatever data it produces, and greatly
cuts down on the need for global data.
We use a single binding directory for application program compiles, so
that related service programs can be linked without too much regard to
exactly where the method is. Service programs that don't end up with
referenced methods are dropped by the compiler, so there's no real down
side.
midrange.com
