PM75119: ARCH LEVEL 1001 SUPPORT

Obtain the fix for this APAR.

APAR status

• Closed as new function.

Error description

• arch level 1001 support.
  This APAR introduces a new ARCH_LEVEL 1001 for Qcapture,
  Qapply, SQL Capture and SQL Apply.
  It also introduces COMPATIBILITY of 1001 for Q Capture.  You
  need to run the migration job for Q (ASNQ1001) and for
  SQL(ASNS1001) to migrate to 1001 level.  There will be new
  samples for the migration and a new message file.
  This APAR also contains the V10 FP2 level of ASNCLP for z/OS.
  You must use the new asnclp if you want to use the new asnclp
  functions shipped in this APAR.
  New function:
  1. Q Replication parallel send queues option Scenario:  High
  rate of small transactions and QMGR (transmission queue) at
  source becomes a bottleneck and slows down Q Capture.  Q Apply
  is not kept busy and end-end latency dramatically increases.
  Please take a look at these values in replication control tables
  to see if this option might help your situation.:
  a. Growing transmission queue depth at Q Capture side reported
  in IBMQREP_CAPQMON XMITQDEPTH value (added in this APAR)
  b. High MQPUT_TIME relative to the MQ_MESSAGES as reported in
  IBMQREP_CAPQMON for that queue
  c. Growing QLATENCY, but low QDEPTH in IBMQREP_APPLYMON for that
  queue Solution:  Use NUM_PARALLEL_SENDQS > 1 in
  IBMQREP_SENDQUEUES table and IBMQREP_RECVQUEUES
  PARALLEL_SENDQS='Y' to assign multiple send queues to a single
  receive queue.  Multiple transmission queues and sender channels
  are defined for a replication queue map, allowing the source
  QMGR to keep up with the transaction rate.  This option is valid
  for z/OS only.  Replication APAR PM75119 and MQ V7 with APAR
  PM63802 are required.  Please see the updated sample
  SANSAMP(ASNQDEFQ) for sample queue definitions for parallel send
  queues option.
  More information can be found at: https://ibm.biz/BdxMw2
  2. New Conflict_rule support Uni-directional replication
  Scenario:  User defines bidirectional replication between two
  sites and relies on a pair of unidirectional Q subscriptions to
  avoid the limitation of the Q Replication bidirectional
  subscription (for example, different table structures between
  the two sites).  However, the user also needs the more generic
  conflict rules of 'C' or 'A' available with bidirectional Q
  subscriptions to detect changes to non-key columns.  Solution:
  Allow unidirectional Q subscriptions to use conflict rules 'C'
  (all key columns plus any changed non-key columns) and 'A' (all
  columns) when detecting conflict.  The existing behavior for
  unidirectional Q subscriptions is to only support the 'K' or key
  columns only rule when detecting conflicts.
  More information can be found here:
  https://ibm.biz/BdxMwq
  And this APAR also delivers ASNCLP V10 FP2 function.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: 1- SQL Capture users wanting to migrate      *
  *                 restart information when migrating DB2 to    *
  *                 data sharing                                 *
  *                 2- Q Capture environments where a single MQ  *
  *                 channel can become a bottleneck              *
  *                 3- Capture/Apply                             *
  *                 4- SQL Capture customers.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: 1- asnplxfy did not accept the second   *
  *                      parameter which specifies SQL Capture   *
  *                      schema                                  *
  *                      2- For some replicated workloads, a     *
  *                      very high message rate of small         *
  *                      messages can create a bottleneck at     *
  *                      the MQ sender channel                   *
  *                      3- Abnormal values > 2000000000 in the  *
  *                      CAPMON counters                         *
  *                      4-  SQL Capture started specifying      *
  *                      STOP_ON_ERROR = 'N' terminates with     *
  *                      ABENDS0C4 after displaying ASN0011E.    *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  1- The second argument to the program (if provided) is now
  accepted as schema of SQL Capture
  2- Q Replication engine can use multiple send queues in
  parallel to transmit messages to Q Apply in parallel and
  overcome the MQ channel bottleneck
  3- The monitoring statistics might overflow and report the
  wrong value.
  4-  SQL Capture stops a source table registration and removes
  the registration information from its memory if it was started
  specifying STOP_ON_ERROR = 'N' and the DB2 compression
  dictionary for the source table no longer exists.  SQL Capture
  terminates with ABENDS0C4 when it references the source table
  registration information it has removed.
  

Problem conclusion

Temporary fix

Comments

• 1- The problem is resolved
  2- Refer to documentation about how to utilize parallel send
  queues
  3- Tolerate the overflow and report the correct statistics.
  4-  Modify SQL Capture to fix this problem.
  ------------------------------------------
  IMPORTANT NOTICE FOR QCAPTURE customers.
  
  You must start Qcapture with LSN= option or OVERRIDE_RESTARTQ=Y
  option when you start QCapture with ARCH_LEVEL='1001', because
  the message format level changes.
  Example:
     // PARM='CAPTURE_SERVER=DSN!! capture_schema=!CSH
     // OVERRIDE_RESTARTQ=Y'
  -- or --
     // PARM='CAPTURE_SERVER=DSN!! capture_schema=!CSH'
     //SYSIN DD *
     LSN=0000:XXXX:XXXX:XXXX:XXXX
     MAXCMTSEQ=0000:XXXX:XXXX:XXXX:XXXX
     /*
  where 0000:XXXX:XXXX:XXXX:XXXX is the LSN value provided by the
  Q Capture program message ASN7901I when it previously stopped.
  If you use OVERRIDE_RESTARTQ=Y, you must first delete the
  message from the MQ restart queue.  This level of Q Capture can
  not read any MQ message from pre-PM75119 APAR levels.
  
  
  ž**** PE13/03/06 FIX IN ERROR. SEE APAR PM82917  FOR DESCRIPTION
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UK91008 UK91009 UK91010 UK91011

Modules/Macros

• ASNAAPP  ASNACMD  ASNACMP  ASNADMSP ASNAFET
  ASNAISO  ASNAMAN  ASNAPPLY ASNAPRS  ASNAWPN  ASNCAP   ASNCCMD
  ASNCCPWK ASNCDINS ASNCLP   ASNCLPAP ASNCLPCL ASNCLPCO ASNCLPCT
  ASNCLPMS ASNCLPQA ASNCSCZ  ASNCTLZD ASNDADK  ASNDBCON ASNDB2CN
  ASNDB2SQ ASNDEDE  ASNENUP  ASNENUS  ASNESES  ASNFIFI  ASNFRFR
  ASNITIT  ASNJAJP  ASNKOKR  ASNLOAD  ASNMCMD  ASNMDATA ASNMIG8
  ASNMON   ASNMONIT ASNMPROC ASNMUPDT ASNNONO  ASNPLPL  ASNPLXFY
  ASNPRUNE ASNPTBR  ASNQACMD ASNQAHKT ASNQAPAG ASNQAPP  ASNQAROW
  ASNQASUB ASNQBRWZ ASNQCAP  ASNQCCMD ASNQCTLZ ASNQDEFQ ASNQDEP
  ASNQEXRP ASNQLODZ ASNQMFMT ASNQMZ10 ASNQP2PA ASNQP2PI ASNQSPIL
  ASNQXFMT ASNQ1001 ASNRBASE ASNRURU  ASNSMZ10 ASNSQLCZ ASNSTRM
  ASNSVSE  ASNS1001 ASNTDIFF ASNTDSP  ASNTDSQL ASNTRC   ASNUOW
  ASNZHCN  ASNZHTW  ASNZOSCN ASN2BASE ASN2DBCN ASN2DB2C ASN2DB2Q
  ASN2SQLZ ASN2ZOSC
  

Fix information

• Fixed component name

  WS REPLICATION

• Fixed component ID

  5655L8800

Applicable component levels

• RA10 PSY UK91008

     UP13/01/26 P F301

• RA11 PSY UK91009

     UP13/01/29 P F301

• RA12 PSY UK91010

     UP13/01/29 P F301

• RA13 PSY UK91011

     UP13/01/26 P F301

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.