dbTalk Databases Forums  

DB2 CPU time returned to calling task

ibm.software.db2.mvs ibm.software.db2.mvs


Discuss DB2 CPU time returned to calling task in the ibm.software.db2.mvs forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Artb
 
Posts: n/a

Default DB2 CPU time returned to calling task - 09-25-2009 , 04:36 PM






For batch programs, CICS, IMS transactions, and TSO calls that access DB2 data the CPU time accumulated in DB2 is returned to the calling event.

Does that returned DB2 time include, or exclude, DB2 time for stored procedures, user-defined functions, and trigger time?

Does it include, or exclude, z/IIP engine time (for stored procedures, triggers) into the corresponding SMF 30 fields for SCP, and z/IIP CPU time?


Example: for a batch program from a chargeback perspective

Total CPU =

Batch CPU time from the SMF 30s (SRB, TCB, RCT, HIP, IOI, ZAP, SUP),

plus
DB2 SMF 101s time for stored procedures, UDFs, and triggers for SCPs,

plus
DB2 SMF 101s time for z/IIP engine stored procedures, triggers.

Art

Reply With Quote
  #2  
Old   
Peter Conlin
 
Posts: n/a

Default Re: DB2 CPU time returned to calling task - 09-25-2009 , 10:26 PM






Hi Art,

I believe all locally connected threads are charged back in the normal fashion you've outlined.

From a DRDA/JDBC connection, charges may be to the ssidDIST address space, rather than the type 30 to the "user" address space.

The DB2 101, etc records contain additional information which can be used when thread identification is sufficient for charge-back.

In regard to zIIP or zAAP processing, I'd expect the caller to invoke the charges, though the requestor may only be identifiable via the DB2 SMF records as the type 30 charges may only be in the ssnDIST address space.

For the most part, the definition of total cpu excludes the specialty processors and the SMF30 summary cpu time (SMF30CPT??) excludes it (it's been 10-15 yrs since my last heavy involvment in this stuff for audit/compliancebut I'd been brought in for a 5 minute conference on what seemed to be dog&pony show.

I think you need to look at two dimensions:

1) identify who is the caller for what;
2) what is CP zIIP zAAP.

When 1) is a server As you point out, item 1) involves anything from JDBC, invocation of preocedures/triggers.

, cont
nraccumula One problem is that local zIIP & zAAP are notexception is that that

Reply With Quote
  #3  
Old   
Peter Conlin
 
Posts: n/a

Default Re: DB2 CPU time returned to calling task - 09-25-2009 , 10:50 PM



Sorry, bad enter key on the last post.

I'd look specifically at what's being accumulated in ssidDIST, type 30, SDSF, etc.

This is the lost chargeback, save what's recoverable via type 101 & not already in the user's type 30.

DB2 for z/OS has done an incredible job for a while to provide this "instantaneous" local type 30 chargeback.

Once you've accurately identified the users, then you can begin to address their consumption, CP, zIIP or zAAP.

I wish it were simpler, but the SMF numbers have to reconcile, so you need to either answer your questions or have a tool that reconsiles with the SMF data.

I believe the DB2 SMF records should provide the answer, but you must ensure the charges for DB2 CPU don't exceed the type 30 ssnDIST & user type 30 DB2 chargeback.

Reply With Quote
  #4  
Old   
Artb
 
Posts: n/a

Default Re: DB2 CPU time returned to calling task - 09-28-2009 , 10:54 PM



The answer I'm looking for is to this question.

Does the DB2 Q8ACTRTT_ZIIP value get returned to the SMF 30 TIME_ON_ZIIP field? Yes/No. And similarly for the other DB2 101 fields (TRT, UDC, stored procedures) for SCP engines into the SMF 30 CPT time, etc.

I could do a detailed analysis to infer what is happening and be completely incorrect.

Art

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.