IN FOCUSMFJUXIT Is Process-Local: Why JCL Events Do Not Form One Timeline
Rocket’s JCL user exit can observe and influence job events, but its state is local to the SEP process that invoked it. Submission, execution, and SSTM events may occur in different processes, and an exit failure disables later callbacks only in the failing process. [1] [2]
Read the full briefing
MFJUXIT Is Process-Local: Why JCL Events Do Not Form One Timeline
Scope: Rocket Enterprise Developer / Enterprise Server 12.0 for UNIX, JCL user exits.
The JCL user exit lets a COBOL program observe job and TSO events and, at supported control points, request an action or modify eligible data. The exit is named MFJUXIT by default; the MFJUXIT environment variable can select another module. Enterprise Server invokes it with one parameter—the interface block defined by mfjdxit.cpy. Fields whose names contain -I- are input-only and must not be changed; -U- fields may be returned with acceptable modifications. All character data in the block is ASCII/ANSI. Rocket also requires the exit to be written in COBOL and recommends the MF dialect plus the NOOUTDD directive. See User Exit Invocation, Rules, and Guidelines.
The subtle operational point is process locality. Most events occur in the batch initiator SEP, but the early Event-job-ready, Event-job-queued, and Event-job-stmt-info callbacks occur in an Admin SEP for jobs submitted through ESCWA Region Monitor and Control, or in a Normal SEP for other submission methods. For SSTM jobs, events from job-started through job-ended occur once in each Normal SEP. Rocket states explicitly that a JCL user exit can remember only events in the process from which it was invoked.
That means working-storage retained by one loaded exit instance is not a reliable job-wide history. If correlation across submission and execution matters, design around identifiers supplied in the event data and an external correlation mechanism; that is a practical consequence of Rocket’s documented process boundary, not a claim that the product supplies such a store. Another important failure nuance: if the exit fails, it is disabled for all subsequent events in that failing process.
Two action codes apply to every event. action-continue, the default, resumes normal processing as if the exit had not been called. action-shut-exit suppresses future exit calls in the current process for the current job or TSO session as a performance aid. Rocket still advises coding the exit to tolerate later events and return action-continue. The event catalog also warns that not every described event is implemented, so verify the specific event page before depending on a callback. See JCL/TSO Events and Actions.
For operational visibility, JCL events are written to MFMVS.SYSLOG. The exit can log every implemented event, log only events that request an explicit action, or disable event logging; the selected state persists until the exit changes it again. Interactive TSO and TSO-in-batch activity are not supported by this logging facility. See Event Logging.
Takeaway: Treat each MFJUXIT invocation stream as SEP-local; never assume one in-memory exit instance sees the complete lifecycle of a job.