John, Several years ago, We upgraded to z/os 1.11 from 1.9 and cobol 3 to cobol 4.1 (I think). Several of our production cobol jobs got S0C4 abends but not on the 'test' LPAR which stayed 1.11. Turned out to be a combo of altered base compiler options combined with several LE parms. Once we got them to all be exactly the same , all jobs started working under the newer 1.11. The only abends occurred in pgms that got re-compiled under the newer system with the newer LE installed. I do not remember the exact parms we had different, but I think one was the TRUNC(BIN) in cobol and the storage heap 4 part parm under LE. Not sure why they were different in the first place. Hope it helps a bit.
John Clifford M/F Consultant (GTSG consulting) On Wed, Oct 8, 2014 at 3:36 PM, Chase, John <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
