My MPF Solution

Important information

This will not work with some default configurations of packaged MVS3.8J systems such as the TK4- one as they are shipped out-of-the-box without working 3270 consoles in the hercules configs (ie: using SPY or IMON option O gives a blank screen). This tool uses console buffer screen scraping and that means it needs a screen buffer to scrape.
You will need to reconfigure your hercules config file to use at least one 3270 console. Which you should do anyway if you want to use SPY or IMON consoles :-).
I have set the below for a tk4-rob genned system... 

# 009 is used by hercules program command line console interface
# 010 and 011 are the master/backup 3270 consoles
# 01F is a telnet hardcopy interface 
# note 30E is a also defined in MVS sysgen for TK4Rob as
#   a console printer but leaving it out of hercules.cnf
#   causes no issues... but some distros use that as the 
#   hercules console interface instead of 009
0009 3215-C
0010 3270 CONS
0011 3270 CONS
001F 3215

The above requires that when you start hercules before IPLing you need two 3270 sessions and a telnet connection established to the console port (normally 3270; set with the CNSLPORT variable in your hercules config file).
The result is almost the same as TK3 as far as consoles are concerned, you just get an extra one writing to and accepting input from the hercules command line also.

What the MMPF utility is designed to help with

We all know MPF just didn't exist way back in the MVS 3.8J days, took me ages to remember you needed to update and re-assemble IEECVXIT for each message you wanted to automate and IPL with CLPA to get the change in. While that was fun for a while I wanted something simple, and something that didn't fill my dump datasets when I made an error in IEECVXIT :-).
That way also had the annoying issue that if messages were written during IPL time before the STC IEECVXIT was to schedule SRBs under was started (for TK3 and TK4- that is BSPPILOT) those early messages could not be handled.

My intention in writing this was to provide me with a way of automating console messages without having to do anything except edit a parmlib member. MMPF is my current solution. Loading a new set of rules is as simple as issuing a "F MMPF,MMPF=nn" to reload rules from a parmlib member named MMPFnn; the days of having to CLPA are gone, rules can be changed/tested on the fly. And you can have mutiple MMPFnn members so can change rules as needed (ie: you may want to cancel jobs waiting for offline devices during the day but not during a batch window).

Basic function overview

First the limitations. First it will only automate action/attention messages, that is because they would not scroll off the screen buffer unless manually deleted or actioned so can be safely automated; trying to automate messages that would scroll off is not possible this way. A second limitation is it may not appear too timely, in worst case if three attention messages are outstanding it will take three (20sec I think) polls to clear them all; that is deliberate as if automation takes any action that will cause messages to scroll it skips all further processing in that poll, needed as rules that require messages to be DOMed for example could not be actioned as its representation of where the line was has changed; but it will get through them eventually.

Its primary function is to automate action and attention messages that are on the console using rules in parmlib members MMPFnn and MMPFEXnn. It has a secondary function of making sure started tasks defined in a parmlib member that are expected to be running actually are and will start them if they are not.

The basic rules can reply to WTORs, DOM messages, issue commands and even link (execute) directly to other program modules (the linking to other programs is primarily for my tape automation which is another large topic entirely).

A more common use of linking to other programs wold be to link to the MMPFEX extension program that can have fine tuned commands (ie: diffent handling for device 00D offline to device 00E online) and run a group of commands for a rule rather than a single one in the normal rule file.

To make it easy to use the MMPF normal MMPFnn member rules allow the use of helpfull keywords, specifically &WORD1 though &WORD20, in the automation rules (being the word values in the message being automated of course); yes message parsing is built in. So if you need to extract key fields and rearrange them in the command response etc. it is easy to do. &WORD1 being very useful as for WTORs that is the message reply number :-).

As an example of how much easier it is to write rules using MMPF instead of having to re-assemble IEECVXIT this is an example mmpf00 member which show how simple it is to use.

Credits

Greg Price has the 'SPY' utility available on his Prycroft site for MVS3.8J users which is a very usefull TSO interface to view what is currently displayed on the system consoles (and does a lot of other bells and whistles stuff). Rather than re-invent the wheel I have copied the screen scraping and delete operater message stuff (and just left out all user input and tso output handling bits), and imbedded it in a program that can run as a started task.

Outstanding issues, well not issues, things to be aware of

Not really an issue, but sometimes an SMF dataset dump request (handling coded in IEECVXIT in TK3 and TK4-) is issued during system startup before BSPPILOT is started so IEECVXIT cannot schedule a SRB under BSPPILOT so does not process it, and that is also before the JES2 startup issues the commands to change the console display format (to put the JOB nnn/STC nnn on the console before the actual message) so it is formatted on the console in a way not expected by MMPF.
I got sick of manually issuing the command for smfdaily when that happens and have hard coded handling for that exact message only if it is at the unusual offset on the console. The message number does not show up in the MMPFnn parmlib member as in this case it is in a position on the screen MMPF would not be able to find it plus as IEECVXIT would normally handle it that message would normally never be outstanding on the console for MMPF to see. So just for documantation/transparency there is one message automated not visible in the rules member.

That is the only message I have seen that occurs before the system is fully up (so far).

One thing that would be an issue is if you change the console display format. If like me you often have jobs with duplicate names and need to determine the job number of the job, be aware that using '$TOSCn,D=J' or '$TSOCn,D=T' to display job numbers in JES2 $D commands it changes the offset of messages on the screen of console 'n' and of course will confuse the screen scrape of MMPF , so either always remember to use '$TOSCn,D=M' to revert back to normal message display on the console, or as I do always turn job numbers on only on a second console (the one MMPF is not using). (for TK3 users MMPF is setup by default to handle the display settings set by the MN JOBNAMES,T and MN SESS,T set in the JES2 startup of the default TK3 install now, so you don't need to worry about that unless you are changing them yourselves).
Thats not a bug in MMPF, if you change the display format and all the message offsets hows it supposed to know :-).

Limitations

As it is a console screen scraper it cannot change message description codes or suppress messages, you still need IEECVXIT to do that. And it does not run in real time but 'polls' the console buffer every 15 seconds.

Also a concious design decision was made to only allow automation of action/atention messages (wtors, nrds, device mounts, hardware interrupts etc) [basically anything with the leading * or @ in your console display] for the following good reasons

And worse at this point in time I haven't coded in any recovery processing for when the console it is reading the message buffer from goes belly up. Should be easy enough but I haven't needed it yet so it's not there yet.

Read this far, you probably want it then

The JCL deck to create the install libraries is available here as a text file MMPF.txt (unix text file format, use unix2dos to convert to a windows text file if using on a windows machine... of course you will need a *nix machine to do that on), version numbers and refresh dates may change so check back occasionally.
Read the comments at the start of the file for volser and dataset prefix changes you will need to make before running it. It will create a SRC, DOC and LOADLIB file and assemble the programs into the LOADLIB file. It will not update any of your system files, there is a seperate $INSTALL member you must manually customise and run to actually migrate the application into your system libraries, which you should review in conjunction with the files inthe DOC dataset.

A draft MMPF User Manual(odt) is also available. It is now really out of date, on my todo list to update this one day.

Known remaining bugs

Refer to the $BUGS member that will be in the .SRC dataset. That is up to date and contains all known issues, and all are minor.