see reply i-line,
Regards
Frank Kolmann
From: CRPence <CRPbottle@xxxxxxxxx>
Date: Sun, 18 Mar 2012 09:57:32 -0700
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
Thanks Chuck I was struggling with a way to monitor QSYSOPR without using
a break handleing program.
I will post back how I went when I get it going.
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
Frank Kolmann
midrange.com
