What is needed to move separate Alchemists from two separate LPARs to the same LPAR?

Products

Alchemist TPX - Session Management Vman Session Management for z/OS

Issue/Introduction

Description:

The two current Alchemist systems are completely separate, no connections and they will continue to be separate in the new environment on the same LPAR.
They have completely different target libraries. Production zone names between the two instances of Alchemist are different (PRD on one, PROD on the other),
However, each OE (Operational Environment) uses the same OENAME and prefix.

Are there any challenges to changing OENAME and prefix on one of the tasks?

Environment

Release:
Component: ALCMST

Resolution

The first thing to consider is if DS (Distributed Services) is in place with one or both of the Alchemist tasks. If so, then that adds another dimension of complication.

If a shared DS system is being used by multiple operational environments, those OE's would need to have different names. So if there are two OE's with the same name, at least one of them will not be using DS - in which case the easiest option would be to rename the base system, i.e. the one that is not using DS.

Without the DS complication, it comes down to this:

There are two items - the OENAME and the OE_PREFIX, both of which need to be unique for each operational environment.

The OENAME needs to be unique for various reasons, not least so that communications between different STC can be correctly directed via our cross-memory communication mechanism.
The OE_PREFIX needs to be unique in order for each operational environment to have a uniquely named REQUEST dataset, and various other control datasets.

The OENAME occurs in several locations:

within the PARMLIB parameters used by started tasks (NAME=oename parameter line)
within ISPF panels that set the ASRXOEN control variable. To allow for the possibility there may have been some panel tailoring, scan the panel library to find all occurrences of ASRXOEN which set the variable to the existing OENAME value.
within various Alchemist JCL PROCs, such as the Alchemist related started tasks and PROCs which execute various Alchemist utilities. References within JCL procs can be either by specification of OENAME=oename within the PARM field or, in rare cases, within SYSIN data. It is, therefore, recommended to scan all relevant PROCLIBs for the existing oename value.

The OENAME may also occur:

within the ZSSCITCP member. Here, for non-SSCI-protocol servers such as the LMI, Web, SCC, and Eclipse interfaces, and the ESP System Agent, lines may be coded in the form: tcp_address:port Roename# PREFIX=prefix KAL=seconds;comments
within customer developed PCL. PCL procedures should always use the ASRENV variable to access the current OENAME, rather than having the OENAME hard-coded within the PCL. However, to allow for the fact that this convention might not have been followed, scan the PCL library(s) for occurrences of the existing OENAME.

There should be no problem changing the OENAME of an operational environment, so long as none of the OE's related STCs (or utility programs) are running at the time the change is made, and providing also that all of the above instances are updated in tandem.

The OE_PREFIX always forms the leading DSN qualifier for the REQUEST dataset. It usually also forms the leading qualifier for other control datasets, including AUDIT, SCF, ZCL, ZCX and ZXL datasets.

The OE_PREFIX value occurs:

within the PARMLIB parameters used by started tasks (PREFIX=oe_prefix parameter line)

The OE_PREFIX may also occur:

within ISPF panels that set the ASRXPRFX control variable. (To allow for the possibility that the customer may have done some panel tailoring, I would recommend scanning the panel library to find all occurrences of ASRXPRFX which set the variable to the existing prefix).
within various Alchemist JCL PROCs, such as various Alchemist utilities, either by specification of PREFIX=oe_prefix within the PARM field, within SYSIN data, or in DD statements that reference control datasets. For example within the DSN= parameter as the leading qualifier. Scan relevant PROCLIBs to find all occurrences of the existing oe_prefix.
If using SCF, SCF dataset names are contained in the SCFICO source member (ZDAICO DATABASE,DSNAME= ) and these dataset names also commence with the oe_prefix.

Again, there should be no problem changing the OE_PREFIX for an operational environment, so long as none of the OE's related STCs (or utility programs) are running at the time the change is made, and providing also that all of the above instances are updated and all relevant datasets are renamed in tandem.

Lastly, it is possible within the system-level configuration (dataset allocation parameters) that an alternative naming convention for the AUDIT, SCF, ZCL and ZXL datasets, other than the defaults as depicted on the sample panel below may have been specified:

ALCHEMIST 5.3.1. System-Level Configuration - Data-set Allocation.
Command ===> OE-Name: ######

The following configuration values are used to specify allocation data forsystem-level and zone-level data sets, excluding target libraries. Target library data-set names are specified in the Entity Type Definition (ETD). The configured dsnames below MAY commence with <PREFIX> which will be substituted with the value specified in the started task PARMLIB. Additionally, for the ZCL and ZXL data sets, the dsname MUST contain <ZONE> at some point, and this will substituted by the zone name for the zone to be accessed.

The WORK Unit indicates the unit name which Alchemist should use to allocate temporary data sets.

   Parameter      Configured Value                         System Default     
   =========      ================                         ==============     
   AUDIT DSName:  <PREFIX>.AUDIT                           <PREFIX>.AUDIT     
   DCL DSName:    <PREFIX>.DCL                             <PREFIX>.DCL       
   ZCL DSName:    <PREFIX>.<ZONE>.ZCL                      <PREFIX>.<ZONE>.ZCL 
   ZXL DSName:    <PREFIX>.<ZONE>.ZXL                      <PREFIX>.<ZONE>.ZXL 
   Work Unit:     SYSDA                                    SYSALLDA

If alternative (non-default) names are being used for one or more dataset types, these may already be unique and so may not need to be changed at all. If they do need to be changed, the change for a particular dataset type would involve:

unlocking the system configuration,
updating the configured value on the above panel,
renaming the related dataset(s),
updating any JCL references to the renamed dataset(s). and finally.
relocking the system configuration.

In summary, with no overlap in target file dataset names, and maintaining separate Alchemist tasks after moving to the same LPAR you can change OENAME and PREFIX.

Changes can also be made independently and prior to LPAR change:

Change OENAME on existing LPAR
Change prefix on existing LPAR
Migrate to new LPAR and implement DS (Alchemist Distributed Services) as required.

IMPORTANT: Take backups before commencing!