×
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.
If you are talking about CPF9805 - Object &2 in library &3 destroyed. Then
look at the second level text.
Cause . . . . . : Object &2 in library &3 type *&5 has been destroyed.
Recovery . . . : No recovery. Report the problem (ANZPRB command).
Apparently IBM wants you to contact them when this happens.
So, if you do a WRKPRB do you see anything around that time?
Also if you do the following:
STRSST
1. Start a service tool
5. Licensed Internal Code log
1. Select entries from the Licensed Internal Code (LIC) log
Do you see anything related?
Also I see this memo from the software knowledge base:
http://tinyurl.com/59x4sm
http://www-1.ibm.com/support/docview.wss?rs=0&dc=DB520&dc=D900&dc=D800&dc=DA900&dc=DA800&q1=cpf9805+AND+AS400KBXXYYZZRCH&uid=nas18695c679a9c6f5b18625708b004ffa81&loc=en_US&cs=UTF-8&lang=all
The situation I see likely there is that you had two copies of the same
job. One was sitting in QRCVDTAQ and the other did it's trash and
rebuild. When the one did it's trash and rebuild then the first job
sitting in QRCVDTAQ hurled. If you still had DSPLOG (QHST stuff) going
back that far it wouldn't be hard to tell by DSPLOG JOB(RCVDTAQJOB) if
there were two jobs running at the same time. Since that's out of the
question, you aren't, by chance, running a High Availability solution
(such as Mimix) that logs everything dealing with data queue's to QAUDJRN,
eh?
Rob Berendt
midrange.com
