Debugging the 733 Deallocation Abend Error for UNIX

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

Summary:

The 733 deallocation abend error on the UNIX platform occurs when the 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:

Error

If executed as a test transaction from the client manager, the error will be similar to:

Client Manager

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:

Client Manager

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:

  1. 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.
  2. 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.

    Telenet Claw

  3. The linked libraries do not have execute permissions. They are similar to the load module permissions above.
  4. 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.
  5. The system has memory or resource issues.

 

Instructions:

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

  1. 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. This would store to a file the date started, 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 daemon.
    Script entries sample:echo 'date' >> aefad.start
     echo env << aefad.start
     echo cat aeenv << aefad.start
     aefad -i 7788 -a 40 -q 2 -m 32
  2. Check permissions on the load modules and libraries. Perform a lib check as follows:
    1. For HP: odump -slliblist <loadmodule>
    2. For AIX: dump -n <loadmodule>
    3. For Solaris: ldd <loadmodule>
  3. 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, you will receive a message 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.

    Telenet Claw

  4. Run server trace on the load module. In order to prepare the load module for tracing, reference 'Server Trace Facility' within the appendix of the Transaction Enabler Users Guide. By stepping through the application code, you may find it is failing at a specific point where the code is corrupted or something unexpected is occurring. In order to prepare the load module for tracing, reference 'Server Trace Facility' within the appendix of the Transaction Enabler Users Guide.
  5. 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.
  6. 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 daemon 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. 

  1. Set execute permissions correctly on the load modules and libraries
    1. See file permissions by performing a long listing use 'ls -l' (ex. -rwxr-xr-x)
    2. Use the command to change permissions. (ex. chmod <u/g/o> <=+-> <filename>)
    3. Permissions are read (r), write (w) and execute (x)
    4. For each file, 10 permission columns exist.
      1. Column 1 describes the file typically file (-) and directory (d)
      2. Columns 2-4 show access permissions for the owner
      3. Columns 5-7 show access permissions for the group
      4. Columns 8-10 show access permissions for others
  2. Check LIB paths. Make sure these paths point to locations of all of the necessary libraries. Here is the syntax for each platform.
    1. HP: SHLIB_PATH
    2. AIX: LIBPATH
    3. Solaris: LD_LIBRARY_PATH
  3. 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 'Server Trace Facility' within the appendix of the Transaction Enabler Users Guide.
  4. When receiving this error sporadically, consult your UNIX system administrator. This is an indication of a possible memory or resource issue.