We learn by making mistakes. That's why we start with pencils and erasers, and after a few years, we use pens in school. Let's zoom in to some common mistakes you should avoid in T24 Core Banking.

#1 Corrupting INPUTTER users as soon as we get DBTOOLS access.

What happens if the TSA.SERVICE user for COB is set to INPUTTER. It will crash the entire COB 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.

#2 Using DELETE-FILE F.BATCH instead of F.BATCH.STATUS in DBTOOLS

Again, the COB crashes when the above command is executed, and all the batch records will be deleted. It requires pack deployment if COB is not started. Sometimes, there is an entire environment refreshment if the COB is going on.

This DELETE will completely erase the application's data if it's not used correctly. It's better to use COUNT with the complete command first and then replace it with the DELETE once we get the full command right.

#3 Confusion between VALIDATE and VERIFY. For this one, we use the 'V' function.

The Validate is just beside the INPUT symbol. It's used to confirm if there are any errors present before committing. While using OFS, we use the 'I' function and the VALIDATE command to refer to this.

We use the 'V' function to verify the record.

#4 Use WRITE to update any application records.

We should update any application using OFS; the main reason is to track the audit fields. We observed some practice updating the audit fields with the WRITE command and incrementing the curr.no field. This will result in no audit field trace for those current numbers. This should be avoided.

#5 Understanding the functional difference between the 'before auth' and the 'auth' routine

We should be aware of the difference between these routines; the before auth is the main routine we should use when we need to make any changes in the version just before authorizing. The conditions are checked before authorization takes place.

The Auth routine gets triggered after the authorization of a record. Usually, we use this routine to get the existing application information and update/write it to another file.

#6 USE RESERVE fields in the local template

When we need to add new fields to the local template with records in the database, we should replace one reserve field with the latest field we use. It's because the newly added field will hold the current number record of the existing record, and audit field records will be moved one step above if it's added directly rather than replaced with the RESERVE field. I hope the developers could have gotten into this situation. So don't forget to add and use RESERVE fields if necessary.

#7 Deployment alert: Financial records

The changes in financial records like ACCOUNT should be amended in prod using special instructions in the Release notes. Taking a back to those records and deploying them will alter balances.

#8 Remove local fields from the Database

If values are assigned to the local field in the application, they will be stored in the DB level. So, it's not recommended to remove the local field from DBTOOLS. We should carefully design and add local fields for the application and use them.

Performetriks provides T24 general, functional, and technical training to make sure our customers make the most out of their Core Banking system. We also bring Observability to your core banking suite and optimize your platform for speed and reliability.

Keep up the great work! Happy Performance Engineering!