Expand all | Collapse all

CV Cloing

Jump to Best Answer
  • 1.  CV Cloing

    Posted 04-21-2016 01:21 PM

    I'm in the process of defining two new CV's. Is there an easy way to clone an existing CV as a starting point?

    Thanks, Ian

  • 2.  Re: CV Cloing

    Posted 04-28-2016 06:46 AM

    Hi all,

    Chris’s post are very clear and TEC471781 are very detailed.

    We have set up a ‘IDMS Cloning’ first of all, to create new test environments. To do this, we copy all files: SYSTEM, CATSYS, Dictionary, Database…After that, we adapted all the specific definitions: DMCL, DBTABLE, SYSTEM, Dictionary name, Lines names,…  Don’t forget:

          - to include a specific RUNUNIT for the new dictionary and maybe delete the corresponding original (in ‘SYSGEN’).

         - to include the new dictionary in the loadlist/s. (in ‘SYSGEN’).

         - GRANT the users to get access to new system and REVOKE to the older.

         - If you have users in dictionary, be careful with security options for IDD, MAPC etc. Maybe you would change it depending on the environment.


    Once the system is ready, we use some of these procedures to clone the systems yearly. We are copying dictionary and database files, and subschemas and applications programs libraries. We are keeping the basic system definitions (SYSTEM, CATSYS) and PUNCHing from source system:

    DMCL, SEGMENTS, DBTABLE, Securities definitions, Program an Task definitions.

    And including it in the target system.

    We have used only IDMS utilities, SORT, File Manager and the usual tools. I strongly recommend using flashcopy to reduce unavailability 

    I had fun preparing this and the result is rewarding.



  • 3.  Re: CV Cloing

    Broadcom Employee
    Posted 04-21-2016 02:10 PM

    Hi Ian,


    Check out TEC471781, but "easy" is not a word I would choose to describe such a venture 

  • 4.  Re: CV Cloing

    Posted 04-21-2016 02:52 PM

    I would suggest that you start by reading the installation manual, chapter 5, go to Installation Types and Complete Base Installation, it will give you an idea of what is required.
    Then read the tech note referenced by Brian.

  • 5.  Re: CV Cloing
    Best Answer

    Posted 04-21-2016 02:04 PM
      |   view attached

    It will be much easier if the CVs share system dict and catalog with existing CV –


    Punch out the required segments  = create new segments with new names where necessary (create new datasets) – build the new DMCL – generat andf punchy it FROM THE EXISTING CV

    Same with a system – punch – alter – load back -  generate it form within the OLD CV


    Then bring up the ne CVs) as jobs at first to get around SOME security issues


    If you must use a new catalog and system dictionary – copy the contents of the old to the new – then in the new – then broing up the mew CV using the NEW cataklog and system dictionary – then delete the unneeded objects form the new catalog/dict


    Its probably more complemented than that – but that is what I deem top revall having done



    Chris Hoelscher

    Technology Architect, Database Infrastructure Services

    Technology Solution Services


    123 East Main Street

    Louisville, KY 40202

    (502) 714-8615, (502) 476-2538


    The information transmitted is intended only for the person or entity to which it is addressed

    and may contain CONFIDENTIAL material.  If you receive this material/information in error,

    please contact the sender and delete or destroy the material/information.

  • 6.  RE: Re: CV Cloing

    Posted 07-14-2021 03:01 PM
    I have a need to make a copy of an CV into another existing CV on a different LPAR. I need some guidance on the above discussion. First of all it appears that the TEC471781 has disappeared. I wonder if someone has a copy of it? I figure that may be very helpful.

    I have ADSO apps, so I believe I am going to have to copy my dictionary and load areas. I understand that I can punch my source DMCL (and may need to make some changes to the content for naming?) Then I can MODIFY the DMCL of the target using the punched DMCL. Now I'll have to make available to the CV the properly named underlying z/OS files to match the DMCL.

    What if I have CV-specific naming in my DMCL - like a T (for Test) in segment and file names that I want to become an A (for Acceptance)? Should I care? I assume it is easier if I leave the original naming in the DMCL, but will my system get confused somehow? If I do change all Ts to As in the Segment/file names in the DMCL, than I need to make changes to the extracted source dictionary DDL, too, right?

    Do I also need to punch the source DBTABLE (and edit it) then MODIFY the DBTABLE into the target?

    How would I go about punching all the DDL from the dictionary? Or is it ok to just copy the underlying z/OS file?

    Do I need to make changes to the SYSGEN? I assume if I want the source and targets to match I'll want the 2 SYSGENs to be similar (perhaps with different naming if there is anything to address).


  • 7.  Re: CV Cloing

    Broadcom Employee
    Posted 04-21-2016 02:16 PM

    The KD is old and item #6 has an outdated statement.


    "Possibly create a new Startup module for the CV. If you use the generic startup module IDMSDC or RHDCOMVS and the new JCL parameters for specifying system number, DMCL, WTOEXIT etc you won't need to create a new startup module and RHDCPARM for this CV. If you make your own uniquely named startup module and/or will not be using the JCL parameters for DMCL etc, make sure you include the RHDCPARM & WTOEXIT you want for this CV."



      Obviously there are no longer any custom startup modules and no more RHDCPARM.   There is only the generic startup module and all Parms are specified in the startup JCL.


    Basically the rest is a good place to start for a list of things to create a new CV from an existing one. 

  • 8.  RE: Re: CV Cloing

    Broadcom Employee
    Posted 07-14-2021 03:14 PM
    Hi Paul,
      I found this Knowledge article 26601 which I believe was created from TEC471781 which was quite old.
      It was published during 18.5 so should be valid for 19.0 as well.

  • 9.  RE: Re: CV Cloing

    Posted 07-14-2021 03:20 PM

    If the DASD is sharable between the LPARS – why not just share the dictionary
    ? is there a possibility that there could be different versions of the same ADS code in the two environments? if not then no problem


    As for DMCL/DBTABLES – male different dmcls/dbtables in the SAME catalog, accessible to both – but only called by the CV needed


    We run one catalog and one appl dictionary across many CVs on multiple LPARS – no problems here


    Chris Hoelscher

    Lead Sys DBA

    IBM Global Technical Services on assignmemt to Humana Inc.

    T 502.476.2538  or 502.407.7266


  • 10.  RE: Re: CV Cloing

    Posted 07-15-2021 08:26 AM
    Thanks a million . This doc looks like what I needed.

  • 11.  RE: Re: CV Cloing

    Posted 07-15-2021 08:30 AM
    Thanks, Chris. I am doing this on a separate LPAR with no shared DASD. I appreciate your guidance with this. :-)

  • 12.  RE: Re: CV Cloing

    Posted 07-16-2021 11:06 AM
    Looking deeper I see I have a couple hundred files defined in OCF for Application data and Dictionary like this:
    *+ Status = 0 SQLSTATE = 00000
    *+ CREATED 1994-04-20- BY PDBDC12
    *+ LAST CRITICAL CHANGE 1994-04-20-
    Is there some easy way to change these

    I am not sure how to punch all of the file definitions so that I can make the changes in a flat file and then BCF the alters back in.
    I also wonder what will happen to the CV if I change the DSNAMEs of the dictionary and I screw it up. Do I get a second chance or can I simply manipulate the definitions with BCF using hard-coded DDNAMEs in the JCL?