So the monitoring software is using a Break program that allocates
the *MSGQ exclusively, and so the application that wants to perform
RCVMSG MSGQ(*SYSOPR) fails due to the conflicting lock held by the 3rd
party monitoring app.? Some thoughts...
Perhaps it is possible for the monitoring software to [effectively]
call the procedure to perform the SNDRPY activity for the messages that
are currently to be handled in the application that [is failing because
it] does the RCVMSG?
Since every message sent to QSYSOPR also appears in QHST and thus the
QHST log, I looked at the Open List of History Log Messages (QMHOLHST)
API but there was no message key referenced. I suppose an unanswered
inquiry could be inquired of the job that is\was waiting for the reply?;
see latter part of the next paragraph:
Per "specific messages", those could be made /alertable/ capable to
be notified using Alerts; e.g. notified to a data queue. However I do
not recall if\what is available using such a feature to enable sending a
reply; i.e. while knowing the message was sent can be learned, I am not
sure enough details are available that would not still require the
RCVMSG. However probably the qualified job name information is
available, I can not recall, but if so, then the Retrieve Job
Information (QUSRJOBI) API could obtain the "Message key, when active
job waiting for a message" for the information supplied to the Send
Reply (SNDRPY) command or the Send Reply Message (QMHSNDRM) API.
The LSTM0100 Format of either of the Open List of Messages (QGYOLMSG)
API or List Nonprogram Messages (QMHLSTM) API offers the Message key as
return data. While these APIs may, while they are running, inhibit
writing to the queue for which the messages are being listed [thus care
for how much data is requested; e.g. against any "highly used message
queues" which would typically include QSYSOPR], there is no mention of
either attempting to obtain a lock on the message queue.
Of course the docs for the Receive Nonprogram Message (QMHRCVM) API
do not explicitly mention a lock required for the message queue object
[and it is the effectively equivalent to RCVMSG], I expect the
requirements would match those of RCVMSG. The API talks about locks
only when a wait-time is specified. So a quick review of the help text
for RCVMSG shows [although I am not clear what it means; I suppose it
refers to each requester of multiple concurrent RCVMSG WAIT(non-zero),
whereby the first of those to get a message will get the lock?]:
"If a wait time is specified (not zero), the message queue is implicitly
allocated to the first user whose message is received, and it is not
released until the request has been handled by the program." If a
non-zero WAIT() is coded on the RCVMSG, perhaps removing that is
allowable for the failing application, and perhaps that would resolve
the conflict.? Difficult to infer from the docs\help if even just
WAIT(0) could prevent the lock conflict, and I do not have time to test;
but of course it may be moot for the failing application.
If the jobs expecting replies to be provided by the code doing the
RCVMSG, instead can be forced to have a[n automatic] reply rather than
Inquiry Message Handling (INQMSGRPY) that requires a reply (*RQD), then
there is a possibility that the Reply Handling Exit Program [Exit Point
Name: QIBM_QMH_REPLY_INQ] could be used to supply the desired reply value.
And of course, whatever are these messages going to QSYSOPR, there is
also the possibility that the messages possibly could be prevented from
occurring so as to avoid the need to look-for\receive them, or perhaps
that they can be directed to another message queue other than QSYSOPR.?
Regards, Chuck
On 17 Apr 2013 11:39, Paul Fenstermacher wrote:
It's looking for specific messages and then using SNDRPY with a C
or an I. V7R1.
On Wed, Apr 17, 2013 at 12:57 PM, Paul Fenstermacher wrote:
I'm using a third party application to monitor the QSYSOPR message
queue and have found a job that does a RCVMSG on QSYSOPR.
Unfortunately it fails because it can't lock the queue, is there
any alternative to RCVMSG or a way to run it without a lock?
Ultimately we're probably going to have to change the application
but I thought I would see if any of the experts have a quicker
answer.
midrange.com
