Re: QCLSRC with PF38-SRC attribute

[CRPence <CRPbottle@xxxxxxxxx>]

  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.