LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (February 1998)Back to main CICS-L pageJoin or leave CICS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Tue, 3 Feb 1998 16:12:00 -0500
Reply-To:     CICS List <CICS-L@UGA.CC.UGA.EDU>
Sender:       CICS List <CICS-L@UGA.CC.UGA.EDU>
From:         "Abraham, Robert" <Robert.Abraham@AETNA.COM>
Subject:      CICS storage violation

We've got an interesting storage violation, and I'm looking for any thoughts on possible causes, or places to look, etc.... We've gone through the basic steps, including CSFE trap & dumps, traces, etc... IBM's recommending applying a new APAR trap, to come closer, so we've moved pretty far through the basics.....

Here's the details:

Our environment: CICS v4.1 DB2 v4 MQseries COBOL370, LE 1.6 CA/Top Secret Abend/Aid Assist/GT The application also uses Distributed Program Link to access another application & data on another CPU. We're using the Synconreturn option.

The operation: We need to run 32 copies of the same transaction, over a short period of time. These are non-interactive (no terminal.. the transactions are 'START'ed). We use Tranclass to limit the number of copies running concurrently. We recently put in a small (how small is a matter of opinion) application change, and afterward, started encountering the storage violation. When we run the transaction single-threaded (tranclass=1), we don't encounter the storage violation.

The violation: The violation is detected at task termination. The problem is that there doesn't appear to be any application data stepping on control blocks. Instead, at task termination, we find one storage area where the leading crumple zone is overlayed with what would appear to be the crumple zone of the task which previously owned the data area. The previous owner is no longer running; the trace shows that it had used the storage for exactly the same function (ie working storage for the same program, in a prior copy of the transaction). Another storage area has the leading and trailing crumple zones of the prior task. The failing task began when the prior task ended, as a result of the Tranclass threshold, so the prior owner is no longer active. The storage violation occurs once per each run of the 32 transactions. Each dump is incredibly similar, including the fact that the overlay is to a leading crumple zone, with the contents from the most recent prior task.

The questions: Has anyone seen a similar scenario? If so, what caused it, and how was it fixed? What other areas would you look at? Program reentrancy, syncpoint management, OSV products?

Other thoughts?

Thanks for your help!

Regards, Bob Abraham Aetna/USHC


Back to: Top of message | Previous page | Main CICS-L page