When executing a RC/Migrator for Db2 for z/OS (RCM) migration strategy with the Exclusive Option SQL ONLY to another target subsystem, the execution fails.
This is occurs because target objects are found to be duplicates. The execution attempts to run on the source subsystem even though this is not specified and RC/Migrator has not generated a batch processor statement to connect to the target subsystem. Why is a .CONNECT statement not generated?
The Analysis Options, Exclusive options, SQL is designed to produce only SQL as a means of generating SQL text from the catalog.
From the RC/Migrator manual....Analysis Options, Exclusive Options
"SQL ONLY
During analysis of an alter or comparison strategy, use this option to specify whether you want to generate only SQL for this compare or alter analysis.
For migration, use the previous field SQL option."
This analysis is not designed to be executed like a normal migration by batch processor with all the usual statements targeting the target subsystem.
That's why no batch processor statements like the .CONNECT and .SYNC statements will be found in the SQL generated.
It could however be used by other SQL processing programs like DSNTEP2, SPUFI or QMF which would find the batch processor statements to be invalid.
Pure SQL code could also be used as input to an RC/Compare analysis.
If you want to actually execute the SQL only with batch processor and the intention is NOT to have any data unloaded or loaded by the execution, then the
best way is to specify in the analysis options that you don't want to unload any data "ALL ROWS ===> N".
Leave the Exclusive Options as "N" instead of "S". Also specify "N" on all the utility options as you don't want any utilities generated.
This means that no utility statements will be generated for this migration analysis. Not only will the .CONNECT still be generated, but equally as important the .SYNC
statements will be generated so that you have your checkpoint restart ability in place.
It is the .CONNECT statement that directs the creation of the objects on the target subsystem therefore the execution won't try and create
the objects on the source subsystem where the objects already exist.