top of page

How to solve the Top 6 Java related errors in T24 TAFJ Core Banking

Investigating and resolving Java-related issues is often more an art than a science. Over time you will collect a good sense for the most common anti-patterns and build your Java tuning toolbox. Today I share some insights on handling Java errors in T24 Transact core banking.


Like any software system, T24 can experience errors that cause problems for end-users and IT teams. In this blog post, we'll look at the top 6 Java-related errors that can occur in T24 and provide practical tips and solutions for resolving them.


So, whether you're an IT professional working with T24 or simply interested in learning more about Java-related errors in enterprise software systems, this post will provide valuable insights and practical advice to help you solve some of the most common Java-related mistakes in T24 Transact Core Banking.

Java.lang.Out.Of.Memory.Error


As we know, the Java Virtual Machine performs memory management and can significantly affect your performance depending on how you configure the JVM. The most critical settings for the JVM are the initial heap size and maximum heap size.

The initial heap size represents the amount of memory that the JVM uses on startup; the maximum heap size represents the amount of memory that the JVM can use. When the JVM starts, the heap space is the initial size specified by the -Xms parameter; as the application progresses, objects are created, and the heap space in Java is expanded to accommodate new objects.

The JVM also uses a garbage collector to reclaim memory from dead objects. JVM expands the Java heap to near the Maximum Heap Size specified by -Xmx. If no memory is available in the Java heap for creating a new object, JVM throws Java.lang out.ofmemory error, and your application crashes. To resolve the error, the heap size of the JVM can be slightly increased based on the system load in the jboss's "run. conf" file (jboss/bin).


Cannot find the jvm.dll error.

Please note that libjvm must be inside the TAFC installation for the variable JBCJVMLIB. Other libjvm files referenced in the variable JBCJVMLIB may cause the error to persist. Therefore, please point the variable JBCJVMLIB to the libjvm section of the TAFC installation.


CALLJ error in Java class "Cannot find the JVM.dll P!"

When the JAVA_HOME and PATH variables in the profile file are not correctly set, the problem occurs. Set the JAVA_HOME and PATH variables in the profile file, clear all caches, and restart the application server.

Investigate Java Virtual Machine Support


The first step for both Linux and Windows is to check that a supported JVM is installed. On Windows, first, invoke the command prompt window.

Run the following command:

java -version

Java JVM errors in the rule engine


For the rules engine to function correctly, CALLJ must be correctly configured for jBASE. See the jBASE Programmers Reference Guide for detailed information on configuring jBASE to support CALLJ. This usually means configuring a specific path variable depending on the T24 Server platform.

Windows: JBCJVMLIB

Linux: LD_LIBRARY_PATH

HP-UX: SHLIB_PATH

AIX: LIBPATH

Solaris: LD_LIBRARY_PATH

Compile and run the testcallj.b file; this test routine is contained in the Rules Engine zip file along with the Rules Engine Java code jars:

testcallj.b $ BASIC

testcallj.b $ CATALOG

If this fails to compile, it must be ensured that the routine testcallj.b has the correct line endings for the environment.

If CALLJ works, a message similar to the lines above should be observed, depending on the T24 server platform. If not, try again after checking the environment's variables.

If CALLJ is not configured correctly, the Rules Designer should report an error when validating, saving, or testing a rule.

Temenos Connector issues


Having confirmed that CALLJ works from the command line, it must be ensured that CALLJ works when communicating from the browser to the T24 server through TCServer. Often, it is observed that connector-specific environment variables are stored in the environment. vars

file) should contain accurate references to JAVA_HOME, CLASSPATH, PATH, etc.

Use the env command in Unix (set for Windows NT) to compare and verify settings.


Keep up the great work! Happy Performance Engineering!




400 views0 comments
bottom of page