Close of Business processing is the bread and butter for the T24 Transact Core Banking system. In the worst case, a too-long COB processing blocks Banks from opening their business in the morning, negatively impacting their reputation.
There are daily, weekly, monthly, and end-of-year COB run in such Core Banking systems. They all require special attention when systems are changed or upgraded to a newer version.
When we optimize COB duration, we review the general setup of T24 and changes in local routines implemented from the Bankside. Usually, performance problems are due to
Local reporting routines
Parametrization of T24 Transact
Database
CPU and file size
JT/RT Analyser tool
The beauty of this tool is that you can investigate Jobs and Report executions from previous days. In addition, it helps to identify long-running Jobs and Reports in your environment, which is a starting point for further optimizations.
You can download the tool Job Time Analyser/Report using the link below.
Dynatrace
The full-stack monitoring solution Dynatrace comes with code-level insights for all T24 and COB requests. As a result, it simplifies the identification of problematic Jobs, and we have all monitoring data from the end-user down to the infrastructure and code level in a single cockpit.
Single or multi Threaded Jobs
Every job processing time consists of selection and execution time. Therefore, it would help to keep in mind that multi-threading does not reduce the selection time. But, if the execution time of a job is more than expected, you should make it multithreaded.
Find the optimal number of Agents
In T24 Transact, we have so-called Agents to execute COB jobs. Finding the optimal number of these Agents is crucial. Based on our experience, the perfect number of Agents per server can be calculated using the following formula: Number of CPUs x 1.5. For example, if you have an 8 CPU server, you could configure 8 x 1.5 = 12 Agents to run on it. Please also remember that each Agent will consume a certain amount of memory depending on its heap size configuration, and the server should have sufficient memory.
EB.CLEAR.FILES
If you are facing such problems, you should review the following:
Changes in PGM.FILE setup
Minimize user records in F.PROTOCOL
IC.COB
Slow response times in IC.COB are usually due to the locking of internal account records, which can be avoided by adjusting the ACCOUNT.PARAMETER configuration. Another performance optimization option is to consider bulking using the PGM.FILE configuration.
COB job PRINT.ACCOUNT.STMT
Slow response times are standard, but you could adjust the ACCOUNT.STATEMENT and AC.CONSOLIDATE.COND configuration to improve the speed.
Enquiry Reports
Consider creating such reports online and not during COB to save essential time.
CONCAT Files
Check if you are reading CONCAT Files rather than executing SELECT statements.
EB.EOD.CUST.CHARGE
Consider running such jobs daily to update CUSTOMER.CHARGE and reflect changes in PGM.FILE to reduce the duration.
DW.EXPORT
If your DW.EXPORT is slow; you should consider bulking or incremental extract to speed up its execution time.
Slow SQLs
There can be many reasons, and most of the time, a detailed review of the database configuration is required. In some cases, a very straightforward table resizing improves the performance.
Improvements in T24 Transact Core
In some cases, adjustments in the T24 core could help to speed up the COB duration. For example, during our COB optimization projects, we have identified issues in the following core routines.
1. SC.UPDATE.SM.PRICE
2. SOD.CASHFLOW.UPDATE
3. RE.UPDATE.SLC.LINE.BAL-RE.BUILD.LINE
4. AA.SERVICE.PROCESS
5. LIMIT.REP.KEYS
6. AA.EOD.PROCESS
7. AA.SOD.PROCESS.
8. COB.AM.BV.FEES.WORK.PC
9. SW.EOD.SCHEDULE
10. BV.PRICE.UPDATE
Don't set your business at risk, and make COB optimization fundamental to your test and operational activities. Our team is here to support your COB performance tuning.
Keep up the great work! Happy Performance Engineering!