A DDL to DDL RC/Migrator compare strategy is created and SRCSSID in Strategy Services is blank
search cancel

A DDL to DDL RC/Migrator compare strategy is created and SRCSSID in Strategy Services is blank


Article ID: 228308


Updated On:


RC/Migrator for DB2 for z/OS RC Compare for DB2 for z/OS


A RC/Migrator for Db2 for z/OS (RCM) DDL to DDL compare strategy is created; SRCSSID in Strategy Services is blank.

The analysis produced a DDL script with an empty .CONNECT.
The analysis execution using Batch Processor created a job with a .CONNECT ssid control card.

Since both inputs are DDL files, not real Db2 subsystems, why is Batch Processor creating a job? Shouldn't it have created a message to the user and not run?
Also how did Batch Processor pickup the ssid? Why did the analysis create the output DDL script? it cannot update the target file of DDL. 
Maybe an ICL analysis would be relevant, but what use an output of DDL for the batch processor?
Is the ssid included with the .CONNECT from the subsystem that created the strategy?


It is valid in a DDLFILE to DDLFILE compare that the ssid included with the .CONNECT is blank but it must be checked to make sure any object changes are made to the correct subsystem.

If submitted, the BATCH PROCESSOR generates a .CONNECT to the current subsystem for the job to be executed. 

If the objects in the DDLFILEs do not exist on the target environment then executing the contents of the analysis dataset will fail so the user has to know what they are doing for this to work.
The Compare should be able to be analyzed but Batch Processor shouldn't necessarily be run since it may not be able to update a target SSID if the target objects don't match.

There can be a use-case to compare the two DDL's where the target is a remote DB2 catalog that does not have DDF in place for remote access. In this situation the use of a MIGRATION strategy on that remote environment to create a TARGET DDLFILE file to compare to the SOURCE DDLFILE file would help to determine object differences. The analysis output could then be transferred to the target remote ssid for execution.

A DDLFILE to DDLFILE compare could for example include 2 sets of cloned objects from a production environment that have both been modified by projects and the requirement arises to determine what differences exist since they were cloned.
An ICL to DDL analysis of the compare strategy could be produced on the production environment of the target objects and the ICL object changes could then be applied to whichever target objects require changes.

Additional Information

DDL File Comparisons

Generate and Use Incremental Change Language Statements

.CONNECT Command