Message Flood Automation is part of z/OS® WTO processing. Message Flood Automation examines each message in the z/OS system, and attempts to identify when too many WTOs are being issued and by whom. It then takes appropriate actions: usually to suppress the message from display at a z/OS console, and to indicate that automation processing is not required. It can also issue commands, for example, to cancel the user or process.

Three separate classes of messages are handled. These classes are:

• SPECIFIC messages: a set of messages identified by the installation that are to be handled separately.
• ACTION messages: messages that have one or more of the following descriptor codes sets:

  1

  System failure messages (typically messages with a W message ID suffix)

  2

  Messages requiring immediate action (typically messages with an A or D message ID suffix)

  3

  Messages requiring eventual action (typically messages with an E message ID suffix)

  11

  Messages requiring critical eventual action (typically messages with an E message ID suffix)

• REGULAR messages: messages that do not fall into any of the above categories.

Each class of messages is handled separately. Each class has its own set of controls (MSGTHRESH, INTVLTIME, and so on). Each set of controls operate independently; for example, the system can be in intensive mode for regular messages but not for action messages. The effect is that z/OS still processes action messages in the normal way.

Message Flood Automation can take action against privileged messages that are queued to consoles even in storage shortage situations.

Message Flood Automation runs in two modes: normal and intensive.

• In normal mode, messages are counted. When a threshold number (MSGTHRESH) of messages have been counted, the time taken to count those messages is determined. If the time is less than a limit value (INTVLTIME), the system is placed into intensive mode. This determination is likely to be done infrequently, for example, every 50-100 messages or more. The INTVLTIME value should be set to identify high message rates, for example, a value of 5 seconds for INTVLTIME indicates an average rate of 20 messages per second if MSGTHRESH is set to 100.

  The processing overhead in normal mode is therefore very small. Only a small number of instructions are executed in Message Flood Automation for each message.

• In intensive mode, each message is subject to extra processing. Messages are counted for each address space (up to a maximum of 128) issuing messages and compared to a further limit value (JOBTHRESH). If any one address space issues JOBTHRESH messages within INTVLTIME, it is subject to action from that time on. This action can be installation-specified, but is typically defaulted to be no-display and no-automation.

  At the end of each interval of MSGTHRESH messages a check is made to see if intensive mode should be maintained, and whether address spaces in act-upon mode should remain so.

  Message bursts can end suddenly. The address space that issues them might suddenly exit a tight-loop condition and resume normal processing. In this circumstance, it is likely that subsequent messages are important and should be processed normally. To allow this to happen, there are two further controls: system inter-message time (SYSIMTIME) and job (or message) inter-message time (JOBIMTIME or MSGIMTIME).

  In intensive mode, if the time since the last message is greater than SYSIMTIME, then intensive mode is discontinued. This ensures that the first message after a break is not acted upon.

  Similarly, if an address space is in act-upon mode, and the time since its last message exceeds the JOBIMTIME, then it is removed from act-upon mode.

  For specific messages, if a message is in act-upon mode, and the time since the last message exceeds the MSGIMTIME, then the message is removed from act-upon mode.

The control algorithms for regular and action messages are identical as described previously. For specific messages, the control algorithm is similar although it is applied to individual messages and not to jobs or address spaces. The MSGLIMIT parameter performs the same function in specific message processing that the JOBTHRESH parameter performs in regular and action message processing. The MSGIMTIME parameter performs the same function in specific message processing that the JOBIMTIME parameter performs in regular and action message processing, although it is applied against specific messages rather than address spaces.