DB2 for z/OS New Function Watch – V12R1M502 is here
The advent of DB2 12 for z/OS brought with it a fundamental change in the way that IBM is delivering new DB2 capabilities. Gone are the monolithic version upgrades with 2-3 year release cycles that we knew so well in the past, IBM has instead embraced a more agile development model and is now shipping major new function in the maintenance stream in a process known as “continuous delivery”.
In support of this new approach, we now have the concept of Function Levels. Upon completing the initial migration from DB2 11, your DB2 12 environment will be at Function Level 100 (aka FL100, V12R1M100, BNFA or Before New Function Activation). This is the equivalent of the old Conversion Mode in previous releases of DB2, with the majority of the new V12 new features disabled. The -ACTIVATE NEW FUNCTION command can then be used at an appropriate time to enable the new V12 features, which will take the DB2 system to FL500 (aka V12R1M500, ANFA or After New Function Activation). This is the equivalent of New Function Mode / NFM in previous releases, and represents the highest function level available with the “base” DB2 12 code delivered at GA.
The function level concept works hand in hand with the application compatibility feature introduced in DB2 11, allowing the subsystem to be advanced to a new function level while individual applications can continue to run at earlier compatibility levels via the APPLCOMPAT BIND parameter and the CURRENT APPLICATION COMPATIBILITY special register.
In March 2017 IBM delivered the first new function level via the maintenance stream, with FL501 being delivered via APAR PI70535. This was very much a toe in the water as IBM got to grips with the new development approach, delivering only a minor (but occasionally useful!) new SQL built-in function called LISTAGG.
Function Level 502
Almost exactly a year after FL501 became available, IBM has announced the availability of FL502, via APAR PI95511. This is a more comprehensive set of updates that introduces transparent encryption of DB2 datasets, as well as the ability to explicitly cast numeric values to GRAPHIC or VARGRAPHIC. Importantly, this is also the first new function level that requires an update to the DB2 catalog, taking the catalog level to FL502.
Implementing FL502 therefore entails an extra step in the process compared to FL501 – see step 2 in the process overview below:
- Upgrade the code level to FL502 by applying the maintenance and pointing DB2 to the updated libraries. You will typically want to run like this for a while to allow the new code to “bed in” and ensure that there are no issues, as you can’t revert to an earlier catalog function level once you’ve completed the next step.
- Update the DB2 catalog using the CATMAINT process, which will be familiar to anyone that has run a DB2 version upgrade in the past. As before, you’ll need to schedule this at an appropriate time as CATMAINT can impact some types of workload. As catalog updates are a group-wide event, all members must be at the appropriate code level before this can be done.
- Activate the new function level using the -ACTIVATE NEW FUNCTION command.
- Once any incompatible changes introduced by the new function level have been remediated, you can allow individual applications to take advantage of the new functionality via the APPLCOMPAT BIND option and/or the CURRENT APPLICATION COMPATIBILITY special register.
- At some point, you may want to consider changing the APPLCOMPAT subsystem parameter, so that any BINDS or dynamic SQL prepares that do not explicitly specify an application compatibility level will automatically use the new function level.
Your DB2 system must be at FL500 or FL501 before you can move to Fl502. Some enhancements are delivered as part of FL502 that will make it easier to move directly to this function level as part of the DB2 11 upgrade process (provided you’re using z/OSMF to manage the upgrade).
As to the new FL502 functionality itself, the transparent encryption capability looks like it’s going to be a great way of securing data at rest without having to endure a painful/elongated/disruptive implementation process. We’ll take a look at some considerations for this (and other recent data security enhancements) in a future blog post.
IBM has taken a commendably cautious approach to agile DB2 development so far, but as a result the delivery has been anything but continuous! Work is under way on the next tranche of new function, and we can expect the delivery pace to begin to pick up from here on in with around 2-3 new function levels being released per year. If you haven’t had time to consider the implications of continuous delivery on your own DB2 environment yet, now would be a good time!
P.S. IBM is maintaining a web page that lists all of the currently available function levels and what they contain, and this should absolutely be on the bookmark list for any DB2 for z/OS professional. You can find that page here.
P.P.S. As at the time of writing, the PTF associated with APAR PI95511 still had several open APARs in its dependency chain so it might take a while longer before you’re able to move ahead with FL502.
One of Triton’s founding Directors, Julian is a highly experienced DB2 consultant with over 30 years relational database experience working with a number of clients within the insurance, telecommunications, banking and manufacturing sectors. In that time he has gained a significant amount of practical knowledge in many aspects of IBM’s Analytics portfolio, including experience in application programming, database administration, technical architecture, performance tuning and systems programming.
Julian is an IBM Gold Consultant, an IBM Champion and a frequent lecturer on DB2-related topics at international conferences such as IDUG.
In his rare moments of spare time Julian can be found working on home automation projects. https://en.wikipedia.org/wiki/Home_automation
« Previous | Next »