PH48657: IBM MQ Z/OS: THE CSQJ370I MESSAGE SOMETIMES HAS AN UNEXPECTED ZHYPERWRITE STATUS OF NO FOR AN ACTIVE LOG

APAR status

• Closed as program error.

Error description

• During some runs of the queue manager, active logs have an
  unexpected status of NO for the zHyperWrite status:
  
  CSQJ370I  LOG status report ...
  Copy %Full zHyperWrite Encrypted DSName
   1     77  NO          NO        hlq.ACTLG1.DS01
   2     77  NO          NO        hlq.ACTLG1.DS02
  
  Other runs of the queue manager might show the log as CAPABLE:
  
  CSQJ370I  LOG status report ...
  Copy %Full zHyperWrite Encrypted DSName
   1     1   CAPABLE     NO        hlq.ACTLG1.DS01
   2     1   CAPABLE     NO        hlq.ACTLG1.DS02
  
  or with a mixture:
  
  Copy %Full zHyperWrite Encrypted DSName
  1      43  NO          NO        hlq.ACTLG1.DS01
  1      43  CAPABLE     NO        hlq.ACTLG1.DS02
  
  MQ determines the zHyperWrite status as Media Manager
  connections are made to each log.  The check of the zHyperWrite
  status occurs only one time during the run of the queue
  manager, so if there is a change from the original status, MQ
  is not aware of it.
  
  MQ only uses a mirroring option for the log write if:
  1) the zHyperWrite status is CAPABLE
  2) the MQ ZHYWRITE parameter is set to YES in CSQ6LOGP or by
  using the SET LOG command
  
  Db2 has some differences in the way it handles the zHyperWrite
  status, so this APAR is to investigate changes to MQ to ensure
  zHyperWrite is used more consistently.
  .
  Additional symptoms and keywords:
  The message
    CSQJ166E zHyperWrite configuration is inconsistent
  for active log copy <number>
  is sometimes seen even though all the logs are configured for
  zhyperwrite.
  

Local fix

• For GDPS be sure you see messages such as these in the GDPS
  NETLOG before you start MQ:
  GEO550I HYPERSWAP PREPARED
  GEO071I GDPS Initialization Successful
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 2 Modification 0 and                 *
  *                 Release 3 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: With zHyperwrite enabled the message    *
  *                      CSQJ370I indicated that zHyperWrite     *
  *                      state as 'NO' instead of the expected   *
  *                      value of 'CAPABLE'.                     *
  ****************************************************************
  MQ determines zHyperWrite status when Media Manager connections
  are made for each log. This check only occurs once during the
  lifetime of the Queue manager so if the status changes then MQ
  will be unaware of this change.
  
  There exists a timing window in Media Manger where the
  zHyperWrite state is not correct and if MQ reads this value then
  the incorrect zHyperWrite state can be reflected in the CSQJ370I
  message.
  

Problem conclusion

• An optional MQ service parameter has been added to allow MQ to
  avoid the timing window in the Media Manager code by always
  indicating to Media Manager that zHyperwrite is in use for each
  log, whether zHyperwrite has been enabled or not. The CSQJ370I
  message may still incorrectly display the zHyperWrite state for
  a log.
  
  Please contact IBM support to enable this function.
  

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:

  UI91940 UI91941

Modules/Macros

• CSQJW107
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels