× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi, David:

Once you have decided that using *SRVPGMs is a "good idea," you need to create a "go forward" plan for how to transition from "where you are today" to "where you want to be" ...

A suggested "rule" -- each *MODULE should only ever be bound into one *PGM or *SRVPGM. (This simplifies maintenance.)

First you should decide how you want to structure your service programs. The choices are:

1. bind all modules into one giant *SRVPGM
(over-simplified -- incurs extra overhead to activate a huge *SRVPGM when only one or a few procedures may actually be needed/called)
-or-
2. bind "related" modules into a *SRVPGM that represents how those modules are related to each other (and where typically when one procedure is called, others in the same "related" service program are also likely to be called);
-or-
3. create one *SRVPGM for each *MODULE (where the name of the *SRVPGM is the same as the name of the *MODULE)

You also need to think about how you want to use activation groups. For example, if you bind all "related" modules into one service program, it might make sense to assign a persistent activation group (e.g. with the same name as the service program) for that service program. That way, whenever that service program gets "activated" this named activation group gets created automatically. You can force termination of that activation group with RCLACTGRP ACTGRP(name) from a command line (for debugging), or within a CL program, when appropriate.

Once you have decided on your approach, you need to bind all of your modules to create the new service program(s) using CRTSRVPGM.

Next, create a new binding directory that lists only the service programs, and does NOT include any modules.
Now, you will use this new binding directory, in place of the old binding directory, whenever you recompile and bind your programs.
(You might want to rename the old binding directory, then rename the new binding directory to the name of the old binding directory.)

Next, you will need to re-bind all of your existing bound *PGMs from its original *MODULE, using the new binding directory, to create new, much smaller *PGMs that use the *SRVPGMs automatically. (Assuming you keep all *MODULEs around, even after binding, you can just use the CRTPGM command to recreate the *PGMs with the new binding directory.)

If you do not keep the *MODULEs for your *PGMs, for example, if you compile them with the CRTBNDRPG command, and use an H-spec in the source such as:
H DftActGrp(*NO) ActGrp(*CALLER) BndDir('BNDDIR')
-or-
H DftActGrp(*NO) ActGrp('QILE') BndDir('BNDDIR')
you might need to recompile each program to create the new version that uses the *SRVPGMs instead of using CRTPGM to recreate from the original *MODULE.

(You could do this re-binding of *PGMs "all at once" or gradually, over a few days or weeks.)

For maintenance, you can use UPDSRVPGM to replace a *MODULE within a *SRVPGM with a new version.

Only when the "interface" (procedure names, number of parameters, etc.) changes, will you need to recompile and re-bind any callers of the changed procedure(s). There are techniques using "signatures" for *SRVPGMs that can avoid the need to re-bind older unmodified callers of those procedures. But that is getting more advanced. For now, you probably do not need to worry about that, to start using service programs and getting the benefits.

Does that help?

Mark S. Waterbury

> David FOXWELL wrote:
Looking forward to the reply to that question, Adam, thanks! But it's winter and late downunder so we might have to wait until tomorrow.

I have been having some fun experimenting while creating a new module recently. I made it into a SRVPGM and then to test, bound it to an RPG. At the same time, I experimented with activation groups and got the test program to run in its own group that was deleted at the end of the program.

Interesting, watching my colleagues continuing to have to recompile each time they changed the module being tested, or having to do sign off when the test program didn't let go of a file ! No more of that for me!

But now I am convinced that SRVPGMs are the way to go, changing all those programs doesn't seem to be an easy task.

-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Adam Glauser
Envoyé : jeudi 31 juillet 2008 14:43
À : rpg400-l@xxxxxxxxxxxx
Objet : Re: Question about service programs

On 31/07/2008, at 6:10 PM, David FOXWELL wrote:
We have not yet implemented the use of service programs. So each
program has its own copy of the code.
<snip>
If we have 50 people using the same interactive program that weighs
40 Mb, made up of many modules bound by copy and no service programs,
are there 50 copies of that program in activated or is it shared ?

Simon Coulter wrote:
All programs on OS/400 are re-entrant. There is only one copy of the
code loaded. Each user has their own copy of variable storage but they
all share the same copy of the code--even if they are running in
different main storage pools. It's been that way since System/38.


I think that David might have the right idea, but not asking quite the right question. To simplify David's case, lets suppose we have PGM0, consisting of modules MOD_0 and MOD_UTIL. We also have PGM1, consisting of MOD_1 and MOD_UTIL.

If I now run PGM0 which calls PGM1, wouldn't there essentially be two copies of the code for MOD_UTIL in memory? I think this must be the case, since if I change MOD_UTIL and rebind PGM0 but don't rebind PGM1,
PGM1 will still use the "old" version of the MOD_UTIL code.

In any case David, I would echo Simon's recommendation to start using Service Programs. It's really not hard, and it beats the "compile the world" maintenance model hands down.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.