Provide a new option for how CICS should recover from a storage violation

Why is it useful?

If I enable all CICS storage protection options (RENTPGM=PROTECT STGPROT=YES TRANISO=YES), define all programs with EXECKEY=USER, and define all transactions with ISOLATE=YES, I can be reasonably confident that any victim task of a storage violation, will also be the culprit. That being the case, I would like 3 things to happen in the event CICS detects a storage violation:

1) The victim task is abended and rolled back if it's still running (otherwise I risk committing corrupted data)

2) The victim's task user storage is freed and available for reallocation (otherwise I risk eventually going SOS)

3) CICS continues to run (otherwise I risk a service outage)

However, all three things cannot be achieved with any of the 3 configuration options CICS currently provides for recovering from a storage violation:

a) STGRCVY=NO

This option abends the victim task if it's still running (although testing suggests this doesn't always happen), and allows CICS to continue running. However the victim's task user storage is "frozen", and is not available for reallocation. A recurring storage violation poses an SOS risk, exacerbated by the 1MB EUDSA page sizes with TRANISO=YES.

b) STGRCVY=YES

This option frees the victim task's user storage at task end, and allows CICS to keep running. However it does not abend the victim task if it's still running - instead it patches storage check zones and allows the task to make decisions based on, and potentially commit, the corrupted data.

c) DEFINE DUMPCODE(SM0102) TYPE(SYSTEM) SHUTOPTION(SHUTDOWN)

This option (in effect) abends and rolls back the victim task if it's still running, and resets all corrupted storage. However, even in a HA topology with cloned regions, restarting the victim region introduces the risk of a service outage - a persistent recurring storage violation could bring down every cloned region in a short period of time.

Who would benefit?

Every CICS customer who suffers storage violations.

How would it work?

A new configuration option could provide the new recovery behaviour described above, e.g. a third option on the STGRCVY SIT parameter. (Or perhaps STGRCVY could be renamed and repurposed.)