Thanks Mark. While I like the idea of auto-retiring the old procedure, there are logistics issues that come to mind: The people running the jobs that use the old procedure should not have authority to UPDSRVPGM, and the spoolfile would cause somebody a fair share of confusion, etc.
But thanks for the ideas.
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Mark S Waterbury
Sent: Thursday, February 20, 2014 4:01 PM
To: Midrange Systems Technical Discussion
Subject: Re: Removing a procedure from a service program
Here is how I would recommend approaching this task, if you want to
maintain "compatibility" and not have to immediately re-bind every
program that uses this *SRVPGM ...
create a small new *MODULE with the one procedure with the same
as the procedure you are "eliminating." In this version of the
procedure, issue a message to the job log, indicating that "a
deprecated procedure 'name' was called ..." and perhaps issue a
to QCMDEXC to run the command: DSPJOB JOB(*) OUTPUT(*PRINT)
OPTION(*PGMSTK) -- and use UPDSRVPGM to replace the module being
"retired" with the new "stub" one
next create the new module with the new procedure, and update the
binder source to add the new procedure name at the "end" of the
*CURRENT signature, and add a *PRV signature section to preserve
compatibility with all the old programs that have yet to be
re-bound, and then add that new module to the *SRVPGM
3. once that is done, you can start compiling programs that use the
procedure, and they will bind with the now updated *SRVPGM
I hope this "makes sense" ...
All the best,
Mark S. Waterbury
> 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.
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.
source of confusion to everyone that follows me and wonders about this
2) Is that old module forever part of the service program (and a
to permanently remove the old module?
3) Would I be better off recreating the service program (CRTSRVPGM)
Running 7.1, no TR 7 yet.
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-