🚀 go-pugleaf

Greetings,

Here at The State of Washington Department of Information Services we are
bringing up a DB2 billing system.  We are a State Government and several of
our customer agencies administer Federal programs.  Therefore we want to
remain in compliance with OMB circular A-87.

In looking at DB2 charge back we have found it to be fairly straight forward
to identify DB2 usage for CICS by Tran Id / User Id.  This is the same
information we use to key our CICS usage to account numbers.  Our concern is
to establish an equitable cost model that does not recover 100% of the cost
of providing DB2 services through CICS generated billing.

The reason for this concern is DB2 transfers CPU utilization (we bill TCB
and SRB) into the SMF30s of the batch job or TSO session.  If the DB2 costs
were 100% recovered through CICS charges, any batch jobs or TSO sessions
that utilize DB2 would be generating revenue in those cost centers above the
level for recovery of costs.  These charges can be substantial.  Our largest
customer is still in development mode and by our measurements have exceeded
$25,000 in one month if billed at standard batch processing rate.  We want
to be equitable to all our customers and avoid having DB2 usage distort our
batch processing and TSO rates.  To do this we need to transfer DB2 costs
from the DB2 cost center to the Batch processing and TSO cost centers where
the revenue is generated.

The DB2 SMF 101 field QWACAJST by testing has shown to be an accurate
indicator of how much time was added to the batch job or TSO session.  The
weakness of DB2 information is the SMF 101 although it has the job name does
not have the reader date and reader time of the batch job or TSO session
that received the utilization time for DB2 processing.  Additionally, we
charge premiums for "hot job" priority classes of up to 4 times our standard
rate or down to 1/2 our normal rate for jobs run over the weekend.

Lets take the example of a TSO session.  For a TSO session the DB2 SMF 101
carries the USER ID in same field that holds the USER parameter from a batch
job's job card.  The TSO session's DB2 SMF 101 also has the TSO USER ID in
the same field where a batch job's jobname from the job card would be found.
 Lets take a hypothetical instance where a TSO user logs on to the system 50
times in a month.  Of these 50, 15 of them are off prime shift and billed at
50% of the normal rate.  For the sake of argument, let's say 8 of the TSO
sessions invoked DB2 services and the other 42 had nothing to do with DB2.
Also imagine that we interrogate the SMF 101 and find on a straight time
basis, that 30% of the total charges came from DB2 utilization.  If you
could establish which 8 TSO sessions used DB2 then you could identify which
if any of those sessions were billed at the off prime rate and prorate
accordingly.  Since we haven't found a way to tie a specific SMF 101 back to
the batch job or TSO session which requested the utilization, we wouldn't
have a way to determine which of the TSO sessions should participate in the
proration.

At this time we are looking for any cost recovery models that other DB2
users utilize.  If you have addressed this problem we would defiantly be
interested in hearing your solution.  Thank you.

                         - Greg Marquiss
                            State of Washington DIS
                             GregM@dis.wa.gov