Re: Scrambled object name

On 12-Dec-2014 09:35 -0600, rob@xxxxxxxxx wrote:

Is this just a timing issue with a custom program in QSTRUP?

Irrespective the /timing/ of the following request to Delete SQL Package (DLTSQLPKG), the error message issued by the OS program [unstated; context lacking] that reflects the condition diagnosed by [and left logged as referenced by] the LIC RM [again, unstated; context lacking], the "scrambled object name" is an error. The error with the replacement text for the msg CPF9803 may be directly related to the missing data in the LIC exception [having the text since edited to show the undelimited token "???" in place of the apparently missing library name] or perhaps as much as completely unrelated to the message data in the prior msg MCH5802; the incorrect messaging appears nonetheless, as nothing short of a defect.

Note that the second message may be getting some of the data from the catalog data [indirectly maintained as part of the *DBXREF data for storage, but maintained directly via the SQL Package features]. The data in the file QADBPKG in QSYS could be copied, to make a backup copy of what the data currently is; the SQLPKG must not yet have been deleted. Very unlikely, any data about the row representing the *SQLPKG object QZDAPKG in QGPL might instead be found in the journal for the files updated\maintained by the QDBSRVXR system job.

The issue may be a hard failure, such that a [system] job may be holding a long-held lock; effectively unrelated to timing of the request. However if any jobs were started prior to the failing request, that means any job on the system that was acting on the object such that a lock was held even temporally, then the lock conflict could be a legitimate issue to be aware of [and might be desirable to be monitored and resolved]. While I have known that SLQ package to be something customers have deleted [¿due to crappy design, defects, or just because others do and report joy?], there should be no reason to delete that object at the start of every user-portion of the IPL; if there is just cause to delete that object at that point, then the errors from which such a conclusion was drawn are likely indicative of a defect that should be reported [and hopefully prevented with a PTF].

...
DLTSQLPKG QGPL/QZDAPKG

Message ID . . . . . . : MCH5802
Message . . . . : Lock operation for object QZDAPKG not satisfied.
Cause . . : The lock operation was not satisfied for object
QZDAPKG in ??? the specified time interval of 30 seconds. The
lock holder type is 1. The lock holder name is
QZDASOINITQWEBADMIN 517399. The lock holder thread identifier
is X'0000000000000006'.

Probably T/QSQDLTPK and F/rm?????

Message ID . . . : CPF9803
Message . : Cannot allocate object ²±Ê/¬■ê-■■ in library ■■■■■■■■■■.
Cause . . : Object ²±Ê/¬■ê-■■ in library ■■■■■■■■■■ type *■■■SQLP
is in use.

Probably F/QSQDLTPK; T/usrpgm per the following.

Message ID . . . : CPF9999
Message . : Function check. CPF9803 unmonitored by OSCUSTOM at
statement 209, instruction X'009A'.

This merely indicates that either the QSTRUPPGM named OSCUSTOM did not include an active monitor\handler for the /object locked/ condition that was manifest as an Escape message for the failed DLTSQLPKG request.

<<SNIP v7r1 PTF group info>>

Checking the APAR database for the symptom keywords, possibly without the command name, might yield a PTF; I did not spend any time to check per the messages were not given as either Spooled Joblog format or F6=Print, thus they are lacking the context that would allow deriving symptom kwd strings.