ACT 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.
rm
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:
  • Allow the application program to invoke a routine that builds and logs an accounting record to the accounting collection file (for example, SMF).
  • 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.