What is needed to move separate Alchemists from two separate LPARs to the same LPAR?
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?
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 occurs in several locations:
The OENAME may also occur:
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:
The OE_PREFIX may also occur:
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:
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:
IMPORTANT: Take backups before commencing!