Separating data from software

When you separate your data from your system software, you eliminate many tasks that must be performed each time you upgrade or replace your system software. An effective way to separate data from software is to use different DASD volumes for each.

You can minimize your installation and migration workload if you try to satisfy these objectives:

All system software volumes for the same product set at the same product and service levels must be identical.
All differentiation between systems must happen during or after IPL.
Only system software (and SMP/E data pertaining to it) should reside on system software volumes.

If you have not previously used a system replacement method to install software, you might find that it makes the installation considerably easier. Most of the work involves separating the following data from z/OS® software:

Customization data, including most system control files
Non-IBM software
IBM® products that run on z/OS
User exits
User data.

Your goal is to make it easier to replace the volumes that contain z/OS software, which are supplied by ServerPac or SystemPac (dump-by-data-set format). This allows you to more easily keep the other software and data you need to use with z/OS across migrations.

What to do with the non-ServerPac or non-SystemPac code

Ask if the code is still required. If not, do not carry it forward; if so, go to the next step.
Determine the usefulness and effectiveness of this code:
- Does it need to be updated for the new function in z/OS? If it does, you might need to upgrade a product or change the code.
If this code can be separated from the code delivered with ServerPac or SystemPac, place it in another product set. The product set must be placed on another volume so that future ServerPac or SystemPac installations will not overlay it. This requires moving it into separate libraries and SMP/E zones.
If the code cannot be separated from the code delivered with ServerPac or SystemPac, then it must be reinstalled in the same zones and libraries delivered with ServerPac or SystemPac. One way to do this is with the SMP/E BUILDMCS command.
Enable the useful and effective code to work with z/OS. This might mean using concatenation, reinstalling the code, or possibly reassembling it.

As you face the task of where to place the various types of code in your installation and enabling the code to work with z/OS, keep in mind the following advice:

Use SMP/E to install all modules you use with the operating system; place comments in each module that identify its function.
Where possible, use IBM-supplied exit points to control the system rather than changing the source or object code.
Where possible, use the dynamic exits service. This service allows you to refresh exits without losing availability. For information about the dynamic exits service, see z/OS MVS Installation Exits.
Where possible, place your exit code in libraries placed on different volumes from IBM code. This allows compatible exits to stay in place when you start to use a new level of the operating system, and reduces migration time.

The following list includes the different kinds of code found in an installation, and describes actions that ensure that the code you want to use with z/OS survives the installation process and is enabled to run with z/OS. The list includes the ways you insert customer-written code into an operating system environment or change the operating system code:

IBM products that run on z/OS: This category includes the following:
- Products that are no longer marketed. Such products are not available through ServerPac. To avoid having to reinstall these products every time you reinstall a z/OS ServerPac order, place these products, if possible, in separate product sets with separate libraries or SMP/E zones.
  Note: SMP/E provides the BUILDMCS command to copy a product from one zone to another. Use BUILDMCS to either (1) move the product to new (target and DLIB) zones, if the product is not available in ServerPac and if it can be installed in a separate zone, or (2) create an installable copy of the product with its service already integrated so that it can be reinstalled in the new zones shipped with ServerPac, which can be faster than reinstalling the product and its service from scratch. This use of BUILDMCS applies to vendor products and to IBM products that are still in service but have been withdrawn from marketing. For the information you need to use the BUILDMCS command and restrictions on its use, see SMP/E for z/OS Commands.
  
  Products that are no longer marketed but are still service supported are available for selection in the SystemPac shopping list. Where appropriate, when you order a SystemPac, have these products separated into their own SMP/E zone or volume using the local order entry tool.
- Available MVS™ SREL products, such as PSF or NetView®. You can order these products in the same ServerPac or SystemPac as z/OS.
- Non-MVS SREL products, such as the subsystems (DB2®, CICS®, IMS™, NCP, and WebSphere® Application Server). Check to make sure that these products do not need to be upgraded to run with z/OS by doing the following:
  - Do cross-zone requisite checking.
    - For ServerPac, run the SMPREP job or the REPORT CROSSZONE command.
    - For CBPDO, do cross-zone requisite checking during APPLY processing, as described in z/OS Program Directory at http://www-03.ibm.com/systems/z/os/zos/installation/. If you did not perform cross-zone requisite checking, run the REPORT CROSSZONE command.
    For information about the REPORT CROSSZONE command, see SMP/E for z/OS Commands. For information about the SMPREP job, see ServerPac: Installing Your Order.
  - Check the cross-product dependencies section of the applicable PSP buckets.
  If you need to upgrade a non-MVS SREL product, order it in a separate ServerPac or use SystemPac. SystemPac provides the option of integrated subsystems. The package you order can include z/OS and no more than one of the subsystems (DB2, CICS, IMS, NCP, or WebSphere Application Server). The deliverable is shipped to you integrated and requires just one installation, by way of either the CustomPac Installation Dialog or a full volume restore.
  
  Should you choose to order subsystems with z/OS in one single SystemPac order, separate your subsystems from the z/OS SREL products to gain maximum flexibility in the future. The local order entry tool enables you to do so.
User modifications: This category includes:
- User exits
- Updates to source code
- Zaps
- Changes to ISPF elements, such as panels, CLISTs, and EXECs.
Isolate this code from the IBM code when possible by:
- Placing it in a separate library that can be concatenated ahead of the IBM libraries
- Using the dynamic exits service and placing the code in separate libraries.
One simple way to tell whether user modifications must be reworked for the new level of software is to try to reapply them and see how many of them SMP/E will install. Those that SMP/E will not install will need to be changed for the new level of software. This method works if you have followed the IBM advice about using SMP/E to install the code.

If your user modifications have been installed using SMP/E, you can get the list of user modifications you now have installed by running a LIST SYSMODS USERMODS command against each of your existing target zones. You will need to evaluate each user modification to determine whether it is still needed and whether it needs to be reworked to be reinstalled.

To save time, you can run SMP/E REPORT SYSMODS commands, specifying each existing target zone on the INZONE keyword and each corresponding new target zone on the COMPAREDTO keyword. (The ServerPac SMPREP job includes a REPORT SYSMODS.) SMP/E will create SYSMODS Comparison Reports that identify user modifications that are installed in the old zones and are applicable to FMIDs in the new zone. It will also create a job in the SMPPUNCH data set to reinstall them (and any applicable PTF and APAR SYSMODs) in the new ServerPac or SystemPac system's target zone.

Some of your user modifications might be listed by the LIST commands but not included in the SYSMODS Comparison Reports. These user modifications apply to FMIDs that are not installed on your new system. Some FMIDs might have been replaced by others, in which case you will have to rework applicable user modifications before reinstalling them. The others might have no replacements and their user modifications are almost certainly no longer needed.

For FMIDs that have changed, evaluate the usermods and rework them, if necessary.
Keep the source for all user modifications in a single data set, and document each modification. Such documentation often includes:
- The name of the part (for example the module) affected by the usermod
- The business justification for the usermod
- When the usermod can be eliminated
- The purpose of the usermod
- Instructions for reworking or reinstalling the usermod
- The product and current FMID to which the usermod is applied.

Some actions not only make a ServerPac or SystemPac (dump by data set format) installation easier, but can also organize code and data so that other tasks are easier. Here are some recommended actions:

SYSRES: Some SYSRES volumes are not large enough to hold all the z/OS target libraries. If you have such a volume you can move some of the data sets off SYSRES. For help in determining which ones to move, see Recommended data set placement.
Parmlib and proclib:
- Do not make changes to the parmlib and proclib data sets that you use for production until you have seen what IBM sends in the copies that IBM ships with z/OS. Compare the IBM copy to your production copy or use the IBM library in your production concatenation and decide which of IBM's parmlib and proclib specifications apply to your environment and manually make the changes. Copy any new parmlib and proclib members into your production copy. Then, tailor your production copy, as needs require.
- In a multisystem environment, try to have SYSRES, master catalog, and system-type libraries (such as IODF, SYS1.DAE, and RACF® data) common to as many systems as is practical. Use symbolic substitution to reduce the number of parmlib and proclib members that are unique to specific systems.
  Using symbols in parmlib members makes it easier to share a parmlib member across multiple systems. z/OS provides a tool that helps you to verify that your system symbolics work successfully in your own configuration before you put the parmlib member into production. This tool, called the parmlib symbolic preprocessor, runs as an ISPF dialog to interactively display the results of symbol substitution before you IPL the system and use the symbols. You can find the tool in members SPPINST and SPPPACK in SYS1.SAMPLIB. Information about setting up and using the tool appears in the prolog of the SPPINST member.

Use parmlib concatenation to separate your tailored parmlib members from the IBM-supplied parmlib members. See information about parmlib concatenation in the description of the LOADxx parmlib member in z/OS MVS Initialization and Tuning Reference.