Subsystems in Message Processing

Following MPF processing, the message is broadcast to all active subsystems. The message is presented to each subsystem in turn. Each subsystem can inspect the message and perform appropriate subsystem processing. The subsystem can alter the message text or other characteristics (WQE fields). The WQE contains fields to carry special job-related information supplied by the job entry system when it processes each message. Typical MVS™ subsystems include JES2, JES3, the NetView® program, OPC/ESA, CICS®, and IMS.

If a primary job entry subsystem (JES2 or JES3) is active, that subsystem is always the first to process a message, regardless of the subsystem's position in the IEFSSNxx member of SYS1.PARMLIB, which is referred to as the subsystems names table (SSNT). Following that, messages go to each subsystem according to the order specified in the SSNT. IMS is an exception to this rule. If IMS runs as an MVS subsystem, it has special code to ensure that it is the last subsystem on the subsystem interface.

Note: For JES2, if secondary job entry subsystems exist, their definitions should precede the definition for the NetView program in the list of subsystems in IEFSSNxx.

If you are using the subsystem interface for messages and an active NetView subsystem address space is present, it receives the WQE on the subsystem interface. The NetView subsystem selects messages to be passed to the NetView application and copies pertinent data from the WQE into its message. The WQE is not modified by the NetView program and passes on to the next subsystem, if any. The NetView subsystem queues the new messages in its own address space before they are dequeued by the NetView application. Messages are passed to the NetView application only while it is running and while an active subsystem interface router task is in that application.

If extended multiple console support (EMCS) consoles are being used by NetView, MVS facilities use cross-memory transfers to send messages directly to NetView tasks, which are defined as EMCS consoles.

The NetView subsystem checks to determine whether the message was marked for automation processing during MPF processing. If it was, the message text and selected attributes from the WQE are copied and queued into the NetView subsystem address space.

To direct a message for NetView automation, set the AUTO keyword for the message to AUTO(YES) or AUTO(token) in the message processing facility (MPF) table. To also suppress the message so it is not displayed at MVS operator consoles (including those owned by NetView operators), set the SUP keyword in the MPF table to SUP(ALL) for any message, or SUP(YES) for messages that are not command responses. However, if you do not direct a message for NetView automation and you also suppress the message, the message is stopped at the MPF table and is effectively lost. Therefore, do not opt to prevent both automation (using AUTO(NO)) and display (using SUP(YES) or SUP(ALL)) for the same message, unless you want to completely stop the message from passing through MPF. For a z/OS® command that is issued in a NetView pipeline, the response is returned to the pipe, even if it is suppressed by MPF or z/OS flood prevention tools. To suppress piped command responses, you can use only the NetView MRT.

EMCS consoles that are acquired by NetView cannot solicit messages by route code if the messages are marked with SUP(YES) or SUP(ALL) in the MPF table.

Messages marked AUTO(YES) or AUTO(token) in the MPF table, or which are subject to NETVONLY or REVISE("1" AUTOMATE) revision table actions or similar, can be received on an EMCS console. By default, these messages are received by the CNMCSSIR task.

Note: JES2, JES3 and NetView allow you to have two or more copies of their subsystems active. Each copy requires a unique name in the SSNT, and each is called under its own subsystem name for a message. Under those circumstances, each NetView subsystem can select the message and queue it for processing by separate NetView applications.