Background
With the advent of DB2 12 for z/OS, IBM has moved to a more agile approach for delivering new function to DB2 customers, known as “continuous delivery”. Major new releases of DB2 will now happen more rarely, with smaller packets of new functionality being delivered via the routine product maintenance process. This allows IBM to develop and release new features much more frequently, thereby reducing “time to value” – a familiar DevOps message.
To allow DB2 customers to absorb this new function in a flexible and efficient way, IBM has also delivered a comprehensive set of capabilities that allow the “function level” of the overall DB2 system to be easily progressed while insulating individual applications from the impact of any changes via the “application compatibility level” set for each program.
Previously, upgrading a given DB2 environment to a new release was a system wide event – all applications hosted within that environment had to accept the new function at the same time (with all of the associated cost with regression testing etc) regardless of the business benefits they would accrue from the new functionality. The cost and complication associated with this monolithic approach could act as a significant disincentive.
The new capabilities provided by IBM in recent releases of DB2 have decoupled the system upgrade from the application upgrade. This allows the DB2 system to be upgraded and new function to be quickly made available to those applications that can derive the most business benefit, while allowing others to remain safely at the old function level until they are ready to move at a later date.
Function Level Upgrade Process
The diagram below illustrates the significant events involved in rolling out a new function level (level 501 in this case) to a given DB2 environment. In this first example, no changes are required to the DB2 catalog.
In this second example, we are jumping from function level 501 direct to 505 (all function levels are cumulative and customers can jump directly to a higher function level without having to take each step in between). As there are some DB2 catalog changes involved in one or more of these function levels, we now have an additional catalog upgrade step (at time T3). Note also that in this example Application B needs the new functionality more urgently, and is therefore able to move more quickly to take advantage of it than Application A (which won’t benefit significantly and therefore stays at function level 501 for the time being).
Summary
This blog post has provided a high-level view of the DB2 continuous delivery capability, illustrating how IBM have very effectively decoupled the upgrade of a given DB2 environment from the DB2 applications within it. This allows new function to be made available within a DB2 system as part of the routine maintenance activities (via the ACTIVATE FUNCTION command and optionally a catalog update) while leaving individual applications to adopt the new function (with the associated regression testing costs) at their own pace according to the underlying business benefit.
Further information on DB2 Continuous Delivery Function Level Upgrades can be found here
Triton offer comprehensive training for DB2 for z/OS version transitions providing DBAs’ with all of the information needed to quickly exploit new features. Talk to our expert team about DB2 12 training and education or our new version exploitation service.