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.