How to create a new, independent CV that is identical to an existing CV?

Products

IDMS IDMS - Database IDMS - ADS

Issue/Introduction

What are the steps needed to create a new, independent CV that is identical to an existing CV?
This is to be a totally independent CV that will need copies of all the databases and dictionaries that are defined to the existing CV.

Environment

Release: IDMS 19.0

Resolution

This document describes steps to create a totally independent CV with separate databases/dictionaries with the requirement that their sizes and database definitions be identical to an existing CV's databases/dictionaries. If your intention is to create a new CV that uses DATASHARING to share all databases/dictionaries with an existing CV please read about CV CLONING.

Within the existing CV, create the following entities
a) Using SYSGEN, create a new SYSTEM in the SYSTEM dictionary.
   1) copy all sub-entities from the existing SYSTEM into the new SYSTEM.
   2) you can do this as follows :
      COPY SYSTEM xx TO yy.
          where xx is the existing system and yy the new one
          Then you need to MODIFY a few parameters in your new SYSTEM :
          - SYSTEM ID IS systemid
              Specifies the name (nodename) by which the DC/UCF system is known
              to other nodes in the DC/UCF communications network.
              System-name must be a one- through eight- character name that is
              unique throughout the DC/UCF communications network).
          - CVNUMBER IS nnn
              Systems executing concurrently must be defined with unique CVNUMBER
              values, even if the systems use different SVCs).
      - GENERATION ID IS generation-id
          Specifies a unique identifier for the system.)
      - SVC IS nnn
          can be the same SVC as the one used in the existing SYSTEM)
      GENERATE.
   3) at this point, your new system has been created.
b) Using OCF (or IDMSBCF (batch)), you can create a new DMCL and DBTABLE which
   will be used in your new CV.
   1) The easiest way to do this is in batch with IDMSBCF using following (SYSIPT) input :
          CONNECT TO SYSTEM;
          PUNCH DMCL your-dmcl AS SYN;
   2) Then take the SYSPCH output and
       * replace all references to your dmcl with the new dmcl name
       * If you use dynamic allocation for your IDMS dictionaries and databases, then
          you need to change the DSNAME parameter in all FILE definitions to point to the
          name of the new datasets (see further on)
       * at the end of the output, add the following line :
               GENERATE DMCL your-new-dmcl;
   3) Then use this modified SYSPCH file as input for another IDMSBCF run to upload and
      generate (compile) your new dmcl.
   4) Next, do the same for your DBTABLE.
      Note : you can create a new DBTABLE (and in that case, you need to specify its new
             name in your new dmcl too, or you can just use the same DBTABLE as in your
             current system. If you do so, you do not need to change your new dmcl,
             because the name of the DBTABLE remains the same.
Copy the datasets for all files defined in the source DMCL except for the Disk Journal
files and the files for the DDLDCLOG and DDLDCRUN area, which must be newly allocated and formatted with
the new CV DMCL that was created in step 1 above.
If you're able to share the same IDMS software loadlib and application loadlibs this is fine,
otherwise copy all loadlibs in STEPLIB/CDMSLIB that will be used by the new CV but we strongly
recommend creating a new CV-specific DBA.LOADLIB for all of your CV-specific things such as
DMCL, DBTABLE, RHDCSRTT, RHDCOPTF, etc.
Note : If copying the IDMS loadlib, remember that any maintenance applied to the original will
require a new copy to your new CV's loadlib.
If this new CV needs its own loadlib environment, then a new SMP/E environment needs to be
created as well as new IDMS system libraries, and populate them using the jcl members in the
SAMPJCL library (or doing this by means of CA CSM.
Create new Startup JCL that defines any new datasets (if needed) in the startup JCL for your
new CV.
Create new ARCHIVE JOURNAL and ARCHIVE LOG JCL that your WTOEXIT will submit to offload journals
and log and define the datasets that contain this JCL to your new startup JCL for ddnames AJNLJOB
and PLOGJOB. These point to the jobs that archive the journal and log respectively.
Each CV will need their own versions of these jobs pointing to the relevant datasets for that CV,
so it is a good idea to allocate a JCL library that is dedicated for each individual CV.
Determine what security definitions need to be changed. You may secure your resources internally,
externally or a mix of both, but since this will be a new system number you will need to create
at least one new resource definition and grant access to it.
Example :
Assume the following :
- your current CV is called SYSTEM12 (= SYSTEM ID in your SYSTEM statement).
- Internal security is used. In this case a RESOURCE SYSTEM statement wil exist :
        CREATE RESOURCE SYSTEM SYSTEM12
                ;
- Userid A125 has been granted signon to this system :
           GRANT SIGNON ON SYSTEM SYSTEM12 TO A125
                ;
- your new system is called SYSTEM15.
In this case following definitions have to be defined in the SYSTEM dictionary (by means of OCF
or IDMSBCF) :
   CONNECT TO SYSTEM;
   CREATE RESOURCE SYSTEM SYSTEM15 ;
   GRANT SIGNON ON SYSTEM SYSTEM15 TO A125 ;
If your SRTT for the existing CV has CV-specific Environment name you may need to assemble a new
SRTT (module RHDCSRTT).
If your existing CV contains VTAM-type lines, then these lines have an APPLicationID (VTAM APPLID).
Example : (LINE definition from SYSGEN)
      ADD LINE VTAM01
          TYPE IS VTAMLIN
          APPLICATION ID IS vtam-applid     <----
Because your new CV will run on the same lpar as the existing CV, each of your VTAM line(s) needs
to be changed to use a different APPLID.
You may need to check this with your VTAM/Opsys colleagues to include these new APPLIDs in the
VTAMLST dataset (APPL type major node and the LOCAL type major node).
The same applies for APPC (VTAMLU) type lines.
If your existing CV contains TCPIP (SOCKET) type line(s), then these lines in your new CV need to
have different TCPIP port numbers.
Example : (LINE definition from SYSGEN)
     ADD LINE TCPIP1
         TYPE IS SOCKET
Such line has one or more 'listener' pterms :
     ADD PTERM TCPPJSRV
         IN LINE TCPIP1
         PORT IS 3768   <--- tcpip port #
If your current CV is accessed from an non-mainframe environment by means of CA IDMS/Server, you will
have to create new ODBC Datasources (on Windows PCs), to point to the new Central Version.
This ODBC datasource will need to
- point to a Dictonary in the new CV,
- reflect the SYSTEM ID of your new CV in the Server definition
- specify the new TCPIP port number as defined in the TCPIP line of your new CV.