search cancel

Endevor error message: SMGR155E BASE MEMBER ALREADY EXISTS on Package MOVE

book

Article ID: 212128

calendar_today

Updated On:

Products

Endevor Software Change Manager (SCM)

Issue/Introduction

Element Move we get the following error:

C1G0202I  ACTION #10 / STMT #15                                                 
C1G0203I     MOVE     ELEMENT GL001                                           
C1G0204I        FROM ENVIRONMENT: QA    SYSTEM: GL      SUBSYSTEM: GL      
C1G0232I        OPTIONS:  WITH HISTORY, SIGNIN                                  
C1G0232I                  CCID: GL01                                        
C1G0232I                  COMMENT: Move Gl01                           
C1G0265I  PROCESSOR GROUP JCL FOR THIS ELEMENT WAS OBTAINED FROM ENVIRONMEN
C1G0000I     DATA SET BST.QA.BASE                                          
C1G0000I     MEMBER GL01                                                     
SMGR155E  BASE MEMBER ALREADY EXISTS FOR THIS ELEMENT                           
C1G0277I  MOVE PROCESSING TERMINATED BECAUSE OF THE PREVIOUS ERROR              
C1G0200I  ELEMENT ACTION REQUEST PROCESSING COMPLETED, HIGHEST ENDEVOR RC WAS 0012
ELEMENT ACTION REQUEST PROCESSING COMPLETED, HIGHEST ENDEVOR RC WAS 0012   

 

Cause

This error happens when Endevor compares the Footprint of the From Element and the To Element. The System,Subsystem,Type and Stage must match.

Common reason for this error is more than one Element with the same name are being stored to the same Base file, and COMPRESS/ENCRYPT(Y/N) in the TYPE Definition is set to N.

Environment

Release : All

Component : CA Endevor Software Change Manager

Resolution

Check the footprint of the Element's Base library.  So in the example above check BST.QA.BASE for member GL01's footprint.  

https://knowledge.broadcom.com/external/article?articleId=111225

The footprint should tell you what happened, what's different between the 2 footprints.

If both Elements are valid and you want to retain both Elements Change the Type Definition on One or Both Types to COMPRESS/ENCRYPT(Y/N) ===> Y

This will store the Member in the Base as a Compressed name. So the member name will not be GL02 (as per the example). So no two names will be the same.  Another way is to change the Base dataset(in the Type definition) so the two Elements are stored on the same Base file.

 

If you only want to keep the new Element and Delete the old Element(so keep the one you're moving). Then you can use Endevor Delete, Transmit(with delete from behind) or Archive (with Delete from behind).

If you want to keep the Element you are moving to. Retrieve the Element to a lower Environment/Stage to the same System/Subsystem/Type as the existing Element. Then move it up.

 

 

Additional Information

Going forward if you want to prevent this in the future you can do the following:

-Look at altering your System definitions changing "ELEMENT REGISTRATION CHECK OPTIONS" to prevent Element duplications.

-Look at changes to the options table (CSIQSRC(ENCOPTBL))  for option ENHOPT REGISTER_ACROSS_SYSTEMS.

-Change COMPRESS/ENCRYPT(Y/N) ===> to Y for you Type Definitions.

-Change the Base dataset so it's unique for a System/Subsystem/Type you can use symbolics 

  for example:

BASE/IMAGE LIBRARY ===> BST.&C1SYSTEM..&C1SUBSYS..&C1STAGE..BASE 

This dataset would be :  BST.system.subsystem.stagename.BASE