On 30-Nov-2011 13:54 , Sam_L wrote:
A batch job tried:
ALCOBJ OBJ((xxxxxPF *FILE *SHRNUP *N)) WAIT(0)
It failed with CPF1002.
Is there a spooled joblog taken with LOG(4 0 *SECLVL); presumably the
actual request "RQS message" was logged too? Any QPDSPJOB produced?
I ran WRKOBJLCK OBJ(xxxxxPF) OBJTYPE(*FILE) MBR(*ALL)
Any spooled output of that request to confirm? A spooled WRKJOB
taken for the job doing the WRKOBJLCK?
It showed only *SHRRD locks.
Any spooled WRKJOB for job(s) listed as holding any of those *SHRRD?
Any recollection if only one job, or more than one job was holding the
member locks and if both MBR and DATA? Were the number of each matching?
FWiW neither request above, had library qualified the file; or so one
might infer for lack of 'xxLIB/' preceding the xxxxxPF
I tried the same ALCOBJ command from the green screen. It also
failed with CPF1002. Tried it several times, same result.
Is there a spooled joblog taken with LOG(4 0 *SECLVL)? DSPJOB output?
Having used WAIT(big_value) instead, should have allowed a review for
the lock "status" of WAIT, via a WRKJOB OPTION(*JOBLCK) against the job
attempting that ALCOBJ issued within that [wait] time; i.e. assuming the
effect had not cleared up, as alluded transpired an hour later.
Hmmm... If the CPF1002 does not have the library name [seems not so
in v5r3], then the joblogs are of less value than I might have assumed
in above comments. The job information, at least the library list, is
still pertinent if the name was not library qualified.
Over an hour later, while attempting to demonstrate the failure to a
coworker, my ALCOBJ worked! None of the other *SHRRD locks went away
(as far as I can recollect.)
User resubmitted the batch job and it worked as expected.
So it appears that something had a lock on the file that WRKOBJLCK
could not show. Any ideas?
The WRKOBJLCK MBR(*ALL) does not show the *FILE level locks when
performed interactively OUTPUT(*). If all of the locks seen were held
by one job, then a *EXCL on the *FILE might have been held by that other
job but not visible as I recall; i.e. a conflicting but unseen lock as
the legitimate origin for the error. The named file being created
either under isolation or as part of a restore would have such a lock;
only the former would also have any data locks... and per exclusive, any
other locks only in the one job. A database file pending database
recovery [for a failed operation not under
isolation\commitment-control], the *FILE will have a *EXCL lock by an
active job which has not yet reacted-to by recovering from a failure;
database message(s) [since a failure leaving the file pending recovery]
in the history likely would record a "recovery completed" or similar, if
that were an issue.
FWiW I believe there is an oddity for database file member objects
whereby the "allocate object" request must first obtain a space location
lock before being able to attempt to get the actual *FILE [*SHRRD on the
file], *MEM [*SHRRD on the member\MBR], and *QDDS [*SHRNUP on the DATA]
locks. I do not recall if WRKOBJLCK shows any SLL [Space Location
Locks}, but IIRC somewhere iNav has a means to include them.? A file
for which a clear [CLRPFM] or reorganize [RGZPFM] request is pending
completion, I believe would hold such a lock to prevent any other lock
requester from appearing to "hang" [in RUN status] on a long-held seize.
Such a scenario should show the dataspace lock as *EXCL however.
FWiW: For a recreate scenario [as with the several failed attempts
before the functional attempts an hour later], a repeatable\persistent
failure for the ALCOBJ could be traced and then a breakpoint added to
catch an error condition [MCH5802] that was signaled but not suppressed
[as could be inferred, given MCH5802 is visible in the text of trace
output; I can not recall, nor trace to confirm]. For example, stopped
at the statement '/0001' of the "receive message" program which
presumably runs with the option to remove the message, F10=Command line
could be used to access the error and press F1=Help [and F6=Print] to
review the extra details recorded in that error message. If the message
does not appear in a trace, that means the message is suppressed and
debug would not help to find the MCH5802 as the underlying condition
which was relayed to the user as CPF1002.
Regards, Chuck
midrange.com
