In a remote deployment scenario, you must create a runtime environment on a specific LPAR
(the configuration system), package the runtime environment data sets
using the PACKAGE action, transfer the data sets to the remote target system
(target system), and deploy (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 system system and
TKANMOD are APF-authorized. APF authorization is needed to run the necessary
actions on the target system 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 system 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 system 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 system system.
-
The z/OS operating system versions on your configuration system
and target system 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 steps in the following procedure describe a sample sequence to be performed for a remote
deployment. The procedure uses the terms configuration system and target
system to distinguish the systems. Typically, the target system is a remote system.
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 | NORELINK.
Procedure
-
For the configuration system, run the CREATE
action to create an initial RTEDEF data set that will contain the configuration
settings of your target system.
(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 system and the target system. The KFJ_LOCAL_PLIB_HILEV parameter is not needed if you will use the same
high-level qualifiers on both the configuration system and the
target system. See the CREATE
action for more details.
- For the target system, 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.
- For both the configuration system and the target system, transfer the RTEDEF created on the
target system to the configuration system, and merge the contents into the
RTEDEF created in step 1 on the configuration system.
- For the configuration system, customize your runtime
environment as per your needs, understanding that the customizations will reflect the target system system, such as the high-level qualifiers 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 system.
Note: The settings in RTEDEF(PCK$PARM) are applicable for all runtime
environments configured in the RTEDEF data sets, that is, for all runtime
environments of the respective SYSPLEX. If you want to use a different local high-level qualifier
for a specific target system system on the configuration system, you can create member
RTEDEF(PCK$lpar) by copying
RTEDEF(PCK$PARM) and making the respective changes.
- For the configuration system, run the
GENERATE action for your target system
runtime environment 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.
(Optional) For the
configuration system, if you used the
KFJ_LOCAL_PLIB_HILEV parameter, after the
GENERATE action
completes, your runtime environment data sets are created using the high-level qualifier 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 runtime environment generation.
Note: In this case, the runtime environment will not be
able to start up as the target system settings are used to
generate the respective configuration settings.
- For the configuration system, 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.
- For the configuration system and the target system, transfer the dump data sets to the target system using the procedure of your choice (for example, FTPS).
Important: If you transfer your package data sets with a qualifier that is different
from RTE_PLIB_HILEV parameter value, you must use the
KFJ_PACK_HILEV parameter when you deploy the runtime environment in the next
step.
- For the target system, run the
DEPLOY action to unpack or restore the (tersed) data sets. See DEPLOY for more details and the options that can be used.
- For the target system, adjust or copy your started
task procedures.