PM26164: EGL COBOL support reinitializes HostVariables between calls which causes an application error

APAR status

• Closed as program error.

Error description

• Rational Business Developer V7.5.1.6:
  
  The EGL COBOL support reinitializes HostVariables between calls
  which causes an application error.
  
  The following is an example of a scenario which causes this
  problem:
  
  - Program PROG1 is generated from EGL and calls PROG2
  - Program PROG2 is generated from EGL and it calls PROG3
  - Program PROG3 is generated from EGL and it calls PROG4
  - Program PROG4 is generated by VisualAge Generator and it reads
    data from a database
  
  The first time that program PROG3 calls program PROG4, it is
  using a working storage record called WSRECP0 where the field
  FIELD1 is equal 4.  Program PROG4 tries to read data from the
  database and gets sqlcode = 100.  This means there is no data.
  When program PROG3 is called again, the field FIELD1 is still
  equal 4.
  
  The second time that the program PROG3 calls program PROG4,
  using a working storage record called WSRECP0, where the field
  FIELD1 is equal 4.  Program PROG4 tries to read data from the
  database and gets sqlcode = 0.  This means there is data and
  that data is received into the record called WSRECIN.  When
  program PROG3 is called again, the field FIELD1 is NOT equal to
  4.  It is equal to 0.  This causes an application error in the
  map managed by program PROG1.
  
  If program PROG3 is generated by VisualAge Generator, this
  problem does not occur.  The field FIELD1 is always equal 4.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The problem was caused because EGL requires two pieces of
  information to determine the cursor and the correct
  record/fields that are to be updated, when a generic get
  next is done, without a result set id. The 2nd piece of
  information is new for EGL, and was being stored in
  working-storage, instead of a maintained piece of memory.
  The problem was that the user's application would call a
  particular called program once, to open the cursor and then
  return from the called program. Later on, this same called
  program would be called to read the records based on the
  previous open. The 2nd piece of information was lost across
  the calls, which made the logic not be able to determine
  what records/fields to update.
  

Problem conclusion

• The solution was to simply place this 2nd piece of
  information in an EGL-maintained piece of memory.
  

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:

Fix information

• Fixed component name

  RBD EGL FOR COB

• Fixed component ID

  5724S5001

Applicable component levels

• R751 PSN

     UP