First off, thank you to W. Kevin Kelley for your response dated Thursday, June 12, 2014. I am guessing that based on your response,
It is up to automation to inspect the Message Flood Indicator(s) in the WQE. I am curious exactly what indicates a message is to be suppressed. There is the WQESUPB byte, the WMJMSUPB byte, the WMN1SUPB byte, the WMN2SUPB byte ? For non-specific messages in our MPFLIST, .NO_ENTRY AUTO(NO),RETAIN(NO),SUP(YES) The purpose of these questions is to build a case where we can make an informed inquiry to our Automation Vendor. Recap of original discussion: Environment: ZOS 2.1 with JES3; OPS/MVS automation Question: Is there a way to prevent messages being placed on the SSI after Message Flood Automation has determined the message is not to be queued to a console and or SYSLOG. As it stands right now, our automation product, OPS/MVS still sees the messages even though MFA has suppressed the display of messages to SYSLOG and consoles. We have interrogated the flag settings in IEAVMXIT to check if the messages have been processed by MFA and have turned on the request delete flags, but, to no avail. Response: Date: Thu, 12 Jun 2014 21:11:22 -0500 From: "W. Kevin Kelley" <wkkel...@optonline.net> Subject: Re: ZOS 2.1 Message Flood Automation If the Message Flood Automation policy for the message is NOLOG, NOAUTO and NODISPLAY, the message will cease to exist after it returns from the SSI. The combination of these three is functionally equivalent to setting the CTXTRDTM bit in an MPF exit. The point is that the message does not cease to exist until it gets back from the SSI; it is up to every subsystem that looks at WTOs (WQEs) on the SSI to determine that a message has been marked for deletion and ignore the message if it so chooses. Not all products receive their messages through the SSI. Some front-end the WTO SVC which occurs before Message Flood Automation has seen the message. Such products will be oblivious to any changes made to the message by Message Flood Automation. Some products receive their messages through the EMCS interfaces. These products will not see any messages that are deleted (NOLOG, NOAUTO, NODISPLAY) by Message Flood Automation; they will see any messages for which the Message Flood Automation policy specifies AUTO (even if the message is not to be logged and is not to be displayed on an operator console). W. Kevin Kelley -- IBM POK Lab -- z/OS Core Technical Development Sincerely Yours; Kenneth J. Kripke k.kri...@comcast.net ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
