PH64697: MQ Z/OS: RFH2 HEADER IS NOT REMOVED WITH PROPCTL(NONE) DUE TO A DATA CONVERSION FAILURE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The reported situation involves an MQRFH2 header being
  added to a message during tracing by the Instana and zAPM
  (IBM Z Application Performance Management) products. See
  www.ibm.com/docs/en/iooz?topic=producer-tracking-mq-cics .
  The APAR could apply to other situations.
  
  The RFH2 header is normally removed by the time the
  message reaches the application.  However, in this case, it
  is not removed due to a data conversion error. The application
  does not expect the RFH2 header so does not know what to do with
  it.
  
  This APAR is raised for an update to the code to attempt
  another data conversion option so that the RFH2 can be
  removed as expected.
  
  
  Additional details:
  
  GTF Trace shows a message being put to a queue with an EBCDIC
  MQRFH2. The MQRFH2 has a single folder that contains a
  <usr><singularityheader> property. The MQRFH2 is then followed
  by EBCDIC string data.
  
  When the message is put, CSQMCHKM calls a function to parse the
  MQRFH2 and extract any properties. The trace shows the
  <usr><singularityheader> property being extracted successfully
  and the folder being removed. The logic subsequently detects
  that all of the folders in the MQRFH2 have been removed so
  attempts to remove the header completely.
  
  To remove the MQRFH2 header, the header chaining fields
  CodedCharSetId/CCSID, Encoding, and Format must be inserted
  into the previous header. The MQRFH2 is the first (and only)
  header in the message body, so the header chaining fields need
  to be inserted in the MQMD. Inserting the numerical
  CodedCharSetId and Encoding worked fine, as both the MQMD and
  the message MQRFH2 are big-endian, so a direct insertion
  without byte swapping was possible. However, to insert the
  Format, the field must be converted from the CCSID of the
  MQRFH2 to the CCSID of the MQMD. The MQMD is always in the QMGR
  CCSID, which in this case is 1399 while the MQRFH2 was in
  CCSID 500.
  
  The problem is that there is no conversion table from CCSID
  1399 to 500, so the conversion fails internally with internal
  reason codes CSQA_INCOMPATIBLE_CCSIDS (00C10016) from CSQALOCT
  and CSQA_CONV_NOT_SUP (00C10011) from CSQACS64. zrfParse
  responds to this conversion failure by leaving the (empty)
  MQRFH2 at the head of the message. When the application later
  gets the message, the MQRFH2 is left at the head of the message
  irrespective of the property control options (either in the
  MQGMO Options or in the queue PROPCTL parameter).
  
  The Format field value in the MQRFH2 that zrfParse is trying to
  insert into the MQMD is "MQSTR   ". CCSIDs 1399 and 500 are
  both EBCDIC-type CCSIDs and all of the characters in "MQSTR   "
  are part of the invariant subset of EBCDIC so no actual
  conversion is required to "convert" the field from CCSID 1399
  to 500.
  
  There is an internal mechanism for requesting that invariant
  conversion be attempted regardless of whether there is a full
  conversion table available. The code in zrfParse should make
  use of this functionality.
  
  Even with the APAR fix, it is not guaranteed that conversion
  from 1399 to 500 will always be possible as it depends on the
  contents of the field being converted. However, it will be
  sufficient for the use-case of converting MQ format fields.
  
  
  Additional keywords and symptoms:
  APM Connect z/APM
  Instana Observability
  CICS
  

Local fix

• N/A
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 2 Modification 0,                    *
  *                 Release 3 Modification 0, and                *
  *                 Release 4 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: A data conversion error from CCSID 1399 *
  *                      to 500 results in RFH2 headers not      *
  *                      being removed when PROPCTL(NONE) is     *
  *                      set on a queue                          *
  ****************************************************************
  When PROPCTL(NONE) is set, the RFH2 header is normally removed
  by the time the message reaches the application.  However, in
  this case, it is not removed due to a data conversion error.
  The application does not expect the RFH2 header so does not know
  what to do with it.
  

Problem conclusion

• The code has been updated to attempt another data conversion
  option so that the RFH2 can be removed as expected.
  

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:

  UO03940 UO03941 UO03942

Modules/Macros

• CMQZRFPA
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R200 PSY UO03942

     UP25/07/12 P F507

• R300 PSY UO03941

     UP25/07/12 P F507

• R400 PSY UO03940

     UP25/07/12 P F507

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.