That will take care of the signature issue BUT if you remove a module
from the middle then older programs will call the wrong module.
On 2/20/2014 9:09 PM, Jeff Young wrote:
He would only need to rebind every program if he did not user binder
Using binder language, he makes a copy of the existing config and changes
the STRPGMEXP PGMLVL(*CURRENT) to STRPGMEXP PGMLVL(*PREVIOUS) on one copy
and then in the *CURRENT copy, he just lists the procedures he now wants.
The programs that have not been rebound will use the *PREVIOUS copy.
Sr. Programmer Analyst
On Thu, Feb 20, 2014 at 3:01 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
On 2/20/2014 2:22 PM, Koester, Michael wrote:
I have a service program that contains 8 modules. One of those modules
I want to replace with another of a different name - deprecating one and
adding a new one that is similar but different enough to be named
differently. The one program that called the module to be removed is being
changed and recompiled (to use the new & improved one), so the old module
would not really be missed.
Terminology can be very important here.
Do you want to remove a module from the service program or a
sub-procedure? A program can't call a module.
cause signature violation issues? I have binder source, which would be
1) Would updating the service program (UPDSRVPGM) to add the new module
updated, but some of the programs that call other modules of the service
program were created before the binder source.
If you remove a procedure from the list of exports, the signature bound
into all of the calling programs is now different. An example of
current service program exports:
I have a program OEORDDSP which uses encode and decode. When I compile
OEORDDSP, the binder doesn't store the procedure names in the code, it
stores their export position. So when the RPG program does a serial =
encode(name) it really calls out to serial = EXPORT PARM(name).
Perfectionists are cringing but that's the general idea.
If you remove centerstring from your service program and run OEORDDSP,
it will still call the 5th export, because that's what we told it to do
the lat time we compiled it. Only now, here is the list of exports:
Yeah, the decode procedure gets called instead of the encode procedure.
That's why service program signatures exist - to stop that from
2) Is that old module forever part of the service program (and a source
of confusion to everyone that follows me and wonders about this phantom
Yes, it would be left in the service program.
3) Would I be better off recreating the service program (CRTSRVPGM) to
permanently remove the old module?
Running 7.1, no TR 7 yet.
If you remove a procedure you will pretty much need to rebind every
program that uses that service program.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives