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