Introduction
This, the first of two articles on how to manage the Application Compatibility level for DRDA applications, provides an introduction to the subject and considers two of the ways of doing this. The second article will concentrate on perhaps the most promising method and discusses its drawbacks.
A very brief history of Application Compatibility
With the release of DB2 11 for z/OS, IBM introduced Application Compatibility, which is intended to make migration from one DB2 release to another less burdensome by separating system migration from application migration, and by allowing you to migrate applications individually once system migration has completed. Application migration is managed using two controls: the APPLCOMPAT BIND option, with a default option provided by the APPLCOMPAT system parameter; and the CURRENT APPLICATION COMPATIBILITY special register.
The original announcement was that DB2 11 would support the SQL DML syntax and behaviour of both DB2 10 and DB2 11, and that DB2 12 would support that of all three. Then along came DB2 12 with Continuous Delivery and Function Levels.
Application Compatibility was extended in DB2 12 in two ways: to support function levels as well as release levels; and to support SQL DDL and DCL as well as DML. It still supports an Application Compatibility setting of V10R1.
One of the big practical issues with Application Compatibility has always been how to manage dynamic SQL packages, and in particular how to manage the NULLID packages used by DRDA clients connecting via DB2 Connect or the IBM data server clients and drivers. That’s what this article is about.
Driver levels
This article wouldn’t be complete if it didn’t say at least something about driver levels. These are documented in various IBM articles and conference presentations, but a good place to start is the DB2 12 for z/OS Program Directory – you can find a link to the latest version on the “PDF format manuals for DB2 12 for z/OS” web page. That offers advice about the Data Server Driver, Data Server Client and DB2 Connect levels required for continuous delivery. In short, for any of these, you should be at Version 11.1 fix pack 2 or higher to specify an APPLCOMPAT of V12R1M501 or higher, but it’s recommended that you use the latest fix pack available.
If you search the web for blog articles or conference presentations, make sure you locate the latest information, as the advice is regularly updated.
The CURRENT APPLICATION COMPATIBILITY special register
One of the ways of setting the Application Compatibility level is to set the value of the CURRENT APPLICATION COMPATIBILITY special register. However, in DB2 12 you can only set the special register to a value that is less than or equal to the current APPLCOMPAT level of the allocated package. For example, if running under a package with an APPLCOMPAT of V12R1M505, you could issue SET CURRENT APPLICATION COMPATIBILITY = 'V12R1M504'.
On the other hand, if running under an APPLCOMPAT(V12R1M503) package on DB2 12 at function level V12R1M505, any attempt to SET CURRENT APPLICATION COMPATIBILITY = 'V12R1M505' will fail. The limiting factor for SET CURRENT APPLICATION COMPATIBILITY is the package APPLCOMPAT level, not the function level of the DB2 subsystem or data sharing group.
Ways of managing the APPLCOMPAT option for the NULLID packages
Once they’ve advanced one or more function levels. most DB2 sites will want to selectively move applications to a higher APPLCOMPAT setting, to be able to limit the amount of testing you need to do, and to be able to introduce the new functionality in a carefully controlled way. At least two of the methods of doing this require you to bind additional copies of the NULLID packages into appropriately named new collections, such as NULLID_V12R1M502 and NULLID_V12R1M505, with APPLCOMPAT attributes of V12R1M502 and V12R1M505 respectively.
It’s a good idea to explicitly keep a separate collection for every APPLCOMPAT level you need to use, so you might have one named NULLID_V10R1 for some of your older applications. You’ll then have the required packages ready if you find that an application isn’t using the correct APPLCOMPAT setting and you need to quickly direct it to the right collection.
The next task is to direct specific applications or application programs to use the packages in those different collections.
Three ways of doing this discussed in this short series are:
- Setting the
CURRENT APPLICATION COMPATIBILITYspecial register - Configuring the client to direct applications to the desired collection by defining multiple data sources at the client – client-side configuration.
- Configuring DB2 for z/OS to selectively direct applications to different collections using system monitoring profiles – server-side configuration.
Setting the CURRENT APPLICATION COMPATIBILITY special register
One way to handle this without using multiple collections is to rebind all the NULLID packages, setting APPLCOMPAT to the highest level you plan to use for all applications. If you did that, you’d have to retest all your distributed applications to make sure there was no unexpected change in behaviour and that all inconsistencies had been resolved. This is a high-risk strategy and only worth considering if you can be sure you’ve resolved all application inconsistencies and behaviour changes.
You could argue you can resolve that by setting the CURRENT APPLICATION COMPATIBILITY special register in the application. However, you’d still have to bind your NULLID packages with the highest APPLCOMPAT setting you plan to use. That’s because if you want to issue SET CURRENT APPLICATION COMPATIBILITY = 'V12R1M503', then the package must already be at a level of V12R1M503 or higher. This means you’d have to amend all other programs to set the special register to a lower level than the package.
Setting the CURRENT APPLICATION COMPATIBILITY special register involves a lot of programming effort, a lot of testing, and plenty of opportunity for errors to be introduced as you make the programming changes or even worse, fail to make changes where they are needed.
Client-side configuration
Client-side configuration involves creating a data source at each client, one for each different collection that will be used from that client, and then getting applications to open a logical connection to the correct data source. You associate the data source with a specific collection by using the currentPackageSet or currentPackagePath configuration option. The first of the these specifies a single collection id, the second a comma-separated list of collections on the server.
There are many ways of configuring clients to use data sources. For example, see the IBM documentation at “Getting started with IBM Data Server Drivers”, “Common IBM Data Server Driver for JDBC and SQLJ properties for DB2 servers” and “Connecting to databases for ODBC and CLI”.
Even once you’ve sorted out technically how you’re going to define the data sources and connect applications to those data sources, this is not a straightforward solution. If you’ve got dozens, or hundreds, or even thousands of clients to configure, with many distinct applications connecting to a single DB2 subsystem or data sharing group, you’re faced with a daunting administrative task. You’ve probably got a large number of client administrators to coordinate with, and potentially a large number of configuration settings to manage, and at the same time you’ve got to avoid disrupting the production service. Technically, client-side configuration is possible, and does work for some sites, but for others the administrative overhead is a challenge.
Next time
Which brings us onto the next article, where we’ll be looking at configuring DB2 for z/OS to selectively direct applications to different collections of the NULLID packages with different APPLCOMPAT settings by setting up system monitoring profiles – server-side configuration instead of client-side configuration.
If you are ready to advance function levels, but want assistance with managing the APPLCOMPAT settings for your distributed applications, you can get in touch with Triton Consulting here, via email or phone on 44 (0)870 2411 550.
Useful links
“Solving an Intermittent Production Problem Using Db2 for z/OS System Profile Monitoring”, a presentation by Mark Rader of IBM
“Db2 for z/OS: Using the Profile Tables to Direct DDF Applications to Particular Package Collections”, a blog article by Robert Catterall of IBM