CV Cloing

[Ian Cameron]

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

[Chris Hoelscher]

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

: humana.com

123 East Main Street

Louisville, KY 40202

Humana.com

[phone], [phone]

 

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.

[Brian Brendlinger]

Hi Ian,

 

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

[Brian Brendlinger]

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. 

[Tommy Petersen]

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.

[Legacy User]

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.

 

Regards.

[Paul Schulz]

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).

Paul

[Brian Brendlinger]

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.

[Paul Schulz]

Thanks a million . This doc looks like what I needed.

[Chris Hoelscher]

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

 

[Paul Schulz]

Thanks, Chris. I am doing this on a separate LPAR with no shared DASD. I appreciate your guidance with this. :-)

[Paul Schulz]

Looking deeper I see I have a couple hundred files defined in OCF for Application data and Dictionary like this:

DISPLAY FILE APPLDICT.DICTDB AS SYN VERB MODIFY;
*+ Status = 0 SQLSTATE = 00000
ALTER
FILE APPLDICT.DICTDB
*+ CREATED 1994-04-20-19.41.24.033021 BY PDBDC12
*+ LAST CRITICAL CHANGE 1994-04-20-19.41.24.350341
ASSIGN TO DICTDB
DSNAME 'IDMS.TR00.APPLDICT.DDLDML'
DISP SHR
NONVSAM
*+ FILE BLOCK SIZE 4820 CHARACTERS
*+ BLOCKS 1 THRU 40000 MAP TO AREA DDLDML PAGES 1 THRU 40000

Is there some easy way to change these 
DSNAME 'IDMS.TR00.APPLDICT.DDLDML'
to
DSNAME 'IDMS.TR00COPY.APPLDICT.DDLDML'

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?

Paul