RE: Removing a procedure from a service program

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.
-- Michael

-----Original Message-----
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

Hi, Michael:

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 ...

1.

create a small new *MODULE with the one procedure with the same
name
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
call
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

2.

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
new
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 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.

Questions:
1) Would updating the service program (UPDSRVPGM) to add the new

module cause signature violation issues? I have binder source, which
would be updated, but some of the programs that call other modules of
the service program were created before the binder source.

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 module)?

3) Would I be better off recreating the service program (CRTSRVPGM)

to permanently remove the old module?

Running 7.1, no TR 7 yet.

Thanks.
Michael Koester
Programmer/Analyst

DataEast

--
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,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-
l.