I do not recall anything other than database save\restore that uses
the member level identifier. But as an exposed value, anyone _could_
write code to store the value and compare later. Because the "To member
identifier" (TOMBRID) parameter was added to the CPYSRCF, I would bet
some software provider cared; the database restore already had the
*FILELVL special value to deal with the changed level IDs.
The features I do know that depend on a value, use the "Last source
change date" instead; typically either to diagnose to the user that the
source has changed since whenever [e.g. a debugger, since compile] or to
perform new validation\checking against the stored source [e.g. the REXX
interpreter rebuild its parse structures and whatever else it does].
IIRC the binder does something with stored member attribute(s) too...
and it may use either or both the change timestamp and\or level identifier.
I suppose a SCM environment might want to store the level-value, even
if only to be aware that restores would be impacted.
Regards, Chuck
On 24 Jan 2013 12:09, Mark S Waterbury wrote:
This brings up an interesting question: (at least, I think it is
interesting ...)
Other than save and restore operations, where else is this "member
level ID" ever used?
On 1/24/2013 2:48 PM, CRPence wrote:
<<SNIP>>
I suppose that [ed: maintaining the Member Level Identifier] is
not extremely important because restores from old backups to effect
source recovery would still require use of the ALWOBJDIF(*FILELVL)
to get past the new File Level Identifier. However any other
interface that might also refer back to a stored copy of that Mbr
LvlId value would not infer change when there was effectively no
change.
