You can rename a procedure...for exmaple from MyProc to MyProc_DEPRICIATED
Along with an appropriate set of comments should make it clear to the next
You can take the PR out of the include file altogether, so the only way
somebody will see it is looking at the source for the *SRVPGM module and or
the binder source.
On Thu, Feb 20, 2014 at 3:41 PM, Koester, Michael <mkoester@xxxxxxxxxxxxx>wrote:
Sorry about my sloppy terminology. I am wanting to remove a procedure.
The module objects are also there in the production library, and in my
case, that old module will be pitched as well. But for my executable
concerns, the procedure would be no longer used, and I would endeavor to
expunge it from the service program.
Looks like my choices are either:
1. Use CRTSRVPGM (listing only the modules that I want going
forward), and regenerate the binder list, and recompile everything that
uses any of the procedures in the service program...
...or 2. Ignore that the service program has some junk that will never be
called (unless somebody messes up the binder list).
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Buck Calabro
Sent: Thursday, February 20, 2014 3:01 PM
Subject: Re: Removing a procedure from a service program
On 2/20/2014 2:22 PM, Koester, Michael wrote:
I have a service program that contains 8 modules. One of thosemodules 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.
Questions:module cause signature violation issues? I have binder source, which
1) Would updating the service program (UPDSRVPGM) to add the new
would be 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 asource of confusion to everyone that follows me and wonders about this
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 at http://archive.midrange.com/midrange-
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