I've noticed that not all our DB2 subsystems return values for special registers such as CURRENT CLIENT_USERID, or CURRENT CLIENT_APPLNAME when I display active threads.
Is there a subsystem specific parameter which controls whether or not special registers are set? Thanks in advance.
Pinned topic Special Registers Do Not Always Contain a Value
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-06-21T16:14:43Z at 2012-06-21T16:14:43Z by ToddBurchDB2
ToddBurchDB2 270001F7F874 Posts
Re: Special Registers Do Not Always Contain a Value2012-06-21T14:26:04ZThis is the accepted answer. This is the accepted answer.Hi Mitch.
No parameter that I am aware of. I think what you are seeing may just be parameters that are not initialized or out of a context of current use.
For instance, both CLIENT_USERID and CLIENT_APPLNAME are set by one of several APIs, and if not set, a reference to them returns the empty string. (See SQL Reference)
Re: Special Registers Do Not Always Contain a Value2012-06-21T15:06:57ZThis is the accepted answer. This is the accepted answer.
- ToddBurchDB2 270001F7F8
but I won't see that application name when I run the same program in another test environment. I'm certain none of our code uses APIs to set the special registers, and I have a vague memory of reading that the CURRENT CLIENT_APPLNAME will contain the program PSB in an IMS environment by default.
Re: Special Registers Do Not Always Contain a Value2012-06-21T15:29:00ZThis is the accepted answer. This is the accepted answer.
- mitchC 27000560GC
That would be me. Who can't tell the difference between DB2 v10 and DB2 v9. The reference I mentioned, regarding the default value of an IMS program's PSB for CURRENT CLIENT_APPLNAME, only appears in the v10 documentation. And wouldn't you know it... turns out those thread displays with application names populated are in v10 environments.
I can't believe they pay me for my brain.