Message Flood Automation processing occurs before a message is placed onto the Subsystem Interface (SSI). Automation products such as NetView®, which can obtain messages from the subsystem interface, see messages after Message Flood Automation have seen (and potentially modified) them. All requests to delete, log or queue messages are processed after return from the subsystem interface. Therefore, NetView and other automation products that sit on the subsystem interface can see the message and potentially copy or modify the message (possibly overriding Message Flood Automation decisions) before z/OS® deletes, logs or queues the message.
The NetView 5.2 Message Revision Table (MRT) performs all of its message processing on the Subsystem Interface, after Message Flood Automation has processed the message. Message Revision Table logic can see and override message specification changes that Message Flood Automation requested. Changes to the message's specifications that the Message Revision Table requested can affect the logging, display, retention and automation of the message by z/OS.
NetView can obtain messages for automation through either the Subsystem Interface or an EMCS console interface or both. (If the NetView MSGIFAC parameter is set to SSIEXT, USESSI, QUESSI or QSSIAT, NetView will obtain messages for processing from the Subsystem Interface. If the MSGIFAC parameter is set to SSIEXT, only unsolicited messages are obtained from the SSI; command response messages are obtained through the EMCS console interfaces). When NetView obtains messages from the Subsystem Interface, it obtains a copy of the original message, before z/OS has an opportunity to delete, log or queue the message to a console. The original message is processed for deletion, logging and queuing after NetView has made its copy. Traditional (non-Message Revision Table) NetView automation can see but cannot alter changes to the message that Message Flood Automation made.