Daily CICS MICS job has been erroring due to runaway transaction

Products

• MICS Resource Management

Issue/Introduction

You have a daily CICS MICS job that has failed due to a runaway transaction in one of your CICS regions. You are unable to get it to process the large amount of CICS transactions and need help to get the job to run. Your storage team has created a separate storage pool to handle the excessive amount of transactions but the job is still failing on sort work.

Resolution

If you have identified the runaway/looping transaction then you can exclude it from MICS processing by means of the USRSCSW user exit.  The USRSCSW exit is called as the CICCSW work file is being defined. You can code an expression that sets SKIP_REC to 1 so that a particular observation is not be written to the CSW work file. Observations not written to CSW will not be available to the CAC, CSU, or CAU files in any timespans.  

To implement this exit at the unit level, code it in prefix.USER.SOURCE(#CICEXIT).   

For example this code skips transaction id of #### from SYSID #### and CICSID ####. 

%INCLUDE  SOURCE(#CICEXIT);                               
MACRO _USRSCSW                                            
IF SYSID='####' AND CICSID='####' AND TRANCODE='####' THEN
SKIP_REC=1;                                               
%  

After coding the user exit, the MICS job can be restarted in the step that failed (DAY040 in this case). 
It might be possible that the transaction is a runaway for a limited time and not during the entire life cycle of the transaction.  In that case you could also have the transaction within the time limit STARTTS and ENDTS in the user exit. 
Once the issue with the looping transaction is resolved, make sure to remove the user exit code to ensure the transaction is not skipped in future loads.

Additional Information

Refer to the section CICS Output Exits for more information about the USRSfff exit.