MPF has the following behavior:

If SUP(YES) or SUP(ALL) is coded on an MPFLSTxx message definition or on 
a .NO_ENTRY statement, any matching message will always be written to 
hardcopy (unless overridden by an MPF exit) even if the message -- when 
issued -- specified no hardcopy (i.e. MPF always forces a matching message 
that is to be suppressed from display to be hardcopied).

MPF was created to reduce console message rates for the 3084 machine (our 
first 4-way MP -- all of about 27 MIPs). Back then, every message was 
considered sacrosanct, so a design decision was made to guarantee that a 
message could always be found in the SYSLOG even if it was suppressed from 
display.

That design decision no longer makes sense. Messages are no longer 
sacrosanct; we've allowed you to delete them completely for quite awhile 
(even if we didn't make it easy for you to do so). As part of the Console 
Restructure, we enhanced the handling of MONITOR messages so that 
automation programs could receive the messages without the messages 
having to be written to the SYSLOG or OPERLOG. Unfortunately, it appears 
that if you create an entry in MPFLSTxx for a MONITOR message (say 
IEF403I) and MONITOR processing has requested that the message be issued 
no hardcopy, MPF will override the no hardcopy and force the message to be 
hardcopied. 

To make a long story short: we are proposing to change MPF processing so 
that it no longer forces matching messages to hardcopy. If a message is 
issued requesting that the message be hardcopied (the default), MPF will 
honor it; if the message is issued requesting that the message not be 
hardcopied, MPF will no longer override the request (forcing the message to be 
hardcopied).

If we decide to make this change, it will be done on a release boundary with 
appropriate Interface Change Notifications (ICNs) to the venders in advance 
of the release being available.

Make sense? I'd like to hear your comments...

W. Kevin Kelley  -- IBM Pok Lab -- z/OS Core Technical Development

----------------------------------------------------------------------
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