Debug Gen 8.6 UNIX/Linux TIRM733E "Error deallocation abend"

Products

Gen Gen - Run Time Distributed

Issue/Introduction

The TIRM733E/733 deallocation abend error on the UNIX/Linux platform occurs when the server load module that is to be accessed and that is referenced in the aeenv file either does not exist or cannot be executed for a variety of reasons including environment settings, permissions, specific problems with the load module application and memory resource issues. These are discussed in more detail below.

If executing the load module application from the build tool on the client side, the error is:

If execute the Test transaction from the Client Manager, the error will be similar to:

Note: If a '632 Trancode does not exist' error occurs, the load module is not defined in the aeenv file. If executing a test transaction from the Client Manager, the error will be similar to:

The aeenv contains an entry for the load module which is accessed by the aefad when the aefad is started. The format of an entry in the aeenv file is:
<Trancode> <Loadmodule> <Userid> <Password> <Database Name>
Verify that the aeenv file that is being referenced contains the correct entry, has correct permissions and is in the correct location.

The 733 deallocation abend error will occur if:

The aefad (Asynchronous Daemon) contains an entry of the load module with the referenced aeenv file but the load module does not actually exist in the appropriate location. The location is typically the inqload subdirectory of the directory where the build was completed.
The load module does not have execute permissions or the owner id is different from the user id. The following screen capture shows a long listing (i.e. ls -l) of a load module P900 with execute permissions. The file P900 shows read/write/execute permissions for the owner and read/execute permissions for the group.
The linked libraries do not have execute permissions. They are similar to the load module permissions above.
The load module contains logic that causes a core to occur. A core dump file results when an unexpected behavior occurs within the application during runtime and a detailed output from the operating system is written to a file. The file is named core and will be located in the directory where the application was started.
The system has memory or resource issues.

Environment

Release: 8.6
Component: Gen Transaction Enabler for UNIX/Linux.

Resolution

Perform the following steps to assist in debugging the 733 deallocation abend:

Manually inspect all inqload directories listed in the AEPATH environment variable to look for missing load modules. A proactive step to take that will assist in the debugging process would be to start the aefad from a script similar to the example shown below. The listed commands would store in the script the current date, the environment settings in place when the aefad was started and the aeenv entries when the aefad was started. The aefad will only use those settings in place at the time it was started; subsequent changes are not referenced by the aefad.
date > aefad.start
env >> aefad.start
cat aeenv >> aefad.start
aefad -i 7788 -a 40 -q 2 -m 32
Check permissions on the load modules and libraries. Perform a lib check as follows:
- For HP: odump -slliblist <loadmodule>
- For AIX: dump -n <loadmodule>
- For Solaris: ldd <loadmodule>
- For Linux: ldd <loadmodule>
Execute the load module from the command line making sure that the environment matches that of the aefad (i.e. see echo env in #1 above). If a library does not exist, a message will be received stating what library it is looking for and is needed. The example below shows that when executing the program P900, libCASCADE.so.a could not be found and was needed.
Run the Diagram Trace Utility on the server load module. In order to prepare the load module for tracing, reference UNIX and Linux Implementation Toolset > Testing and Running Applications. By stepping through the application code, it may be found that it is failing at a specific point where the code is corrupted or something unexpected is occurring.
Monitor the system. This could mean several things including such things as CPU usage, memory requirements, disk space requirements or other resources. The UNIX system administrator may need to be consulted for these functions.
If nothing results from performing the above steps, run the aefad with high level tracing. (i.e. Start the aefad with a - t 31 option. This will create a processing log file that will be located in the location/directory where the aefad was started. The file will be named lgxxxxxx where the xxxxxx is process id (PID) of the aefad itself. Also, perform a long listing to verify the date of the lgxxxxxx files. The log file was meant to be sent to CA for review.

To remove the abend, follow these steps:

Make sure all the aeenv listed load modules exist in the appropriate location and that the AEPATH environment variable points to these locations.

Set execute permissions correctly on the load modules and libraries
- See file permissions by performing a long listing use 'ls -l' (ex. -rwxr-xr-x)
- Use the command to change permissions. (ex. chmod <u/g/o> <=+-> <filename>)
- Permissions are read (r), write (w) and execute (x)
- For each file, 10 permission columns exist.Column 1 describes the file typically file (-) and directory (d)
  - Column 1 describes the file typically file (-) and directory (d)
  - Columns 2-4 show access permissions for the owner
  - Columns 5-7 show access permissions for the group
  - Columns 8-10 show access permissions for others
Check LIB paths. Make sure these paths point to locations of all of the necessary libraries. Here is the syntax for each platform.
- HP: SHLIB_PATH
- AIX: LIBPATH
- Solaris: LD_LIBRARY_PATH
- Linux: LD_LIBRARY_PATH
Run the application load module in trace. By tracing, a corruption or something unexpected may present itself within the application code. A common example of this would be mismatched views when calling/using action blocks. In order to prepare the load module for tracing, reference UNIX and Linux Implementation Toolset > Testing and Running Applications.
When receiving this error sporadically, consult the UNIX/Linux system administrator. This is an indication of a possible memory or resource issue.