When comparing a DDL input file to a subsystem, unexpected results are being generated, detecting changes between the source and target objects, that cannot be explained.
The changes do not reflect the attributes of the objects contained in the DDL file.
This results in DDL being generated by the Analysis to perform the false changes.
The 'DB2 COMPARE FACILITY CHANGE ANALYSIS REPORT' section of the Analysis Report will also report these false changes.
This is a DDL to ssid comparison and the user was not creating a new strategy for each new DDL input file.
For compare strategies that involve DDL files, RC/Compare maps objects that are contained in the input file when the strategy is created.
This mapping is retained as part of the strategy definition. RC/Compare does not refresh the strategy based on the current contents of the DDL file when an
analysis is performed. Therefore this type of strategy can not be used repeatedly if the content of the input file is changed.
In this scenario, a new strategy must be created, each time the content of the DDLIN input file is changed.
If the requirement is to regularly compare the input file to a subsystem(s), after amending the content of the input file, then we would recommend using
the Batch Compare Facility. This will create a new strategy (replacing the old) each time it is executed, comparing the latest input DDLFILE to your subsystem.
We can compare the source DDLFILE to either a target subsystem, or to a target DDLFILE.
So one approach could be to create a DDLFILE for the production subsystem and a DDLFILE for the test subsystem. The Batch Compare Facility can
then be used to create an Automap compare strategy, comparing these two files. Analysis can then be performed against this new strategy.