Qsysopr Break Handling Programme
Creating message queue QSYSMSG for severe error messages You can create an optional message queue, QSYSMSG, to hold specific severe system messages. QSYSMSG holds only messages that require immediate action.
To create QSYSMSG, type CRTMSGQ QSYS/QSYSMSG TEXT ('OPTIONAL MSGQ TO RECEIVE SPECIFIC SYSTEM MESSAGES') at the command line and press Enter. The system then creates the message queue.
Qsysopr Break Handling Programmer
Once you create the QSYSMSG message queue, your system stores specific system messages in it. Example: CPF0907 Serious storage condition may exist. While I came up the ranks through Operations, I haven't worked that side of an AS/400 for awhile now. But the 400 is such as easy box to run, that you never really forget how to manage the system. To answer your question, I haven't worked with the QSYSMSG queue, but I near as I can tell, it's not really any different than QSYSOPR or most any other message queue for that matter. QSYSOPR and QSYSMSG are just two queues that the systems happens to be setup to use.
Personally, as long as my operations staff knows to check for messages in both queues, I'd create the QSYSMSG queue in a heartbeat. The QSYSOPR msg queue gets overrun with tons of extraneous msgs all the time. This QSYSMSG queue is an excellent idea for cutting through the clutter and getting right to the serious stuff. Do you know how to use IBM's Information Center website? For information and suggestions on how best to use the QSYSMSG queue you can go to the info center and just type in 'QSYSMSG' and click search. A pop-up window with the search results will display and you can click on any of those links and the page will appear in the browser window underneath the pop-up. Depending on which version of the OS your system is currently using, just click on one of the following links: V5R1: V5R2: V5R3: Probably, the most proactive thing that you can do with the QSYSMSG queue is to attach a break handling program to the queue.
The Break Handling exit program provides the capability of handling messages that arrive at a message queue that is in.BREAK mode. A break handling program is defined to the system by specifying both break delivery and the name of the program on the same Change Message Queue (CHGMSGQ) command.
Additional information and an example are provided in the CL Programming book Such a program can do any number of things, from actually handling a particular recurring message id to paging the Systems Administrator that a Critical Error has occurred on the production system. I hope I haven't been too confusing and that some of this is helpful to you. Shalomc: David's comments are pretty much the way it works. The deal with QSYSMSG is simply that QSYSOPR is a user message queue associated with the QSYSOPR user profile. Because of that, any time any QSYSOPR profile signed on to any AS/400, that message queue was allocated.
And because so many useful messages are automatically sent to QSYSOPR, a lot of sites wanted to automate the handling of those messages. But any batch job that was allocating the QSYSOPR message queue was also interfering with QSYSOPAR signing on to the system. So, IBM created the QSYS/QSYSMSG message queue concept.
If you create QSYSMSG in library QSYS, OS/400 will recognize it and begin sending messages to it. Only messages that IBM designates as important enough will be sent to QSYSMSG. Most messages sent to QSYSMSG are no longer sent to QSYSOPR though a few are duplicated. This allows automatic handling of QSYSMSG plus interactive use of QSYSOPR for normal stuff. I agree with David about creating QSYS/QSYSMSG.
It's the kind of thing I do on the first day of administering a system, even if I don't have a monitor program for it. I invariably create a monitor eventually anyway, and I want the message queue in place and active when I do. Besides, I don't want someone to clear QSYSOPR carelessly and wipe out a bunch of important messages. OTOH, it then becomes necessary to track QSYSMSG for important notices.
This can be done by placing it in.BREAK mode if you wish, but responsibility falls on you. If you have a CL Programming guide, most of the specific messages sent to QSYSMSG are listed there.
David's links to the InfoCenters probably will also lead to lists. Hi Shalomc, Quick question for you. Why you want to create this message queue??? I created this queue in my system 6 months ago thinking it will decrease the number of messages in my QSYSOPR queue enough. This queue is suppose to provide only critical IBM errors. It work fine but didn't solved my problem who was to decrease the number of message in QSYSOPR queue to see what was important to see!!! So I decided to create a new message queue named PRTMSG.
This queue receive all the messages sent by my printers. 'Load form type '.STD'.' ' 'TCP/IP connection to remote system 25.255.103.31 closed, reason code 2. ' This new message queue did more then everything else. Shalomc: Messages deemed important by IBM will be sent to QSYSMSGQ. A few will also be sent to QSYSOPR. CPF0907 Serious storage condition may exist.
CPF111C System scheduled to power down. CPF111D System is powering down. CPF1393 User profile has been disabled because maximum number of sign-on attempts has been reached. Are examples of messages that could be sent. The OS/400 CL Programming Guide has a list.
Applications can also send to the message queue. Messages 'get to the console' because you put the message queue into.BREAK mode at the console.
Messages get to your workstation the same way. Or of course you can do DSPMSG QSYSMSG. There's no difference in how this message queue is handled from any other message queue. The point of QSYSMSG is not to get the messages to display. The point is to create programming that receives the messages and then does remediation.
As for a large volume of messages in QSYSOPR, any authorized user can control the volume. There are two elements to attend to: (1) What severity have you set the message identifier to? And (2) what severity do you have QSYSOPR set to. If you don't want to see a bunch of messages appearing on a QSYSOPR workstation screen, then don't ask for those messages to be displayed. Go to the message file and change the severity.
Then set the message queue to filter messages based on severity.