PH38249: AbendAXG4 when making a DPL with a commarea greater than 24K

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• After converting regions from CICS 5.4 to CICS 5.6 the following
  message started coming out.
  
  DFHDU0203I 06/01/2021 11:16:37 regnname A transaction dump was
  taken for dumpcode: AXG4, Dumpid: 1/0003, Tranid: xxxx, Tranum:
  nnnnn, Program: DFHMIRS.
  
  The AXG4 abend is happening in the DFHXFP Transformer 4 code on
  the return of a DPL request when the COMMAREA is > 24 k.
  Here's what it looks like in CICS Internal Trace.
  
  PG 1700 PGCH  ENTRY INQUIRE_CHANNEL       DFHTRANSACTION
  
  PG 1701 PGCH  EXIT  INQUIRE_CHANNEL/OK    3211D030,3211F030
  
  AP 4E16 APCR  EVENT Extract_container_header DFHCOMMAREA
  
  
  AP 4E17 APCR  EVENT Extract_container_length 29768
  
  AP 4E18 APCR  EVENT Extract_container_data
  
  PG 1900 PGCR  ENTRY PUT_CONTAINER
  3211F030,DFHCOMMAREA,IMPORTED,CICS,ANY,BIT,NO,REPLACE,329BC070
  
  PG 1901 PGCR  EXIT  PUT_CONTAINER/OK      2,1
  
  AP 4E01 APCR  EXIT  IMPORT_CHANGED/OK
  0,0,,00000000,749D,YES,3211F030
  
  PG 1900 PGCR  ENTRY GET_CONTAINER_INTO
  3211F030,DFHCOMMAREA,CICS,3297D018 , 00000000 , 00000050
  
  PG 1901 PGCR  EXIT  GET_CONTAINER_INTO/EXCEPTION
  MORE_DATA,3297D018 , 00000050 , 00000050
  
  PG 0500 PGIS  ENTRY INQUIRE_CURRENT_PROGRAM
  .
  An incorrect length of x'50' is being used in the  PGCR
  GET_CONTAINER_INTO request rather than the COMMAREA length that
  is >24K. The use of the much shorter length produces the
  EXCEPTION response of MORE_DATA.
  
  The incorrect length is obtained from DFHXFP's LIFO stack but
  this was set up in Transformer 1. and is not successfully
  reinitialised when calling DFHXFP again for Transformer 4
  processing. Depending on the sequence of events between the two
  calls to DFHXFP, Transformer 4 may use incorrect data that has
  been updated by other users of the stack storage since the
  Transformer 1 call.
  
  
  Additional Symptom(s) Search Keyword(s):
  

Local fix

• n/a
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: Transaction abend AXG4 when processing  *
  *                      an EXEC CICS LINK request with          *
  *                      COMMAREA LENGTH at least 24K.           *
  ****************************************************************
  An EXEC CICS LINK request to a remote program, over an MRO
  CONNECTION, specifies a COMMAREA LENGTH of at least 24K.
  This COMMAREA is shipped using a DFHCOMMAREA container in the
  DFHTRANSACTION channel. On return to the originating region,
  CICS issues a DFHPGCRM GET_CONTAINER_INTO request to obtain the
  COMMAREA data. However, the length used on this request is not
  initialised correctly. If it is less than the actual length, an
  exception response of PGCR_MORE_DATA is returned and transaction
  abend AXG4 is issued.
  

Problem conclusion

• CICS is changed to use the correct length on the
  DFHPGCRM GET_CONTAINER_INTO call when obtaining the commarea
  from the DFHCOMMAREA container.
  

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:

  UI76524

Modules/Macros

• DFHXFP   DFHXFQ
  

Fix information

• Fixed component name

  CICS TS Z/OS V5

• Fixed component ID

  5655Y0400

Applicable component levels

• R300 PSY UI76524

     UP21/09/01 P F108

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.