My MPF Solution

Important information

This will not work with packaged MVS3.8J systems such as the TK4- one as they are shipped out-of-the-box without 3270 consoles. This tool uses console buffer screen scraping and that means it needs a screen buffer to scrape.
If you have been using something like TK4- you will have noticed that while utilies SPY and IMON are installed they display abosultely nothing on their console screen, to get those to work you must have at least one 3270 master console. But if you have reconfigured the config file and do have a 3270 console and SPY and the IMON console option "O" shows you whats on the console then this application will work for you.

Actually you probably don't want it until I have reviewed the requirements... I have made it overly complicated.
The current version I have hooks into my tape management application (which the current user manual does not cover and you may not want) so I need to update the doc...
ahh, it's coming back to me, I think the extra DD is only if a link command for an automation action to my tape management modules is done so the doc may be still valid; if linked to modules need files they can be added to the MMPF proc.

Application/Product overview

We all know MPF just didn't exist way back in the MVS 3.8J days, took me ages to figure out you needed to recode IEECVXIT. 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 :-).

My intention in writing this was to provide me with a way of automating console messages without having to keep re-assembling IEECVXIT and CLPAing in the new code to test. It should also be easy to use. MMPF is my solution to all my issues. For starters loading a new set of rules is as simple as issuing a "F MMPF,MMPF=nn" to load (or reload) a new parmlib rule member named MMPFnn; the days of having to CLPA are gone, rules can be changed/tested on the fly.

It can respond to action and attention messages by issuing a MVS or JES2 console command, DOM'ing the message or calling additional programs you may wish to code. Using the MMPFEX extension it can also run groups of commands for a message, not just MVS console commands but also Hercules commands (such as devinit) if needed to respond to a message.

To make it easy to use the MMPF 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, rearrange then in the command response etc. it is all done for you.

And another large advantage over using IEECVXIT is that MMPF can access disk files.
In my case it meant that a lot of automation that had to be done by issuing "S xxx,parm=yyy" from IEECVXIT due to the need for those operations to use disk files I could simply move to MMPF (and remove lots of getmain/freemain/message-parsing code from IEECVXIT in the process as MMPF does all the message parsing).
Specifically in my case all the "S xxx" commands I needed for tape automation disappeared simply by adding a DD card for my VSAM tape catalogue to the MMPF procedure and using MMPF rules to link to my tape-automation routines directly.

As an example of how much easier it is to write rules using MMPF instead of having to re-assemble IEECVXIT this is my current 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.

As well as MVS console commands MMPF (using the MMPFEX extension) can also issue Hercules commands using the DIAG8 interface. To do that it uses my MDDIAG8 program that you will need to also download the source from this site.
Alternately you can obtain the binary only HERCCMD program written by Grzes Plucinski and change all referenced to MDDIAG8 to HERCCMD. Refer to the herccmd document on how to obtain that.

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

Not really an issue, but on a TK3 system sometimes an SMF dataset dump request is issued during system startup before BSPPILOT is started so IEECVXIT does not process it, and also before the JES2 startup issues the command to change the console display format (to put the JOB nnn/STC nnn on the console before the actual message). That is the only message I have seen that occurs before the system is fully up (so far).
Currently MMPF expects the mesages to be offset due to the display change commands issued during startup so it cannot handle that message if it occurs during startup either.
I will not put any handling in for this as it is not an issue with TK4- which I am using now.

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 actually changes it for all console messages on console 'n') changes the offset of messages on the screen 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 :-).

And a curious one, that is obviously MVS releated rather than an MMPF issue, is that I have observered (admitedly on only one occasion) that editing/saving a member in the PDS that MMPF reads the control member from causes automation to stop, MMPF appears to read the control cards correctly but it does not action any rules. After eliminating my code as being the issue I found the fix to be simply compressing the PDS and requesting MMPF to re-read the member with "F MMPF,MMPF=00"; a stop/start of MMPF may have worked as well but I don't intend to spend decades trying to recreate the problem... just compress the parmlib you use after any updates as I normally do but did not do on this occasion.

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

• non action/attention messages may have scrolled off the screen between poll intervals and be missed
• and if they didn't scroll off the screen then the automation would be triggered again and again until they did, wheras when an attention message is actioned it drops back to a normal RD message, so once handled it won't retrigger automation rules where a normal message that stayed in the screen buffer would

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.

Change History

• V1 2007/10/20 Initial version working with CMD function.
• V1 2007/10/25 Got the program PARM='MMPF=nn' working to override the member name on startup, plus got the F MMPF=nn working
• V1 2007/10/27 Added in test DOM and CMK types to allow changing a message to non-highlighted and change to non-high plus execute command respectively Any rule involving a DOM will only be attempted if we have not yet issues any commands, this is because if we issue a command we know the console will have rolled and we no longer have the correct line number to be dom'ed. At this point we just pray no other external command has rolled the screen for CMK type (while no issue for DOM type, for CMK type we rely on the message being dom'ed before we trigger the command to avoid looping, may have to look at having a table of messages undergoing CMK processing to redrive doms, but that will have it's own issues if there are more than one message of the same on the screen)
• V1 2007/10/27 Added assembly toggles for TK3
• V2 2008/12/17 Finally got around to iplementing the LNK option
• V2 2009/03/24 Changed LNK so it DOM's the message that triggered the event. Avoids automation loops if the LNKed to program fails (repeatedly) to handle the event
• V2 2009/04/25 Added the MMPFEX utility to be linked to from MMPF to provide the ability to issue multiple commands from within MMPF based on a key built from the message (so device interrupt on 00C can issue different commands to a device interrupt on 00D, but without the need for messiy if/else logic)
• V2 2009/07/17 Allowed for a PARM of DEBUG to also be passed, in which case we log the messages we are checking and any rule matched we found but do not actually perform any actions. And added the optional LIVE parm also so the proc can use something other than debug and still work; the LIVE parm does nothing but is legal...and permitted the proc to be updated for the debug option
• V2 2009/10/13 Something unique about Turnkey3 ?. Would not assemble into a 4K code block in TK3 (addressability errors) even though it worked fine with lots of symbol space free on my system. So added a lot of LTORGs, and truncated a few error message strings, to get a few bytes back. Assembled on TK3 again now.
  Also on TK3 BSPPILOT uses @ instead of * in it's attention messages, so coded to allow for that (actually since then I have discovered thats normal, the manual says for WTO * is used for authorised programs and @ for non-authorised programs).
• V2 2010/12/18 Added a WTO option line to the MMPFEX extension so that hints and help can be WTOed to the console for outstanding events; specifically to remind me that the outstanding error on unit 009 is that I have forgotten to start the telnet session :-), but will be usefull for other things as well.
• V2 2012/07/11 Just changed the packaging so it assembles modules to an install dataset instead of directly into system datasets; added the $INSTALL member in the SRC library to do the actual copy to system datasets when the user is comfortable to run it. Also created and populated the DOC dataset as provideing documentation is probably a good idea.
• V2 2013/01/20 Fixed all remaining bugs in the message parsing module and added an extra field to the dsect used to map memory for the same. Fields in the dsect have been rearranged so all programs must be reassembled if you are already using a copy of this toolkit.
• V2 2014/11/24 Got bored, added the "F MMPF,STATS" option to pass some time.
• V2 2017/03/28 Quite a few updates since I last updated this page. Extra key-action-words added to message rules, dd name changes that affect your jcl etc, and finally had to use three base registers for MMPF itself, it's getting big. Refer to the $changes member.

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.