PI52884: ELACOMB AND ELACOMC ABENDS IN THE HEAP MEMORY MANAGER

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• ELACOMB and ELACOMC will sometimes use an old type pointer
  address that no longer exists causing abends in the heap memory
  manager.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: Users that have long-running transactions    *
  *                 that load and unload the EGL runtime over    *
  *                 and over.                                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: The ELACOMB and ELACOMC modules         *
  *                      were saving the type pointer address    *
  *                      for an exception string in the working  *
  *                      storage of the program. Normally, this  *
  *                      would be fine, but when a new EGL       *
  *                      runtime got loaded, this saved          *
  *                      address became invalid.  This           *
  *                      now-invalid address was then            *
  *                      assigned to a heap memory string        *
  *                      variable for the exception record and   *
  *                      when garbage collection was run at      *
  *                      a later time, an 0C4 would occur due    *
  *                      to the invalid reference.               *
  ****************************************************************
  * RECOMMENDATION: Apply this maintenance.                      *
  ****************************************************************
  The ELACOMB and ELACOMC modules were saving the type pointer
  address for an exception string in the working storage of the
  program. Normally, this would be fine, but when a new EGL
  runtime got loaded, this saved address became invalid.  This
  now-invalid address was then assigned to a heap memory string
  variable for the exception record and when garbage collection
  was run at a later time, an 0C4 would occur due to the invalid
  reference.
  

Problem conclusion

• The modules no longer keep the pointer, but instead look it up
  each time. The overhead of this is minimal, but it ensures that
  the pointer address if always valid.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  PI52971

Modules/Macros

• ELACOMB  ELACOMC
  

Fix information

• Fixed component name

  RATL COBOL RT Z

• Fixed component ID

  5655R2900

Applicable component levels

• R601 PSY UI33732

     UP15/12/15 P F512

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.