Getting error messages from qsysopr

25 pts.
Tags:
QSYSOPR
SNMP
Need to gain access to qsysopr error messages coming from custom apps written. Do NOT want an agent on box. Any thought son how to gain access to these error messages?

Software/Hardware used:
i-series 7

Answer Wiki

Thanks. We'll let you know when a new response is added.

In a CL program, you can use the RCVMSG command to read the messages in QSYSOPR.

A simple program to monitor for messages would be something like this:

PGM

DCL &MSG *CHAR 128

LOOP:

RCVMSG QSYSOPR WAIT(*MAX) MSG(&MSG)

your logic here – Either within this CL or call a program with &MSG as a parm.

GOTO LOOP

 

Discuss This Question: 4  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • John Andersen
    The one issue you will run into using RCVMSG is it allocates the object...  Also what apps are you referring to? They may be an alternative to using QSYSOPR... -John Andersen
    195 pointsBadges:
    report
  • TomLiotta
    First, there should not be any messages from "custom apps" in QSYSOPR. But you probably can't do anything about that.   No matter what, you are going to have an "agent on box" (well, unless you pay someone to watch QSYSOPR and manually enter messages somewhere else). You can program the agent yourself, or you can use a 3rd-party agent. For simple work, you can program the "agent".   But most likely you won't want to. For a system message queue such as QSYSOPR, it's not as easy as just using RCVMSG. E.g., as noted above, the automatic allocation of QSYSOPR ensures that no other process can be using the message queue. That means that you can't even have a logon that has QSYSOPR messages breaking at a workstation as long as the "agent" needs to be running. I.e., you can't have two processes monitoring QSYSOPR at the same time.   If you are not already familiar with methods of message queue monitor programming, you're likely to run into conflicts that can take possibly days to resolve while you learn the concepts and the programming. I assume you have a business reason for doing this and for mentioning an "agent" in the first place.   Tom
    125,585 pointsBadges:
    report
  • NickHutcheson1
    At a former employer we used ACOpager from DDL systems to monitor message queues, qsysopr, qhst, etc.  Fairly cheap(cheaper than others) and easy to setup.  It also featured a reply list, 'ignore' list for messages.  There may be a way to copy new or un-answered messages to a file and let a program read through the file for specific messages.  When this process executes, you could remove any un-needed messages.  Of course, the best way would be to make your application messages go to another queue or file instead of QSYSOPR then you could still look for messages from your apps without locking qsysopr or removing messages from there.  The reason I say this is I'm not sure how large the qsysopr message queue will get on your system before it wraps or is cleared.My two bits.Nick
    1,380 pointsBadges:
    report
  • TomLiotta
    The reason I say this is I’m not sure how large the qsysopr message queue will get on your system before it wraps or is cleared.   The maximum size of a *MSGQ is 16MB. QSYSOPR should have the default set by IBM. But the queues usually don't actually hold "messages"; they usually hold message IDs, some minimal replacement values and various definition fields. What you see when viewing the queues is the interpreted content. They can appear to be much larger than they are.   ...without locking qsysopr or removing messages from there.   "Removing" (or more likely not removing) messages is one fun part of RCVMSG. The handling of 'old' or 'new' messages when a message monitor is restarted takes practice. The content of QSYSOPR can be cleared real fast if not done right. Messages can also be processed multiple times after restarts.   For a system message queue, there are various things that can go wrong. Finding problems a week or a month or more later can be messy.   Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following