RE: Procedures, Modules, Service Programs

If that's the end of this discussion, then I'd like to add a question that I haven't found the answer to in the dummy's guide to service programs.

Some of you may remember that we don't do service programs. I brought the subject up again yesterday during a meeting when we were discussing the difficulties in installing modifications. Everything being bound by copy, the slightest change in a module is becoming difficult to maintain, as everything get's recompiled. Anyway, I think it's sinking in to management that we need to start doing some ILE quite soon instead of just RPGIV.

My question : if one chose the huge service program option with everything in, isn't that service program activated once only and shared, or does it get activated by other users when they need to use it? If I had to guess, it would be one activation per job.

-----Message d'origine-----
De : midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de Birgitta Hauser
Envoyé : mercredi 20 mai 2009 06:57
À : 'Midrange Systems Technical Discussion'
Objet : AW: Procedures, Modules, Service Programs

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.

--
Pete Hall
pete@xxxxxxxxxxxxxx
--
This is the Midrange Systems Technical Discussion
(MIDRANGE-L) mailing list To post a message email:
MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting,
please take a moment to review the archives at
http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion
(MIDRANGE-L) mailing list To post a message email:
MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting,
please take a moment to review the archives at
http://archive.midrange.com/midrange-l.