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. The focus of this post is to provide insight into Db2 development’s service philosophy, which is intended to simplify and otherwise improve maintenance processes for customers. This blog post does not discuss the customer maintenance strategy side of the partnership. Stay tuned for another post on that subject soon.
Simplifying maintenance rollout
Minimizing dependencies and reducing the need for complex coordination of maintenance rollout is a key focus area of the Db2 development maintenance strategy.
Db2 development does not ship PTFs that require a group-wide shut down to apply them. Such a violation of data sharing philosophy would result in the PTF being marked in error. To avoid such situations in the past, the development team employed the use of a pre-conditioning PTF followed later by an enabling PTF. The pre-conditioning PTF must be rolled out to the entire group before the enabling PTF is put on any member. Db2 development strives to ensure that the pre-conditioning PTF and the enabling PTF end up on different RSUs so that they can be applied separately. However, that approach alone is not sufficient to prevent difficulties when rolling out maintenance that often spans multiple RSUs.
Continuous delivery provides an alternative solution since enhancements can be tied to function levels, which guarantee that the necessary maintenance is applied across the entire data sharing group and cannot be removed. However, this approach does not work well for defect fixes because our strategy dictates that defect resolution should not be dependent upon a function level, so the use of pre-conditioning and enabling PTFs cannot wholly be avoided.
Another dependency can occur between code operating in a batch address space, typically Db2 utility code, and code executing in the Db2 address space. Code changes are designed to tolerate differences in code levels such that a PTF may exist on one side but not the other. The corresponding enhancement won't be available until the PTF is on both sides, but crucially there must be no regression to existing function from such a scenario.
Dependencies between different FMIDs are also to be avoided. Db2 ERLY code and base code is a good example: These are different FMIDs and therefore require separate PTFs. Any dependency between the two without toleration code creates challenges when rolling out maintenance.
Meaningful, reliable information
In an ideal world neither HIPER nor PE designations would be necessary, and Db2 development strives to reduce occurrences of both. However, these designations play an essential role in alerting customers about important defects and thereby help to prevent any impact from such. Note that HIPER and PE designations are completely independent of each other. An APAR can fix a PE and not be marked HIPER or vice versa. In brief, the overall strategy for HIPER and PE designations is as follows:
- Mark APARs HIPER and PTFs in error as quickly as possible.
- Provide as much accurate information as possible, as soon as possible, to aid impact and risk assessments.
- Provide operational bypass information and/or a relief aparfix or usermod if possible because a PTF in error cannot always be removed from the system.
- Prioritise resolution of HIPER and PE-fixing APARs even though the impact of encountering the problem the bad PTF introduces is low. The reason is the impact that the PE PTF can have on the ability to apply other maintenance.
Another aid to identifying important maintenance is the use of fix categories (FIXCATs) for PTFs associated with specific function. FIXCATs are intended to help customers identify maintenance that should be applied in certain situations, such as when considering enabling specific new functionality in Db2. The FTB capability originally introduced in Db2 12 is a good example of the use of FIXCATs. Note that FIXCATs are only created when considered necessary. For more information about FIXCATs, see IBM Fix Category Values and Descriptions.
Finally, Db2 development recognizes that ++HOLD information must be concise and accurate. Misleading or incorrect information is likely to result in a PTF being marked in error even if the code changes within the PTF are correct.
There is no question that product stability is of paramount importance to our customers and to Db2 overall, and in recent years the development team has proven the ability deliver significant new functionality through the service stream without jeopardizing quality. Although statistics demonstrate year-on-year declines in APARs, HIPERs and the number of PTFs in error, nevertheless Db2 development, and the IBM Z platform overall, remain focused upon continuing to simplify and enhance product quality and maintenance processes.
Update: Check out the follow-on post by Anthony Ciabattoni: Best practices for applying software maintenance in your Db2 for z/OS environment.