We're looking for the best way to differentiate JCBC calls from different clients.
My (eventual) question is, "How do we do this?"
http://By the way, ACCUMAC=NO in our ZPARM.
I've tried by setting up a sample JCBC call passing the following information -
When I run a collect, I don't see any of these fields where I expect to. What am I doing wrong?
Pinned topic DB2 DDF/JDBC chargeback
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2011-03-04T05:07:58Z at 2011-03-04T05:07:58Z by SystemAdmin
Re: DB2 DDF/JDBC chargeback2011-02-15T13:33:21ZThis is the accepted answer. This is the accepted answer.I fear I may have asked too global a question, so I'll simplify to YES/NO questions.
Is anyone charging DB2 JDBC CPU & I/O?
Can this even be done?
KarlaBester 060001XK8Y15 Posts
Re: DB2 DDF/JDBC chargeback2011-03-02T04:35:08ZThis is the accepted answer. This is the accepted answer.Hi Kevin
Do you see these fields in the SMF records generated, and not in the TDS tables (after you ran the collect)? Or do you not see these fields in the SMF records?
Re: DB2 DDF/JDBC chargeback2011-03-02T11:28:49ZThis is the accepted answer. This is the accepted answer.
- KarlaBester 060001XK8Y
All the SMF exceptions killed me. Some CPU was counted under the DIST type 30, some under the authid submitting the DDF request and some on BOTH.
That's when I turned to TDSz. I assumed the reporting half of TDSz would at least allow us to report DB2 JDBC calls.
I've been slamming my brain against DRLCDB2 with no result. The accounting fields above (setDB2ClientAccounting, etc) are making it to DRLCDB2, but the program has no way of using that info. The accounting field passed to SMF is not a recognized DRLCDB2 accounting field.
At the moment, I'm looking at moving the setDB2ClientAccounting info to an accounting field that DRLCDB2 does recognize. As you can guess, reformatting SMF records is tricky business.
That answers my first question, "Can it be done?"
The remaining question stands, "Is anyone but me trying to do this?"
Thank you for your time,
SystemAdmin 110000D4XK112 Posts
Re: DB2 DDF/JDBC chargeback2011-03-04T05:07:58ZThis is the accepted answer. This is the accepted answer.
- firstname.lastname@example.org 060000CSRQ
As far as I can tell, the id fields have to come from the set (AuthorizationID, Package ID, Correlation ID, System ID, Connection Name, Sub-System ID, Plan Name, DB2 Type, DB2 Reserved Fields), although some customers have customised their DB2 installs to populate the reserved field with other values. That might be a possibility in your case.
Our resident UAC expert is due back on Tuesday so I'll ensure he takes a look at it.
Also keep in mind that DRLCDB2 collects data but does not use it to populate the core TDSz tables. From memory, it creates the 791 format files which can then be turned into CSR+ files for import into TUAM. We do import the SMF 101 into TDSz as part of the System Performance component but whether that's suitable for chargeback purposes I couldn't say.