The interpreter converts C/I text to SWA control blocks used by the initiator to run the job. The interpreter can be called as part of the conversion phase of a job or at the start of a job's execution. When the interpreter is run is based on the INTERPRET keyword on JOBDEF. If INTERPRET=JES, the interpreter is called during the conversion phase.

When the interpreter is called during the conversion phase, processing for both the converter and the interpreter is normally run under a subtask in the JES2CI address space. The actual address space name is jesxCInn, where jesx is the subsystem name and nn is a number 1-25. Exits in this environment are called at the same point in processing as they are when running in the JES2 address space. However, because the code is running in a separate address space, the exits cannot access JES2 private storage data areas such as the HCT and the PCE.

Other control block structures are the same regardless of the environment; there is a converter DTE in both environments. The local work are the $CIWORK and $CIWORKB (31 and 24 bit data areas); both are in private storage in the address space. Communications between the PCE and the subtask is done by the $CIPARM data area, which is located in the “PSO” data space with an address and ALET in the $DTE work area.

When considering exit usage, you must consider the environment that the exit will run in. Exit 7 (CBIO for the $JCT) executes in the maintask environment, Exit 8 (CBIO for the IOT) runs in the user environment, and Exit 6 and the SMF IEFUJV exit execute in the subtask environment when the converter is being called in the JES2 address space. If the converter is being called from the JES2CI environment, then Exit 7 and 8 are running in the same environment, Exit 60 is called in the user environment instead of Exit 6, and the SMF IEFUJV exit is running in the user environment. All user environment exits called from the JES2CI address space cannot access JES2 private storage. If maintask functions are required for a subtask exit, two exits might be required to provide a specific function: for example, Exit 6 or 60 in conjunction with Exit 44.

Another important consideration is that there can be, and typically are, more than one converter processor (and subtask); therefore, any exits taken in the subtask or user environment (Exits 6, 59, 60, and SMF exit IEFUJV) must be MVS reentrant. The following scenario describes the processing that occurs during the conversion processing.

Table 1. Conversion phase processing

Step	Processing	Exit Used
1	A job is selected from the input queue, and the job's $JCT is read from spool. Exit 7 is invoked with a value of zero in general register zero (R0=0). The Converter Interpreter Parameter area ($CIPARM) is initialized and the Converter subtask is POSTed (either in the JES2 or JES2CI address space).	7
2	The JES2 conversion subtask locates the job's $PDDBs (JES2 Peripheral Data Definition Blocks) and Fake Opens the ACBs (Access Control Blocks) for internal text, job log, system messages, JCL, and JCL images data sets. The Converter subtask LOADs the MVS™ Converter, if the Converter has not already been loaded. Exit 8 is taken for reading the $IOTs from spool.	8
3	The Security Access Service ($SEAS) macro calls the Security Authorization Facility (SAF) to build the security environment in case the jobstream contains MVS commands which if present, would be issued by the Converter using the Command SVC. The userid associated with the command would be the user's, not JES2. As a result of the $SEAS call, Exits 36 and 37 are called.	36 37
4	For each JCL image, SMF exit IEFUJV (entry codes 0, 4, 8, and 64) is taken. This includes continuation statements. IEFUJV is called once more with an entry code of 16.	SMF exit IEFUJV
5	After the statement and all continuation statements have been converted into C/I text, the Converter exit, XTXTEXIT is called to provide spool data set names for SYSIN and SYSOUT JCL statements. If the statement represents a SYSIN data set, a $SEAS call is made to audit the creation.	XTXTEXIT
6	At the completion of conversion and after the Converter returns to the JES2 converter processor module Exit 6 (when running in the JES2 address space) or Exit 60 (when running in the JES2CI address space) is taken with R0 set to 4 to allow final conversion processing.	6/60
7	At the completion of conversion and after the Converter returns to the JES2 converter processor module, a $SEAS call is issued to delete the security environment. Exit 6 (R0=4) is taken again to allow final processing.	6
8	If the interpreter should be called because INTERPRET=JES is set (bit CIPOINTR in CIPARM flag CIPOFLAG is on) and the job is not to be reconverted, then the JCL, JCL images, and internal test ACBs are fake closed. The internal text ACB is fake opened for input and SWA blocks ACB fake opened for output. The environment is set up and the MVS interpreter is called. After calling the interpreter, any JESDS and MERGE=YES OUTPUT statements are processed. Then Exit 59 is called with the SWA blocks still in memory. After exit 59, the SWA blocks are written to spool, and the SWA data areas deleted.	59
9	A $SEAS call is issued to delete the security environment and exits 36 and 37 are called as a result.	36 37
10	Exit 8 is taken to write the $IOTs. The JES2 converter processor module subtask POSTs its maintask and WAITs for the next job.	8
11	Exit 44 is taken to allow user modifications that require the maintask environment. Using the $DOGJQE macro you can access and optionally update fields in the JQE.	44
12	The JES2 converter module checkpoints the $JCT and invokes Exit 7.	7
13	The $JQE is queued to the execution queue and Exit 51 is invoked.	51

The conversion phase offers the only chance to have exit control over all of a job's JCL. Although SMF exit, IEFUJV is taken for each JCL and JCL continuation statement, JES2 Exit 6 and Exit 60 offers some advantages.

First, the format of the C/I text is more structured. It is in parsed form and all major syntax errors have been removed. This has all been done by the converter before the exit gets control.

Another advantage of Exit 6 and Exit 60 over IEFUJV is that when JCL statements have been converted into C/I text, there are no continuation statements. That is, the entire JCL statement, along with all continuation statements, are represented by a single C/I text statement.

A SAF security environment exists within the subtask and can be used with the RACF® FACILITY class to control the specification of options within JCL. Exit 6 and Exit 60, messages can be returned to the Converter to be issued by the Converter.