The inability to propagate application-defined user abend codes through JVM shutdown is a fundamental obstacle to modernizing z/OS batch jobs with hybrid Java/COBOL architectures.When running hybrid batch jobs (Java + COBOL) inside a JVM on z/OS — launched via the JZOS Batch Launcher (JVMLDM) — application programs can issue arbitrary user abend codes (e.g., U0100, U0200, U0300) to signal specific error conditions to the job scheduler. This is standard practice for automated job control.However, when the JVM shuts down after such an application-level user abend, the IBM Language Environment (LE) runtime issues its own internal U4094 abend during the cleanup phase (e.g., while releasing latches, mutexes, or thread resources — reason codes such as X’8C’, X’48’, X’44’, etc.). MVS then reports U4094 as the final abend code for the job step, completely obliterating the original application user abend code.This behavior is inconsistent with classic COBOL batch jobs running outside a JVM, where the application’s user abend code is preserved and visible to job schedulers.Current Behavior 1. Application (Java or COBOL within JVM) issues user abend code e.g. U0200. 2. JVM begins its shutdown sequence. 3. Language Environment cleanup issues U4094 (LE internal termination abend) during resource release. 4. MVS records U4094 as the final step abend code. 5. IWS / job scheduler sees only U4094 — the original U0200 is lost. Expected / Desired BehaviorThe original application-level user abend code (e.g., U0200) should be preserved and reported as the final step abend code, even if the Language Environment internally issues U4094 during JVM cleanup. U4094 termination cleanup abends that are a mere side effect of JVM shutdown (especially those explicitly documented as ignorable, e.g., reason code X’8C’) must not overwrite the application’s abend code.Proposed Solutions (one or more): 1. Suppress ignorable LE cleanup U4094 codes: If a U4094 occurs during JVM teardown as a consequence of a prior application-level abend (i.e., as a secondary termination side-effect), suppress or demote it so it does not replace the original abend code at the MVS step-level. 2. Preserve the original user abend code in the MVS step completion: Provide a mechanism in the JZOS Batch Launcher or LE runtime to pass the original application user abend code through JVM shutdown, ensuring it is reported as the step-level abend code to MVS — similar to how System.exit(rc) propagates return codes today. 3. New JZOS / LE runtime option: Introduce a new runtime option (e.g., a JZOS environment variable or LE runtime parameter) that controls abend-code preservation on JVM termination, allowing sites to designate specific U4094 reason codes as non-overriding. Business ImpactOur production environment operates a large number of hybrid Java/COBOL batch jobs scheduled and controlled by IBM Workload Scheduler for z/OS (IWS). IWS recovery definitions rely on specific user abend codes to drive automated job control decisions (restart, re-queue, skip etc.) Since U4094 always masks the real abend code, all these IWS automation paths are broken for JVM-hosted batch jobs. We cannot distinguish between error conditions, making intelligent, code-driven recovery impossible. This forces manual operator intervention for every abend — a significant operational overhead — and represents a regression compared to classic non-JVM COBOL batch jobs, where this job control model works reliably in production today.
Hello,
Even a very simple transition from COBOL 31 to COBOL 64 results in the loss of the actual cause of termination (a 0C7 in my case) if the COBOL 64 program crashes; instead, a meaningless U4094 RC=400 error is generated. The problem is further compounded by the fact that this makes dump analysis using Fault Analyzer almost impossible. In my assessment, error handling in 31/64-bit mode is still at the prototype stage and not yet mature enough for production use. Urgent improvements are needed here.
Regards
Alex