PI85387: THE STOPQ SIGNAL CAUSING ALL QUEUES TO BECOME INACTIVE IS REPROCESSED WHEN A STARTQ SIGNAL IS LATER ISSUED.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• When a STOPQ is issued and all queues become inactive, a STARTQ
  command or signal causes the STOPQ to be re-read from the log,
  and re-processed.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: 1- Q Apply                                   *
  *                 2- Q Capture                                 *
  *                 3- SQL Apply users                           *
  *                 4- Fidelity                                  *
  *                 5- All Q Capture customers.                  *
  *                 6- SQL Apply users                           *
  ****************************************************************
  * PROBLEM DESCRIPTION: 1- Q Apply program should stop if an    *
  *                      agent encounters a DB2 abend when       *
  *                      applying replicated changes to a        *
  *                      target, even when TERM=N setting is     *
  *                      used. However, under certain            *
  *                      conditions, Q Apply program may         *
  *                      continue processing after a DB2 abend   *
  *                      eventually leading to a crash.          *
  *                      2- When a STOPQ is issued and all       *
  *                      queues become inactive, a STARTQ        *
  *                      command or signal causes the STOPQ to   *
  *                      be re-read from the log, and            *
  *                      re-processed.                           *
  *                      3- The Apply program in SQL             *
  *                      Replication can incorrectly deactivate  *
  *                      subscription sets when an SQL error     *
  *                      occurs at the source server while it    *
  *                      is attempting to access the             *
  *                      IBMSNAP_CAPPARMS table.                 *
  *                      4- customer encountered an error with   *
  *                      a queue that terminated with error      *
  *                      code "602".                             *
  *                      5- Q Capture does not display ASN7227I  *
  *                      if it receives 'STOPQ=                  *
  *                      STOPAFTER=DATA_APPLIED' command for     *
  *                      one send queue followed by a 'STARTQ='  *
  *                      command for a different send queue.     *
  *                      6- SQL Apply did not fullrefresh        *
  *                      complete CCD table correctly when       *
  *                      using ASNLOAD                           *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  1- Q Apply program may not stop when an agent encounters a DB2
  abend and TERM=N setting is used. This could further lead to Q
  Apply crash.
  2- The logic to keep track of processed signals is incorrect.
  3- Apply should not deactivate a subscription when it
  encounters an SQL error at the source server.
  4- the subscription points to a non-existent table on the
  target side, but apply doesn't output a corresponding error
  message when describing the non-existent table failed.
  5- Q Capture deactivates and then activates all Q subscriptions
  after a STARTQ command. Q Capture does not save the
  STOPAFTER=DATA_APPLIED information for send queues before it
  reinitializes.
  6- In SQL Apply V10.2.1, the IBMSNAP_COMMITSEQ and
  IBMSNAP_INTENTSEQ columns are defined as VARCHAR(16). But they
  still initialized with 10 byte values when fullrefreshed by
  ASNLOAD user exit.
  

Problem conclusion

• 1- Q Apply is fixed to stop when a Q Apply agent gets a DB2
  abend.
  2- The STOPQ is not re-processed from the log.
  3- The Apply program is changed not to deactivate a
  subscription when an SQL error occurs at the source server. It
  will only terminate the current subscription cycle and try
  again later.
  4- With this fix, apply will output ASN7645E message after
  apply fails to describe the non-existent table.
  5- Q Capture has been changed to save STOPAFTER=DATA_APPLIED
  information for send queues before it reinitializes so that it
  can restore the send queue information after reinitialization
  completes.
  6- ASNLOAD is changed to check for COMPATIBILITY level of the
  source server and use 16 bytes values for the IBMSNAP_COMMITSEQ
  and IBMSNAP_INTENTSEQ columns if COMPATIBILITY=1001 or 1021.
  Note: ASNCLP has been updated from db2_v105fp9 n170829.
  

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:

  UI50186 UI50187 UI50188 UI50189

Modules/Macros

•    ASNACMD  ASNADMSP ASNAPPLY ASNAPRS  ASNCAP
  ASNCCMD  ASNCLPAP ASNCLPCL ASNCLPCM ASNCLPCO ASNCLPMS ASNCLPQA
  ASNLOAD  ASNMCMD  ASNMON   ASNQACMD ASNQAPP  ASNQASUB ASNQBRWZ
  ASNQCAP  ASNQCCMD ASNQDEP  ASNQEXRP ASNQMFMT ASNQNMIH ASNQXFMT
  ASNRBASE ASNTDIFF ASNTDSP  ASNTRC   ASN2BASE
  

Fix information

• Fixed component name

  WS REPLICATION

• Fixed component ID

  5655L8800

Applicable component levels

• RA21 PSY UI50186

     UP17/09/17 P F709

• RA24 PSY UI50187

     UP17/09/17 P F709

• RA25 PSY UI50188

     UP17/09/17 P F709

• RA26 PSY UI50189

     UP17/09/17 P F709

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.