System migration considerations
There are as many different possible z/OS configurations as there are z/OS customers. As a result, it is impossible to provide a document that comprehensively describes all the considerations for migrating from one Application Developers Controlled Distribution (ADCD) release to another for every customer.
However, certain “good housekeeping” practices exist that can make it easier when you are ready to move to a new ADCD release or a new release of the 2017 Sysplex Extensions. This chapter describes those practices.
This chapter includes the following topic:
2.1 System layout recommendations
Although an ADCD system is not for use in production environments, there is still value in configuring it in a manner that minimizes the time and effort to migrate it to a newer release in the future.
In an ideal scenario, you would download the volumes that are associated with a new ADCD release, perform an IPL with the new sysres, and everything would work as expected with no extra customization or effort. The other extreme scenario is that you must start from scratch when you install a new release and repeat the same customization process every time you move to a new release.
Although it is unlikely that you can achieve the ideal scenario, you can take actions to bring you closer to that scenario rather than the other, extreme scenario. This chapter provides advice to help you achieve this goal.
2.1.1 Avoiding updates to ADCD-provided volumes if possible
When users move to a new ADCD release, they often want to carry over as much existing customization as possible, without having to manually reapply all of the changes to the new ADCD-supplied data sets. A good way to come close to this outcome is to do your utmost to avoid changing ADCD-provided volumes. It helps with this process if you think of data sets as falling into one of the following categories:
•SMP-maintained software libraries. These data sets should be treated as though they are read-only, with the only updates being applied by SMP/E when you are applying service or performing an upgrade.
•System data sets that contain information that is specific to that system or sysplex, such as your IBM RACF® databases. These databases are provided by ADCD, but they also contain information that is unique to your environment.
•Your own programs and data.
Roughly corresponding to these categories, you ideally have the following types of DASD volumes:
•Volumes that contain SMP-maintained software libraries, which are known as system volumes. These volumes are supplied as part of the ADCD package and are replaced in their entirety when you move to a new ADCD release.
•Volumes that contain data sets that are updated by the system or by the people maintaining the system (for example, the page data sets, RACF data sets, couple data sets (CDSs), Parmlib, Proclib, and others). Known as system work volumes, these volumes are supplied by ADCD. However, you often must perform some migration activity to carry forward some of the information in these data sets to the next release.
•Volumes that contain your data, programs, databases, and so on. These volumes are known as user volumes and are not provided by ADCD.
In practice, several of the ADCD volumes are a mix of system volumes and system work volumes. ADCD volumes are structured in this way to minimize the number of volumes that are required for the complete ADCD environment. For example, the D2C521 volume contains CICS SMP-maintained libraries and CICS runtime data sets. Nevertheless, the concept of trying to segregate volumes that are replaced by a future ADCD release from volumes that you carry forward from one release to the next is still a valuable one.
System volumes
The sysres volume is a good example of a system volume. Typically, you do not change any of the data sets on that volume. Taking the May 2017 ADCD release sysres volume as an example, the following data sets are exceptions to the recommendation about treating that volume as though it was read-only:
•SYS1.PARMLIB
•SYS1.PROCLIB
Although you can change the SYS1.PARMLIB and SYS1.PROCLIB data sets manually, try to apply any Parmlib or Proclib changes to the USER.Z22D.PARMLIB and USER.Z22D.PROCLIB data sets. Those data sets are placed ahead of the SYS1 equivalents in their respective concatenations. For example, if there is a PROGBO in the SYS1.PARMLIB data set and in the USER.Z22D.PARMLIB data set, the member from the USER.Z22D.PARMLIB data set is used.
If you can adhere to this guidance, moving your SYSRES volume to the new ADCD level should be a lot easier and less time consuming.
The product volumes (D2PRD1, D2PRD2, and D2PRD3) are more examples of system volumes because the data sets that they contain should be updated only by SMP/E for z/OS.
The subsystem volumes (those volumes that are used by DB2, CICS, and so on) as provided by ADCD are something of a hybrid. They contain SMP-maintained data sets and data sets that are used by your subsystems.
System work volumes
The system work volumes are provided by ADCD, but they contain data that is specific to your environment (for example, D2SYS1, D2PAGA/B/C, D2USS1/2, and D2CFG1). Unfortunately, no simple one-size-fits-all migration process exists for these volumes.
|
Tip: The VOLSERs that are used in the bulk of this document (D2nnnn) reflect the May 2017 ADCD. If you install the 2017 Sysplex Extensions on top of a more recent ADCD release, you need to adjust for the different VOLSERs used by your ADCD release. For example, the November 2017 ADCD release (the first release to deliver z/OS 2.3) uses VOLSERs such as A3nnnn.
|
Several of these volumes contain data that you might be willing to discard when you move to a new release, such as your JES2 spool, SMF data sets, page data sets, log recording data sets (LOGRECs), and dump analysis and elimination (DAE) data sets.
The only data set on your sysres volume that will be changed is the backup RACF database data set. When you upgrade to a new release, you can start with a new ADCD-provided RACF database, or you can use a RACF utility to copy the RACF database from your old release over to the new release.
|
Tip: You can use the RACFUNLD and DBSYNJCL jobs in the ADCD.*.JCL data set to unload the RACF databases and then compare the old database to the “new” one. The DBSYNJCL job also creates RACF commands to bring the two databases in line with each other. See the DBSYNDOC member of ADCD.*.JCL for information about using the DBSYNC exec.
If you want to use a copy of the old RACF database, use the IRRUT200 utility to create an exact copy of a RACF database. For more information about the RACF database utilities, see the RACF database utilities section in z/OS Security Server RACF System Programmers Guide, SA23-2287.
|
Other volumes contain data that you likely want to merge with the version of that data set that is provided by the new release, such as your Master catalog,1 RACF database, and SMS SCDS.
|
Tip: The ADCD-provided VATLST00 member mounts the D2SYS1 volume as a storage volume, meaning that things such as local TSO data sets are likely to be allocated on that volume. To save the work of moving those items to another volume when you replace D2SYS1 in the future, use a VATLSTxx member other than VATLST00 and ensure that it points at a local volume (WORK01, for example).
|
Review the contents of these volumes and identify how you can handle each data set when the time comes to upgrade to a new ADCD release.
The 2017 Sysplex Extensions package provides DB2 and CICS subsystems that are tailored to run in a Parallel Sysplex environment. They use the ADCD-provided CICS and DB2 software libraries. All of the other data sets that you need to run the subsystems that are provided by the 2017 Sysplex Extensions are contained on a pair of SMS-managed volumes (one volume for CICS and one for DB2).
Packaging the subsystems in this way makes it easier for you to add or remove those subsystems. It minimizes the number of steps that are required to add those subsystems and makes it easier for you to migrate these subsystems from one ADCD release to another. If you plan to add your own subsystems, you can use this model to build the subsystems in a way that eases the migration effort when you move to a new ADCD release.
Future releases of the 2017 Sysplex Extensions are expected to follow this model. That is, the volumes that contain the subsystem work data sets will be delivered with each new release. This configuration provides the option of replacing volumes with the new volumes (and cold starting subsystems) or carrying your volumes forward. However, in the latter case, you must follow the migration process that is provided by the new release of CICS or DB2.
zFS data sets
An increasing number of products provide their own zFS data sets. The zFS data sets display the same complexities that apply to many other software data sets:
•Some of them contain files that get updated on an ongoing basis, such as logs.
•Some of them are read only, and should be shared by all systems in the sysplex.
•Some of them require a separate instance for each system in the sysplex.
•Some of them require a separate instance corresponding to each set of target data sets for that product.
ADCD delivers over 70 zFS data sets, and it is outside the scope of this deliverable to address the sysplex considerations for all of those data sets. We do handle the sysplex needs of the zFS data sets that are delivered on the D2USSn volumes. For those data sets that require a separate instance for each system, we create a clone for the second instance and provide an updated BPXPRMxx member to reflect the new file names and mount points.
For the zFS files that are not on the D2USSx volumes, we do not provide clones or updated BPXPRMxx members. If you need to create such clones, you can use the provided OMVSCLON and MKDIR jobs as a sample to create your own copies.
User volumes
Most importantly, do your utmost to avoid adding new data sets to the ADCD-provided volumes. If you have data sets that you know you want to carry forward from one ADCD release to another (such as those containing application programs, your own data, load libraries, and JCL), place those data sets on volumes (called user volumes) that are not replaced by the new ADCD volumes or by the Sysplex Extensions. Also, ensure that they are cataloged in user catalogs that are also on user volumes.
In as far as reasonable, place any new data sets that you create on a user volume that does not contain any system data sets. The objective is to maintain a clear delineation between ADCD-delivered volumes and data sets, and your own volumes and data sets. The fewer changes that you must make to anything on an ADCD-provided volume, the easier it is to migrate to a new ADCD release.
2.1.2 Catalogs
Expect that every new ADCD release contains new data sets in support of new software products or new releases of existing products. These data sets often are cataloged in the Master catalog that is provided with the new ADCD.
When you complete an IPL of the new ADCD release with your Master catalog, you cannot access those data sets unless you specify the volume serial. Therefore, part of the migration to a new ADCD release includes creating a Master catalog that contains these data sets:
•All of the data sets on the new ADCD system
•All of your own data sets that you were using on the previous release
When you are deciding how to create this superset Master catalog, you have the following choices:
•Identifying the new data sets and adding them to your current Master catalog.
•Identifying the entries (data sets, user catalogs, aliases, and so on) that are in your current Master catalog that are not in the new Master catalog. Then, identifying the subset of entries that you want to carry forward to the new release and adding them to the new Master catalog.
In either case, the task is greatly simplified if you maintained a “clean” Master catalog, which is a catalog that has a minimum number of changes to the Master catalog that was delivered with your current ADCD release. One of the best ways of achieving a “clean” Master catalog is to catalog all of your user data sets in user catalogs and place those catalogs on your user volumes.2
There are a few restrictions that are related to the use of user catalogs. If a data set that is specified in any of the following Parmlib members is cataloged in a user catalog, the VOLSER that the data set is on must be specified in the corresponding Parmlib member:
•COUPLExx
•IEAFIXcc
•IEALPAxx
•LNKLSTxx
•LPALSTxx
•MSTJCLxx
•LOGREC data sets
•Vitual input/output (VIO) journaling data set (often called SYS1.STGINDEX)
•Data sets in the Parmlib concatenation (for example, SYS1.PARMLIB, ADCD.Z22D.PARMLIB, and USER.Z22D.PARMLIB)
Although this list is long, most of the affected data sets are system data sets. Therefore, they normally are cataloged in the Master catalog.
A good way to ensure that you do not forget to create an ALIAS that points at a user catalog when you create a high-level qualifier is to severely restrict the number of users that have RACF update access to the Master catalog. This restriction helps highlight situations where a data set might be cataloged in the Master catalog because no corresponding ALIAS was defined.
Another useful tip is to use a consistent naming convention for user catalogs, for example, UCAT.PROJECTA. This naming convention makes it easy to differentiate between aliases that are delivered with ADCD (the ADCD-provided user catalogs all have a high-level qualifier of USERCAT) and aliases that were created by you (and, therefore, point at a user catalog that is called UCAT.xxxxx).
2.1.3 Minimizing changes to provided Parmlib members
Most (but not all) Parmlib members support the ability to concatenate multiple members. For example, assume that the IGGCAT00 member contains a parameter that you want to override.
One way to achieve this override is to update the IGGCAT00 member in the ADCD.Z22D.PARMLIB member. Although this method works, the next ADCD release includes a new ADCD.anna.PARMLIB data set, which means that the change you made to the IGGCAT00 member in ADCD.Z22D.PARMLIB is lost.
Another option is to copy the entire IGGCAT00 member to your USER.Z22D.PARMLIB member. Because USER.Z22D.PARMLIB is ahead of ADCD.Z22D.PARMLIB in the Parmlib concatenation, the USER.Z22D.PARMLIB version is used and the copy in ADCD.Z22D.PARMLIB is not used.
|
Important: If a member with the same name is in two data sets in the Parmlib concatenation, only the first member in the concatenation is read when the IPL occurs or if you issue a command that causes the member to be read.
|
This method is effective from the perspective that you can easily copy your USER.Z22D.PARMLIB data set contents to the corresponding data set in the new ADCD release. However, it has the drawback that if IBM updates the 00 member, your system does not pick up that change. The system only reads the first member if there are multiple identically named members.
For components that support multiple concatenated members, the ideal solution is to create a member with a meaningful suffix (something other than 00) and to populate that member with only the parameters that you are overriding. Then, specify something such as CATALOG=(00,PS) in your IEASYSxx member. This specification results in the 00 and the PS members being read during the IPL. If IBM makes changes to the 00 member, those changes are picked up during the IPL.
Unfortunately, not every component supports the use of concatenated Parmlib members. Nevertheless, this methodology is valuable for those components that do support this use.
For more information about effectively managing Parmlib members, see the “Description and use of the Parmlib concatenation” in z/OS MVS Initialization and Tuning Reference, SA23-1380.
2.1.4 Simplifying your system structure
Try to keep your system structure as simple as possible. Simplicity makes the administration of your system easier and less prone to human error. It also can significantly reduce the problem determination effort if something is not working as planned.
A good example of this guideline is to minimize the number of Parmlib members through the intelligent use of system symbols. Example 2-1 shows an excerpt from the IEASYSB1 Parmlib member. The highlighted text shows that the page data set names contain the system name as the second qualifier.
Example 2-1 IEASYSB1 Parmlib member
MLPA=00, SELECT IEALPA00, MLPA PARAMETERS
MSTRJCL=00, SELECT MSTJCLEX, MASTER JCL
OMVS=00, SELECT BPXPRMCS
OPI=YES, ALLOW OPERATOR OVERRIDE
PAGE=(SYS1.S0W1.PLPA.PAGE,
SYS1.S0W1.COMMON.PAGE,
SYS1.S0W1.LOCALA.PAGE,
SYS1.S0W1.LOCALB.PAGE,L),
PAK=00, SELECT IEAPAK00
PLEXCFG=ANY,
Example 2-2 shows an excerpt from the IEASYSB2 Parmlib member. The highlighted text in this example shows that the two members are identical, except for the page data set names.
Example 2-2 IEASYSB2 Parmlib member
MLPA=00, SELECT IEALPA00, MLPA PARAMETERS
MSTRJCL=00, SELECT MSTJCLEX, MASTER JCL
OMVS=00, SELECT BPXPRMCS
OPI=YES, ALLOW OPERATOR OVERRIDE
PAGE=(SYS1.S0W2.PLPA.PAGE,
SYS1.S0W2.COMMON.PAGE,
SYS1.S0W2.LOCALA.PAGE,
SYS1.S0W2.LOCALB.PAGE,L),
PAK=00, SELECT IEAPAK00
PLEXCFG=ANY,
An alternative is to maintain a single IEASYSxx member, which is similar to the one that is shown in Example 2-3. In this case, the system name in the page data set name is replaced with the system symbol &SYSNAME. When that member is read by system S0W1, the &SYSNAME in the page data sets is replaced with S0W1. When it is read by S0W2, it is replaced by S0W2.
Example 2-3 IEASYSxx Parmlib member
MLPA=00, SELECT IEALPA00, MLPA PARAMETERS
MSTRJCL=00, SELECT MSTJCLEX, MASTER JCL
OMVS=00, SELECT BPXPRMCS
OPI=YES, ALLOW OPERATOR OVERRIDE
PAGE=(SYS1.&SYSNAME..PLPA.PAGE,
SYS1.&SYSNAME..COMMON.PAGE,
SYS1.&SYSNAME..LOCALA.PAGE,
SYS1.&SYSNAME..LOCALB.PAGE,L),
PAK=00, SELECT IEAPAK00
PLEXCFG=ANY,
System symbols are a powerful tool for simplifying the task of managing your systems. Symbols are defined in the IEASYMxx member. In that member, you can specify values for symbols that are used on every system in the sysplex. You can also filter based on the LPAR name or virtual machine name (or zPDT host name) so that the same symbol resolves to different values, depending by which system they are referenced.
In addition to Parmlib members, system symbols can be used in procedures, TSO logon procedures, and system commands. Starting with z/OS 2.1, system symbols also (optionally) can be used in normal job JCL (including in SYSIN statements) and even in jobs that are submitted by using the internal reader. A future update to this document will contain some real-world examples of how this capability might be used.
Also, starting with z/OS 2.1 is the ability to dynamically change system symbols by using a system command (SETLOAD IEASYM,xx). In z/OS 2.2, the maximum length of a system symbol was increased to 44 characters so that a system symbol can contain a value, such as a data set name or an IP address.
If you refer to the IEASYMPS member in the SYSPLEX.PARMLIB data set after you download the 2017 Sysplex Extensions volumes, you can find examples of system symbols to simplify the members that are used for the sysplex.
2.1.5 Summary
This release of the 2017 Sysplex Extensions is a significant change from the previously available ADCD sysplex support.
However, future releases plan to expand on the examples and advice that is provided in this chapter. If you have any suggestions that you believe might benefit other zPDT users, send an email to: [email protected] or [email protected].
1 There are several tools on the CBT tape that might help carry over catalog entries to a new Master catalog. In particular, consider the MCNVTCAT tool. For more information, see CBT V494 Final Version.
2 To support RLS management of user catalogs, place any new user catalogs on SMS-managed volumes. Even if you do not intend to use this capability now, placing user catalogs on SMS volumes now can greatly simplify the migration to RLS-managed catalogs in the future and does not have any downside in the interim.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.