Cloning a Datacom Environment with DFDSS
search cancel

Cloning a Datacom Environment with DFDSS

book

Article ID: 56135

calendar_today

Updated On: 05-22-2023

Products

Datacom Datacom/AD Datacom/DB

Issue/Introduction

Occasionally it may be necessary to duplicate a Multi-User Facility (MUF) environment for the purpose of:

  • Disaster recovery
  • Volume testing
  • Recreating an existing problem in a controlled environment
  • Testing the upgrade process to a new version


RECOMMEND using CXXCLONE

To create a duplicate MUF, the recommended process is to use DBUTLTY and VLSUTIL as is described in informational solution QI94581. Those instructions still apply to current releases of Datacom.

However, if as an alternative IBM's Data Facility Data Set Services (DFDSS) is used, this document will provide information to make its outcome successful.

Environment

Release: 15.1

Resolution

Creating a duplicate MUF using IBM's Data Facility Data Set Services (DFDSS) utility.

In order to use this procedure the following requirements must be met:

  • The appropriate Common Services for z/OS and IPC products are installed.
  • The same DASD types (same device geometry) must be used.
  • Datacom uses the same CXXNAME for the Directory (CXX).
  • The contents of the new CXX will be the same as the old CXX after the DFDSS Restore.
  • Familiarity with Datacom DBUTLTY and the IBM DFDSS utility.

Step one: Backup all of the data sets that make up the source MUF environment. To successfully build a duplicate environment, the source MUF must be shut down normally before beginning the backup. Use the DFDSS DUMP function with the following parameters to create the backup data sets:

  • INCLUDE -
    This must include all the libraries, MUF system data sets (CXX, LXX , FXX , PXX, VLS files, database indexes, and data areas). Optionally, include user index and data areas (databases) needed for the duplicate MUF. If you can not get all the data sets with the one high-level qualifier, then you will need multiple include statements (one per high-level).

 

  • OUTDDNAME -
    This is the output data set and is used as input to the restore process.

    Sample Backup JCL:
    //BACKUP EXEC PGM=ADRDSSU,REGION=6M
    //SYSOUT DD SYSOUT=*
    //SYSPRINT DD SYSOUT=*
    //SYSUDUMP DD SYSOUT=*
    //*
    //TAPE DD DSN= caithlq .DB11.BACKUP,
    // DISP=(NEW,CATLG,DELETE),
    // UNIT=CART,LABEL=(1,SL,EXPDT=99365)
    //SYSIN DD *
    DUMP OUTDDNAME(TAPE) -
    DATASET(INCLUDE( caihlq .DB11.**)) -
    ALLDATA(*) -
    ALLEXCP -
    SHARE -
    TOLERATE(ENQFAILURE)
    /*
    NOTE: caithlq refers to the cart high-level qualifier and caihlq refers to the disk high-level qualifier.

Step two: Restore the data sets from the DFDSS backup data set. If you are restoring these data sets to the same image as the source MUF, you must use the DFDSS rename capabilities to provide a new high-level qualifier . Failure to do this could cause the system to have data sets with duplicate names and possible overlays. When this step is completed, you will have the same environment you had at the time the backup was taken.

To complete the restore, use the DFDSS Utility with the following parameters:

  • INCLUDE - The name of the data sets or high-level qualifiers that are to be restored for the new MUF.
     
  • OUTDYNAM -This should contain the DASD devices to which the data files are being restored.
     
  • EXCLUDE -This control statement is used only if you need to exclude data sets from the restore process.
     
  • RENAMEU -This is used to rename the data sets when restoring to the same image where the source MUF exists or when you want to create a new system, such as prod to prod2, prod to test or test to test2.

    Sample Restore JCL:
    //RESTORE EXEC PGM=ADRDSSU,REGION=6M
    //SYSOUT DD SYSOUT=*
    //SYSPRINT DD SYSOUT=*
    //SYSUDUMP DD SYSOUT=*
    //*
    //TAPE DD DSN=caithlq.DB11.BACKUP,
    // DISP=SHR,
    // UNIT=CART,LABEL=(1,SL,EXPDT=99365)
    //SYSIN DD *
    RESTORE DATASET -
    (INCLUDE(caihlq.DB11.**) -
    EXCLUDE(caihlq.DB11.xxxxxxxx.**) -
    ) -
    OUTDYNAM((DASD01),(DASD02),(DASD03)) -
    INDDAME(TAPE) -
    RENAMEUNCONDITIONAL((*.DB11.**,*.DB11TST.**)) -
    REPLACE -
    CATALOG
    /*
    NOTE: If this system is going to exist on a different machine or LPAR, running the above restore without the RENAMEUNCONDITIONAL control statement will give you a new system. Remember that, when creating new data sets, you must have the appropriate security clearances and profiles.

Step three: If you want the new target environment to coexist with the original source environment on the same system, you must complete the following steps after completing the restore/rename process.

WARNING: Do not attempt to start the new MUF until after you complete the following steps!!!

Step 3a: Modify the DBSYSID macro to code new CXXNAME, TOGROUP and TARGET_MUF_LIST parameters. If using simplify mode also change FORCE_DSN_CXXNAME and FORCE_DSN_CHAR parameters.
Refer to documentation section Modifying DBSIDPR Parameters for more details.

Once these changes have been made, re-assemble the DBSYSID macro to create a new DBSIDPR module. Place this copy of DBSIDPR into a new library that will be exclusive to this new MUF.

Step 3b: If you are using external security, copy the rules from the original system and make the appropriate changes to this new system.

Step 3c: Change the CXXNAME name (for example, PRODCXX to TESTCXX).

NOTE: If you are using external security, this new name must be used as the resource prefix of the rules that were added to that security product in Step 3b.

You must use DBUTLTY to accomplish this. For more details on the following control statements, refer to documentation section  Utility Function Summary. 

  • Backup the new CXX (TESTCXX):|
    BACKUP AREA=CXX,DDNAME=DDNAME1
  • Change the name of the new CXX (TESTCXX):
    INIT AREA=CXX,CXXNAME=TESTCXX,DATACOM=zz
    where: zz = DB or AD, depending on the type of CXX backed up.
     
  • Restore the new CXX (TESTCXX) backup:
    LOAD AREA=CXX,DDNAME=DDNAME1
  • A new backup should be taken of this CXX. This will give you a stable CXX to return to if something goes wrong with the remaining steps:
    BACKUP AREA=CXX,DDNAME=DDNAME2

Step 3d: Modify the new CXX to reference the new data areas.

  • Initialize the new Log Area (LXX)
     
  • Initialize the new Force Area (FXX).
     
  • Initialize and null load the following Databases using DBUTLTY: 006, 016, 017, 1000, 1006 and 1007.
     
  • Create new startup and shutdown JCL. This should be pointing to the new libraries and data sets.
     
  • Start up the new MUF. Making the following changes to the MUF Start up parameters. (which may be changed back to their prior values when cloning is complete):
     
    1. ECHO YES -turn off echo console messages
    2. MUF MUF11xx,99,YES -logical name of this MUF,# extra rununits
    3. CBS 6,256K,0,0,16,1006
      - CBS DBID, BFR(TSKS*1K), MXSTEN,MXSTIO, MAXAGE,heuristic-dbid
      (Please note that the heuristic-dbid (1006) is not valid in version 12.0 and beyond of Datacom/AD, and should be removed)
    4. HISTORY 1007 - History DBID
    5. SYSTEMDBID 1000 -System information Database DBID

      NOTE: Depending upon the purpose of the new MUF, the various value requirements that are specified on the TASKS parameter may warrant re-evaluation as well.

  • Rename all dataset names stored in the CXX. Run a full CXX Report and from the CXX report information, create Datacom DBUTLTY CXXMAINT input statements for each database index and data area that has been renamed. One CXXMAINT statement must be created for each data area and index area. If a data area has multiple tables, only one CXXMAINT statement needs to be created. Only one index statement is required per database. The examples below are for database 0001, the Human Resource database. If you get an error during the rename, correct the input statements and re-submit. After this step completes, backup the CXX. See article 96558​ for an alternative method to rename all dataset names in the CXX.

    NOTE: Virtual Tables dataset names cannot be altered. They must be changed with DBUTLTY.

    NOTE : The MUF must be up and running for the following CXXMAINT and LINK functions.

    Example CXXMAINT Transactions:
    CXXMAINT OPTION=ALTER,AREA=DEM,DBID=00001,DSN=caihlq.DB11TST.DBDEM
    CXXMAINT OPTION=ALTER,AREA=IXX,DBID=00001,DSN=caihlq.DB11TST.DBIXX
    CXXMAINT OPTION=ALTER,AREA=PAY,DBID=00001,DSN=caihlq.DB11TST.DBPAY
    CXXMAINT OPTION=ALTER,AREA=PMF,DBID=00001,DSN=caihlq.DB11TST.DBPMF
  • After completing the rename, utilize DBUTLTY to update the new database data sets with the new CXXNAME. This is completed by executing the DBUTLTY LINK command. One LINK command is needed for each database defined to this CXX (example below).

    NOTE: The MUF must be running to perform the LINK function.
    LINK DBID=00001
    LINK DBID=00002
  • Run a final CXX report and verify that all data set names have been updated correctly. Any data set that has not been updated should be renamed to a dummy name so that any attempt to access the data set would fail, rather than accidentally opening the wrong data set.

This completes the creation of a duplicate Datacom Multi-User Facility. At this point a full backup should be performed and existing JCL should be modified to reference the new data set names.

Powered by Wolken Software