KICKS KooKbooK recipe

Run Away Task!

What’s an AICA abend and how to prevent it

We interrupt this discussion of KICKS/CICS api’s (aka ‘Simple KICKS COBOL programs’) to talk about the AICA abend, also known as ‘Runaway Task’.

When KICKS or CICS gives control to your program (initially and again after each EXEC KICKS api call) it sets a timer (elapsed, not cpu time). If that timer expires before your program gives up control (an EXEC KICKS RETURN or any other EXEC KICKS api call) an AICA abend results.  The idea is that if a program has not returned or at least asked for some kind of api service in that amount of time it is probably in some kind of loop and should die. Your application has ‘run out of time’, or it was a ‘runaway’.

The duration of the timer is defined by the SIT parameter ICVR (default 5000 milliseconds, 5 seconds).

In CICS an AICA is a ‘normal’ transaction abend and CICS and other running tasks continue normally.

In KICKS an AICA abend (like ASRA and ASRB abends) results in KICKS itself abending with a dump after it does a normal transaction dump for your task.  Since KICKS is a single user system it makes sense to collect maximum debugging information and shutdown after these serious errors rather than attempt to continue. Recovery is after all just a matter of starting KICKS again and resuming work…

Why would your application run out of time? It might really be in an endless loop. It might be waiting for something. Or it might be processing normally but the process takes more than the timer duration.

An endless loop could be as simple as either of these

A wait could be as simple as asking the operator to do something, as either of these

An example of something that just takes too long (more than 5 seconds with the default ICVR) might be using the COBOL READ verb to read and process all the records of a large file.

Another possibility for something taking too long is the system being extremely busy and hence unable to process your work fast enough (especially including swapping out your address space)!

When you get an AICA abend you should obviously first determine why your program ‘ran away’.  If a program bug was the fault you only need to correct the program. But sometimes you decide that what the program is doing is REALLY what you want it to do at which point the question becomes “how can you get KICKS to allow it?”.

If your application has an ‘endless’ loop (hopefully one that really does end at some point) or has some other process that ‘just takes too long’ you can let KICKS know not to abend the task by periodically doing something with KICKS. The standard something to do is an EXEC KICKS SUSPEND, which does nothing other than tell KICKS (or CICS) that your program is busy but doing what it should, so KICKS should not abend it. If the GO TO in our first example wasn’t a bug, just part of a time consuming but valid process, we could tell KICKS to allow it to run a long time by modifying the code as below

If you are trying to debug an AICA abend you might be tempted to use EXEC KICKS ENTER to put special user entries into the trace table – but don’t! ENTER is just another something that will reset the AICA timer, so adding those user trace table entries will hide the problem! DISPLAY or DISPLAY UPON CONSOLE is ok (as long as you don’t flood the console and crash MVS).

If your application is going into waits you won’t be able to do SUSPEND’s, so the only option is to increase the ICVR parameter, which of course will affect all transactions you run. For example if you are using DISPLAY/ACCEPT to communicate with the operator you might want to set ICVR=60000 (1 minute) or perhaps even more. ICVR can be at most 2,147,483,648 (more than 3 weeks); if that isn’t enough you can set ICVR=0 which disables runaway detection and makes an AICA abend impossible. Maybe OK on KICKS, but don’t expect your CICS administrator to go for it (‘course he wouldn’t be happy with your using DISPLAY/ACCEPT either).