How to analyze a RC/Compare strategy and not have the SET CURRENT SQLID statements generated

Products

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

Issue/Introduction

Have blanks in the DEFAULT SQLID analysis option but RC/Compare for Db2 for z/OS (RCC) strategy still generates the
SET CURRENT SQLID statements. Trying to locate the parameters that control the generation of the SET CURRENT SQLID statements.
The parameters that control the SET CURRENT SQLID statements are the NO SET CURRENT SQLID in the User Profile and the
NO .AUTHS parameter on the Strategy Analysis Options screen.

Resolution

The SET CURRENT SQLID statements are controlled by two parameters.

The first parameter is in the User Profile.

Field: NO SET CURRENT SQLID

Description: Indicate whether you want a SET CURRENT SQLID statement generated.

Values:

  Y   The analysis output file will not
      contain SET CURRENT SQLID statements.
  
      .AUTH will contain the SQLID of the
      CREATOR ID of the object, rather than
      the CREATEDBY ID.
  
   N   (Default) Generate SET CURRENT SQLID = sqlid
       statements to set the SQLID as the CREATOR.
   
       Use the .AUTH command to preserve the
       CREATEDBY of an object.

 

The second parameter is in the Analysis Options of the strategy.

The parameter is NO .AUTHS and the valid settings for this parameter are:

Field: NO .AUTHS
Description: Specify whether you want to generate a dataset that has no Batch Processor .AUTH statements.

Values:

  Y          Yes - Generate no .AUTH statements. This is useful if you want
             to execute the migration, alteration, or comparison online. The
             User ID executing the strategy analysis output must have the
             authority to perform all statements. RC/Migrator might not be
             able to recreate objects exactly as they exist if this option is
             specified.
  
  N          No - Do generate .AUTH statements as needed. Note that the
             .AUTH generated for an external stored procedure will not have
             an ID specified. The submitter must have authority to do the
             CREATE, and must also have authority to issue the associated SET
             CURRENT SQLID statement, if it is requested.