Monitor Qsysopr Message Queue
admin 02.09.2019
Monitor Qsysopr Message Queue Average ratng: 6,1/10 2417 reviews
Monitor Qsysopr Message Queue Video
Who answered that message on the QSYSOPR message queue? Here is a fast and easy way to see who answered a message on Qsysopr message queue. Share this item with your network. Vso convertxtodvd 7.0.0.61 serial key.
Monitor Qsysopr Message Queue Download
- First, QSYSOPR shouldn't be monitored for critical messages such as hardware failures. Those messages shouldn't be sent to QSYSOPR; they should be sent to QSYSMSG. In order to enable QSYSMSG, all you need to do is create a message queue named QSYSMSG in library QSYS, and the OS will automatically use it for critical system messages.Second, are you sure the program will be able to run after a hardware failure?Third, IBM provides Example: Receiving messages from QSYSMSG. If you really want QSYSOPR, all that example needs is to use the other name. (It's not a good idea to use QSYSOPR.)Fourth, we don't know how your system sends e-mail, so you'll have to do that part on your own. If you run into a problem, you can post your code and describe the problem. We can help when we know what some problem is.Fifth, using Management Central is probably better than writing programming for this. Why write a program if the system will do it for you? You can find an example in Scenario: Message monitor. That example is about QSYSOPR and *INQUIRY messages, but a different name can be used and different messages can be listed.Tom
report - Hi Tom, Thanks a lot for your valuable inputs. Currently i am using message monitors in Management Central to alert me using SNDDST command when ever the specified message ID's occur in QSYSOPR. These monitors working absolutely fine till the monitors are in 'Started' status. But these monitors are not reliable as these are going to 'Failed' status randomly. I don't even get proper solution also from IBM from past 6 months. so, I am looking for alternative solution. Now, I have created a session using the command STRWCH which monitors the message queue and call the program. The program contains only SNDDST command, but i dont see it is working.The below session is for testing. The session details : Session ID . . . . . : ALERTMON Started: Started by: Date . . . . . . . : 05/17/13 Job name . . . . . : QPADEV0008 Time . . . . . . . : 05:35:35 User . . . . . . . : QSECOFR Call exit program: Number . . . . . . : 034200 *WCHEVT Watch program . . . : ALERT Library . . . . . : MADHUTST Origin . . . . . . . : STRWCH Run priority . . . . : 25 Message Job Message queue Library name User Number CPIEF01 QSYSOPR QSYS Bottom Please suggest & advise if this approach works to monitor QSYSOPR (or) QSYSMSG. Rgs, Madhu
report - I don’t even get proper solution also from IBM from past 6 months.I don't quite understand. Have you been trying for 6 months with Management Central (MgtC)? This question thread is only 11 days old.You have the STRWCH command, so you are at least at V5R4, i.e., on a supported release. There are at least three elements needed to handle failed monitors properly on any current release.First, there are PTFs. If you've been working with IBM, they should have verified that you have the appropriate ones installed.Second, the MgtC Properties need the 'Automatically restart monitors on failed systems' option checked.But the third element is a tricky one. The 'Name' of the monitor needs to include the word '&RESTART'. I'm not at all clear why that is a requirement, and it's not easy to find. (I'm not sure I can even find the documentation again.)So, for example, I have a Message Monitor and its Properties show:Name: Test &RESTARTWhen a failure occurs, it has no problem starting back up automatically. In my current setup, I'm running MgtC on V5R3 as the Central system, with V5R3 and 6.1 as Endpoint systems. If you have V5R4, it should work better (with any needed PTFs).For STRWCH, I don't yet have good useful info on failures. I don't any history on failed watches yet, so there's not much I can say.However, you need to understand that various failures are at least just as likely if you create your own function. And if you create your own, elements such as object (message queue) locks can cause problems.Do you know anything about the causes of 'Failed' status? Are you running a single system or is it a network of AS/400s? If you have multiple AS/400s, what are the oldest releases you have?Tom
report
Microsoft Message Queue
Hi, James:
Placing a message queue into *BREAK mode in your interactive or batch job,
or sitting on a RCVMSG instruction (or QMHRCVM API) will place a lock
(*EXCLRD, I think) that prevents other jobs from 'updating' the queue. The
effect is the same from an outside standpoint, but it's not the same.
What you're saying is analogous to 'ALCOBJ does the same things as OPEN on a
file.' Well, yeah, to a point, I guess, but not the same.
Anyway, this approach has worked for me in the past. Pseudocode:
LOOP:
Receive message immediate
If message_received
Special processing
Goto loop
End-if
Sleep 30
Go to LOOP
Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
Computers are not intelligent. They only think they are.
Placing a message queue into *BREAK mode in your interactive or batch job,
or sitting on a RCVMSG instruction (or QMHRCVM API) will place a lock
(*EXCLRD, I think) that prevents other jobs from 'updating' the queue. The
effect is the same from an outside standpoint, but it's not the same.
What you're saying is analogous to 'ALCOBJ does the same things as OPEN on a
file.' Well, yeah, to a point, I guess, but not the same.
Anyway, this approach has worked for me in the past. Pseudocode:
LOOP:
Receive message immediate
If message_received
Special processing
Goto loop
End-if
Sleep 30
Go to LOOP
Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
Computers are not intelligent. They only think they are.
I just made an interesting discovery:
If I have a CL program monitoring QSYSOPR for messages (using a RCVMSG
command), that message queue then behaves like the user message queue
of
a signed-on user, in that you can't delete QSYSOPR messages.
I don't suppose there's an easy way for a CL program running in a batch
job to monitor the QSYSOPR message queue without actually tying it up?