PARMGEN transport scenarios

Edit online

The way in which you decide to share or transport work and runtime libraries determines where you run the configuration jobs required by the replication scenario you are using to create new runtime environments.

For a first-time deployment, it is ideal to keep the deployment simple by creating the RTE on the same system that the PARMGEN deployment jobs and product started tasks will be running.

The following are all possible methods of sharing or transporting the runtime libraries between one runtime environment and another.
  • Method 1: Defining a runtime environment on a z/OS image using shared DASD.

    This scenario employs a central site that defines and maintains the runtime environment configuration for both local and remote z/OS images. Each unique runtime environment that is defined represents a z/OS image. If a site has 10 shared-DASD z/OS systems (LPARs), the central site defines 10 unique runtime environments (either sharing-with-SMP/E targets, Full, or sharing-with-base) as part of the normal PARMGEN configuration process. These runtime environments are configured based on each remote site's respective configuration requirements (data set naming conventions, VTAM nodes, and the like). The central site must allow for the necessary DASD to allocate the libraries needed for each runtime environment.

    Using this method, all jobs run on the same system and no libraries are copied.

  • Method 2: Transporting a runtime environment from one z/OS image to another.

    This scenario is similar to method 1, except the 10 LPARs are on unshared DASD. During rollout of the initial runtime environment or during maintenance, you transport the product execution libraries (RK*) to each LPAR using unshared DASD.

    Using this method, all jobs are run on the same system. Only the RK* libraries are copied to the target system. If system variables are enabled, the GBL_USER_JCL library must also be copied.

    If the PARMGEN jobs are being submitted on the central staging LPAR for a non-local RTE, ensure that you modify the site-specific values to the system values for the RTE being transported during the "Customize PARMGEN configuration profile members" step. Specifically, change the LPAR-specific values autodiscovered by the PARMGEN KCIJPCFG/KCIJPPRF set-up jobs because LPAR RTE profile values for WCONFIG(PLB1SP22) for parameters for system name, IP hostname, Sysplex name, VTAM network ID, and other system values will reflect autodiscovered values on the system that the PARMGEN job ran on. Change these values accordingly before RTE transport or after you transported the jobs to the target LPAR.

  • Method 3: Transporting PARMGEN WKANSAMU batch jobs from one z/OS image to another equipped with the SMP/E target libraries.

    In this method, a central site maintains the OMEGAMON and Tivoli Management Services CSI and the SMP/E maintenance of the target data sets. Initial build distribution of the PARMGEN-supported OMEGAMON and Tivoli Management Services products to the remote z/OS images is done by copying the SMP/E target libraries and the PARMGEN batch jobs in the %RTE_HILEV%.%RTE_NAME%.WK* and WCONFIG libraries to the remote sites. If system variables are enabled, the GBL_USER_JCL library must also be copied.

    All the required steps are performed at the central site, up to $PARSE or $PARSESV job. Then the WKANSAMU jobs and the SMP/E target libraries are transported to the remote LPARs. On the remote site, only the WKANSAMU jobs (such as the KCIJPALO allocation job and the KCIJPLOD load job) are run to complete setup of the runtime environment (option 11 on the PARMGEN Workflow main panel). During maintenance, the latest fixes are applied to the central site, which then redistributes the updated target libraries to each remote site. The remote sites simply run the KCIJPLOD job to copy the new fixes from the updated or upgraded SMP/E target data sets to their product execution libraries (RK*).

  • Method 4: Transporting PARMGEN runtime environment work libraries from one z/OS image to another that is equipped with the SMP/E target libraries.

    This scenario is similar to scenario 3, except in this scenario the PARMGEN setup is done at the remote LPAR. That is, the $PARSE or $PARSESV job is run at the remote site instead of the central site. That means that the runtime environment members and jobs are created on the remote LPAR, and you have the option of cloning from an existing set of PARMGEN work environments with already customized configuration profiles in WCONFIG, then transporting the PARMGEN work libraries (%RTE_PLIB_HILEV%.%RTE_NAME%.IK*, %RTE_PLIB_HILEV%.%RTE_NAME%.WCONFIG, %RTE_PLIB_HILEV%.%RTE_NAME%.WK*, GBL_USER_JCL) to the remote LPAR, and completing the remaining PARMGEN setup there.

Methods 1 and 2 support the use of system variables; methods 3 and 4 do not.

In methods 1 and 2, if system variables have been enabled for the runtime environment, there are several ways you can implement these symbolics as profile parameter values, depending on which type of system variables are being used (static symbols, KCIPARSE-extracted symbols, or user-defined symbols).

Symbolics for PARMGEN parameters like RTE_NAME and RTE_HILEV are used directly in the KCIJP* and KCIJV* batch jobs created by $PARSESV in the WKANSAMU library. If these symbolics are static system symbols (&SYSNAME., &SYSCLONE., for example) or KCIPARSE-extracted symbols (&SYSIPHOSTNAME., &SYSVTAMNETID.) that resolve to different values on each LPAR, rather than user-defined symbols whose resolution values are controlled by the %GBL_USER_JCL%(%RTE_NAME%) LPAR system variables resolution member, the PARMGEN process assumes you plan to submit the WKANSAMU(KCIJV*) jobs on the system where the symbolics resolve.

If you want to complete the setup in the local system (the central site) rather than the target system (the remote LPAR) where you intend to deploy the product execution RK* runtime libraries, ensure that the system variables member in the user JCL on the target LPAR properly defines the static system symbols with your override values. Lines 12-14 in the following screen show an example of KCIPARSE-extracted symbols and your override values for LPAR2 if you intend to run the LPAR2 KCIJV* jobs on LPAR1.
LPAR1  EDIT      TDITNT.PARMGEN.JCL(LPAR2) 
Command ===>                                                  
****** ***************************** Top of Data ******************************
000001 * *******************************************************************   
000002 * USER SECTION: USER-DEFINED SYMBOLICS                              *   
000003 * *******************************************************************   
000004 * ---------- BEGIN - USER SECTION: USER-DEFINED SYMBOLICS --------- *   
000005 * ======================          ===============                       
000006 * User-defined symbolic:          Resolved value:                       
000007 * ======================          ===============                       
000008 * Type 1: Static system symbol overrides:                                         
000009 SYSALVL                           2                                     
000010 SYSNAME                           LPAR2                                 
000011 SYSCLONE                          02                                    
000012 * Type 2: KCIPARSE-extracted symbol overrides:                                    
000013 SYSIPHOSTNAME                     LPAR2                                 
000014 SYSVTAMNETID                      IBMNETID                              
000015 * Type 3: User-defined symbol:                                          
000016 U_SYSALVL                         2                                     
000017 U_SYSNAME                         LPAR2                                 
000018 U_SYSCLONE                        02       
000019 BASELVLU                          1                                     
000020 * ---------- END   - USER SECTION: USER-DEFINED SYMBOLICS --------- *   
****** **************************** Bottom of Data ****************************
Required LPAR2 WKANSAMU jobs:
  • KCIJPALO
  • KCIJPUPV
  • KCIJVSUB
  • KCIJVALO
  • KCIJVLOD
  • KCIJVUPV
Optional WKANSAMU LPAR2 jobs (depending on the configuration):
  • KCIJVSEC
  • KCIJVUSP
  • KCIJVUSS
  • KCIJVLNK
  • KCIJVSYS
  • KCIJVIVP
  • KCIJVCPY
  • KCIJVW2R
  • KCIJVDEL
  • KCIJVMNT