Re: replacing binding by copy with binding by reference

Hi, Dave:

Issue the DSPPGMREF command against any one of your *PGMs, and you will see ... *:-)*

This information is useful for "impact analysis" purposes. For example, if you change a *FILE (PF, LF, DSPF, PRTF, etc.), such that the record format level ID changes, you need to know where that file is used, so you can recompile those programs to avoid "level-checks". One way to do this is to create or maintain an *OUTFILE of DSPPGMREF information that you can query.

The problem that Jon mentioned is not that UPDPGM (or UPDSRVPGM) does not update this information, but that it can only _add_ information for the module(s) being updated, and has no way to remove any references that might no longer be valid. This happens because all such cross-references are maintained at the object level, and in the case of a "composite" object like an ILE bound program or service program, there is no way to tell which references came from what modules, once they have been bound into a *PGM or *SRVPGM, as far as the cross-references for that composite program is concerned. So, for example, suppose you have a module M1 that references files F1 and F2. You bind module M1 into programs P1 and P2, and service program S1. Now, you change module M1 so that it now only uses file F1. When you re-bind using UPDPGM or UPDSRVPGM, the cross-references for P1, P2 or S1 will still show a reference to file F2. So, in some cases, this information may become somewhat erroneous, if you use UPDPGM or UPDSRVPGM.

As I mentioned in my prior reply, all you need to do is keep the *MODULEs, after binding them into *PGMs and *SRVPGMs, and use them to find the "where used" information, via the DSPPGMREF command, to get an accurate picture of which modules use what objects (files, etc.), since those are what you need to recompile and replace.

Hope that helps,

Mark S. Waterbury

> On 6/27/2012 7:05 PM, Dave wrote:

What's the emmbedded "what used' information?

2012/6/28 Jon Paris <jon.paris@xxxxxxxxxxxxxx>:

Don't forget that (unless it changed in V7) a UPDPGM will not cause the embedded "what used" information to be updated. So if the in-house tool depends on that data to determine what needs to be recompiled then UPDPGM is not a good idea.


On 2012-06-27, at 5:43 PM, midrange-l-request@xxxxxxxxxxxx wrote:

I think it should be easy to at least change the tool to do UPDPGM if
the pgm exists already instead of crtpgm. I'll try and test that. Are
you sure that would work in all circumstances?

I know of no scenarios where this would not work.

As for changing to srvpgm, that's what I was worried about : all those
files that stay open, global and static variables,... It looks like
we'd have to go through every job to make sure that the difference in
behaviour of the new programs does not have any effect. Should we
start by eliminating the use of the dftactgrp while still using
binding by copy?

Sounds reasonable to me.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com




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