PH62378: IBM MQ Z/OS: THERE IS A DELAY OF SEVERAL SECONDS IN RESTARTING SHARED SENDER CHANNELS

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Shared sender channels are running in a Queue Sharing Group
  QSG1. The channels are connected from queue manager Q1. When
  Q1 ends, the channels are taken over by another queue manager
  Q2, but it takes around 7 seconds even with PH35786 applied.
  Several seconds is considered to be too long for some types of
  business logic.
  
  As mentioned in PH35786: As part of STOP CHINIT processing, all
  active channels are stopped before shared channel recovery
  begins. This means that channels stopping slowly can result in
  a delay in shared channel recovery being initiated.
  
  Message CSQM052I "CSQMPCRT Shared channel recovery completed"
  in the MSTR job log indicates when shared channel recovery
  completes.
  
  A joblog showed that a 5-second gap accounted for a large
  portion of the time gap.  In module CSQXRSAC, there is a loop
  of up to 5 1-second waits during channel stop processing.
  
  This APAR is to investigate options to reduce that gap.
  

Local fix

• One option to test is to issue an MVS CANCEL command (not
  FORCE) against the CHIN address space. This might terminate the
  address space more quickly, but some channels might need to do
  additional work to resolve any inconsistencies when they
  restart.
  

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: Shared sender channels can take up to   *
  *                      and around 7 seconds to restart on      *
  *                      another Queue Manager in the same Queue *
  *                      Sharing Group.                          *
  ****************************************************************
  After a 'STOP CHINIT' command is issued Peer Channel Recovery
  only starts after all channels on the Queue Manager have failed.
  This included all private channels. This can delay the shared
  channel from restarting on another Queue Manager in the same
  Queue Sharing Group for up to 7 seconds if other private
  channels such as Sever Connection Channels are taking a long
  time to stop.
  

Problem conclusion

• The code has been changed so that after a 'STOP CHINIT' command
  is issued Peer Channel Recovery will start as soon as all
  eligible shared channels have stopped.
  

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:

  UI98959 UI98960 UI98961

Modules/Macros

• CSQXRSAC CSQXSPRT
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R200 PSY UI98961

     UP24/11/16 P F411

• R300 PSY UI98960

     UP24/11/16 P F411

• R400 PSY UI98959

     UP24/11/16 P F411

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.