Remote deployment scenario

In a remote deployment scenario, you must create a runtime environment on a specific LPAR (the configuration LPAR), package the runtime environment data sets using the PACKAGE action, transfer the data sets to the remote target system (target LPAR), and deploy or restore the packaged runtime environment data sets on the target LPAR using the DEPLOY action.

Before you begin

Review the following information before you implement a remote deployment:

  • Make sure the SMP/E target libraries for TKANMOD and TKANCUS on the target LPAR system and TKANMOD are APF-authorized. APF authorization is needed to run the necessary actions on the target LPAR system.

  • If you are using the default RTE_TYPE (that is, SHARING with SMP), make sure a copy of the SMP/E target libraries is available on the target LPAR system, using the value you specified in GBL_TARGET_HILEV of member RTEDEF(GBL$PARM).

    If you cannot share your SMP/E target libraries on the target LPAR system, you can use the action BLDREMDS in the utility flow TKANSAM(KFJMAINT) to build the respective TKANSAM, TKANCUS, and TKANMOD data sets and transfer them to the target LPAR system.

  • The z/OS operating system versions on your configuration LPAR and target LPAR should be ideally at the same level. If this is not the case, you will have to customize the z/OS specific libraries, such as SCEELKED in RTEDEF(GBL$PARM) or RTEDEF(GBL$lpar), to handle this situation.

    For example, parameter GBL_DSN_CEE_SCEELKED pointing to the default SCEE.SCEELKED system library could point to the z/OS 2.4 version of the library in GBL$lpar1 and the z/OS 2.5 version in GBL$lpar2, respectively.

    When generating the runtime environment locally, the respective GBL$lparn member will be used.

About this task

The list in the following procedure describes a sample sequence of steps to be performed for a remote deployment.

You cannot customize some parameters when you are creating a runtime environment for remote deployment. For more information, see Parameters that cannot be customized for remote deployment.

Tip: If you need to assemble and link elements (for example, when applying maintenance), you can use the GENERATE action with OPTION RELINK. For more information, see RELINK.

Procedure

  1. For the configuration LPAR, run the CREATE action to create an initial RTEDEF data set that will contain the configuration settings of your target LPAR.

    (Optional) Specify the KFJ_LOCAL_PLIB_HILEV value in the KCIVARS DD statement to indicate that you want to use different high-level qualifiers or z/OS® UNIX System Services paths on the configuration LPAR and the target LPAR. The KFJ_LOCAL_PLIB_HILEV parameter is not needed if you will use the same HLQ on both the configuration LPAR and the target LPAR. See the CREATE action for more details.

  2. For the target LPAR, run the DISCOVER action to discover the subsystems and system symbols. This action will also create a RTEDEF data set that will contain the Kpp@lpar members for the subsystems discovered as well as the SYS@lpar member containing the system symbols.
  3. For both the configuration LPAR and the target LPAR, transfer the RTEDEF created on the target LPAR to the configuration LPAR and merge the contents into the RTEDEF created in step 1 on the configuration LPAR.
  4. For the configuration LPAR, customize your RTE as per your needs, understanding that the customizations will reflect the target LPAR system, such as the HLQs needed and features enabled in RTEDEF(Kpp$PARM or Kpp$lpar) members.

    (Optional) If you used the KFJ_LOCAL_PLIB_HILEV parameter, member RTEDEF(PCK$PARM) will be created, which allows you to map local Qshell and z/OS UNIX paths for allocating the runtime environment data sets or z/OS UNIX directories on the configuration LPAR.

    Note: The settings in RTEDEF(PCK$PARM) are applicable for all RTEs configured in the RTEDEF data sets, that is, for all RTEs of the respective SYSPLEX. If you want to use a different local HLQ for a specific target LPAR system on the configuration LPAR, you can create member RTEDEF(PCK$lpar) by copying RTEDEF(PCK$PARM) and making the respective changes.
  5. For the configuration LPAR, run the GENERATE action for your target LPAR RTE by adding the KFJ_SYSNAME parameter to the KCIVARS DD statement. The value of KFJ_SYSNAME specifies the SYSNAME or LPAR name or the SYSSMFID if the LPAR name is longer than four characters.

    See KFJ_SYSNAME for more details.

  6. (Optional) For the configuration LPAR, if you used the KFJ_LOCAL_PLIB_HILEV parameter, after the GENERATE action completes, your runtime environment data sets are created using the HLQ or z/OS UNIX root path name mapping as specified in RTEDEF(PCK$PARM or PCK$lpar). The members RTEDEF(PCK$PARM) and RTEDEF(PCK$LPAR) will be read and used during RTE generation.
    Note: In this case, the runtime environment will not be able to start up as the target LPAR settings are used to generate the respective configuration settings.
  7. For the configuration LPAR, run the PACKAGE action to build transferable dump data sets. Refer to PACKAGE for more details about the data sets created and the options that can be used.
  8. For the configuration LPAR and the target LPAR, transfer the dump data sets to the target LPAR using the procedure of your choice (for example, FTPS).
  9. For the target LPAR, run the DEPLOY action to unpack or restore the (tersed) data sets. See DEPLOY for more details and the options that can be used.
  10. For the target LPAR, adjust or copy your STC procedures.