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.
midrange.com
