EVENTHUB Macro, multiple timers and WTORs for MVS3.8J
The purpose of the EVENTHUB macro is to make it easy for anyone using S/370 assembler under MVS3.8J to write code to process operator commands from the comm area, have multiple WTORs in flight, and provide easy to use multiple timer queueing (as MVS3.8J doesn't have STIMERM to provide that).
And it must be easy to use, plus allow easily readable code in the callers program which is achieved by allowing each event to branch to its own 'handler' code when the event is triggered.
The initial version here is limited to eight(8) queued items, including the COMM area if used. That limit will be removed in a later version when I getmain table space, but currently while testing this I'm using an inline table with a max size of 254 bytes, so eight entries. The reserved textid field in the event table I intend to use to allow clearly identifiable user tags to add/delete events in a later revision, a placeholder for now but has dropped the test event table from 10 to 8 elements.
The test program shows how easy it is to use the macro. In 75 lines of user code (excluding comments) it...
- handles P(park) and F(modify) commands issued against the job from the console. In this test program modify input is WTO'ed to the console, and the park command will end the program
- has two outstanding WTORs, that can be replied to in any order, each will run it's own 'handler' code when the WTOR is replied to. In this test program when a WTOR is replied to it is re-issued, replying 'END' to the second WTOR will end the test program
- has two timers created (queued) to show multiple timer queuing. A five minute timer that re-queues itself forever and a seven minute timer that expires when triggered
Currently the best usage documentation is by looking at how it is used in the test program, so review the test program.
The EVENTHUB macro is available for your use at your own risk of course, this is an ongoing piece of work I am probably going to overcomplicate at some point.
Notes and cautions
This macro works by generating the code and data areas needed to perform the functions required, this can result in quite a large code footprint. Currently code is always generated to support WTORs and timers even if you are not using them (I may revisit that by added timer=yes|no,wtor=yes|no macro options, but again that is making the macro more complicated to use). The code to support the COMM area processing is only generated if you initialise the macro to use the COMM area, but the dsects needed are always created (may add comm=yes|no option on the dsects action but then for readability should add a pointless comm=yes|no on the create statement to match them, sigh).
There will be changes made to this macro over time. While I will try to keep the macro interfaces backwards compatible you should be prepared to modify any program source files you use this in. Also as the 'immediate' code changes planned over the next few months will be code consolidation to make the code footprint smaller you should re-assemble programs that use this as new versions are released anyway.