Protecting the System from Exit Errors

To protect the system from exit errors, you should:
For exits that reside in SYS1.LPALIB you can at least partially resolve these problems by:

You can then limit the front-end test exit in scope (testing for specific job names, for example). Afterwards, when it completes its task, the test exit gives control to the original exit code outside the LPA.

The test exit, after being coded and tested, is unlikely to need frequent changes. The original exit is now in another library, where it can be changed without the assistance of an IPL. This eliminates the need for reentrant code in the original exit during testing, because it is loaded for each invocation. Run additional tests later with the original exit in the LPA to ensure that exits are truly reentrant.

A safety feature of this testing method is that, should something be wrong with the test exit, you can eliminate it by an IPL without the MLPA parameter. You should run an exit from outside the LPA only in a testing environment because of the overhead involved in loading the exit each time it is entered.

After the exit is in production mode, you can prevent unexpected problems by having the exit check the contents of the CVTUSER field (at offset 204 in the CVT). If the contents are zero (the usual case if CVTUSER is not being used by your installation), the exit should proceed. If not, it should return to the caller without taking further action (except to set register 15 to zero). When the exit is being used and an unexpected error is encountered, the contents of CVTUSER should be set to a nonzero value with console alter or display functions. This temporarily disables the exit code (a re-IPL causes CVTUSER to become zero again, reactivating the exit).