Good comments from you all. Thanks! The specific problem we are attempting to solve is interactions between MONITOR message generation and MPF. With the changes we made during the Console Restructure, MONITOR messages can be produced without a console requesting them. You can request that the messages not be queued to a console for display purposes (but will be queued to EMCS consoles for automation purposes) and you can request that the messages not be logged. All of this was done to allow customers whose automation require the messages to receive the messages but not have the messages -- optionally -- go anywhere else. The problem is that if a customer requests that the messages not be logged but puts an entry for the message in MPF, MPF undoes the no logging. The simple solution is to remove the message entry from MPF, but perhaps the customer wanted to drive an MPF exit, and then would be unable to do so.
There is a more general question and that is how should we be handling messages that are being generated solely for automation and being solely consumed by automation? The MONITOR messages are but the tip of the iceberg in this regard. We have had requests for ways of specifying on commands that the command response message is to be returned to the console (typically an EMCS automation console) but is not to be logged. >From the comments I've seen so far, whatever we do must be optional. 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
