OS/400 puts critical messages into the QSYS/QSYSMSG message queue. If I were you, I would code a program to check this message queue and filter out those message-ids that require immediate attention. These selected messages should then be emailed to me asap. For course some kind of control (example: compare date/time of last extraction)is needed to make sure I do not get the same message over and over again. Some checking for duplicate messages would be nice too (to avoid redundant emails) Some of these messages-ids are: CPF1393 - Subsystem ... disabled user profile ... on device ... CPF0907 - Serious storage condition may exist. Press HELP. CPI099C - Critical storage lower limit reached. CPPEA05 - *Attention* Contact your hardware service provider. CPI1165 - One or more device parity protected units still not fully operational. CPI1166 - Units with device parity protection fully operational. Just remember, this is basically a short-listed set of alerts. Once in a while, you should still go in and take a hard look-around for problems.
Unconfigured Ad Widget
Collapse
Announcement
Collapse
No announcement yet.
Email Notification
Collapse
X
-
Email Notification
Hi Alan, I've setup monitoring on our systems that uses basic CL and REXX as the programming/scripting languages and it works well, so I don't think your not having COBOL will hurt you. There are always better ways of doing things of course. If you're not interested in programming, there are a number of products available that do the majority of the work for you (two that I've looked at are MessengerPlus and ICOM/400)...all you do is simply tell them what to monitor for, what to do when an event is encountered and they take care of the rest. You'd have to weigh the software cost against how much of the available functionality you'd actually use (and how long it would take/how much it would cost to have your staff write your own code). In both solutions (purchased or home-grown), you still have to research what you want to monitor for to support your environment. Good luck and I hope this helps, Steve Carvaines
Comment
-
Email Notification
Alan, Who said anything about Cobol? I develop all my utilities in RPG and CL. Anyway, I thank you for giving me the idea. I will be writing my own code to send me the email notifications. Until now, I have been relying on a small CL program that automatically sends me the whole QSYSMSG queue twice a week via snads. I suppose some people may think this stuff is so trivial, but when you are monitoring up to 15 remote AS/400s running different applications under different time schedules and with not so reliable communication lines the tediousness just piles up. If you have snads setup at your sites, I can give you the CL's source code. Or maybe latter next month, I should be finished with my new program to send email notifications. Just hope this forum is still open by then.
Comment
-
-
Email Notification
Hi guys, Here is my CL program to monitor selected messages from QSYS/QSYSMSG and send email whenever such messages are received. I still have some more improvements in mind, but this should do quite nicely as a starting point for anyone else interested in this topic. By the way, lest you be misled, the built in time delay is arbitrary. It only determines how often the program checks for a shutdown condition. There is no delay-time involved in the detection and email of notices.
monsys.txt
Comment
-
Email Notification
Hello Shafiq, The message indicates that the QSYSMSG message queue has already been allocated by another job. Here are some possible causes: 1. Someone is monitoring (and allocated) it online (via CHGMSGQ command) 2. There is a running batch job that has allocated it (either via ALCOBJ or RCVMSG command) If you just recently created the QSYSMSG message queue yourself, I strongly suspect you already have a previously submitted version of the MONSYS program running somewhere in batch. This program would allocate QSYSMSG to itself and prevent you from accessing QSYSMSG from another program. You can check for this condition by running the WRKOBJLCK command on QSYSMSG. By the way... you might want to take a look at the article I wrote on this same topic. It is not only free, it also includes a more robust code for monitoring QSYSMSG. http://www.mcpressonline.com/mc?1@17...ae.1@.5bfa6e6c I hope you find this useful. Ric Ang
Comment
-
Email Notification
Shafiq, I tested the setup in v5r1, it works. There is no system value involved. As long as message queue QSYSMSG is in library QSYS, the operating system will always try to send critical messages to it whenever a serious problem is detected. Please note that not all messages sent to QSYSOPR are also sent to QSYSMSG. It is possible that there is nothing to worry about. You may be running the monitor in an AS/400 with very low activity and no serious problems whatsoever. If you want to test this, just create a dummy user profile and make several invalid sign-on attempts until it becomes disabled. This will trigger the OS to send a warning message to QSYSOPR and QSYSMSG.
Comment
-
Email Notification
Shafiq, I am not aware of any documentation on critical messages. All I can suggest is that you look at the sample code in my article http://www.mcpressonline.com/mc?1@17...ae.1@.5bfa6e6c You can extract a number of critical messages from the code. Sorry I cannot help you further. I am currently jobless and thus have no access to an AS/400.
Comment
-
Email Notification
Thanks Ric, I just found these messages by searching the QSYS/QCPFMSG File and they are CPI116A 99 Mirrored protection suspended on the load source disk unit CPI116B 99 Mirrored protection still suspended on the load source disk unit I hope you will get a better oppurunity sooner. Thanks Shafiq
Comment
-
Email Notification
Shafiq, It is good that you found the message. Just beware that these may not be the exact messages that may pop up in QSYSMSG. Also, beware of complacency. While this monitoring program can considerably reduce your monitoring activity, it has it's limitations, so you should take care not to be too dependent on it. Some notes: 1. It only monitors messages you programmed into it. You never know when a never-before-experienced problem (and accompanying QSYSMSG message) should pop up. In my case where I was monitoring 15 AS/400s, I made it a point to view each AS/400's QSYSMSG queue at least twice a week. 2. The program relies heavily on email to inform you of potential problems. Make sure your AS/400 email services are always up! A quick check would be to send email to yourself from each AS/400. I used to entertain myself by assigning each AS/400 a human name and program them to email me a unique cheerful message every morning. 3. You might want to code a program to monitor for never-before-seen messages in QSYSMSG and to email you about it. This will help cut down on unpleasant surprises. Well, that's all for now. Ric Ang
Comment
Comment