|
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:ago and go no responses so I’m trying this list.
I posted the original email below to the RPG list a little over a week
directory. Don’t ask why they did this because I don’t know. For the most
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
part, the only entry in the binding directory is the service program. The
entry shows *SRVPGM and activation *IMMED.
created with a signature of all zeros which it does have. Don’t ask why
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
they did this because I don’t know.
results, not the new expected results. I tried adding a DSPLY in the code
Now here is where I am stuck.
I modified one of the functions and when I called it, I got the previous
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.
program being moved to QRPLOBJ, I tried deleting the module and the service
Thinking this might be caused by the previous version of 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.
can’t post it.
What did I miss? Before anyone asks, this is proprietary source and I
dead and can’t think through this. Either that or the drugs from my
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
rotator cuff surgery are getting the better of me.
that call one or more functions in it and I need to modify one of those
We have a service program that is used by a couple dozen RPGLE programs
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.
questions.
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
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 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.
midrange.com
