Thanks for the info. I fully understand your warning however, as earlier stated, it is part of a package and my hands are tied. Fortunately, this particular one is part of a one time conversion (one time for us anyhow). There are highlighted notes at the top of the source that you can't miss to only add new procedures to the end.
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.
Maybe you answered these and I'm just not getting it. Maybe I need to go back to Service Programs 101 class. 😊
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Jon Paris
Sent: Friday, November 15, 2019 6:17 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Changing a service program
Oh dear - where to start!
First an apology - I never saw your original post and I wonder if others missed it too.
Anyway.
What are you doing wrong? Well it would be much easier to say what is right! Whoever you inherited this from should probably be shot.
Let's look at the effect of the STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*NO) SIGNATURE(*GEN) statement.
LVLCHK(*NO) is the problem - it is saying that the system should not check the Service Program's (SPs) signature at all. That is a really bad idea.
To give you a hint as to why your change did not work you need to understand the way in which routines in an SP are identified.
When an SP is created each procedure is assigned to a "slot". Its procedure pointer is then placed in that slot. When a program is told that it is to use an SP it stores the signature and the slot number of the procedure it is to use. At run time the program requests the pointer at slot n and will call that procedure. So far so good.
The problem is that if you ever add a new procedure you can change the slot assignments! Normally when using *GEN for the signature this would not be dangerous because the signature would change and therefore there would be a signature violation at run time. BUT - it has been told NOT to check the signature. So the program can get the wrong pointer and in your case probably did. In your case you were testing and the failure was obvious. But what if during testing calling the wrong procedure appeared to give the correct answer? You could be tricked into placing the code into production - and then the excrement might well hit the fan. Imagine how hard it would be to diagnose why you were getting the wrong answers!
The solution is first of all to STOP using LVLCHK(*NO).
Then you can decide - do you want to use *GEN for the signature - in which case you will need to re-bind all programs that use an SP if you ever add a procedure
OR (the preferred approach)
Use Binder Language to establish a fixed signature and manually control the slot associations by ALWAYS adding new procedures to the end of the list.
There's some basic information on these issues in this article:
https://ibmsystemsmag.com/Power-Systems/10/2003/service-programs-signatures <
https://ibmsystemsmag.com/Power-Systems/10/2003/service-programs-signatures> from 2003.
This talks to maintaining multiple signatures which is not the approach I would use today but it teaches the mechanics.
My partner Susan wrote this in 2007 and it talks to maintaining hared-coded signatures.
https://www.mcpressonline.com/programming/rpg/writing-the-binder-language <
https://www.mcpressonline.com/programming/rpg/writing-the-binder-language>
You might also find this one on Binding Directories useful.
https://www.itjungle.com/2011/06/08/fhg060811-story01/ <
https://www.itjungle.com/2011/06/08/fhg060811-story01/>
Hopefully this will help you understand. But I cannot emphasis strongly enough that the approach currently being used by your shop is dangerous. This is an accident waiting to happen.
On Nov 15, 2019, at 5:39 PM, smith5646midrange@xxxxxxxxx wrote:
I posted the original email below to the RPG list a little over a week ago and go no responses so I’m trying this list.
I did some additional digging while waiting on a response and here is
where I am at. Remember that I inherited this so don’t blame me when
you see something stupid in my descriptions. 😊
Each program that is bound to the service program has it’s own binding directory. Don’t ask why they did this because I don’t know. For the most part, the only entry in the binding directory is the service program. The entry shows *SRVPGM and activation *IMMED.
The QSRVSRC source for the service program contains the line
STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*NO) SIGNATURE(*GEN)
which if I understand correctly, this causes the service program to be created with a signature of all zeros which it does have. Don’t ask why they did this because I don’t know.
Now here is where I am stuck.
I modified one of the functions and when I called it, I got the previous results, not the new expected results. I tried adding a DSPLY in the code and it didn’t display. I recompiled the calling program and the DSPLY displayed. I changed the service program again to change the DSPLY statement and when I ran it, I got the old DSPLY statement.
Thinking this might be caused by the previous version of the service program being moved to QRPLOBJ, I tried deleting the module and the service program and recreating both but the only way I can get the calling program to call the new version of the service program is to recompile the calling program. This confused me. Out of curiosity, I deleted the service program and the module and called the program expecting it to fail. It did not. This defeats everything I thought I understood about service programs.
What did I miss? Before anyone asks, this is proprietary source and I can’t post it.
From: smith5646midrange@xxxxxxxxx <smith5646midrange@xxxxxxxxx>
Sent: Monday, November 4, 2019 1:27 PM
To: 'RPG400-L' <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx>
Subject: Changing a service program
I apparently worked too many hours over the weekend because I am brain dead and can’t think through this. Either that or the drugs from my rotator cuff surgery are getting the better of me.
We have a service program that is used by a couple dozen RPGLE programs that call one or more functions in it and I need to modify one of those functions. It seems like I need to do something special when creating the new version of the service program so the other programs can call the new version of the function without generating an error but I just can’t remember how this all ties together. I don’t want to touch the other programs in any way to do this.
Thanks in advance for providing some extra brain power.
--
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
midrange.com
