DB2 12 for z/OS, DRDA Applications and Application Compatibility Part Two

Server-side configuration

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 profiles¹.

System Profiles

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.DSN_PROFILE_TABLE and 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

Managing NULLID package 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:

1. LOCATION
2. PRDID
3. AUTHID, ROLE
4. COLLID, PKGNAME
5. CLIENT_APPLNAME
6. CLIENT_USERID
7. CLIENT_WRKSTNNAME

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 ATTRIBUTE1 column.

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_APPLNAME, CLIENT_USERID or CLIENT_WRKSTNNAME And 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_ENABLED is set to ‘Y’ are activated. You can’t start and stop individual profiles via the PROFILEID identifier
• If you are data sharing, you need to coordinate these commands across the data sharing group, as the -START and -STOP PROFILE commands have member scope.

Conclusion

Managing the 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.

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

Footnotes

^{1 Also known as system monitoring profiles; another term you’ll come across is system profile monitoring.}