DB2 12 for z/OS, DRDA Applications and Application Compatibility Part Two
When considering how to manage managing Application Compatibility –
APPLCOMPAT – for your distributed applications which use the
NULLID packages, the main alternative to client-side configuration (discussed in the previous article) is server-side or DB2-side configuration. Although not without its challenges, the advantage of server-side configuration is that much of the necessary configuration is done in one place, using system profiles1.
System profiles were introduced as long ago as DB2 9, and have been successively enhanced in every release since then. They provide a range of capabilities, including setting ZPARMs at a more granular level, production modelling in test systems, and managing application-specific behaviour via
APPLCOMPAT, all using online change. Configuration information for system profiles is stored in two tables,
SYSIBM.PROFILE_ATTRIBUTES, and managed using the
-START PROFILE and
-STOP PROFILE commands. See “Monitoring and controlling Db2 with profile tables” for official IBM DB2 12 for z/OS documentation covering the entire range of system profile capabilities and procedures.
SYSIBM.DSN_PROFILE_TABLE is used to define the filtering criteria – what you are monitoring – and SYSIBM.DSN_PROFILE_ATTRIBUTES is used to define the attributes that are applied to what you are monitoring. You’ll see what that means as we go along.
Server-side APPLCOMPAT management
APPLCOMPAT levels using system profiles involves setting special register values for remote applications. In particular, that involves setting the CURRENT PACKAGE PATH special register.
First you need to create filters that identify which applications you want to direct to those collections with different
APPLCOMPAT attributes – that is, you need to create one or more profiles for those applications. Each row in
DSN_PROFILE_TABLE defines a single profile, with a unique identifier in column
PROFILEID. The eligible filters for setting special registers are listed below, but if we divide those filters into categories, you can only choose one category of filter per profile:
See Mark Rader’s presentation, listed below in Useful links, for more information about filtering categories.
If you create multiple profiles with different filtering categories that a thread or connection could match on, then you need to be very careful. To avoid unexpected – and undesired! – results, take into account the DB2 rules for applying multiple matching profiles, and the order of precedence.
Once you’ve created a profile, you then need to insert a row with a matching
PROFILEID value into
DSN_PROFILE_ATTRIBUTES to set the
CURRENT PACKAGE PATH special register. For example, you might insert a row with a matching
PROFILEID value, with the value “
SPECIAL REGISTER” in the
KEYWORDS column, and the value “
SET CURRENT PACKAGE PATH = ‘NULLID_V12R1M505’” in the
To make the profile effective, you need first of all to set the
PROFILE_ENABLED column in
DSN_PROFILE_TABLE for that profile to ‘
Y’. Secondly, you need to activate it by issuing the
-START PROFILE command. If the profile is already active, you need to issue the
-STOP PROFILE command first.
There are some practical challenges here.
- If you want granular control at the application or application program level over APPLCOMPAT levels, then you’ll probably want to filter on the
CLIENT_WRKSTNNAMEAnd where do they come from? They’re either coded in the application or set via client-side configuration. If you’re not already using the client information fields, making the necessary changes to use them could be a significant project in its own right. But once set up, this has benefits not only for system profiles, but also for workload classification by z/OS Workload Manager (WLM). And, once set up, you can then centralise further configuration changes at the system profile level.
- When you issue
-START PROFILE,all profiles where
PROFILE_ENABLEDis set to ‘
Y’ are activated. You can’t start and stop individual profiles via the
- If you are data sharing, you need to coordinate these commands across the data sharing group, as the
-STOP PROFILEcommands have member scope.
APPLCOMPAT level of applications that use the
NULLID packages is not straightforward. The key thing is to choose the strategy that best suits your organisation and set up a project to implement it. If you don’t do this, then all your applications will be limited to the lowest application compatibility level of all your applications.
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.
“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
1 Also known as system monitoring profiles; another term you’ll come across is system profile monitoring.« Previous | Next »