IMS accounting information

The nature of accounting methods varies a great deal among data processing installations. The IMS Transaction Manager presents special difficulties, because many and varied transactions are processed by a partnership of the control region and dependent regions.

Further, operationally discrete applications can be served concurrently.

For installations with IMS-dedicated processors, the overall cost of hardware and support functions is often charged back based on predicted and actual use by contributing groups. For shared systems, the processor usage can be the base for proportional cost.

Although IMS does not have an explicit accounting function, the individual events that make up the processing activity are recorded on the IMS log in considerable detail. Analysis of IMS log records can be used as a basis for charge-back algorithms. You can, for example, obtain a report from the Statistical Analysis utility of the number of transactions and the average number of DL/I calls for each transaction.

Another source of resource usage figures is the reports produced as a result of IMS Monitor data collection. Samples of processing activity can be taken on a regular basis. Accounting algorithms can use, for example, processor utilization by program.

Both of these approaches require further manipulation and calibration of the resource indicators.

If the DL/I address space option is used (LSO=S), accounting procedures based on SMF data will be affected. SMF statistics for IMS system data sets and Fast Path databases are accounted to the control region procedure. Full function databases are accounted to the DL/I address space procedure.

Using the Application Accounting report

The Statistical Analysis utility produces an Application-Accounting report that you can use to assess machine charges. The following breakdown is provided for each transaction and for each program:

  • The number of messages with related total and average processor time in seconds
  • The number and type of DL/I message calls
  • The number and type of DL/I database calls

The following example illustrates the output format.

        A P P L I C A T I O N   A C C O U N T I N G   R E P O R T         D A T E  06/05/07                       P A G E 00005
PROGRAM TRANSACTION    MESSAGE- - - - COUNTS    DATA - - - - - - - - - BASE - - - - - - - - COUNTS  CC OR RC    TOT PROG      AVG
 NAME      CODE   PRI  QTY    GU    GN  ISRT    GU    GN   GNP   GHU   GHN  GHNP  ISRT  DLET  REPL   NOT 0      CPU TIME      TIME
CPGM2V0  CONV21V0  1     5     5    10     9     0     0     0     0     0     0     0     0     0     0            0.0S      0.000S
PGM2C0   SMQR21C0  1     3     3     3     2     0     0     0     0     0     0     0     0     0     0            0.0S      0.000S
PGM2V0   TRAN21V0  1     1     1     1     1     0     0     0     0     0     0     0     0     0     0            0.0S      0.000S
ICE143I

Using IMS transaction profiles

You can use a composite picture of each transaction as a basis for estimating usage. The IMS Transaction profile can contain DL/I call requirements by type of call and possibly items derived from path length for other processing blocks. You can weight the message count to allow for heavy DL/I use by the transaction. Transaction statistics can be obtained on a regular basis from /DISPLAY output, for example at end-of-day or before shutdown.

The profiles should characterize the IMS workload in such a way that growth trends and major deviations from the predicted load can be traced to the transaction codes responsible.