× 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.



I have not looked at the library because the message instructs to look at the journal and the receiver for locks.
I will look at the QDBSRVxx job for any messages.

Thanks

Tom Garvey



On 7/16/2015 4:16 PM, CRPence wrote:
On 16-Jul-2015 12:41 -0600, Thomas Garvey wrote:
We have a journal that is system-managed, but the receivers are
manually deleted.
We then changed the journal to be Delete Receivers *YES and since
then receive the message CPI70E6 (Journal or Receiver not available,
Reason Code 01).
The 01 indicates "A lock conflict on either journal &1 in library &2
in Auxiliary Storage Pool (ASP) group &13, or receiver &3 in library
&4, prevented the system from either determining if receivers were to
be deleted by the system, or from deleting the receiver at this
time."

This seems to be happening when the receiver has filled up, a new one
is created by the system, and the old one detached.
We have changed the Delete Receiver Delay Time from 10 minutes to 30
but it hasn't helped.
The weird thing is that eventually the detached (status=online)
receiver does get deleted by the system.

When the message arrives (which would be after 30 minutes of
waiting, based on the Delete Receiver Delay Time setting) we do a
WRKOBJLCK on the receiver and there are no object locks at all.


The condition would be expected near immediately and then *again* 30 minutes later on the delayed-retry as recovery from the prior failed attempt. The Delete Receiver Delay Time (DLTRCVDLY) "parameter specifies the time (in minutes) to be used to delay the next attempt to delete the journalreceiver."; with an emphasis on *next*.

Was the Work Object Lock (WRKOBJLCK) request performed also on the Library object and the Journal object as alluded could be possible origin for any conflicting locks?


Has anyone seen this? What could take the system 30 minutes to
delete the receiver?

Any suggestions?


Perhaps review the joblog of the QDBSRV## job that sent the msg CPI70E6 to see if there are diagnostic messages logged that precede the /unable to delete/ error for which the Informational message was delivered [probably to QSYSOPR and\or according to the named Journal Message Queue (MSGQ)]. Perhaps the Return Code 01 (RC01) covers situations other than visible locks, if none of the *LIB, the *JRN, or the *JRNRCV were locked when [each time] the condition was logged; the Default Wait Time (DFTWAIT) of the system jobs is, IIRC, quite short.



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.