> 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. :-)
I reviewed your PMR and dumps, and made some suggestions in the PMR. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
