Re: QCLSRC with PF38-SRC attribute

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.