× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Every "object" has a creation date in the LIC object header, as well every object has a permanent "address" [a "segment"]. When a program is "re-compiled" from source as a bound program, the old program object is typically renamed and moved to the QRPLOBJ library leaving the original object and address with everything except the change date [both rename and move update that] and the context [*LIB] in which the object is considered to be residing effectively unchanged; i.e. the renamed object still has its original creation date. The new "created" object has its own, new, creation date\timestamp. The "replace object" library named QRPLOBJ is cleared on every IPL however, so the older program object was presumably long since deleted and thus the address invalidated; since the creation date is part of the object and not the pointer, even having available a stored copy of the associated pointer can not assist, since references to a pointer will effect nothing but MCH3402. If the OS replace-object technique was not used, then that means the deletion was just done earlier or perhaps the person\feature doing the "recompile" activity had done so; for the former, the same issue as with QRPLOBJ, and for the latter, if that moved or renamed copy still exists or was saved later, the creation date may still be available from the existing object or media. Because...

Restore provides a nuanced "creation" in that the LIC header was included on the media, and that information replaces\sets the object creation date of the new object within the new [segment's] associated address. Thus if there is a backup copy of the *PGM noted in the original post for this discussion, if there exists SAVOBJ or SAVLIB media that was taken before the last recompile, then the creation date\timestamp is still available on that media; i.e. the *PGM could be restored into QTEMP, and a DSPOBJD would show the creation information.

Regards, Chuck

On 09-Dec-2011 10:18 , Jerry C. Adams wrote:
I'm not sure about the object restore, Paul, as I haven't done any
empirical testing. But I suspect you are correct because CRTDUPOBJ
and CPYLIB do have a create date = the date of the copy, not the date
in the original object.

paul therrien on Friday, December 09, 2011 11:22 AM wrote:

I may be missing a nuanced conversation here but ...AFAIK the
create date is the create date is the create date. The change date
may be affected by a couple of operations, but the create date is
the compile date. I may be wrong, but I have no reason to believe
otherwise.

Now, if the program object was placed on the system by a restore
command then this may be a different kettle of fish.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.