Allow Client Information to be propagated from a Db2 REST call

In a multi-tenant environment it is of great importance to be able to quickly isolate a problem in order to resolve a problem. We are currently using the Db2 JDBC Client Information API to provide Db2 with various correlation data from our Java based applications such that it will show up in different messages, traces and accounting information so that we could relate a transaction to not only a technical user but also to the real end user (authenticated by an LDAP catalog) as well as to where in the code we had the problem. We are also providing a reference to a correlation identity generated in the user's device so that we can correlate logs from all tiers of the application all the way down to Db2 for z/OS. Our implementation is based on design rules effectively managed by framework code.

When introducing the valuable Db2 REST feature in Db2 for z/OS, the implementation itself populates four of the client information special registers with Db2 related, and relevant information. A fifth special register is populated with the information in the User-Agent HTTP header. Furthermore the client's ip address is put into a global variable. The problem for us is that this is basically Db2 related downstream information that does not really refer to what is happening upstream in the calling stack of tiers in which Db2 more or less is in the bottom, at least far down.

Hence, the current implementation is basically fixed. The only way  we can influence the content is to let a REST call modify the User-Agent HTTP header with our own information. This is not acceptable to us. If we cannot have more control over the client information for a Db2 REST call as we have for our Java JDBC calls to provide similar correlation information we will have difficulties in correlating activities in all tiers. This in turn will have a negative impact on problem isolation, determination as well as resolution that will be hard to accept by our line-of-business.