T24 Core Banking Coding Rules for High Performance

How can T24 core banking systems be coded to ensure high-volume clients' best performance and throughput?

We all agree that yesterday was the best time to plant a tree and that the second best time is today. However, sometimes not everything works as expected from the beginning, and thanks to our human ability to learn, adapt and improve, we keep climbing and enhancing our work step by step.

Developing a core banking system is a big adventure. You can learn from your peers, do it yourself or use a standardized system, but there will be some level of customization. Unfortunately, this custom code is vulnerable to performance mistakes. So we've developed some simple rules to avoid critical reliability in your custom core banking code.

Basic Coding Standards

1. SELECT statements are concatenated using the AND/OR WITH" clause operators for multiple selections

2. A template routine should not exceed 2000 lines.

3. A call subroutine should not exceed 600 lines.

4. A GOSUB block should not exceed 100 lines.

5. A IF condition block should not exceed 60 lines.

6. Not more than three nested if statements in a Subroutine

7. To suppress such warning messages, the following environment variables can be set in .profile– JBASE_ERRMSG_DIVIDE_ZERO, JBASE_ERRMSG_ZERO_USED, JBASE_ERRMSG_NON_NUMERIC

It is better not to suppress the DIVIDE_ZERO error as this error can to be captured and fixed in the application. Furthermore, this error may be more dangerous in arithmetic calculation than the other two messages.

Performance Tuning Rules

1. FOR..NEXT should be replaced with LOOP

2. EXECUTE or PERFORM should be replaced with CAL because it will create its own memory space.

3. In some cases, READ is better than F.READ, and WRITE is better than F.WRITE.

4. Don't put big codes between a TRANSSTART and TRANSEND

5. While developing BATCH programs, use multithreading

6. In jbase, we have the utility' jprof', which tells which part of code consumes how much time.

Things you should avoid

Don't lock records if we're updating the id with a unique session number

DON'T – Call CACHE.READ and F.READ without ID

DON'T - Use CACHE.READ for dynamic tables like ACCOUNT, CUSTOMER SELECT on huge files

SELECT in .RECORD routines

Things you should do

BULK simple transactions in the .SELECT routine

Index frequently used fields

Lock and write Records in Multisession environments

Use the .FILTER routine

Our coding standards and performance tuning cookbooks for the T24 Core Banking system contain many more hints. We specialize in tuning your core banking engine for speed and best throughput. In addition, there will be a Core Banking tuning workshop available soon. Follow us on our website to learn more about how we make our customer's performance dreams come true.

I look forward to learning more about some performance pain points you face. We are here to optimize your complex systems.

Keep up the great work! Happy Performance Engineering!