Re: Objects not in a library

That QT3REQIO *PGM exists twice out-of-context [i.e. not in a library] is suspect, but possible by origin for an ENDJOB against a RSTOBJ [or RSTLIB, but effectively it would be LODPTF for that object name -- but a terminated LODPTF???]. Restore is enhanced in v5r4 to enable ENDJOB cleanup for controlled end. Note: immediate end will always leave the greatest opportunity for problems, like objects that are not in a library to be orphaned, due to requesting that the OS not be given time to cleanup.

That multiple objects of type *USRSPC named PSGRSP owned by OSGGMMPD suggest that an application, most likely running under that user or a user that has GRPPRF(OSGGMMPD) OWNER(*GRPPRF), is creating the user space using some means or is being interrupted in some way, that the object is [presumably] incorrectly left outside a library. An object with that /external object type/ should only ever have an *extremely* short period of existence outside of a library. Review of the joblog of the application for the creation and change dates [last change is already known from the report] of the object may suggest the origin for the object being lost to a library.

For more advanced debug: The address of the objects can be obtained from DMPOBJ OSGGMMPD *USRPRF, and each address can then be used to obtain a formatted (Base Structure) MI Object dump of the *USRSPC object type x19 and subtype x34, where the TIME denotes the Creation date/time, and the MDTS denotes the Change date/time. With an MDTS not more than several seconds beyond create, may indicate the error is at that moment.

Hmmmm.... then memory strikes. There was a problem with QTEMP in v5r2m0 at the highest security levels, whereby a crash of the system would have objects that were in QTEMP lost from a library versus being cleaned up properly. Preventives would be on C3021520 however; i.e. a cumulative from early 2003.

Regards, Chuck