RE: Need help with a service program

"RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxx> wrote on 08/12/2016 02:32:05
PM:

OK, now the next problem.

When I try to create the service program using *SRCFILE, it is
popping an error because it is finding the definitions in both the
*MODULE and the *SRVPGM.

Definition supplied multiple times for symbol 'SCGETNVP'.

We are using Aldon so I can't alter the library list during compiles
and promotes and the *SRVPGM it is finding is in production. Is
there any way around it finding the *SRVPGM in the libl and
triggering this error?

In most cases the binder will weed out "duplicate" references when
it is able to determine that such references are really to the same
procedure in the same service program. However, occasionally it will
think that they are two different procedures even though you know they are
really the same one. In most cases, this occurs because the procedure
interface has changed in some way for the procedure.

Note that the binder does not search the library list for either
modules or service programs unless the binding directory tells it to do
that. So, what I have found the problem to be is that the service program
reference is specified both in the module (via H-spec or ctrl-opt) and as
a BNDDIR parameter override in the CRTSRVPGM command. Use one or the
other -- but not both. In this way we only have to have just one binding
directory, too. I would not use the *DUPPROC option to eliminate
duplicates.

If you've done all of the above and you still find you are getting
duplicate procedure references, then I do one of two things. In some
cases the service program is in my development library. If it is, then I
delete that before recreating the service program. In other cases the
service program may be at a higher promotion level and I don't want to
delete that. In this case, I remove the service program from the binding
directory, recreate the service program, and then re-add the service
program to the binding directory.

A better solution would be if IBM would give us a CHGBNDDIRE
command and an activation option of *INACTIVE for these types of
situations so that the binder would bypass the service program in
question. I asked for this (among other enhancements to the WRKBNDDIRE
command, but who knows if they will ever do it.

Sincerely,

Dave Clark