On 17-Mar-2012 15:01 , frank kolmann wrote:
The following is not a request it is a fyi.
If you knew this already, my apologies.

Sharing experiences can often be valuable... esp. of difficulties encountered, because there is a good chance others might stumble there as well. I just wish I had that /heads up/ way back when; long, long ago. I am sure that others may [if only eventually] appreciate your comments as an admonishment. So although not helpful to me... Thanks, and IMO, certainly no apologies necessary.

I added my experience and my resolution, FWiW; following the quoted\replied-to message.

Also some may reply why did I not read the manual, well I did, But
my understanding was completely different to what is implied QSYSMSG
does.

Are you under the impression that QSYSMSG gets all CRITICAL messages.
It is not so. The ONLY messages sent to QSYSMSG is what is listed in
an IBM manual. This makes QSYSMSG as useful as the proverbial .....

We set up a monitor on QSYSMSG think Ah Ha the Critical messages are
now monitored. But <<SNIP what seems s /critical/ issue\condition,
msgCPPEA56 and doc reference; though here is the corrected URL:>>
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rbam6/msmqu.htm


OK back to the drawing board, and redesign the monitor to work
over QSYSOPR as well as the QSYSMSG *MSGQs, this is a farce, I
should never have set up QSYSMSG, thanks IBM for not very much.


I recall that long ago I had read somewhere, to request the "CRTMSGQ QSYS/QSYSMSG", but with little additional commentary other than for the reason I went looking in the first place; i.e. as a means both to avoid the locking of and deferring to a "Break handling program" the control of, the *SYSOPR message queue. So after creating the QSYSMSG *MSGQ and then controlling that message queue instead, with my break handling program intending to effect alternate\additional notification, I also had learned eventually that some of what I felt was /critical/ was not, at least according to the since-reviewed docs :-(

I ended up using instead, "alert options" [ALROPT] on some individual messages that were of interest to me for notification; using CHGMSGD to make the specific messages for which I had interest in tracking, become alert capable\activated. At the time I could find no documentation about enabling alerts, but after a lot of fumbling and inference [GO CMDALR, WRKALR, plus GO CMDACN for /action/ "ACN" or "ACNE" entries and GO CMDFTR for /filter/ "FTR" mentioned in ALR related commands], I was able eventually to get the necessary objects created and necessary alert action entries and filter selection entries added to cause each message that I enabled, to have some detail logged to a data queue when issued to QSYSOPR [and\or QHST IIRC]. There was more capability in the actions allowed beyond just depositing an entry on a *DTAQ, e.g. SNMP traps, but I already was familiar with a NEP to monitor the data queue... and that was sufficient for my needs.

After I had that working, I do not recall ever looking back, though recall encountering the documentation eventually, in its own manual. Note: For any case where the message would go only to QSYSMSG, if that *MSGQ exists, then using only the /alert/ implementation may not be an option for an overlap in messages. I do not recall, but I guess I probably deleted my QSYS/QSYSMSG message queue, because I do not recall keeping both methods active.? In the InfoCenter there is a section "IBM i PDF files and manuals" where a manual "Alerts Support" guide number SC41-5413 is listed:
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/books_web/sc415413.pdf

I must admit after some trudging through getting the alerts active, although with eventual success, I recall wishing there had been a much simpler request such as CHGMSGD CRITICAL(*YES) to make functional the former idea of using QSYSMSG to satisfy my requirements.

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.