Robot Console Job Abend
HBMB
AS/400. The msgq monitoring job, RBCQSYSOPR has an *EXCL lock on the msgq,
however other jobs may DSPMSG and reply msgs but cannot delete them.
Recently, the RBCQSYSOPR has been ending unexpectedly in the midst of
monitoring the queue with messages such as "Monitor for msgq failed" and
"Msgq allocated to another job". Upon checking, we found that the job had
lost the lock and another job (a sign-on session by QSYSOPR) had locked the
msgq. We suspect that somehow, this new job had "wrestled" away the lock.
How can this happen and how do we prevent it? Does anyone have any insight
into this matter or have encountered the problem before? Any help would be
appreciated. Thanks.
red_rid...@my-deja.com
user profile is allocating the message queue. Then WRKUSRPRF on the
user profile and check the values for MSGQ and DLVRY also if you are
running any INLPGM check that also the see if there is a request there
to allocate to message queue.
This is what I have if I WRKOBJLCK
Work with Object Locks
System: PUB01
Object: QSYSOPR Library: QSYS Type: *MSGQ
Type options, press Enter.
4=End job 5=Work with job 8=Work with job locks
Opt Job User Lock Status
RBCQSYSOPR RBTUSER *EXCL HELD
Hope this helps you, good luck.
In article <849rcg$k48$1...@news4.jaring.my>,
Sent via Deja.com http://www.deja.com/
Before you buy.
Steve Van Portfliet
AS/400. The msgq monitoring job, RBCQSYSOPR has an *EXCL lock on the
msgq, however other jobs may DSPMSG and reply msgs but cannot delete
them. Recently, the RBCQSYSOPR has been ending unexpectedly in the
midst of monitoring the queue with messages such as "Monitor for msgq
failed" and "Msgq allocated to another job". Upon checking, we found
that the job had lost the lock and another job (a sign-on session by
QSYSOPR) had locked the msgq. We suspect that somehow, this new job had
"wrestled" away the lock. How can this happen and how do we prevent it?
Does anyone have any insight into this matter or have encountered the
problem before? Any help would be appreciated. Thanks
We are also using Robot Console, not sure what version, and have not
had this problem. I don't think a job can "wrestle" an object lock
from another job. When the job does abend, look at the QSYSOPR message
queue locks (WRKOBJLCK QSYSOPR *MSGQ) and check out the joblog and
invocation stack to get a clue of what's going on. If you have
maintenance on the product, give Help Systems a call, they are very
helpful. Something you probably know, before applying PTFs you must
end Robot Console to allocate the QSYSOPR message queue.
Not related, are you using Robot Alert? I am very interested in that
product and what you have to say about it.
Best of luck.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
HBMB
*BREAK.However, the problem is still recurring. We are thinking of changing
the delivery to *HOLD instead but how does this affect Robot Console? What
is the relationship between the delivery and the lock?
Also, we know that a job can "wrestle" away the lock from RBCQSYSOPR job as
we have tested it. We used a ALCOBJ command on the QSYSOPR msgq while
RBCQSYSOPR job was holding an EXCL lock on the msgq. After a few minutes,
the lock was obtained by our job and RBCQSYSOPR lost it. We tried the same
experiment on another job, a QSYSOPR sign-on session however, our job failed
to allocate the msgq.
A side-note: We are not using ROBOT Alert at the moment. If we have any
info, we'll be glad to help.