Kevin ,

The SYSLOG / OPERLOG in many place treated as an aeroplane black boxes. It
records *everything *that is happening in the system. It server as tool for
technical and legal problems investigation and it is archived for years.

There are installations that forbid suppressing any message, including
messages that create and serve only automation processes (by automation
products).

Another issue is that, the MPF does not have a security mechanism.
Therefore, anyone that can write a MPF process can cause eliminating
messages from SYSLOG unintentionally or intentionally. Automation products,
that already suppress messages from everywhere, have the security mechanism
that can and should be use.


 Bottom line: Leave it as today. Those that need more sophisticated options
should use more sophisticated tools.

Have a nice day

Doron


On Wed, Oct 20, 2010 at 08:02, Barbara Nitz <nitz-...@gmx.net> wrote:

> Kevin,
>
> maybe som of the others have the same problem *I* have in understanding
> the term 'monitor message'. I just reread Planning:OPS and the message
> manual where the IEF's are in, and I am still unclear what 'monitor
> message'
> is/means.
>
> Take IEF403I and IEF404I (two of those that I need in hardcopy to *prove*
> that something happened at a certain time, in addition to the HASP messages
> and our home-grown uji001 and trt002 at step start/stop):
>
> Is all of IEF403I the monitor message that would not be issued if we hadn't
> set
> the consolxx definition to MONITOR(JOBNAMES-T)? Or is just the time part of
> ief403I (which would appear in joblog that doesn't have the hardcopy-log-
> timestamp) the 'monitor' thing? The 1.12 message book for ief403i is
> certainly
> VERY silent about this.
>
> Is a list of 'the monitor messages' published anywhere?
>
> We still have the MN dsname command in commndxx, which at IPL gets the
> expected error of 'monitor command not supported' or some such (I was not
> allowed to remove it for heaven knows what reasons). Despite that, D opdata
> still shows that DSNAME monitoring is on (because of the INIT statement in
> consolxx?)
>
> Why can I not specify the log option on the INIT statement? We don't issue
> any setcon command for it, and it defaults to LOG (which isn't explicitly
> stated
> in the books, either!) Presumably for monitor dsname on init, it will also
> default
> to log.
>
> In addition, the message books are fairly obtuse about what a monitor
> message is. Unless you already know, it is not clear what is a monitor
> message
> and what isn't.
>
> Looking at the hardcopy log, IEF403I shows that it is issued without any
> routing codes, but it does have the 'MESSAGE NOT SERVICED BY ANY WTO
> USER EXIT' and 'AUTOMATION REQUESTED' bits on in HCLREQFL (x'00000090').
> I have always been unclear if such a message would show up on the console
> or not and had to rely on actually *looking* at he console to determine
> that.
> This despite us having a default routcode of 11 specified in consolxx.
> Which
> does not show up in the hardcopied message.
>
> And some of the responses here seem to reflect the same lack of
> understanding I have, probably because of fairly insufficient docs. Maybe
> IBM
> will consider to educate us at the next SHARE?
>
> Richard,
> >But if I understand this correctly, these messages normally didn't
> >go to syslog. They only went to syslog if MPF deleted them from the
> >console.
> No. We don't have anything in MPF for ief403/404 (other than a no_entry
> statement explicitly saying SUP(NO)), and these messages certainly appear
> in
> hardcopy log *and* on the console.
>
> Brian,
> >Personally I have used seemingly trivial Syslog entries to debug and
> correct
> >issues that would have been difficult or next to impossible to do in a
> >timely manner without them.  I don't think making a no-log default is ever
> a
> >good idea.
> I concur. Thanks.
>
> Best regards, Barbara
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to