Re: Service program signatures, and how to avoid unnecessarilyrecompiling programs that call service programs

On Sep 14, 2017, at 6:37 PM, Mark S Waterbury <mark.s.waterbury@xxxxxxxxxxxxx> wrote:

Jon,

A minor correction ...

It is not the case that UPDPGM and UPDSRVPGM do not update the "where used" information, but rather, they update it with new information, but if a component *MODULE no longer uses or refers to an external object, that object will still show as "used" in the bound *PGM or *SRVPGM when you issue DSPPGMREF.

Example:
Module M1 uses *FILE F1, *PGM P1 and *SRVPGM S1.

Say you bind M1 into another program P2.

Now, when you issue DSPPGMREF for P2, you will see that it "uses" F1, P1 and S1 as well as M1.

Now, if you change M1 so that it now also references another *SRVPGM S2, and no longer references F1, and issue UPDPGM to update P2 with the new copy of M1, DSPPGMREF will now show that it "uses" F1, P1, S1, S2 and M1.

The "downside" to this is that a change management tool might then unnecessarily recompile M1 when file F1 is changed, and then re-bind M1 in any *PGMs or *SRVPGMs where it is used.

This is why it is a "best practice" to not delete *MODULEs after binding them into *PGMs or *SRVPGMs, so you can easily recreate any *PGM or *SRVPGM from its constituent *MODULEs, using CRTPGM or CRTSRVPGM, rather than using UPDPGM or UPDSRVPGM.

Also note that, if no external "where used" references in module M1 were changed, then it is 100% "safe" to go ahead and use UPDPGM or UPDSRVPGM.

I hope this helps to clarify this situation.

All the best,

Mark S. Waterbury

On 9/14/2017 6:19 PM, Jon Paris wrote:
With the caveat that the what used info is not updated when you use the UPD commands. If the CMS tool that the shop uses relies on that info then UPD is not a good idea and recreation is the only real option.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD