Problem solve Get help with specific problems with your technologies, process and projects.

Problem with ATCH abends and backouts

HI, I have 80 or so ATCH abends each day that I would like to stop. (CICS 4.1) I understand the basic explanation from my book that the task was purged for one of several reasons but as we are not doing a purge from CEMT and I do not use a any value for DTIMOUT, so I think that CICS is doing the purge request.

(Is there some default value for DTIMOUT that I do not know about?) Also related to this, I would like to prove to the folks above me that any abend, even with a good backout is bad. Am I right in thinking that CICS has to do just as much work backing out a transaction as it would on a successful one?

I must say that my first reaction on reading this question was "Urk! I don't like this at all."

There is something going on in your region which needs attention, and these ATCH abends are a symptom of it. This may be a shortage of resources or some strange application code, but you will need to investigate further by running with AuxTrace and seeing why these Abends are happening. Although this is a bit of a generalisation, when the Application Program issues an XC Call, these eventually float through into a CICS Domain function, and at this point the CICS Task Manager has decided to chop the task and the ATCH Abend occurs. Trace will show which Domain Call caused the Abend.

If it tends to be coming out of the SM Domain, then Storage will probably be the prime cause. This might well indicate that you are running short of Storage, and some tasks which use a lot of it and don't appear to be terribly active are chopped.

If File Control is involved, then you are probably into some sort of record/file contention arena : perhaps two transactions are in a deadly embrace (both waiting on a resource held by the other) so CICS will chop one to permit the other to continue.

It could be that these transactions are trying to ENQ on something, and never getting control of the Resource - and so eventually get cancelled.

Most installations do not issue an Abend willy-nilly - these should be reserved for situations where it is very difficult to get updated Recoverable Resources rolledbacked manually, and so it's best to leave it to CICS facilities to restore the status quo ante. End Users much prefer a message at their terminal saying something has gone wrong rather than a DFH message saying an Abend has occured. However, it's a perfectly valid technique for an Application to issue a user-type of Abend and this does ensure that Recoverable Resources are correctly recovered.

In your case, these ATCH Abends should be got rid of - your Applications which are involved in these issues should not be getting into this situation and I urge you to resolve this situation.

It's not the performance of backout that should worry you - it's the Abends themselves.

Dig Deeper on IBM system z and mainframe systems

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.