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
midrange.com
