PH13862: CSQX456I & CSQX469E IN FULL REPOSITORY CHIN JOB LOG WHEN CLUSTER TRANSMISSION QUEUE HAS CUSTOM CAPEXPRY SET.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The following error message is a sample recorded in the CHIN
  job log of full repository:
  
  CSQX469E MQA2 CSQXREPO Update not received for CLUSRCVR channel
  MQ.CLUS1.TO.MQA1 hosted on queue manager MQA1.XXXXXXXXXXXXXXXX
  in  cluster MQ.CLUS1, expected 9 days ago, 53 days remaining
  
  CSQX456I MQA2 CSQXREPO Full repository update not received,
   cluster MQ.CLUS1
   queue MQ.LOCALQ1
   (queue manager MQA1.XXXXXXXXXXXXXXXX)
  ----------------------------------------------------------------
  
  The above error message would be seen when the cluster
  transmission queue is configured with a custom expiration time
  using CUSTOM(CAPEXPRY(n)).
  
  This setting causes the expiry time on the cluster update
  messages to be reduced to n/10 seconds, which in turn means
  that the object on the full repository has its expiry set to
  n/10 seconds.
  Once n/10 seconds have passed, the full repository thinks it is
  overdue an update for the object, so starts issuing the
  

Local fix

• Remove the custom CAPEXPRY from the
  SYSTEM.CLUSTER.TRANSMIT.QUEUE.
  Then republish the problem cluster object by altering object
  description or REFRESH CLUSTER on partial repositories.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 0 Modification 0 and Release 1       *
  *                 Modification 0.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: CSQX456I and CSQX469E are issued during *
  *                      cluster maintenance when CAPEXPRY is    *
  *                      set on the cluster transmit queue of    *
  *                      one or more queue managers in a         *
  *                      cluster.                                *
  ****************************************************************
  When a queue manager receives information about cluster objects,
  the expiry date is calculated based on the remaining expiry
  interval of the control message.
  If the sending queue manager had CAPEXPRY set on the cluster
  transmit queue, the expiry can be unexpectedly reduced,
  resulting in cluster objects expiring prematurely.
  During cluster maintenance the unexpectedly reduced expiry
  causes inconsistencies to be detected, resulting in messages
  including CSQX456I or CSQX469E being issued to report the
  unexpected state.
  

Problem conclusion

• CSQMPUTI is changed to prevent CAPEXPRY overriding the expiry
  interval for cluster control messages put by the repository
  task.
  

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:

  UI67274 UI67275

Modules/Macros

• CSQMPUTI
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R000 PSY UI67274

     UP20/01/25 P F001

• R100 PSY UI67275

     UP20/01/25 P F001

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.