Topic
  • 4 replies
  • Latest Post - ‏2012-06-21T16:14:43Z by ToddBurchDB2
mitchC
mitchC
3 Posts

Pinned topic Special Registers Do Not Always Contain a Value

‏2012-06-19T17:45:00Z |
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.
Updated on 2012-06-21T16:14:43Z at 2012-06-21T16:14:43Z by ToddBurchDB2
  • ToddBurchDB2
    ToddBurchDB2
    74 Posts

    Re: Special Registers Do Not Always Contain a Value

    ‏2012-06-21T14:26:04Z  
    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)

    Todd
  • mitchC
    mitchC
    3 Posts

    Re: Special Registers Do Not Always Contain a Value

    ‏2012-06-21T15:06:57Z  
    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)

    Todd
    Thanks, Todd. But I'm still curious as to what might be setting the values that I do see in some of our environments but not in others. For instance, a detailed thread display in one test DB2 subsystem will show:

    V437-WORKSTATION=*, USERID=*,,
    APPLICATION NAME=VOTAPCS

    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.
  • mitchC
    mitchC
    3 Posts

    Re: Special Registers Do Not Always Contain a Value

    ‏2012-06-21T15:29:00Z  
    • mitchC
    • ‏2012-06-21T15:06:57Z
    Thanks, Todd. But I'm still curious as to what might be setting the values that I do see in some of our environments but not in others. For instance, a detailed thread display in one test DB2 subsystem will show:

    V437-WORKSTATION=*, USERID=*,,
    APPLICATION NAME=VOTAPCS

    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.
    What's 5 feet 8 inches tall and dumber than a bag of hammers?

    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.
  • ToddBurchDB2
    ToddBurchDB2
    74 Posts

    Re: Special Registers Do Not Always Contain a Value

    ‏2012-06-21T16:14:43Z  
    • mitchC
    • ‏2012-06-21T15:29:00Z
    What's 5 feet 8 inches tall and dumber than a bag of hammers?

    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.
    Some days you get the bear, some days the bear gets you. ;)

    Todd