Re: Object destroyed

WRKPRB apparently was cleared. I am not the SA, and he is not communicative. Unless grunts are considered communicating. Also do not have access to SST.

However, you may have been able to shed light on the mess, which is what I
needed. We are not HA. We do have multiple work environments on the system. Usually, one is used to apply vendor code changes. I am thinking that the NEP
got started in a non production environment, but with library list incorrectly
set. Or, the NEP could have been sent a shutdown transaction, again with the
wrong library list.

Isn't the first time and won't (unfortunately) be the last time that the SA

might< have done something and been extremely defensive - when the only motive

was to get things working again without unsolved mysteries. Which this will
unfortunately remain.

Thanks for the suggestions. Next time this happens, I might be able to
understand >why<.

John McKee

Quoting rob@xxxxxxxxx:

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
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





John McKee <jmmckee@xxxxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
06/05/2008 04:40 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Object destroyed






I wish I had posted this question while QHST still had this message. My
loss.

Early last week, a program bombed. It is an RPG III program written a
LONG time
ago. This program is a NEP that reads from a data queue and prints data.
First
thing the program does at startup is a call to QCMDEXC to delete the data
queue.

For whatever reason, the data queue was gone when this program was
started.
Since QCMDEXEC ended in error, and no error monitoring was done, the
program
died.

Quick fix was to create a data queue that it could subsequently delete and
recreate.

I did look at QHST at the time, but only found the message that the data
queue
object had been destroyed. Nothing near it that seemed to be related to
why
the object had been destroyed.

No other odd events, as far as I know.

As I said, I wish I had looked closer at QHST before it got deleted.

This may be either a) a dumb question or b) unanswerable based on limited
information provided, but: What would typically lead to a "object
destroyed"
message being sent to QSYSOPR?

Thanks.

John McKee

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.