Simply put LVLCHK(*NO) prevents you from ever safely making an incompatible change in a service program. If you use a fixed signature instead then if you ever need to make such a change _AND_ be sure that all programs that use the SP have been rebound to the SP then you have the option rot change the signature.

Look at any IBM supplied SP. It has a signature and it is normally the name of the SP. If they ever need to make an incompatible change they can change the signature and voila! There are a few IBM SPs with "weird" signatures and there's a whole story behind that but I don't think you'll ever find an IBM Sp with LVLCHK(*NO).

What you need to remember is that in the design of ILE it was never IBM's intention to allow SPs to run in the default AG. That had to be changed - long after the base architecture was set pretty much in stone. As a result there is no way to safely clean up an SP in the default AG except by logging off. Which should be a hint to you - don't run SPs in the default!

You might like to read this on the 7 Deadly Sins of ILE (http://archive.ibmsystemsmag.com/ibmi/developer/general/the-seven-deadly-sins-of-ile/ <http://archive.ibmsystemsmag.com/ibmi/developer/general/the-seven-deadly-sins-of-ile/>) you'll find that running SPs in the DAG is the second sin!

P.S. Sorry I missed the bit about it being vendor software in my original post. They really should know better.



On Nov 18, 2019, at 9:40 AM, smith5646midrange@xxxxxxxxx wrote:

I just wanted to say thanks to everyone for all of the GREAT information. My problem was "general" knowledge of service programs but not "detail" knowledge which you have all provided. And yes, I knew that LVLCHK(*NO) was a bad thing (although I didn't know exactly why) but sometimes you have to work with what you are given and that is what I was given. ☹

Now that I understand how a service program is loaded into the activation group, I understand why changing it and calling it from the same session did not give me my expected results. However, if I log of and back on an run it again, I do get the expected results which was the piece that I was missing. I also now understand how I can call the service program, delete it, and it still work until I log off. That one really confused me. 😊

I will say that while this is a nice feature, it sure makes it a pain to debug and fix a service program.

Again, many thanks to all.


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Mark Waterbury
Sent: Sunday, November 17, 2019 9:34 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Changing a service program

Hi, Vern,

When "P" gets activated into any AG in your job, at that time, it 'resolves' to the address of "S" and also resolves pointers to any procedures (entry points) in that *SRVPGM. Those pointers are now loaded in the "working storage" of "P" ... in its AG.

Hence, when you recompile "S" if "P" is already activated, those copies still have pointers to the old "S" (now in QRPLOBJ).

You can sign-off and sign-on or issue RRTJOB to "clean up" all AGs and reset the job to the way it was when you first signed on.

Hope that helps,

Mark S. Waterbury

On Sunday, November 17, 2019, 9:18:02 AM EST, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> wrote:

Hi Joep

I think the same thing is done with P as with S - IF it is in use when it is recreated. That's been my understanding, that objects can be recreated without interrupting work - but the work will use the object before it was changed.

So the job using program P would still not see the new S, since it is still using the old P.

Now someone who knows better than I can straighten me out, please!!

Regards
Vern

On 11/17/2019 7:44 AM, Joep Beckeringh via MIDRANGE-L wrote:
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

--
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

--
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


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-2022 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.