To see a complete picture of the usage of resources by each CICS® transaction in both the CICS and DB2® address spaces, you need to match up the data in the DB2 accounting records with the data in the CICS performance class records. When you have a complete picture, you can analyze the resources used by individual transactions, and also charge back to the end user the total amount of resources consumed for a given set of transactions, using whatever data types you have decided to include in your cost formula.
If you are examining resource usage because you are carrying out performance analysis, rather than accounting, then you always need to match up the DB2 accounting records and the CICS performance class records. However, if you are examining resource usage for accounting purposes, you might not need to match up the DB2 accounting records and the CICS performance class records. You do not need to match up the records if:
In this situation, the processor time consumed in DB2 is reported by the CICS performance class records as well as by the DB2 accounting records, so the CICS performance class record for a transaction gives you all the information on processor time that you need to charge the resources for that transaction back to the end user. If you are in this situation, skip the rest of this section, and instead read the sections Accounting for processor usage in a CICS DB2 environment (to understand how processor time consumption is reported), and Calculating CICS and DB2 processor times for DB2 Version 6 or later (to find out how to use the information on processor time that is available to you).
If you are using DB2 Version 5 or earlier, or you have chosen to use data as well as, or other than, processor time consumption as the basis for your accounting, read the rest of this section to find out how to match up the DB2 accounting records and the CICS performance class records. If you are using processor time consumption for your accounting, you can then read the section Accounting for processor usage in a CICS DB2 environment to find out how to calculate your processor time consumption using your matched-up DB2 accounting records and CICS performance class records.
Because CICS and DB2 have different accounting needs, it is not always easy to match up DB2 accounting records and CICS performance class records. There are two main issues involved:
For the purpose of charging resources back to end users, it is possible to give each end user a different authorization ID from a DB2 viewpoint, by specifying the DB2ENTRY or DB2CONN parameter AUTHTYPE as OPID, USERID, GROUP, or TERM. In this case, a DB2 accounting record is generated that contains data only for the authorization ID. You can then collect together all the DB2 accounting records by authorization ID, and charge the resources consumed directly to the end user. This method means that you do not need to match the DB2 accounting records with the CICS performance class records. However, from a usability and performance viewpoint, using OPID, USERID, GROUP, and TERM is not an attractive solution, for the reasons discussed in Controlling access to plans. For large networks, specifying these authorization IDs can complicate maintenance and result in performance overhead. It is preferable to plan your use of authorization IDs with performance in mind, and assign DB2 accounting records to the end user by matching them to the CICS performance class records.
This section tells you:
By default, DB2 always writes its accounting records at thread termination, or at the signon of a new authorization ID that is reusing the thread. 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.
There are three ways in which you can influence the relationship between DB2 accounting records and CICS performance class records, to deal with these issues:
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.
Certain fields in DB2 accounting records can help you match them to the corresponding CICS performance records. In order of usefulness, these fields are:
There is not a single ideal way of matching DB2 accounting records and CICS performance class records. In a few cases, it might be impossible to make the matching correct, because transactions are being run concurrently. In most situations, though, there are strategies you can use to match up the two types of records with reasonable accuracy.
If the resources used in the individual transaction are the basis for accounting, then when you have matched up the CICS performance records and the DB2 accounting records, you can relate them back to the specific end user. Alternatively, you can define and calibrate a number of model transactions, measure these transactions in a controlled environment, and count only the number of model transactions executed by each end user.
The two main factors that determine what strategies you should use are:
Figure 40 shows how these factors combine to create four typical scenarios that you might encounter when matching DB2 accounting records and CICS performance class records. The following sections suggest strategies for matching the records in each case, and for charging the resources used back to the end user.
In this scenario, you know that each DB2 accounting record contains information relating to a single, identifiable CICS transaction. If the transaction accessed DB2 resources more than once, DB2 might have created more than one accounting record for it. You simply need to match the DB2 accounting records relating to the transaction, to the CICS performance record for the transaction.
The end user for the transaction can be identified from the CICS performance record. This record contains the CICS activities related to this transaction. You can identify the DB2 accounting records that apply to this transaction by using any of the data items listed in Using data in the DB2 accounting record to identify the corresponding CICS performance class records.
As all these transactions are identical, you can expect that they consume comparable amounts of resources. For accounting purposes, you could create model transactions for each transaction type. Because you can identify which DB2 accounting records apply to which CICS transactions, you can match up the DB2 accounting records and the CICS performance record for one transaction, and then simply assign the amount of DB2 resources used in those accounting records, to each subsequent transaction of that type. You should validate the correctness of your models on a regular basis, in case the resource usage changes.
In this scenario, each DB2 accounting record can contain information relating to more than one transaction, so you can't simply match each DB2 accounting record directly to the relevant CICS performance record. However, you can identify the types of transaction that are present in the DB2 accounting record, because each transaction ID only refers to one type of transaction.
If only one type of CICS transaction is present in a particular DB2 accounting record, then for accounting purposes, the resources consumed in DB2 can be split equally between each transaction. This is reasonable, because the transactions are (by definition) almost identical. The number of commits and backouts in the DB2 accounting record indicates the number of units of work covered in this record. However, as noted in Controlling the relationship between DB2 accounting records and CICS performance class records, units of work in the same transaction might use a different thread, and so not be present in the same DB2 accounting record. Make sure that you have assigned all the relevant DB2 resources to each transaction; this may involve examining more than one DB2 accounting record.
If two or more different types of CICS transaction are present in a particular DB2 accounting record (because they use the same DB2ENTRY and hence the same thread), you cannot use the method of distributing the resources equally, because the different types of transaction might use different resources. In this case, you can create model transactions by periodically measuring the amount of DB2 resources used by each type of CICS transaction. Take these measurements by temporarily disallowing thread reuse, and looking at the resulting DB2 accounting records, which will contain information relating to only one transaction. Use these model transactions to charge back the resources to the end user. You should periodically validate the correctness of the model transactions.
In this scenario, you know that each DB2 accounting record contains information relating to a single CICS transaction, but because several types of transaction use the same transaction ID, you can't be sure which type of transaction is shown by a particular DB2 accounting record.
You won't be able to match up a set of records for one instance of a transaction and then re-use those figures, as you could in Scenario A. You will need to match all the individual CICS performance records with their corresponding DB2 accounting records. Unless you do this, you won't know what type of transaction is represented by each DB2 record.
You can match each of the DB2 accounting records to the relevant CICS performance record by using the data items listed in Using data in the DB2 accounting record to identify the corresponding CICS performance class records. If you have specified either ACCOUNTREC(TASK) or ACCOUNTREC(UOW) in the DB2ENTRY or DB2CONN, so that CICS passes its LU6.2 token to DB2, then you can match the records together easily. If not, you will need to match the records based on their time stamps. In this case, the matching may not be accurate if transactions are being run simultaneously.
You can then use your matched sets of records to charge back the resources used for each transaction, to the end user identified by the CICS performance record.
In this scenario, each DB2 accounting record can contain information relating to more than one transaction, and also you can't use the transaction IDs to identify which types of transaction are present in the accounting record.
This situation is best avoided, because you are unlikely to be able to match records accurately. If you do find yourself in this situation, the best solution is to create model transactions, as described for Scenario B. Next, find a way to mark the CICS performance records with an identifier that is unique to each transaction. For example, the user could supply information in a user field in the performance records that identifies the transaction being executed. Now you can use this field to identify which of the model transactions should be used for accounting in this case.