2. COST ACCOUNTING CONCEPTS FOR IS ORGANIZATIONS › 2.4 Transaction Accounting › 2.4.2 Implementing Transaction Accounting › 2.4.2.3 Transaction Logging Facilities

2.4.2.3 Transaction Logging Facilities

Transaction accounting implies that the accounting process
understands and has quantified the number of transactions
that have been processed for the user.  Unfortunately, this
is not the situation in most data centers today.  The
computer charging systems have little or no knowledge of the
number of transactions processed (checks generated, employee
records maintained, mailing labels printed, etc.).

The following examples illustrate the ways a transaction can
be the product (output) or service (input) as viewed by the
user:

    Batch:

    System A produces a financial statement from general
    ledger expense entries.  The expense entries, as
    input, represent the transactions (for example, $1.20
    per general ledger expense entry serviced).

    System B produces payroll checks and each output check
    is a transaction ($4.50 per payroll check produced).

    TSO:

    Command A requests the time of day.  The transaction
    is the TIME command input by the user ($0.25 per TIME
    command serviced).

    CLIST B lists the records of a file and each line
    displayed is a transaction ($0.05 per line printed).

    IMS or CICS:

    Transaction A requests that the salary of an employee
    be displayed.  The employee salary request is both the
    transaction and the user input ($0.23 per employee
    salary request serviced).

    System B maintains personnel data on all employees.
    Each employee maintained is a transaction ($1.76 per
    employee processed).
This accounting quantification cannot be measured in a
traditional global manner (for example, by SMF), but must be
calculated and logged by the application systems that are the
processors of the transactions.  In other words, the batch
program that generates payroll checks within the Payroll
Check Generation Application must inform the accounting
system that 1,435 payroll checks were printed, and the TSO
command that compiles a program must account for the fact
that 325 source statements were processed.

If no one has built accounting facilities within the
application processors to count and log transactions, a large
measurement hole exists.  Hence, we strongly recommend that
you consider transaction accounting only as new applications
are developed, and that you do not attempt to retrofit into
existing systems.

For transaction accounting to become a reality, the data
center accounting staff must provide the application systems
developers with the methodology and the means for counting
and logging transaction activity.  Transaction logging
requires facilities that:

o Allow the application program to invoke a routine that
  builds and logs an accounting record to the accounting
  collection file (for example, SMF).

o Allow the application program to invoke a routine that
  finds the task's appropriate internal accounting record
  (for example, SMF step termination record type 4) and
  inserts the necessary accounting data into the existing
  record structure.

These facilities need a parameter-driven subroutine that is
accessible by any programming language and the ability to
provide at least two data elements:  a code identifying the
transaction being accounted (for example, 103 is for hourly
payroll checks) and a count of the number of transactions
processed (for example, 83,576 hourly payroll checks).

For transaction accounting to become possible, the need for
transaction logging must be addressed.