Tuesday, March 26, 2019

IBM Releases Db2 12 for z/OS Function Level 504

Early in March 2019, IBM announced the latest and greatest new function level, 504 (FL504), for Db2 12 for z/OS. For those of you not paying attention, starting with Version 12, IBM has moved to a continuous delivery model and has been releasing new functionality regularly. This means that new capabilities are rolled out periodically in what IBM calls function levels.

The first few new function levels were released slowly since the GA of Version 12, but IBM has indicated that it will begin releasing function levels much more quickly now that it has tested and perfected its continuous delivery methodology.

So, what’s new in FL504? Well, several things. Let’s start with better control over deprecated objects. Those of us who work with Db2 know that, over time, IBM deprecates functionality. When functionality is deprecated it means that it is on the list of things that will be removed from Db2 in the future. That is, deprecated features are still supported, but IBM does not recommend that you continue to use the features. Basically, deprecation gives users time to migrate their usage to another feature or capability until such time as support is entirely removed.

OK, so IBM has been deprecating features for a long time now, what is new in FL504? We now get the ability to prevent the creation of new deprecated objects, which is a good idea, right? If the feature has been deprecated by IBM you really shouldn’t be building new systems with that deprecated capability; the idea behind deprecation is to allow existing functionality to work until you can remove or replace it with support functionality. Click here for a full list of deprecated function in Db2 12.

Once you have enabled function level 504 you can prevent the creation of certain deprecated objects in your Db2 subsystems. Starting in function level 504, SQL statement in packages that are bound with APPLCOMPAT(V12R1M504) or higher, or with comparable SQL options in effect, are prevented from creating the following types of deprecated objects:
  • Synonyms
  • Segmented (non-UTS) or partitioned (non-UTS) tables spaces
  • Hash-organized tables

Hash-organized tables are an interesting new deprecation. They were introduced quite recently in Version 10. Evidently, they were not used by enough Db2 sites to justify their continued support.

Another new capability of function level 504 is support for Huffman compression of Db2 data. This uses the IBM Z hardware-based entropy encoding (Huffman) compression with the IBM z14 Compression Coprocessor (CMPSC). A new ZPARM, TS_COMPRESSION_TYPE, has been introduced (once you have implemented FL504) that controls the compression method for the entire Db2 subsystem. 

The TS_COMPRESSION_TYPE subsystem parameter specifies the type of compression algorithm to use when Db2 creates new compressed table spaces, loads into, and reorganizes existing compressed table spaces. Of course, the Db2 subsystem must be running on z14 hardware with Huffman compression enabled for this parameter to be used. Additionally, Huffman compression only applies to universal table spaces. All other table space types will use fixed-length compression regardless of TS_COMPRESSION_TYPE.

The third new capability of FL504 is support for the built-in functions provided by the IBM Db2 Analytics Accelerator  (IDAA). The support is pass-through only, meaning that you must have IDAA in order for these BIFs to work. Db2 will recognize that they are supported by IDAA and pass the work to the accelerator. Db2 for z/OS only verifies that the data types of the parameters are valid for the functions. The accelerator engine does all other function resolution processing and validation. Click here for more information on how Db2 determines whether to accelerate eligible queries or not


Finally, FL504 provides new SQL syntax alternatives to make it easier to port applications to Db2 from other platforms. This capability gives developers more options for specifying certain special registers and NULL predicates.

Table 1 below outlines the new syntax variations that are supported for several existing special registers:
Table 1. New Special Register Syntax Alternatives 
Existing Special Register
New Syntax Alternative
CURRENT CLIENT_ACCTNG
CLIENT ACCTNG
CURRENT CLIENT_APPLNAME
CLIENT APPLNAME
CURRENT CLIENT_USERID
CLIENT USERID
CURRENT CLIENT_WRKSTNNAME
CLIENT WRKSTNNAME
CURRENT SERVER
CURRENT_SERVER
CURRENT TIME ZONE or
CURRENT TIMEZONE
CURRENT_TIMEZONE

Additionally, ISNULL and NOTNULL are also now supported as alternatives for the IS NULL and IS NOT NULL predicates. For additional details, see NULL predicates.

Summary

Take some time to investigate this new functionality to determine whether it makes sense to introduce it to your Db2 environment. If so, be suire to read through the incompatible changes (such as if your Db2 has a UDF that matches one of the new IDAA BIFs, or a variable that uses one of the new syntax alternatives).  And only then build your plan for activating the new function level.

Also, be aware that if you are not currently running at FL503, moving to FL504 activates all earlier function levels. You can find a list of all the current function levels here.

3 comments:

  1. I was also somewhat surprised at the deprecation of Hash organized tables (especially as an ex-DL/1 DBA!)

    I thought a HDAM Db2 table was JUST what the world was waiting for - the ability to get a row with ONE I/O was pretty appealing

    Seems that there are less situations where retrieval of one row, with associated I/O delays, happens much less often than I thought. Just goes to show how efficient Db2 is at avoiding I/O delays!

    Luckily I don't come across that many (any?) implementations of Hash tables so I imagine they'll only be missed by a small number of us Db2 geeks

    ReplyDelete
  2. Oh, and one point on FL504 - it does not control utility usage of deprecated options (and if you follow Craigs link, there are a LOT of those)

    One that I have heard rumblings of discontent over is the CHANGELIMIT keyword on the Copy utility. It is a MUCH better proposition to have utilities determine at EXECUTION time what they should be doing. This makes creation and management of utilities far simpler. Certainly mush simpler than having to create JCL anew every time using some tool that does the same thing as CHANGELIMIT did

    Perhaps the only complaint I would lay at the door of CHANGELIMIT is that it is buried in utility control cards - it really ought to be an object level attribute (something like the RUNSTATS profiles) so that copy requirements can be managed in a single place. Using DSNACCOX doesn't deliver that level of centralized management either

    ReplyDelete
  3. Yes, Phil, I imagine that it is mostly old IMS DBAs like us who made the move to Db2 that were intrigued by hash-organized tables

    ReplyDelete