top of page

Optimizing T24 File Sizing for Efficient Processing and Data Transfers

T24 Transact is a core banking system developed by Temenos. In T24, file sizing refers to the maximum size limit of a file that can be uploaded or processed within the system.


File sizing is essential when designing interfaces or data transfers between T24 and other systems. However, the maximum file size limit can vary depending on the interface or process. Keeping file sizes as small as possible ensures efficient processing and avoids potential issues such as timeouts or system crashes. It is also essential to ensure that files are correctly formatted and structured to prevent errors during processing.


T24 provides various tools and utilities to manage file sizing and ensure smooth data transfers, including options to split large files into smaller segments or compress files to reduce their size.


Reduce the size of the bnk.run directory


To reduce the size of the bnk.run file, please use the appropriate methods for the &HOLD&, &COMO&, &PH&, EXCEPTION.LOG.FILES, OFS.REQUEST.DETAIL, and PROTOCOL files.

  • &PH& is the log file created for the phantom processes run using EB. The PHANTOM file will be made in the &PH& directory. These log files are just for informational purposes and should be cleared manually based on the requirement after taking a backup.

  • COMO will have the log files that will have the details of every action being performed, like COB logs, upgrade logs, UPDATE logs, etc. This should be cleared manually based on the requirement, after taking a backup.

  • The generated reports will be held and cleared in COB based on the reports.The job PURGE.HOLD.RPTS during COB mention retention days in the SPF. The job PURGE.HOLD.RPTS will select all the reports in the HOLD.CONTROL file that has been spooled and delete all those records that have been in the "HOLD" file for more than the number of days specified in field 17 "Report.Retention" in the SPF record or in field 15 "Report.Retention," if present.

  • EXCEPTION.LOG.FILES/HIST will only be used to store overrides and errors while committing an application's transaction and errors thrown during EOD, where the EXCEPTION.LOG.HIST file will contain the details for the previous day. The file EXCEPTION.LOG.FILE is cleared during the COB daily. The job EB.CLEAR.FILES is attached to the batch record file. TIDY.UP clears this file during COB.

  • OFS.REQUEST. DETAIL will maintain the details like username, IN string, OUT string, and OFS process status of the transactions that are processed through OFS. This should be cleared manually based on the requirement, after taking a backup.

  • If the requirement is to remove all the financial data, then SYSTEM.CLEAR.FILES can be used. This SYSTEM.CLEAR.FILES routine will remove all the financial data from the environment.

Upkeep of the "COMO" directory


The COB directory within bnk.run will contain log files containing information such as COB logs, upgrade logs, update records, etc.

The system does not clear this directory, and hence the size of the directory will grow periodically. The ID of the COM files generated by COB will be in the format "tSA_3_20230201_03-04-10." These CO files can be moved from one environment to another.

To reduce the size of the COMO directory, the COMO directory should be cleared manually based on the requirement after taking a backup.

Execute CHECK.T24.FILES for resizing

There is a utility in jBASE named jrf that can be used to resize files in jBASE.

Use jrf with the -Rv option to check if a file needs resizing. '-Rv'

(This option will only report and not resize the file.)

How frequently should you resize

The frequency of resizing depends on the growth of the database. Start with a weekly resizing procedure; over time, you will arrive at the right frequency to resize files, i.e., weekly, fortnightly, or monthly. Monthly resizing is an absolute minimum requirement.


The preferred way to resize files in T24 with jBase 5 and R7

Resizing can be done through a formal inquiry in Globus called EB.BAD.SIZE.FILES. Kindly run this inquiry, ENQ EB.BAD.SIZE.FILES. When this inquiry runs, it will ask, "Gather new file size information?" The user has to enter either FULL or FAST. The FULL option will keep a count of records in each file, but FAST will not do the count on the records, so the FAST option will be quicker than FULL. This inquiry will create the VOC entry RESIZE.GLOBUS with the files to be resized as shown below:

During resizing of jbase files using RESIZE.GLOBUS, the system prompts a "probably in use" message, and the file was not resized.

File resizing is a downtime activity that should be performed when no users are logged in to the system.

Hence, please execute RESIZE. GLOBUS when all the users are logged off.

Resizing JR Files

Before converting, backup the J4 (data and dict parts) file.

From the jsh prompt, execute the below:

J4_FILE_NAME> jsh -H6 jrf

Check the following to ensure that the file was successfully converted to JR format:

jstat -v FILE_NAME>

How frequently should archiving be done?

The frequency of archiving depends on the growth of the database. For sites with large volumes, suggest that this is a monthly exercise. Suggest that the retention period be kept to an absolute minimum. For example, if you require the FT data only for the past month, then please keep it only for the past month. Start archiving as soon as you go live to maintain the peak performance of your system. If you are on JBase, please do not forget to resize your files after archiving.


BAD FILES NEED TO BE RESIZED.

Please note that the BAD.SIZE.FILES command in CHECK.T24.FILES will use a simple formula to calculate the modulo of the files and, based on conditions, will update the downsizing or resizing. Hence, this can be termed a tool for resizing T24.




Keep up the great work! Happy Performance Engineering!



bottom of page