Does MIM needs to manage qname SYSIGGV1

Products

• MIM Resource Sharing (MIM)

Issue/Introduction

For the T-Rex release above V7R4M0 it's possible to receive the following message during the REORG process:

AMSE5476E RNL CHANGE FOR 'SYSIGGV1' TO 'SYSTEM' REQUIRED

  Explanation: The REORG command has detected that the active GRS RNL includes QNAME SYSIGGV1 for propagation with a SCOPE of SYSTEMS. 
  Although this was once a setting recommended for REORG processing, that practice is no longer suggested.

  The SYSIGGV1 QNAME should be removed from the GRS “inclusion” RNL and allowed to be handled as SCOPE=SYSTEM.

  Response: Modify the GRS RNL and resubmit the REORG command

It could be possible there is this setting specified:

  QNAME=SYSIGGV1 - GDIF=YES,SCOPE=SYSTEM,EXEMPT=NO,    
                   TRACE=NONE,ECMF=NO,                 
                   RPTAFTER=000,RPTCYCLE=060           

Also the IBM DFSMS managing catalogues manual comments:

Do not place an entry for SYSIGGV1 in the SYSTEM inclusion RNL. 
Every SYSIGGV1 request that needs the SYSTEMS attribute already has it. 
Placing an entry for SYSIGGV1 in the SYSTEM inclusion RNL can degrade performance.

Is it safe to remove the MIM QNAME definition for SYSIGGV1?
If so, what are the commands to do this without an IPL?

Environment

MIM all releases

Resolution

To delete the SYSIGGV1 queuename, the command DELQ Q=SYSIGGV1 can be used
If the lpars are all in the same MIMPlex, the command response will be returned from all active systems... 

SYSIGGV1 is an IBM qname used by the Catalog address space to serialize its control blocks. 
Catalog issues SYSIGGV1 ENQs using SCOPE=SYSTEM on the ENQ macro. 
By definition, SCOPE=SYSTEM is used when serializing access to resources that are known within a single Z/OS system. 
IBM therefore recommends that SYSIGGV1 ENQs not be propagated to other systems in a complex.

The T-REX software product from Dino Software also used the SYSIGGV1 qname for resource serialization. 
For their purposes, Dino Software recommended that the SYSIGGV1 ENQs be propagated by a global serialization product. 
As of the 5.2 version, T-REX is no longer using the SYSIGGV1 qname and therefore no longer requires that SYSIGGV1 ENQs be propagated globally.

Broadcom agrees with the IBM recommendation that SYSIGGV1 ENQs not be propagated across the DASD sharing complex.
If you are running the T-REX product at a pre-5.2 level, then Broadcom recommends to upgrade T-REX to a minimum level of 5.2 and treat SYSIGGV1 ENQs as local requests.

Use CA MII commands DISPLAY COUNTS and DISPLAY QNAMES to determine whether CA MII is managing SYSIGGV1.

Additional Information

When issuing the DELQ command you will see something like this:

@DELQNAME QNAME=SYSIGGV1                                           
@MIM0067I Command DELQNAME 984                                     
@MIM1109I DELQNAME QNAME=SYSIGGV1 pending on system SYSA         
@MIM1111I DELQNAME QNAME=SYSIGGV1 processed by system SYSA       
@MIM1111I DELQNAME QNAME=SYSIGGV1 processed by system SYSB         
@MIM1113I DELQNAME QNAME=SYSIGGV1 complete on all active systems   
@MIM1113I DELQNAME QNAME=SYSIGGV1 complete on all active systems   

The @D QNAMES shows:

QNAME=SYSIGGV1 - GDIF=NO    
     SOURCE:DELQNAME        

The @D COUNTS shows:

   RESOURCE TYPE  ------ ENQS ------   ----- RESERVES -----     GLOBAL 
    (QNAME)        ISSUED  PROCESSED      ISSUED   PROCESSED   CONFLICTS
*SYSIGGV1            20         20           0          0           0