Why is it useful?
Abending the victim task of a storage violation is a defence against applications acting upon and/or committing corrupted data.
CICS Documentation (all releases) promises "If you specify STGRCVY(NO), CICS abends the task if it is still running."
Ref -> https://www.ibm.com/docs/en/cics-ts/6.1?topic=summary-stgrcvy
Also, "If storage recovery is not on, CICS abends the transaction whose storage has been violated (if it is still running)."
Ref -> https://www.ibm.com/docs/en/cics-ts/6.1?topic=violation-what-happens-when-cics-detects-storage
STGRCVY=NO is the default.
(NB. The caveat "if it is still running" is significant. CICS detects storage violations when task-lifetime storage is freed, and since this mostly happens at task end (after syncpoint), abending a task at that stage is not applicable.)
However, task-lifetime storage is also freed while a task is running, and can be divided into two categories:
1) Storage that is acquired and then freed as a result of explicit requests by application programs, e.g. EXEC CICS GETMAIN / FREEMAIN
2) Storage that is acquired by CICS when the application needs it, and freed by CICS when the application no longer needs it. An example is the working storage of an application program invoked via EXEC CICS LINK; the LINK results in CICS issuing a GETMAIN for the target program's working storage, and the subsequent EXEC CICS RETURN results in CICS issuing a FREEMAIN for the same storage.
Observing the results of multiple different storage violations (examples below), it would seem the STGRCVY=NO promise to abend a running task only applies to application issued FREEMAINs (category 1 above), and NOT to FREEMAINs issued by CICS (category 2). It's not clear if this is by design, or a defect.
Example scenario #1 (STGRCVY=NO working as documented):
PROGA links to PROGB (EXEC CICS LINK)
PROGB getmains some storage (EXEC CICS GETMAIN)
PROGB violates this storage (trailing check zone is overwritten)
PROGB freemains this strorage (EXEC CICS FREEMAIN)
CICS detects the storage violation (code x'0D11')
SM0102 system dump is requested; task is abended with code AEXZ
Example scenario #2 (STGRCVY=NO not working as documented):
PROGA links to PROGB (EXEC CICS LINK)
CICS getmains working storage for PROGB
PROGB violates its own working storage (trailing check zone is overwritten)
PROGB returns to PROGA (EXEC CICS RETURN)
CICS freemains PROGB working storage and detects the storage violation (code x'0D11')
SM0102 system dump is requested. No transaction abend, even though the task is still running.
PROGA continues to execute
Who would benefit?
All CICS customers who suffer storage violations.
How would it work?
No external changes.
Internal changes to ensure STGRCVY=NO always abends the victim task of a storage violation if it is still running.