MFE SCF: MSC TAKEOVER fails with message SCF153FE when an SDDF session is not found

Summary: The command MSC TAKEOVER is issued in a SRDF/STAR environment to move the primary server to a WF=2 secondary server. The message SCF153FE is received for a missing Symmetrix Differential Data Facility (SDDF) session and causes the TAKEOVER command to fail. Found in a solution that had devices added to the SRDF/STAR but forgot the MSC ADDDEV command to add in SDDF sessions. ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

Issuing the MSC TAKEOVER command for MSCGROUP MYMSC on the WF=2 host receives message SCF153FE followed by SCF15CBE. 
 

SCF1390I MSC,TAKEOVER,MSCG(MYMSC)                                                                 
SCF1391I MSC - TAKEOVER COMMAND ACCEPTED.                                                            
SCF15ABI MSC - GROUP=MYMSC                  TAKEOVER processing initiated                         
SCF153FE MSC - GROUP=MYMSC                  (00100,10) SDDF B1 Session not found for device 15E2                               
SCF15CBE MSC - GROUP=MYMSC                  (00100,20) TAKEOVER processing failed  

SCF153FE 

Cause
During restart or takeover, the SDDF session does not exist for the indicated device.
Action
Run the M6 Cleanup utility and restart SRDF/Star or SRDF/SQAR. For SRDF/SQAR, M6 must be run separately for each group.           

Cause

The TAKEOVER command is invoked as part of the GDDRPA36 script. The procedure for moving the MSC primary server can be done using manual Symmetrix Control Facility (SCF) and ConGroup commands. The steps are outlined in the following sentences. The current MSC primary server must be deactivated because there cannot be two WF=0 servers. If the current primary MSC server is becoming a secondary server after the TAKEOVER completes, then an MSC DEACT RETAIN command is issued. This command allows the MSC RESTARTTOSEC command to succeed. If SCF is brought down, then the MSC DEACT is used. Then the ConGroup owner is moved to the WF=2 Logical Partition (LPAR). Once that is done, the MSC TAKEOVER can be issued.  

The likely reason for the failure is caused by adding new devices to a running SRDF/STAR. Then not issuing the MSC ADDDEV command which creates the SDDF sessions for all the devices that are added to the running MSC group.  

The SCF153FE message appears for the first device found not having a session. All devices added are missing their sessions. Running program EMCSNAP against the synchronous target frame with parameter SESSION_LIST(YES,DETAIL) shows the devices missing their SDDF sessions.
The SCF153FE message shows device 15E2. The display below shows no 34FE STAR SDDF session.

ESNPI63I   000015E1(N/A )        TDVS CKD-0000032760 RDY
ESNPP37I        SESSION#-TYPE                     
ESNPP31I          34FE-STAR SDDF SES IN USE

ESNPI63I   000015E2(N/A )        TDVS CKD-0000065520 RDY
ESNPI63I   000015E3(N/A )        TDVS CKD-0000065520 RDY


                    

Resolution

  1. Run the M6 Cleanup utility and restart SRDF/Star or SRDF/SQAR. For SRDF/SQAR, M6 must be run separately for each group. The M6 job fails if it finds MSC or SRDF/A still active. In this instance, issue the following SRDF Host Component command to DROP SRDF/A and then rerun the M6 command.
SC  SRDFA,LCL(gk,rdfg),DROP
  1. SRDF resumes the devices in the SRDF/A group and then activates SRDF/A.
  2. When MSC is restarted on the primary server, it builds the SDDF sessions for all devices including the previous missing SDDF sessions.

Affected Products

Mainframe Enablers
Article Properties
Article Number: 000195664
Article Type: Solution
Last Modified: 21 نوفمبر 2025
Version:  5
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.