On Aug 3, 2006, at 4:49 PM, Scott Barry wrote:
Consider that job-end statistics (if the output is captured or
reviewed by the submitter) only
represents a portion of what would normally be a chargeback bill/
invoice/receipt (okay, or call it
cost allocation or recovery). Also, how will a DB2 DDF (remote)
customer get their bill or a CICS
transaction user, etc. -- these typically involve tables mapping
USERIDs to a related owner/group?
Considering the cost of DASD and tape storage (local/vault, reel,
real, virtual, high-capacity), how
will these resources be tallied and communicated to the appropriate
department/cost_center or
resource consumer?
CPU normalization, rates, and possibly surcharge/discount logic may
need to be maintained, depending
on the chargeback algorithm and IT chargeback methodology intended
to be used for any given
system/customer. Support for "new rates" with effective dates and
other comprehensive logic should
likely be considered, if the reported charges are to be considered
credible, especially when
transitioning between fiscal calendar cycles.
Better to consider generating a consolidated resource consumer
report, at day's end (or otherwise),
and accumulate the various resource buckets/areas, in a back-end
system that post-processes the
various SMF and other system logs. Some that come to mind are SMF
type 30 (address space activity
for batch, TSO, STC, OMVS/USS, and maybe APPC), type 6 (output/
print), type 101 (DB2), type 110
(CICS/CMF), IMS log (or BMC's Patrol / IMF), other DBMS tools
(IDMS, M204, Datacom, Supra), and DASD
(IBM DCOLLECT snapshot), tape (tape mgmt catalog snapshot) focusing
on long-term data storage.
-----------------SNIP
Scott,
There *USED* to be a package (called QCM) that did all this and quite
a bit more 20 or more years ago. I believe it was written by Glen
Chatfield(sp?) of Duquesne systems in Pittsburg. If there was
something to account for QCM could produce *VALID* numbers. Like
chargeback for paging and even IO timings for anything in the system.
IIRC we had a user who disputed the numbers and brought in a hardware
monitor to "verify" (contest?) the numbers. The difference was so
insignificant that the user coughed up the $$ without admitting defeat.
Unfortunately the cost for the product was not cheap and I think that
is what lead to the demise of the company. BTW they developed SDSI
(now called MIM) on our systems. They also offered a product called
STAM which allowed tape drives to be shared among systems. This was
in the 70's and perhaps early 80's. When (at the early stages) their
software caused any of our systems to crash they were always the
first one to step up to the plate with research and debugging that
even our local PSR was impressed with.
Ed
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
