Protecting Language Environment User Condition Handlers
Related Topics
A Language Environment user condition handler (UCH) resembles a subroutine in several ways. A UCH can be registered like a static call and link-edited into the main code base, or registered like a dynamically called subroutine and link-edited as a separate load module. Since UCHs involve error handling, they are also similar to CICS handle facilities.
There is a major difference, though, in how UCHs and CICS handle facilities process error conditions. CICS handle facilities drive error routines in a single-stage, inline sequence. Control is passed to an error routine that is directly responsible for branching back to the main code base, if appropriate for a particular application. UCHs, on the other hand, use a two-stage processing sequence that is totally independent of the main code base. The Language Environment condition manager drives both UCH invocation and retry.
Because of the way UCHs break from the main code base, their monitoring requirements can be very different from those of mainline applications. To deal with these potential differences, Code Debug CICS treats the invoking of a UCH in the same way as it does a CICS link request. For this reason, you must make separate entries on the Storage Protection screen (1.8 or 9.8) in order to establish storage protection for UCH modules. Specifying exclusions for UCHs also requires individual entries on the Monitor-Exceptions-9-4-1 screen.
In the following example, a mainline program registers two handlers: one for screening conditions unique to its own processing tasks and one for screening all program checks in the entire application. The mainline program calls an Assembler subroutine that requires reentrancy monitoring, but the handler for screening program checks is an Assembler module that, for valid reasons, violates reentrancy rules. In this situation, the mainline program, its subroutines, and its general condition handler require different protection rules than the handler that screens program checks.
As displayed in the following figure, a single entry on the Storage-Protection-1-8 can be used to establish protection for the mainline and associated routines. A separate entry is created to protect the program check module.
Language Environment Storage Protection Entries
COMMAND ===> SCROLL ===> CSR
MODULE: LEPROGRM CSECT: LEPROGRM
ENTRY 000001
LINE COMMANDS: A (After) B (Before) C (Copy) D (Delete) I (Insert) M (Move)
-----------PROTECTION OPTIONS-------
CMD TYPE TERM TRAN PROGRAM STORE FETCH SHR PGM CMD Store
-----------------------------------------------------------------------------
_ USER T123 **** LEPROGRM YES NO NO YES NO
_ USER T123 **** PROGCHEK YES NO NO NO NO
_ ____ ____ ____ ________ ___ ___ ___ ___ ___
_ ____ ____ ____ ________ ___ ___ ___ ___ ___
_ ____ ____ ____ ________ ___ ___ ___ ___ __
If the handler for program checks has been tested and is allowed to run without any form of protection, the 1.8 entry for the mainline program can still be used. An entry on the Monitor Exceptions screen (9.4.1) could be used to specify that the program check module be excluded.
Handler Module Exclusion
COMMAND ===> SCROLL ==> CSR
MODULE: CSECT:
ENTRY 0000 of 000
LINE COMMANDS: L (List of Entry Points) D (Delete)
CMD TRAN PROGRAM CSECT EXCL. LEVEL/MESAGE
------------------------------------------------------------
_ **** LEPROGRM PROGCHEK
_ ____ ________ ________
_ ____ ________ ________
_ ____ ________ ________
If an error condition occurred, control would pass from the main code base to the program check module. The 9.4.1 entry for the program check module would cause Code Debug CICS to suspend its monitoring cycle during the time the module was in control. If this handler were to percolate the condition to another handler, Code Debug CICS would reestablish its monitoring cycle, because the storage protection entry encompasses the other handler.