top of page

Troubleshooting T24 COB getting stuck Issues

Close of business is crucial for any bank. The most common issue all banks face is the COB getting stuck for known or unknown reasons. When we come across such situations, what should we do?


As T24 consultants, we might have run and monitored COB at certain stages of our careers. Based on our real-time experience, let us give you a few tricks for handling such situations.


Check for USER corruption.

What happens if the TSA.SERVICE user for COB is set to INPUTTER. If the USER record is corrupted, the entire COB will crash for a while. We won't be able to log in or perform any activity with the INPUTTER user.

So, we must avoid resetting/using INPUTTER users at any cost, or the bank has to use a dedicated USER in TSA.SERVICE.


Check COMO files

First, we need to find out which job is causing the issue, and then we need to check the corresponding COMO to find out what is happening.


Core/Local job analysis

If the local job is causing the issue, we can easily DEBUG and check the issue. Usually, most of the local routines are attached in the reporting stage.

Suppose the CORE job is causing the issue. In that case, we need to check the functionality of the job/application involved and the possibility of parameter changes before raising it with Temenos.


Locking issues

For most of the read/write in T24, we need to ensure multiple updates to the same record are not happening. We need to avoid locking issues by using alternate approaches.


COB Slowness

Even though the agent allocation and job functionality are proper, we might face memory issues due to other processes running on the server taking most of the CPU, halting T24 record updates or job progress. We should ensure all the other non-T24 processes are not required to be shut down or kept on the other server.


EB.EOD.ERROR rectification

For time's sake, we will clear the EB.EOD.ERROR application and start the COB. The best approach is to rectify the error before the next COB and update the DATE.RESOLVED field to YES, and then proceed with the COB. This will avoid the same EEE appearing in the next COB.


BATCH.HALT in the batch

If we know that COB will crash in any particular JOB, then if we need to DEBUG and check that specific JOB, we can STOP COB just before that job by using the BATCH.HALT before the other JOB, which we need to analyze.


Some of the possible suggestions for COB slowness and tuning are provided in our COB optimization blog, where we segregate the COB tuning into T24 technical, T24 functional, and T24 environmental suggestions. Each bank will face different scenarios; obviously, if you follow the correct approach, there will be solutions for all.

We are here to improve your COB and Core Banking system for speed and best throughput. Contact us any time.

Keep up the great work! Happy Performance Engineering!

Recent Posts

See All


bottom of page