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