Whether you use a constant signature, or use the *CURRENT/*PREV method, you can only add new procedures to the end of the current binder source group. You cannot reorder procedures in either case. This is because only one version of the service program procedures are maintained, and they are bound by relative location in the service program. So if procedureC is in position 3 of the binder source when it is initially created, it must be in position3 in every export group in the binder source, and the groups that do not have procedureC must not have 3 or more procedures defined. This is why the *CURRENT/*PREV method of writing binder source is mostly busy work. It gives you nothing, takes more work, and the rules for changing and recompiling procedures stay the same.

Mark Murphy
Atlas Data Systems

-----David Gibbs <david@xxxxxxxxxxxx> wrote: -----
To: "RPG programming on the IBM i (AS/400 and iSeries)" <rpg400-l@xxxxxxxxxxxx>
From: David Gibbs <david@xxxxxxxxxxxx>
Date: 09/13/2017 03:14PM
Subject: Re: Service program signatures, and how to avoid unnecessarily recompiling programs that call service programs

On 9/13/2017 2:08 PM, Alan Campin wrote:
As long as the interface has not changed, you will not need to

You need to create a current listing your procedures. then when you
add a new procedure, your current becomes your previous and your new
current is at the top.

As long as new procedures are added to the end of the list of procedures, and you specify a constant signature in the binder source, you don't need to recompile programs that reference the service program.

As I understand it, procedures are reference by their relative location in the service program.

The only time you would have to specify multiple PGMLVL's in binder source is if you remove, or reorder, the procedures that are specified.

I have service programs that have the same signature since they were originally written. We always add new procedures at the end, and the programs that use the service programs never have to be recompiled.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.