CICS offers a lot of possibilities when it comes to errorhandling of EXEC CICS interface calls. I will summarize some of them in this tip. If you do nothing then it is almost certain that your EXEC CICS interface call will cause your task to abend if something goes wrong. It is up to you to change this rather stubborn behaviour. Let us look at an example:

EXEC CICS
  IGNORE CONDITION DUPREC
END-EXEC
EXEC CICS
  WRITE FILE('MYFILE')
  FROM(MY-RECORD) RIDFLD(MY-KEY)
END-EXEC
EXEC CICS
  HANDLE CONDITION DUPREC
END-EXEC

The first interface call tells CICS not to abend if the condition DUPREC should occur. The next call is then carried out even if a DUPREC condition occurs. The last call tells CICS to handle DUPREC the CICS way. In this example the idea is to ignore any records that you try to write to a VSAM KSDS with the same key as an existing record. New keys are written but existing are ignored. The smart part is that we don't have to write any IF statements. The same method can be used for all other CICS interface calls and their error conditions. If you always want to receive control after a CICS interface call you can add an option called NOHANDLE:

EXEC CICS
  LINK PROGRAM('MYPROG')
  NOHANDLE
END-EXEC

In this example CICS will return to your program without abending your task even if MYPROG isn't available. If you want to know what happened then you have to check the value of EIBRESP and act accordingly. You can read a lot more about CICS errorhandling if the manual Application Programming Reference. Depending on the CICS version used at your installation the correct manual is also named either CICS something or Transaction Server something. Maybe the newest release of CICS has got a third name.