How a compression dictionary is selected with LEVEL(IMAGCOPY) parameter?

Products

• CA Fast Recover for DB2 for z/OS
• CA Log Analyzer for DB2 for z/OS
• CA Quick Copy for DB2 for z/OS
• CA Database Management for DB2 for z/OS - Recovery Suite
• CA Merge/Modify for DB2 for z/OS
• CA Recovery Analyzer for DB2 for z/OS
• CA Log Analyzer SMF Audit Trace Option
• CA MM Backup and Recovery for DB2

Issue/Introduction

When a table is defined with COMPRESS YES then the record in the DB2 log has to be rebuilt and Log Analyzer needs to take the compression dictionary from the last Image Copy to rebuild the row.

What about the result if the compression dictionary was changed between last Image Copy and the time the DB2 log record was created?. 

Environment

Release : 20.0

Component : CA Log Analyzer for DB2 for z/OS

Resolution

In order to decompress data, a compression dictionary is required every time. Log Analyzer has sophisticated logic to detect and pick correct compression dictionary for the data it is processing. Moreover there is a way to force use of specific dictionary in case of problems. In general there are 3 possible sources, where the program looks for a dictionary: DB2 log, tablespace (or partition) VSAM dataset or an image copy. Obviously when the dictionary changes, VSAM is not usable source anymore.
 
If we are to decompress incomplete update log record, we need to complete it first. This is because compression essentially replaces character strings with shorter tokens. DB2 logging does not care about nature of data and simply starts writing the first changed byte up to the last changed one. Therefore it is almost certain, that the first changed byte is not the first byte of a token and decompression would necessarily fail. Log Analyzer does not allow it to fail and does not attempt to decompress data in such case.
 
So in your case the incomplete update log records were reconstructed from full row images taken either from the tablespace VSAM file or from an image copy and the dictionary was taken most likely from the same source. Please note, there is relatively new control card PURSRC, which allows some control over the process, but we expect most users would be using PURSRC(AUTO), which lets the program to choose the best source.
  
You can read more details about PURSRC parameter in the following Log Analyzer doc:
 
Partial Update Reconstruction
 
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/database-management/ca-log-analyzer-for-db2-for-z-os/20-0/using/log-processing/partial-update-reconstruction.html