The stability of Db2 for z/OS systems is legendary. That stability is based upon a partnership between Db2 development and the customer, where each party has a responsibility that cannot be wholly mitigated by the other. Haakon Roberts recently described the Db2 for z/OS development side of this partnership in his “Db2 for z/OS development maintenance strategy” post. This follow-on post focuses on the customer maintenance strategy side of the partnership.
SMP/E and Db2 for z/OS best practices need to be implemented for customers to achieve the desired objective of a robust and efficient Db2 for z/OS preventative maintenance strategy. A strong Db2 for z/OS preventative maintenance strategy includes selecting the appropriate PTFs to apply, frequency of applying preventative maintenance packages, well-designed procedures for PTF (patch) management, flexible SMP/E configuration, and the ability to maintain availability when applying corrective maintenance.
Db2 for z/OS preventative maintenance strategy
Achieving the highest availability depends on having an adaptive preventative maintenance process and adjusting it for your attitude toward risk in a changing environment and your goals for exploiting new releases and new features in support of application development. If you move up the adoption curve of a Db2 for z/OS release and adopt new features within a Db2 for z/OS release relatively early, then you should stay more current on your maintenance level and apply more frequent maintenance drops.
Your change management process should balance the risk of making ‘no-change’ versus making ‘a change’.
The further any given environment falls behind in terms of software maintenance, the greater the risk of encountering an event that could have been avoided due to a fix being readily available. It is sometimes thought that the best course of action is not to apply maintenance to a stable system. However, stability today does not necessarily imply stability tomorrow because workloads and other environmental aspects continue to evolve and change, creating exposures to latent issues associated with timing windows, workload dependencies, and so on.
An additional concern with back-level maintenance is that if a critical issue were to occur that necessitated applying an urgent solution, the risk profile of applying a single PTF in a production environment is much less than if many pre-requisites also need to be applied.
For a solid maintenance strategy, you should target applying maintenance every quarter with a defined methodology. Adopt a best practice methodology of applying four ‘major’ releases a year or as an alternative consider applying two ‘major’ and two ‘minor’ releases each year. For the ‘major’ releases, refresh your base from the latest quarterly RSU. Then construct two ‘minor release’ packages which cover HIPERs and PEs for the ‘minor’ releases and deploy them between the ‘major’ releases. Early adopters of new releases and/or new features should consider a strategy of applying preventative service more frequently.
On top of the initial starting strategy, your Db2 for z/OS maintenance experience over the past 12-18 months is also worth considering when determining the frequency of applying maintenance. If you encounter too many known problems where the fixing PTF is readily available, it indicates that you should apply more frequent drops of preventative maintenance service. Conversely, if you experience too many PTFs in error (PEs), you may want to apply preventative service less frequently.
PTF (patch) management
Well-designed procedures for PTF (patch) management are very important to maintain the highest level of availability. Important key components to the patch management process:
- Proactively identify the risk and exposure of critical missing HIPERs and/or PTFs that are now in error.
- Db2 for z/OS PTFs and enhanced HOLDDATA should be received frequently (e.g., weekly, bi-weekly)
- Important SMP/E report (ERRSYSMODS REPORT) needs to execute after regular receives of enhanced HOLDDATA against the production and development maintenance levels to produce a summary report
- The summary report will include the fixing PTF number when the PTF is available and include the HIPER reason code
- Mitigate the production exposure by expediting critical fixes to production after 1-2 weeks in test or implementing operational bypasses that can be followed until the corrective fix can be moved into production.
- During the deployment of a Db2 for z/OS maintenance package proactively monitor for PE fixers, new PEs and missing HIPERs on a weekly basis until production deployment.
- Unresolved PEs need to be examined and you need to determine the level of exposure and action to take
SMP/E configuration
Several SMP/E target zone representations of the Db2 for z/OS maintenance level are needed to support various levels of maintenance at any one point in time. At a minimum, three SMP/E target zone representations are recommended to support a production maintenance level, a new maintenance-level package and a production -1 level. Best practice to support this objective is to implement a single SMP/E environment configured with one global zone, and a minimum of three target and distribution zones. With the recommended configuration you can easily access each level of maintenance using common SMP/E processes. It also supplies the ease and flexibility of receiving PTFs and enhanced HOLDDATA once in the configured global zone and supports the ability to execute ERRSYSMODS REPORT on any of the SMP/E configured target zones.
Additional recommendations
Develop processes, procedures, and technical changes to implement ‘rolling’ maintenance outside of typically heavily constrained change windows. This includes separate Db2 for z/OS execution libraries for each Db2 for z/OS member and separate ICF user catalog alias per member. The benefit of a ‘rolling’ Db2 for z/OS maintenance process is that only one member of the data sharing group needs to be stopped at a time, which promotes continuous availability. As long as there are no application affinities, ‘rolling’ preventative maintenance can be applied and it is also possible to fall back to a prior level of maintenance without compromising application availability.
Conclusion
Db2 for z/OS customers strive to achieve continuous stability, availability, and optimal performance while exploiting new Db2 for z/OS features and functions to support system improvements and application development. Applying maintenance based upon a process that minimizes the risk of encountering defects whilst gaining the advantage of product enhancements can have a major beneficial impact on the running of your Db2 for z/OS systems.
A well-designed and adaptive Db2 for z/OS preventative maintenance strategy is foundational to achieving this objective.
#Db2forz/OS#db2z/os#Db2Znews