How To
Summary
The existing documentation on migration does not cover completely all the ramifications that may be experienced when migrating to a new zWS in a phased approach (such as rolling out the new release one LPAR at a time). This technote will cover the main points of such a migration.
Objective
Make it easier to migrate from one zWS release to another over a period of time (i.e. not all trackers and controllers are migrated simultaneously)
Changes made April 4, 2023 are marked with a vertical bar "|" in the left margin.
Steps
For general documentation about migrating to a new release, refer to the technote:
https://www.ibm.com/support/pages/node/213015
(TWSz MIGRATION TO NEW RELEASE - BEST PRACTICES)
There are some things that have to be considered when doing a migration if you are not going to migrate EVERY zWS task at the same time- for example, if you plan to just migrate some trackers but not the controller, or if you plan to migrate some trackers but leave other trackers still running on their current release.
| (1) If you are going to have a 9.3 or 9.5 or 10.1 controller or tracker running on the same LPAR as other controllers or trackers from an
earlier release (9.2 or earlier), you have to ensure that the PI24927 fix has been applied to the EARLIER releases (this fix is in the
base code for 9.3 and higher. See this technote (which was formerly a FLASH):
https://www.ibm.com/support/pages/node/531133
The JES and SMF exits must always be assembled using the macro libraries from the HIGHEST release of zWS that is used.
These exits are DOWNWARD compatible EXCEPT if PI24927 is not correctly applied.
(2) If you are going to migrate your controller WITHOUT migrating all the trackers, you will need to run the EQQPMCKP job
from SEQQSAMP to merge the checkpoint files so that you do not lose positioning for the event datasets (EQQEVDS) for the
trackers which are not migrated. You do NOT need to run EQQPMCKP if all the trackers will have a newly allocated (empty)
EQQEVDS file. The use of the EQQPMCKP job is documented in the Planning and Installation Guide, chapter 6, section "Migrating the production environment".
| (3) Any PIF jobs you run must use the same release level of the SEQQLMD0 library as the controller they run against. This should not be a problem if you run the PIF jobs on the same LPAR where the controller runs, as you will probably have the correct SEQQLMD0 library in the LINK LISTfor this LPAR. However if you run PIF jobs on a different LPAR, and these PIF jobs do not have a STEPLIB to the SEQQLMD0 library that is used by the controller, you have to be careful with your LINK LIST version of SEQQLMD0. You will most likely want to keep the SEQQLMD0 in LINK LIST to be the one needed for the PIF jobs, even if this means using a STEPLIB for the zWS tasks like a tracker task,
For example, if on LPAR "A" you are going to run a 9.3 controller, and on LPAR "B" you are going to run a 9.5 tracker,
any PIF jobs that run an LPAR "B" for the LPAR "A" controller must use the 9.3 SEQQLMD0 library. In this case you may need
to have a STEPLIB in the 9.5 tracker pointing to the 9.5 SEQQLMD0 until you have finished migrating ALL of your zWS tasks.
If you do NOT have the 9.5 SEQQLMD0 library in LINK LIST you will still have to copy these load modules to some other
library in LINK LIST: EQQINITN, EQQSSCMN, EQQMINON.
(4) You need to consider any features which have "enabler" code for the dialog/controller that does not have to be installed on every tracker. For example, for the 9.3 release PI62521 (enabler) needs to be installed on the controller/dialog before PI62520 is installed for the tracker
(or you can install both PI62520 and PI62521 simultaneously.
(5) Any servers attached to the controller such as dialog servers must run at the exact same maintenance level (SEQQLMD0) as the controller- so any dialog user logging on to a remote controller must have access to this same SEQQLMD0 library either in LINK LIST or STEPLIB. So for example going back to the same configuration as in (3) above:
LPAR "A" running a 9.3 controller, and LPAR "B" running a 9.5 tracker, an ISPF user on LPAR "B" connecting to the controller
on LPAR "A" would have to be pointed to the 9.3 SEQQLMD0 (just like a PIF job). If you have the 9.5 SEQQLMD0 in LINK LIST
on LPAR "B" the dialog user would need to have the 9.3 SEQQLMD0 via STEPLIB.
Related Information
Document Location
Worldwide
[{"Type":"MASTER","Line of Business":{"code":"LOB35","label":"Mainframe SW"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSWL3F","label":"IBM Z Workload Scheduler"},"ARM Category":[{"code":"a8m0z0000001fw9AAA","label":"ZOS-\u003EIZWS-\u003EMigration to a new release"}],"ARM Case Number":"TS003960170","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]
Was this topic helpful?
Document Information
Modified date:
04 April 2023
UID
ibm16342825