If you run the trap to check all not just current task storage (csfe debug,chkstsk=all) then the violation must occur during task termination. If the check zones were not intact when the previous trace entry was created your should have gotten a dump at that time. When you get the dump during task terminatin with the trap active does the dump come from the trap springing or from scp detecting the storage violation. I believe the trap checks amoung other things to insure that the trailing check zone matches the leading check zone and that matches the task number but I am not certain because IBM does not let us have access to DFHSCP on R410 with VPL. Is PQ10599 an APAR taken for your problem. If not you may want to look at it. It has a trap in it.

---------- > From: Abraham, Robert <Robert.Abraham@AETNA.COM> > To: CICS-L@VM.MARIST.EDU > Subject: CICS storage violation > Date: Tuesday, February 03, 1998 4:12 PM > > 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