Controlling the relationship between DB2 accounting records and CICS performance class records
By default, DB2 writes its accounting records at thread termination, or at the signon of a new authorization ID that is reusing the thread.
About this task
If a thread is reused by a transaction that has the same CICS transaction ID and the same DB2 authorization ID as the previous transaction that used the thread, DB2 does not write an accounting record at that point. (See Providing authorization IDs to DB2 for the CICS region and for CICS transactions for information about the relationship between the CICS transaction ID and the DB2 authorization ID.) This means that each DB2 accounting record for the thread can contain information about multiple CICS transactions. In addition, if different types of CICS transactions use the same transaction ID to access DB2, the DB2 accounting record can contain information about different types of CICS transactions.
- You could design your CICS applications so that each CICS transaction ID and DB2 authorization ID always represents the same piece of work, that consumes the same resources. This ensures that each DB2 accounting record contains either a single piece of work, or more than one occurrence of the same piece of work, and it will not contain different items. If such a DB2 accounting record contains multiple items, because the items are identical you can divide the resources used equally between them. However, it might not be practical to design your applications in this way. For example, take the case where a terminal user has a menu displayed at the terminal, and can choose different options (involving different pieces of work) for the next transaction. If the previous transaction ended by setting up the CICS transaction ID with the EXEC CICS RETURN TRANSID(zzzz) command, the next transaction runs under the transaction ID zzzz, no matter what piece of work the terminal user chooses. You might not want to re-design this application for accounting purposes.
- You could avoid reusing threads. This ensures that the thread terminates, and DB2 writes an accounting record, after each task, so each DB2 accounting record represents a single task. However, by doing this, you would lose the significant performance advantages of thread reuse. Also, if different types of transaction used the same transaction ID to access DB2, each DB2 accounting record could still refer to one of several possible tasks.
- You can make DB2 produce an accounting record each time a CICS task finishes using DB2 resources, by specifying ACCOUNTREC(TASK) in the DB2CONN or DB2ENTRY definition. ACCOUNTREC(TASK) is recommended rather than ACCOUNTREC(UOW). This ensures that there is at least one identifiable DB2 accounting record for each task, and the DB2 accounting record will not contain multiple tasks. Also, to solve the issue of different types of transaction using the same transaction ID to access DB2, when you specify ACCOUNTREC(TASK), CICS passes its LU6.2 token to DB2 to be included in the accounting record. You can use this token to match each DB2 accounting record to the relevant CICS transaction. Using ACCOUNTREC(TASK) is generally the most practical and complete solution to control the relationship between DB2 accounting records and CICS performance class records. It carries an overhead for each transaction, but its usefulness for accounting purposes normally outweighs this overhead.
Even if you specify ACCOUNTREC(TASK), note that DB2 can only recognize a single CICS task as long as the task continues to use the same thread. If a transaction contains more than one UOW, assuming that it releases the thread at the end of the UOW, it could use a different thread for each of its UOWs. This can happen with terminal-oriented transactions issuing multiple syncpoints (commit or rollback), and also non-terminal-oriented transactions if NONTERMREL(YES) is set in the DB2CONN. In these cases, DB2 produces an accounting record for each UOW, because it does not recognize them as a single task. So for this kind of transaction, each DB2 accounting record can contain information about only a part of the transaction, and you need to ensure that all the relevant DB2 accounting records for the transaction are identified.