Synonyms XCTL, TRANSFER
EXIT { Program | Subprogram | Routine | FOR | PROCESS | CICS Options }
CICS Options are: [TO program [COMMAREA (data)]| CLEAR]
The statement following EXIT must be an END, ELSE, or ENDIF; Statements directly following an EXIT cannot be executed.
Causes an immediate exit from the program, a routine, a PROCESS loop, or a FOR loop. In a CICS program it may transfer control to another task.
Causes the program/subprogram to be immediately terminated.
If a GET … UPDATE is pending, the final update is done
Final subtotals and grand totals are printed
Files are closed.
You may assign a value to Return-Code before the EXIT, to allow JCL to control the execution of following steps. For example
COBOL.RETURN-CODE =
16;
EXIT AAP21BE;
$PROGRAM means “The current program name”. For example, in an Easytrieve
conversion the EZT statement
STOP EXECUTE
was converted to the Jazz Statement
EXIT $Program;
If this was in program AAP21BE, then this would be equivalent to EXIT AAP21BE;
When the EXIT statement names the ROUTINE/FOR loop that contains it, the ROUTINE /FOR loop is terminated. Execution resumes at the statement following the PERFORM that invoked the routine.
EXIT FOR is used within a FOR loop. It causes the FOR loop to be immediately terminated, and execution to resume following the END FOR statement. If FOR loops are nested, then EXIT FOR statements can be used with the inner or outer loop, or both. This example shows EXIT for being used, and also
PROGRAM ATstFor
BATCH;
FOR JZ2.IX1 = 1 TO 5;
IF JZ2.IX1 = 3;
EXIT FOR;
JZ2.IX2 = 3;
#686 S EXIT must be followed by ELSE, ELSEIF, or END
END IF;
EXIT FOR;
END FOR;
#699 W EXIT statement is unnecessary, and should be removed
$Routine
means “the current routine name”, just as “$Program”
means “The current program name”. Easytrieve conversion will convert
STOP
(without EXECUTE) into
EXIT $ROUTINE;
If used invalidly
(not within a ROUTINE), EXIT $Routine; will be handled as EXIT $Program;
EXIT PROCESS is only valid in batch programs, and PROCESS cannot be nested. It causes the PROCESS loop to be immediately terminated and execution to resume at the statement following END PROCESS.
In a CICS program, if the EXIT statement does not use the TO or CLEAR option, then if a GET … UPDATE is pending, the final update is done
These options are only valid in CICS programs. If used, then the exit is immediate so if an update is pending it will be abandoned.
TO program causes transfer to be passed to the program named. MANASYS cannot check that this program exists.
COMMAREA(Data) passes data to the program named in TO. This option is not valid if TO is absent. See notes below about “Jazz-created programs and Commareas”
CLEAR behaves like the default handing when the Clear key is clicked: -
If the PROGRAM statement has an EXIT option, then control is immediately transferred to that program,
Else the CICS screen is cleared, “Enter transaction code” is displayed, and CICS awaits another transaction code.
You don’t have to think about this UNLESS you are mixing Jazz and Non-Jazz programs.
Each program has its own unique screen and commarea format, and errors will result if they are mixed up. For example with
PROGRAM
CICS3 CICS INSCREEN(CICS3S) TRANSID(TRN3) COMMAREA(CICS3C) EXIT(menu1);
you can expect errors if program CICS3 reads a screen that is not in the CICS3S format, or attempts to read data from a commarea that is not formatted like CICS3C.
Programs are normally started with neither a screen nor a commarea: the first thing that they do is to invoke themselves, sending themselves an empty screen map, and an empty commarea. Logic is
IF there is no commarea
Send input screen map and empty commarea to self
ELSE
Read input screen and Commarea
However if program CICS3 contains a statement like
EXIT
TO CICS4 COMMAREA(CICS4C);
then the logic above won’t work in CICS4. If logic in CICS4 sent screen CICS4S with empty commarea CICS4C then it would lose all the data passed to it from program CICS3. On the other hand, if it simply read the input screen it would abend because the screen format would be CICS3S, not CICS4S.
MANASYS wants to make it easy for you: it doesn’t want you to have to distinguish between programs like CICS4 that are invoked by EXIT and programs like CICS3 that are invoked by a menu. So the problem is managed like this: -
1. When Jazz generates a commarea (as in New/CICS Program) the commarea always contains a flag called “JZ-XCTL” with default value “N”.
2. EXIT statements set this to “Y” before they transfer control
3. In all Jazz programs the logic is like this: -
IF there is no commarea
Send input screen map and empty commarea to self
ELSE IF the flag is “Y”
Set it to “N” and send the input screen map and received commarea to self
ELSE
Read input screen and Commarea
You only have to think about this if you are mixing Jazz and Non-Jazz programs.
A. Invoking a Jazz program from a non-Jazz program. The Commarea must contain a field called JZ-XCTL (PIC X VALUE ‘N’). Set this to ‘Y’ in the Commarea passed to the Jazz program. Unless you do this, your Jazz program will fail when it is invoked by XCTL.
B.
Invoking a non-Jazz
program from a Jazz program. Your Jazz program will contain EXIT TO XXXX COMMAREA(XXXXC);
Jazz will NOT generate the logic
MOVE ‘Y’ TO JZ-XCTL OF XXXXC
unless it can find JZ-XCTL within the data definition XXXXC.
If XXXX is ALWAYS invoked by XCTL from other programs then there is no problem. It can be written with the correct code to start from XCTL, and while it will fail if it is invoked directly from CICS this never happens.
If XXXX might be invoked from the
system or from XCTL then it will need another way of distinguishing whether to
send itself the empty map with a passed commarea. You may need to code assignments to some
other flag variable just before the EXIT
statement.