Well I needed to make a modification to my MMPF utilty over the last few days, finished it off yesterday and finished testing it today. Works a treat.
For first time readers, while I enjoy using MVS3.8J under hercules at home I got sick of having to keep changing IEECVXIT and CLPA’ing the new exit in every time I wanted to automate *or even test) a new message automation rule. I wrote MMPF to do my message automation instead, it runs as an STC and loads it’s message rules from a parmlib member (and accepts F MMPF,MMPF=nn to change rules on the fly which is much easier for testing a new rule than having to IPL with a CLPA). It also lets commands be build using usefull keywords like &WORD1-&WORDnn which in one swoop got rid of all the fancy parsing I used to have to do in IEECVXIT to stip out fields for an automation command.
You need to remember here that MMPF was designed to replace the mucking about in IEECVXIT and pretty much does the same thing; get a message id and trigger an event on that message id (although because it can use &WORDn when building the command to issue it was still a huge improvement over having to parse out message fields in assembler in IEECVXIT).
The issue I hit was I didn’t want to respond in a generic way to a message number. More specifically on my windows hercules instance that has the card reader 00C using files it always gets an INT REQ event when I IPL the system, but the handling of that event is specific to device 00C; if I got exactly the same message on device 00D (a print device) then obviously the recovery would be completely different (ie: card device just submit a dummy jcl deck to it, a printer device wouldn’t like having a card deck stuffed into it).
It seemed like I needed to start implementing if/then/else logic into MMPF, which quite honestly it is not designed for. So I thought about the strenghts MMPF already had, such as the inbuilt word parsing and the ability to link directly to other program modules (the later because I wanted by tape mount automation to be totally under MMPF control rather than MMPF issuing S xxxx commands to start jobs to handle tape mounts; but being the forethinking chap I am I made the entire program linking interface totally generic allowing any module to be called, never thinking I would need it but simply because I always code that way).
Cool, I can use both those strengths.
So I wrote a new very simple module that can be linked to by MMPF, names MMPFEX (MMPF extension of course). Was I going to muck about with if/then/else statements, no way, it wasn’t needed with MMPF message parsing already in place.
The MMPF proc itself remember, has a SYSIN DD card to the PDS file containing the MMPF rules. Now MMPFEX will need rule members of its own but the beauty of my MMPFEX solution is that no changed need to be made to the MMPF proc at all. MMPFEX also wants to use SYSIN to get it’s rule members, and as its invoked from MMPF that already has the DD allocated it just works, no JCL changes needed to the MMPF proc at all.
But what about the if/then/else issue you ask, I seem to have been skirting that. Well I havn’t, it was all explained above.
Basically for an device interupt IEE001A UUU,INT REQ,….. (UUU being the device unit number), then the MMPF rule
IEE001A LNK MMPFEX 00 &WORD1&WORD2&WORD3
will link to the MMPFEX module and go searching for a MMPFEX rule matching UUUINTREQ, so a single MMPF rule can generate unique rule keys to be used by MMPFEX without any mucking about with if/then/else logic at all. Such a simple solution and fully within the scope of the existing MMPF utiity which needs no code changes at all (ie: rule 00CINTREQ and 00DINTREQ can issue different (multiple) commands).
A special note on the 00 before the parameter building part of the MMPF rule begins. That indicates the PDS member to be used for MMPFEX rules, the 00 means use MMPFEX00. I thought about providing a &MMPF substitution field (and may implement that in future) but decided to make the rule hard-code select it for now. Two reasons, one being that implementing an &MMPF flag will require changes to the dsect layout used by the existing MMPF modules (which will then make them MMPF specific and I will probably use the parsing routines in other utilities so I don’t want to make the dsects specific to one utility); the second being that the MMPFEX rules files could grow to be extremely large in size so being able to select a member suffix may be usefull in the future. As to why I may implement an &MMPF value in the future its simply because people don’t have to use it, they can still keep coding 00 or XX in their MMPF rules.
Anyway, did I mention that the MMPFEX ruleset member could get quite large :-).
It really does extend MMPF a long way, for every rule key there can be muliple commands (comprising both MVS console and HERCULES console commands). The five commands per rule is an arbitrary limit I have put in the code (as so far I only need two).
So with the one extra module you can now issue multiple commands for an event and using the existing MMPF functions unique keys can be generated for rule matches in any MMPFEXxx member without any if/then/else complexity.
Another fine weekends work on an obsolete operating system, specifically for my needs.
But as always the solution is so generic that the if/then/else problem is solved for every eventuality I can think of, without even needing any complicated logic.
Anyway, if interested in the new enhancement to MMPF the hercules download section for MMPF has an updated (still draft) manual including it and the new installation JCL deck that includes MMPFEX is available there also.
