Defining an exit

Defining an exit means telling the system the set of information that comprises the exit. You define the exit through the CSVDYNEX DEFINE request. A scenario of an exit provider defining an exit named EX1 would look like this:

exit provider setup
    _______

    CSVDYNEX REQUEST=DEFINE,EXITNAME==CL16'EX1'...
    _____
exit provider processing
    _____
    _____
    the call ------------------------  routine or routines
                                       associated with the
                                       exit named EX1

Questions you need to ask when you define the exit are:

What is the name of the exit?
The 16-character name must be unique within the system. Each CSVDYNEX request requires that you specify the name of the exit.
What should the addressing mode of the exit routines be?
If you are providing data above 16 megabytes, you might require that exit routines be AMODE 31.
Should the exit routines be reentrant?
If an exit routine can get control from more than one task or SRB before returning to the caller, require that exit routines be reentrant.
How long is the exit to remain in effect?
The exit provider is likely one task of many tasks that constitute the application or subsystem. The exit provider must decide whether the exit is to remain for the life of the exit provider's task, for the life of the exit provider's address space, or if it is to persist throughout the IPL. The PERSIST parameter choices are TASK, ADDRESSSPACE, or IPL, as follows:
- If the exit provider's task ends and PERSIST=TASK, then the system deletes the exit.
- If the address space containing that task ends and PERSIST=ADDRESSSPACE (or PERSIST=TASK), then the system deletes the exit.
- If the address space containing that task ends and PERSIST=IPL, then the exit remains (in which case frequently the application would be restarted).
How many times should the system continue to call an exit routine that consistently ends abnormally?
On the ABENDNUM parameter, you tell the system how many times an exit routine can abnormally end (and not retry from its recovery routine) before the system changes the state of the exit routine to inactive (that is, before the system stops calling it). On the ABENDCONSEC parameter, you describe how the system is to do the counting: does it count consecutive abnormal endings, or does it count by simply tallying the number of abnormal endings, ignoring the times the exit routine runs successfully? For example, suppose ABENDNUM has the value 2; if you then code:
- ABENDCONSEC=YES, the system stops calling the exit routine after a total of 2 consecutive abnormal endings; in other words, the system resets the count to zero if the exit routine runs successfully.
- ABENDCONSEC=NO, the system stops calling the exit routine after a total of 2 abnormal endings have occurred. An abend is counted when both of the following conditions exist:
  - The exit routine does not provide recovery, or the exit routine does provide recovery but percolates the error
  - The system allows a retry; that is, the recovery routine is entered with bit SDWACLUP off.
How should the system process the return codes from the multiple exit routines associated with the exit?
Each exit routine that runs at an exit has return information, including return and reason codes. On the DEFINE and CALL requests, you tell the system which routine's return information is to be placed into an area called the return area. This topic, which requires your understanding of parameters on the DEFINE and CALL requests, is described in Returning information from multiple exit routines.
Is the exit to be enabled for FASTPATH processing?
The topic of FASTPATH Processing is covered in FASTPATH processing.