Monitor and Test COB in T24 Core Banking
Close of Business (COB) is run daily by banks to consolidate the transactions that happened and make the systems available for next-day transactions. Monitoring the COB requires in-depth knowledge of T24 services, jobs, and COB setup. This also involves executing a few manual steps to run and check the COB progress.
In this blog, you will learn about certain aspects to check before running the COB, how to monitor it, and how to identify issues and possible resolutions.
Pre-COB Checks
To make sure the COB runs smoothly, there are a few essential checks we need to perform.
Before COB, CPU should be below 30%. If the CPU is > 30%, it is recommended to stop other applications.
Ensure sufficient memory to run the COB; A memory issue might result in the COB not starting
EB.EOD.ERROR: The application stores the previous COB errors; all these errors need to be addressed before running the next COB.
After the COB service is started, there is a chance that the TSM is not started properly; usually, we execute the command START.TSM in the TAFJEE to trigger the TSM correctly.
The TSA.STATUS and BATCH.STATUS need to be checked. We need to make sure these are ready to take the COB job’s agent status properly
All the PRE-COB activities need to be completed before starting the COB. These vary depending on the bank’s requirements.
COB Monitoring and COB Health Check
In order to monitor COB, we need to know how COB is designed in T24. COB is a combination of many BATCHES; each batch can have multiple JOBS. Also, each batch is part of different stages in COB. BATCH.STAGE field will contain which part of the application it belongs to.
APPLICATION Stage: The first stage of COB. Has its own batches. Each batch will have its own jobs.
SYSTEM WIDE Stage: The second stage of COB. Has its own batches and jobs.
REPORTING Stage: The third stage of COB. Has its own batches and jobs.
START OF DAY: The fourth stage of COB. Has its own batches and jobs.
ONLINE Stage: The final stage of COB. Has its own batches and jobs.
If you are aware of batches and services, you will be able to know how the services are run. It’s the same way COB works. Since it’s a combination of multiple batches, each batch is run in a sequential manner. We can use COB.MONITOR to know which stage the COB is in and ENQ COB.PROGRESS to check how many jobs are completed. In order to get to know which batch is running, which JOB is running, and what is happening in the JOB, we need to follow a different procedure.
The batch application has a field PROCESS.STATUS, which lets us know which batch is running. If the value is ‘1’, that particular batch is running. There is another associated field, JOB.STATUS, which will give us the details on which job is running if the value is ‘1’. If the value is ‘3’, that particular batch or job is having an error. There is another application that tracks what is happening inside the job. TSA.STATUS stores the currently running service details, like the last message, COMO name, batch, and job details. Using this COMO name, we will be able to see what is happening inside the job.
Analyzing a COB Stuck Issue
There are many reasons to find out why a COB is stuck.
Check the EB.EOD.ERROR details for the latest COB.
Check JOB.STATUS value as ‘3’ in the BATCH application to find out which job is having the issue
We can also check LAST.CONTACT field in TSA.STATUS application. If this value is unchanged for a long time, we need to check the COMO details.
TSA.WORKLOAD.PROFILE decides the number of agents allocated for COB, if more agents are allocated, the CPU increases to max, and no activity takes place.
Memory also plays a significant role in running COB. If memory is not sufficient or is consumed by other services during the COB, jobs cannot be executed properly.
Resolving Common COB Issues
Once we know what is causing the issue, we will be able to address it. Some of the common solutions are listed below:
TSA Agents Management: Make sure the CPU is below 70%. If it is higher, we need to decrease the number of agents running the COB
Memory Management: Allocate sufficient memory for the COB run. If any other service is utilizing more memory, we might need to suppress it during the COB run. Multi-app servers are preferred to address the memory and CPU issues.
The problem with the job can be checked in two possible ways:
1) Local Job: We can involve the IT team to resolve the issue immediately;
2) Core Job: We might need to raise a Temenos service ticket to resolve it on priority.
There is a way to run the COB in classic DEBUG mode. We can start the TSM in classic using START.TSM -DEBUG; we need to enable DEBUG in code to find out where exactly the program is going wrong. This is mostly applicable for local jobs.
Any bank needs a dedicated COB resource with a backup to run their COB every day. In order to check everything manually everyday takes lot of efforts, as a part of our Dynatrace T24-Fastpack services, we bring all the monitoring data into one dashboard to check all the topics. We also alert if the COB is having trouble and send the COB reporting on the timing issues, if any, to the email. If you are looking for a complete COB management service, please do contact us.
Every bank needs a dedicated COB resource and a backup to run COB every day. Checking everything manually can take a lot of time and effort. That's where Perofmetriks comes in: as part of our Dynatrace T24-Fastpack services, we bring all your monitoring data into one dashboard, so you can see everything in one place. We also alert you the moment COB runs into trouble and send you a report by email if there are any timing issues.
If you are looking for a complete COB management service, feel free to contact our experts at Performetriks today. We would be happy to assist you along your journey.
Happy Performance Engineering!
Comments