JR62160: LOG PARSER CANNOT PARSE A DML AFTER A DDL EVEN AFTER UPDATING THE TABLE DEFINITION AND REFRESHING THE TABLE

APAR status

• Closed as program error.

Error description

• The problem occurs when parsing a DML after a DDL and the
  subscription is using shared scrape. The user updated the table
  definition, but the parser in-memory cache was not reloaded so
  the shared scrape parser did not see the new table definition.
  Currently, it only reloads this cache from disk when the parser
  starts again after stopping. When the problem occurs, the user
  will get the following "unparsable operation" error on a DML
  operation even after updating the table definition and
  refreshing the table
  
  An exception has occurred in the log parser.
  IBM Data Replication Db2 for z/OS Remote Source was processing
  an insert at position XXX for table <tablename> with obid X,
  dbid Y, psid Z, and noticed that the insert log record is
  associated with the table <tablename> as of version number
  <newerversion>. The latest structure (in CDC table history
  metadata) of table <tablename> is version <olderversion>. This
  is likely due to a DDL executed on the table <tablename> at some
  point in the past with data found in the insert as having been
  added to the table prior to the DDL.
  

Local fix

• Stop all subscriptions using the shared scrape staging store
  then clear the staging store. This forces the shared scrape log
  parser to stop. OR: Stop the instance. OR: Stop all
  subscriptions and wait 10 minutes for the shared scrape log
  parser to stop. OR:Drop and re-add the table mapping for the
  table
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * This issue may affect you if you are using CDC Db2 for z/OS  *
  * remote source and a table being replicated is structurally   *
  * altered with DDL, followed by changes to rows with DML.      *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * LOG PARSER CANNOT PARSE A DML AFTER A DDL EVEN AFTER         *
  * UPDATING THE TABLE DEFINITION AND REFRESHING THE TABLE       *
  *                                                              *
  * MORE DETAILS:                                                *
  * The problem occurs when parsing a DML after a DDL and the    *
  * subscription is using shared scrape. The user updated the    *
  * table definition, but the parser in-memory cache was not     *
  * reloaded so the shared scrape parser did not see the new     *
  * table definition.                                            *
  * Currently, it only reloads this cache from disk when the     *
  * parser starts again after stopping. When the problem occurs, *
  * the user                                                     *
  * will get the following "unparsable operation" error on a DML *
  * operation even after updating the table definition and       *
  * refreshing the table                                         *
  *                                                              *
  * An exception has occurred in the log parser.                 *
  * IBM Data Replication Db2 for z/OS Remote Source was          *
  * processing an insert at position XXX for table <tablename>   *
  * with obid X,                                                 *
  * dbid Y, psid Z, and noticed that the insert log record is    *
  * associated with the table <tablename> as of version number   *
  * <newerversion>. The latest structure (in CDC table history   *
  * metadata) of table <tablename> is version <olderversion>.    *
  * This                                                         *
  * is likely due to a DDL executed on the table <tablename> at  *
  * some point in the past with data found in the insert as      *
  * having been                                                  *
  * added to the table prior to the DDL.                         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  

Problem conclusion

• Upgrading to IDR 11.4.0.2-5560 for Db2 for z/OS remote source
  resolves the issue.
  

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:

Fix information

• Fixed component name

  IDR DB2ZOS REMS

• Fixed component ID

  5737C30DR

Applicable component levels