It takes quite a bit for QSYSOPR to fill up. May I suggest going to the clean-up menu, and schedule a message cleanup on a daily basis. You may be pleasantly surprised at the overall results. GO ASSIST, select Clean-up. Dave
It takes quite a bit for QSYSOPR to fill up. May I suggest going to the clean-up menu, and schedule a message cleanup on a daily basis. You may be pleasantly surprised at the overall results. GO ASSIST, select Clean-up. Dave
Thank you David for your response, it is appreciated! We have a monster 890 which talks to many other systems and once in a while, QSYSOPR will need to be F16'ed, (or cleared), every 2 hours. We have 24 hour coverage and usually every shift clears the MSGQ hopefully at least 3 times per shift, but again, when the system is in a heavy batch mode, and there are extra things going on with the communications, (like funky problems), the informational messages are streaming thru like a mainframe. If the message queue maxs out, then (sometime multiple) legacy jobs that are asking for a tape mount abort, the message never breaks to QSYSOPR, the tape never gets created, and the job never continues to the code beyond that inquiry message. Then we have the pleasure of going back and seeing which jobs aborted and need to be resubmitted and/or continued from where they left off. Worse yet, this may not get caught right away. Rookie operators almost always get burned by this one at some point in their development. Can the QSYSOPR MSGQ capacity be increased? GO ASSIST, select Clean-up may be an option, however; generally, my Boss likes us to do the F16 manual clear. Chow!
Robert, at first sight I'd think that CHGMSGQ QSYSOPR MSGQFULL(*WRAP) may solve your problem, but may be i'm missing something. hth Bernd
If you use ROBOT, schedule following jobs to run every 120 minutes. If not use OS/400 Job Scheduler (ADDJOBSCDE). You'll need to create several to accommodate the 2 hour requirement: If you want to archive messages - DSPMSG MSGQ(QSYSOPR) OUTPUT(*PRINT) If you want to delete all unanswered messages - CLRMSGQ MSGQ(QSYSOPR) CLEAR(*KEEPUNANS)
Hello All, QSYSOPR message queue automatic clearing of informational messages. OS/400 Job Scheduler (ADDJOBSCDE)- could/would work if the powers that be sign off on it.[*]WRAP would be cool except that it would clear all informational and inquiry messages - we would get slammed by letting inquiry messages go unanswered and thus, unresolved. Ultimately, a way to test the capacity of the QSYSOPR message queue and then send an inquiry break message to QSYSOPR informing OPS that the queue is at 90% or 95% capacity would be perfect. The operator would reply with an acknowlegment that would then trigger the message queue to automatically clear only the informational messages or the operator would simply manually F16 the QSYSOPR *MSGQ from the system console display. Whether or not it is determined that the time that it takes to set something like this up is a good ROI of someone's time and gets assigned to someone is the next big question... Thanks to all who participated and I will try to post a follow up... Take care!
WRAP would be cool except that it would clear all informational and inquiry messages - we would get slammed by letting inquiry messages go unanswered and thus, unresolved. Well according to the documentation: WRAP When the message queue is full, the oldest informational and answered messages are removed from the message queue to allow space for new messages to be added. If the removing of the informational and answered messages does not provide enough space to add the requested message, then unanswered inquiry messages are removed until there is space to add the requested message. When the message queue is wrapped, CPI2420 or CPI2421 will be sent to the queue that was full to indicate it was wrapped. If there is no space on the queue to send these messages they are sent to the joblog of the user that was sending the message to the queue and they are sent to QHST if the full queue is QSYSOPR. So you would need to have a lot of unanswered messages on the queue if these needed to be removed the first time a wrap occured. And in those cases I suspect something may be more wrong then just the queue being full. You could still monitor for the CPI2420 and CPI2421 messages, as I would expect the first wrap will have sufficient space to put the msgq wrapped message. So your operators could take manual action.
Dave, thanks, you pointed out what I meant. :-)) Bernd
Robert: With that volume of messages, you should not just flush the queue. Consider using third-party tools that manage messages outside your queues. There are some excellent ones out there. For instance, the company I work for, CCSS, sells a message handling and automation tool called QMessage Monitor which you could find useful. Regards, Kurt
As an aside: If you decide to leave your messages on a queue, QMessage Monitor also provides an alarm when the queue is full to x percent, where x is a threshold that you can customize. Also, once you determine that a queue is "too way too cramful", QMM allows you to ease the load by selectively deleting messages based on their date, message ID, and other criteria. Hope this helps. Regards, Kurt
Thank you again everyone for your participation - you have my gratitude and your time, experience and ideas are appreciated! Bernd and Dave400: If what you are suggesting turns out to be true, this just may do it, (at first reading, it just seemed to good to be true! Good things usually do not come easy, for me anyway...). This particular system is a big money system and I always proceed with extreme caution relating to this system. This will ultimately be my bosses call, but if I can make the case and he signs off on it, I'll let you know how it turns out. Kurt: I will research this option also. Again, if the product is useful for our needs and I can make the case for ROI, this could also be an alternative. When the Boss has the time, I will discuss my findings. Take care.