Hi, Listers, We seem to have hit a "show stopper" in our effort to implement COBOL v5.1 (upgrading from COBOL v4.2).
A collection of nightly batch jobs incurs sporadic, seemingly random S0C4 abends when the "main" program and a couple of subroutines are compiled with the COBOL v5.1 compiler, with the rest of the subroutines compiled with COBOL v4.2 and/or COBOL v3.4. We've been working a PMR with IBM COBOL Support for a few months now, and IBM has identified the cause of the S0C4 as corruption of a pointer to a key LE control block. Current efforts are aimed at identifying the perpetrator of the corruption, but it seems we cannot obtain the problem documentation IBM has requested. "Why not?" you might ask. Well, first, the abends occur ONLY in Production. All efforts to recreate them in DEV have failed so far. Thus, setting up the "capture environment" in Production requires that we discuss its setup in Change Control each time, effectively limiting our attempts to once per week. Second, when one (or more) of the jobs incurs the S0C4, we set up a dynamic Storage Alteration SLIP with ACTION=TRACE and other parameters specified by COBOL Support, start GTF with TRACE=SLIP and re-run the job. Unfortunately, the job then runs to normal completion and no SLIP trace is captured. This has been true for each of multiple failed jobs that are re-run with the diagnostic capture set up. After all diagnostic capture attempts, the change package for the failing program is reverted to "no COBOL v5.1-compiled components". Needless to say, we tend to get less enthusiastic about subsequent capture attempts. Environment: z/OS 1.13 on all LPARs, currently at identical maintenance levels (~RSU0514 plus HIPERs and PEFIXes through August); DB2 v10 in "new function mode". DEV runs on a z114-N02; Production runs on a z114-Y02 (in case machine speed might be a factor); both CECs are at current and required MCL levels. Compiler options for COBOL v5.1 include ARCH(9), OPT(1) and TEST(EJPD,SOURCE). The batch jobs (31 total) in the collection are identical except for a "warehouse identifier" passed as a run-time parameter and are released to run concurrently. The load library is (required to be) a PDSE. Any ideas as to what else we might try would be appreciated, as would any ideas as to "why only in Production?" Regarding the latter, we've already dismissed planetary alignment, sunspot activity, moon phase, etc. :-) TIA, -jc- ********************************************************************** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
