It depends on the activation group in which the programs and service programs are running.
If a service program is running within the same activation group as the caller program and the service program is activated with *IMMED, it is resolved as soon as the caller program is activated.
If the service program runs within the same activation group, but is activated with *DEFER, it is not resolved before the first procedure from this service program is called.
As long as the activation group is not reclaimed, the old (service-)program version is running.
It could be that, the same service program is running within the same job in different activation groups.
So it might be, after an update of the service program (without reclaiming all activation groups within the job) the old and new version of the same service program are running within the same job.
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!"
„Train people well enough so they can leave, treat them well enough so they don't want to.“ (Richard Branson)
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Joep Beckeringh via MIDRANGE-L
Sent: Sonntag, 17. November 2019 14:44
To: midrange-l@xxxxxxxxxxxxxxxxxx
Cc: Joep Beckeringh <joep.beckeringh@xxxxxxxxxx>
Subject: Re: Changing a service program
When I think I understand something about RPG and Barbara claims she doesn't, it is time to start worrying :-)
This is how I understand it:
- When program P, which uses service program S, is activated, S is located and P receives pointers to the procedures it uses;
- When service program S is recreated, the old version is moved to QRPLOBJ; P keeps the pointers to the old version in QRPLOBJ; thus it doesn't "see" the new version;
- When program P is recreated and activated, S is located and so the new P receives pointers to the new S; and thus it "sees" the new version.
Am I wrong in my understanding?
Joep Beckeringh
Op 16-11-2019 om 14:17 schreef Barbara Morris:
On 2019-11-15 10:01 p.m., smith5646midrange@xxxxxxxxx wrote:
...
What I still don't understand is that I didn't add or remove any
procedures. I only modified the code within an existing one but the
changes won't execute until I recompile the program. I thought the
idea of a service program is that you could make changes (if you
found a bug for example) and not have to recompile everything that
used it because it would automatically pick up the new version. Is
there a restriction that if you change an existing function that you
have to recompile all of the calling programs?
I also thought the service program was not bound into the program
(like a module would be) but when I deleted the service program, the
program still ran.
...
When a service program has been used in an activation group, the
activation group "remembers" the service program. If you change the
service program, the change won't be noticed by anything in the
activation group. (It might be "anything already in the activation
group, which would explain why recompiling the program made it see the
new version of the srvpgm, but I don't really understand how that
aspect of activation groups works.)
When you change a service program, you _could_ (but shouldn't) reclaim
the activation group. I say "shouldn't" because reclaiming activation
groups can sometimes cause strange problems if other activation groups
have hooks into the reclaimed one.
So I find it's safer, and easier in the long run, to just sign off and
sign back on again.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
