Accounting for processor usage in a CICS DB2 environment

This section tells you about the information on processor time consumption that is provided in the DB2® accounting and statistics trace records, and about how to calculate the total processor time used in CICS® and DB2.

The DB2 accounting trace can be started with CLASS 1, CLASS 2, or CLASS 3. However, CLASS 1 must always be active to externalize the information collected by activating CLASS 2, CLASS 3, or both classes.

The processor times reported in the DB2 accounting records are the TCB time for the thread TCB running code in CICS or in the DB2 address space, using cross-memory services; and the SRB time for work scheduled in CICS.

CLASS 1 (the default) results in accounting data being accumulated by several DB2 components during normal execution. This data is then collected to write the DB2 accounting record. The data collection does not involve any overhead of individual event tracing.

CLASS 2 and CLASS 3 activate many additional trace points. Every occurrence of these events is traced internally, but is not written to an external destination. Rather, the accounting facility uses these traces to compute the additional total statistics that appear in the accounting record when CLASS 2 or CLASS 3 is activated. Accounting CLASS 1 must be active to externalize the information.

CLASS 2 collects the delta elapsed and processor times spent ‘IN DB2’ and records this in the accounting record.

CLASS 3 collects the I/O elapsed time and lock and latch suspension time spent ‘IN DB2’ and records this in the accounting record.

CLASS 7 and CLASS 8 in DB2 collect package level accounting in DB2 and package level accounting wait in DB2. For information on package level accounting, refer to the DB2 Universal Database™ for OS/390® and z/OS® Administration Guide.

The statistics trace reports processor time in the statistics records. The processor times reported are:

The DB2 address spaces reported in the statistics record are:

In a CICS DB2 environment, the processor time from the DB2 accounting records is typically much greater than the processor time reported in the DB2 statistical records, because most of the processor time used is in the thread TCB itself and in the DB2 address spaces using cross memory services.

DB2 accounting records are produced when a thread is terminated or signon occurs. This means that the period reported in the DB2 accounting record is the time between thread start or user signon (if reusing a thread previously used by another user) and thread termination or another signon. If several different transactions are specified for the same DB2ENTRY, and they use the same CICS transaction ID and the same DB2 authorization ID to sign on to the thread, then the DB2 accounting record for this thread can include data for more than one transaction. Also, if a transaction releases its DB2 thread at syncpoint, and the thread is terminated or re-used by another transaction, then the original transaction has to use a different thread. A single transaction can therefore be associated with multiple DB2 threads during the life of its execution. As DB2 produces accounting records for each thread, this can mean that multiple accounting records are produced for the transaction. See Controlling the relationship between DB2 accounting records and CICS performance class records for information on how you can determine the transactions that are included in each DB2 accounting record.

The processor time is accurately obtainable by authorization ID within the transaction by aggregating all the accounting records for this authorization ID and transaction. Note, however, that the elapsed times associated with the accounting record would be of little value in this case, because the sum of the elapsed times does not include the time from one commit point to the first SQL call in the next UOW. The elapsed time for a thread is associated with the thread and not with the transaction.

Figure 41 and Figure 42 show each period of processor time that is reported by CICS and DB2, and where it takes place. The location of processing differs depending on the version of DB2 to which CICS is connected, and whether or not the application accessing DB2 is threadsafe. This is because when CICS is connected to DB2 Version 6 or later, and is exploiting the open transaction environment, the CICS DB2 attachment facility uses CICS-managed open TCBs rather than CICS DB2 subtask TCBs.

Figure 41 shows the situation when CICS is connected to DB2 Version 5 or earlier, or when the application accessing DB2 is not threadsafe.

Figure 41. CICS with DB2 Version 5 or non-threadsafe application: Processor times recorded
 Processing is carried out in the CICS address space and in the DB2 address space. In the CICS address space, processing is carried out on either the CICS main TCB, or a thread TCB that controls the thread into DB2. In the example, processing begins on the CICS main TCB, then moves to a thread TCB. It then moves into the DB2 address space, and then back to the thread TCB. From the thread TCB, processing moves back to the CICS main TCB. After some time on the CICS main TCB, processing moves to a thread TCB again, then into the DB2 address space, then back to the thread TCB, then back to the CICS main TCB again. The sequence is repeated once more, and processing finishes up on the CICS main TCB. This represents a total of three accesses to DB2, and from this process, ten different periods of processor time are reported. Time 1 is when processing is on the CICS main TCB, at the start of the example. For the first access to DB2, Time 2 is the time spent in the DB2 address space. Time 3 is the processor time from when processing moves to the thread TCB, to when it moves off the thread TCB to return to the CICS main TCB. Time 2 is therefore nested within Time 3: Time 3 includes all the processor time for which CICS has assigned the task to the thread TCB, even though some of the processing activity (Time 2) is taking place in the DB2 address space. Time 4 is the time when processing is back on the main CICS TCB. The remaining two repeats of the sequence are numbered as follows. For the second access to DB2, Time 5, in the DB2 address space; Time 6, on the thread TCB; Time 7, back in the CICS main TCB. For the third access to DB2, Time 8, in the DB2 address space; Time 9, on the thread TCB; Time 10, back in the CICS main TCB. The processor times are reported as in the text that follows, which is embedded within this figure.
This picture shows the environment when CICS is connected
to DB2 Version 5 or earlier, or when the application
accessing DB2 is not threadsafe.

Times 3 + 6 + 9 are reported as CLASS 1 processor time
(time spent under the thread TCB)
Times 2 + 5 + 8 are reported as CLASS 2 processor time
(time spent in DB2)
Times 1 + 4 + 7 + 10 are reported as CICS processor time
(time spent on the CICS main TCB)

If CICS is connected to DB2 Version 5 or earlier, it is using a subtask TCB to run the thread into DB2. If CICS is connected to DB2 Version 6 or later but the application accessing DB2 is not threadsafe, then CICS is using an open TCB to run the thread into DB2, but it is using the open TCB in the same way as it would use a subtask TCB. The TCB that CICS uses to run the thread into DB2 is called the thread TCB.

The periods of processor time shown in the figure are as follows:

Figure 42 shows the situation when CICS is connected to DB2 Version 6 or later, and the application accessing DB2 is threadsafe.

Figure 42. CICS with DB2 Version 6 and threadsafe application: Processor times recorded
 Processing is carried out in the CICS address space and in the DB2 address space. In the CICS address space, processing is carried out on either the CICS main TCB, or an open TCB that controls the thread into DB2. In the example, processing begins on the CICS main TCB, then moves to the open TCB. It then moves into the DB2 address space, and then back to the open TCB. As the open TCB can run the application code, processing does not now move back to the CICS main TCB, but remains on the open TCB. Processing moves into the DB2 address space twice more, returning to the open TCB each time. Finally, when the task is complete, processing finishes up on the CICS main TCB. This represents a total of three accesses to DB2, and from this process, ten different periods of processor time are reported. Time 1 is when processing is on the CICS main TCB, at the start of the example. For the first access to DB2, Time 2 is the time spent in the DB2 address space. Time 3 is the processor time from when processing first moves to the open TCB, to when it finishes processing the DB2 access and recommences application code, still on the open TCB. Time 2 is therefore nested within Time 3: Time 3 includes all the processor time for which CICS has assigned the task to the thread TCB, even though some of the processing activity (Time 2) is taking place in the DB2 address space. Time 4 is the time when the open TCB is running application code prior to the next DB2 access. The remaining two repeats of the sequence are numbered as follows. For the second access to DB2, Time 5, in the DB2 address space; Time 6, on the open TCB processing the DB2 access; Time 7, still on the thread TCB but processing application code. For the third access to DB2, Time 8, in the DB2 address space; Time 9, on the open TCB processing the DB2 access; Time 10, moving back to the CICS main TCB, as the task is complete. The processor times are reported as in the text that follows, which is embedded within this figure.
This picture shows the environment when CICS is connected to DB2
Version 6 or later, and when the application accessing DB2 is threadsafe.

Times 3 + 4 + 6 + 7 + 9 + 10 are reported as CLASS 1 processor time
(time spent under the open TCB, processing access to DB2
and running application code)
Times 2 + 5 + 8 are reported as CLASS 2 processor time
(time spent in DB2)
Times 1 + 11 are reported as CICS processor time
(time spent on the CICS main TCB)

Here, CICS is using an open TCB to run the thread into DB2. As the application is threadsafe, the application code can also run on the open TCB. The periods of processor time shown in the figure are as follows:

Note that an application that is defined as threadsafe (that is, you have told CICS that the application code is threadsafe), can still issue CICS commands that are not threadsafe. These commands force a switch back to the CICS main TCB, and the application code then continues to run on the CICS main TCB until the application makes its next EXEC SQL request. The activity associated with the non-threadsafe CICS command, and with the application code that runs on the CICS main TCB, is reported as CICS processor time, and not as CLASS 1 processor time. Once the EXEC SQL request is issued, the application code can run on the open TCB again, and is reported from then on as CLASS 1 processor time.

Accounting CLASS 1 processor time

In Figure 41, when CICS is connected to DB2 Version 5 or earlier, CLASS 1 is the sum of the times 3, 6, and 9. In Figure 42, when CICS is connected to DB2 Version 6 or later, CLASS 1 is the sum of the times 3, 4, 6, 7, 9, and 10.

For CLASS 1, a task processor timer is created when the TCB is attached. When a thread to DB2 starts, the timer value is saved. When the thread is terminated (or the authorization ID is changed), then the timer is checked again, and both the timer start and end values are recorded in the SMF type 101 record (the DB2 accounting record). The fields in the SMF type 101 record used for accounting CLASS 1 processor time are:

You can find a description of the contents of the DB2 accounting record in the DB2 Universal Database for OS/390 and z/OS Administration Guide. There is also the description of accounting record fields in member DSNWMSGS, which is shipped in SDSNSAMP.

When CICS is connected to DB2 Version 6 or later, when the CLASS 1 recording becomes active for a thread, it is recording time spent on the L8 open TCB. Because the L8 TCB is used for both CICS activity and DB2 activity, this includes processor time spent in the CICS-DB2 attachment facility, including trace calls. It also includes processor time spent running application code (if the application is threadsafe) and threadsafe CICS commands on the open TCB. If a thread is reused, the thread housekeeping processor time is also included in the CLASS 1 processor time. As in previous releases, there is a proportion of thread creation and thread termination processing that is not captured by CLASS 1 time. The CLASS 1 processor time does not include any time spent running application code on the QR TCB, which happens as follows:

When CICS is connected to DB2 Version 5 or earlier, CLASS 1 processor time does not include any processor time spent in application code, because all application code is executed under the QR TCB.

Start of changeWhen CICS is connected to DB2 Version 6 or later, unless you are using DB2 sysplex query parallelism (parallel query), you do not need to use the DB2 CLASS 1 processor time for accounting purposes.End of change The processor time recorded in the CICS SMF type 110 record is all that is required to give a complete account of the processor time consumed by an application. This record includes the time spent in the application code, the thread creation and termination costs, and the time covered by the DB2 CLASS 1 processor time. For more information, see Calculating CICS and DB2 processor times for DB2 Version 6 or later.

Accounting CLASS 2 processor time

In Figure 41 and Figure 42, CLASS 2 is the sum of the times 2, 5, and 8.

For accounting CLASS 2, the timer is checked on every entry and exit from DB2 to record the ‘IN DB2’ time in the SMF type 101 record. In this case, it is the difference that is stored in the record. The fields in the SMF type 101 record used for accounting CLASS 2 processor time are QWACAJST for CICS attach TCB time and QWACASRB for CICS ASCB SRB time.

For a description of the contents of the DB2 statistics records, see the DB2 Universal Database for OS/390 and z/OS Administration Guide.

The elapsed time (start and end times between the above defined points) is also reported in the SMF type 101 record (QWACASC).

When CICS is connected to DB2 Version 5 or earlier, the CLASS 2 processor time is not significantly different from the CLASS 1 processor time, in contrast to IMS™ and TSO. However, when CICS is connected to DB2 Version 6 or later, there can be a significant difference between CLASS 1 and CLASS 2 processor time, as there is for IMS and TSO. This is because when CICS is connected to DB2 Version 6 or later, the CLASS 1 processor time includes processor time spent in the CICS-DB2 attachment facility, including trace calls, and also includes processor time spent running threadsafe application code and threadsafe CICS commands on the open TCB. All this processor time occurs in the CICS address space, and so is not reported for accounting CLASS 2. The CLASS 2 processor time itself is not affected by the open transaction environment.

Unlike accounting CLASS 1, the CLASS 2 elapsed times and processor times accurately reflect the elapsed times and processor times spent ’IN DB2’, whether CICS is connected to DB2 Version 5 or earlier, or to DB2 Version 6 or later. Accounting CLASS 2 information is therefore very useful for monitoring the performance of SQL execution. However, the processor overhead associated with having class accounting is quite considerable.

To reduce the overhead, it was usually recommended that the CLASS 2 trace be limited to trace data for plans and locations of specific authorization IDs. The processor overhead is 0-5%, with 2% being typical.

Calculating CICS and DB2 processor times for DB2 Version 5 or earlier

When your CICS system is connected to DB2 Version 5 or earlier, the CICS performance class record does not include processor time consumed in DB2. To estimate the total processor time for a single transaction, you could add information from the corresponding CICS performance record and DB2 accounting record (SMF type 101 record). For information about matching CICS performance records with DB2 accounting records, see Relating DB2 accounting records to CICS performance class records.

You should take the CPU field from the CICS performance class record. Using the DB2 accounting record, you can calculate the DB2 thread processor time (T1) as:

          T1 = QWACEJST - QWACBJST

This calculates the CLASS 1 TCB processor time. The sum of the processor time from the CICS CPU field and the calculated value of T1 is an expression for the processor time spent in CICS and DB2.

Notes:

Calculating CICS and DB2 processor times for DB2 Version 6 or later

When CICS is connected to DB2 Version 6 or later, and is exploiting the open transaction environment, the CICS DB2 attachment facility uses CICS-managed open TCBs rather than CICS DB2 subtask TCBs. This means the CICS monitoring facility can measure activity that was previously only reported in the DB2 accounting record (the SMF type 101 record). For example, CICS can now measure the processor time consumed on the DB2 thread and the processor time consumed in DB2 (the CLASS 1 and CLASS 2 CPU time). When CICS is using L8 open TCBs, the CPU time reported for these TCBs by the CICS monitoring facility includes the DB2 CLASS 1 processor time.

In the open transaction environment, the CICS L8 task processor time can also include the cost of creating a DB2 thread. When CICS is connected to DB2 Version 5 or earlier, this time is unaccounted for in the CICS and DB2 SMF records. When CICS is connected to DB2 Version 6 or later, if a transaction causes a DB2 thread to be created, you can expect the total task processor time accounted for to be higher than that accounted for by a CICS system running with earlier DB2 releases. Correspondingly, if at the end of a transaction, the thread is terminated (because it is unprotected and no other task is waiting to use it), then the cost of thread termination is included in the CICS L8 task processor time. Again, this cost is not accounted for by a CICS system connected to DB2 Version 5 or earlier.

Start of changeUnless you are using DB2 parallel query, when CICS is connected to DB2 Version 6 or later, do not add together the processor time from the CICS records (SMF type 110 records) and the DB2 accounting records (SMF type 101 records) when calculating the total processor time for a single transaction, because the DB2 processor time would then be included twice. The total processor time for a single transaction is recorded in the USRCPUT field in the CICS records (performance class data field 008 from group DFHTASK). This field includes all processor time used by the transaction when it was executing on any TCB managed by the CICS dispatcher. CICS-managed TCBs include the QR, RO, CO, J8, and L8 mode TCBs.End of change

Start of changeIf you are using DB2 parallel query, you do need to add some of the processor time from the DB2 accounting records. With DB2 sysplex query parallelism, DB2 might use multiple TCBs within the DB2 address space to service a query. (For more information about when DB2 does or does not parallelize a query, see the section "Enabling Sysplex query parallelism" in DB2 UDB for OS/390 and z/OS Data Sharing: Administration and Planning.) The TCBs used for this purpose are non-CICS TCBs, so any processor time that they consume is not accounted for in the CICS SMF type 110 records. To obtain the total amount of processor time used for a parallel query, you therefore need to add the PAR.TASKS processor time recorded in the DB2 SMF type 101 record that applies to the transaction, to the processor time recorded in the USRCPUT field in the CICS SMF type 110 record.End of change

Related concepts
Accounting and monitoring in a CICS DB2 environment
CICS-supplied accounting and monitoring information
DB2-supplied accounting and monitoring information
Relating DB2 accounting records to CICS performance class records
DB2 accounting reports
Monitoring a CICS DB2 environment: Overview
[[ Contents Previous Page | Next Page Index ]]