Why does my Web Application fail with an IEFT abend on CICS server?

Document ID : KB000011344
Last Modified Date : 14/02/2018
Show Technical Document Details

Our web application is deployed to the Weblogic application server installed on Solaris. This web application connects to the CICS server without problems.    We have the same web application deployed to Weblogic on Linux but connecting to the CICS region produces an IEFT abend.


Why does my Web Application fail with an IEFT abend on CICS server?

We ran a CMIDEBUG trace in both the environments and found out that the working application (deployed to Solaris) is sending information with code page 819 where as the non-working application (deployed on Linux) is sending information with 1201 code page.

How can this be resolved so that the Linux machine would also send the information in code page 819?


An IEFT abend error message on the CICS server side means that there is a code page translation problem. In order to send the desired code page (in this case 819) to the CICS server, modify the CFBDynamicMessageEncodingExit.java file. Open this file and look for the serverEncoding method. Replace or comment out the default code that is present in the method body with the following line of code:

return "ISO-8859-1";

Make sure that the above line is the only line of code in this method's body. The finished code would look something like this:

 public static String serverEncoding( String tran, String encoding ) 
{ return "ISO-8859-1"; } /**********************************************************************/

This will cause the runtimes to build the CFB (Common Format Buffer) using codepage 819 and will send the message to the server in this codepage.

Save the user exit and recompile it from a DOS prompt using the javac command.  Update the CA Gen java runtimes jar file i.e. genrt.nn.jar (where nn is representing the release of Gen like 86 for 8.6) with the newly updated class file for the user exit. If the runtime jar file is packaged within the EAR file then redeploy the EAR file to the application server otherwise, if the runtime jar is separately deployed i.e. to the application server classpath, then make sure that the classpath is updated with the newly updated jar file.