How CICS PA creates Cross-System records
The records that make up the Cross-System Work extract are created by combining records, that is, by combining corresponding fields in the records, of the input data sets. How the fields are combined depends on both the type of record and the type of field.
- Normal Application records
- Terminal Owning Region (TOR) records
- Function Shipping request records. Note: Function Shipped Distributed Program Link (DPL) records are interpreted as normal Application records.
- Character fields
- Packed decimal fields (transaction sequence number)
- Time of day fields (start and stop times)
- Stopwatch (elapsed time) fields
- Accumulators (counters)
- Normal
- High-Water Marks (program storage and user storage)
- Error flags
- Terminal information flags
- Transaction definition and status flags.
The following paragraphs describe how the different field types are combined to create the fields for the Cross-System extract records:
- Character Fields
- Character fields are normally taken from the application records,
except for the following special fields:
- DFHCBTS C202 PRCSID
- The CICS-assigned identifier of the CICSĀ® BTS root activity (process ID).
- DFHCBTS C203 ACTVTYID
- The CICS-assigned identifier of the CICS BTS activity.
- DFHTASK C082 TRNGRPID
- The transaction group ID.
- DFHTASK C190 RRMSURID
- The RRMS/MVS Unit-of-Recovery ID (URID).
- DFHTASK C194 OTSTID
- The Object Transaction Service (OTS) Transaction ID (Tid).
The CICS BTS process ID and activity ID are taken from application records only. If no application record is found, the process ID and activity ID fields appear as hexadecimal zeros.
The transaction group ID is taken from application records only. If no application record is found, the transaction group ID field appears as hexadecimal zeros.
The RRMS/MVS unit-of-recovery ID (URID) is taken from application records only. If no application record is found, the unit-of-recovery ID (URID) field appears as hexadecimal zeros.
The OTS Tid is taken from application records only. If no application record is found or the record is not part of an OTS transaction, the OTS transaction ID (OTSTID) field appears as hexadecimal zeros.
All other character fields are processed as follows:- If no application record is found, the character fields appear as hexadecimal zeros.
- If multiple application records are found, the character fields are taken from the first one in the sort order. Because the sort order within the network unit-of-work is in reverse stop time, the first one in the sort order is usually the one with the latest stop time.
If the field is shorter in the output data than in the input data, only the left-hand bytes that fit are saved. Also, if the field is shorter in the input data than in the output data, it is padded on the right in the output record with hexadecimal zeros.
- Packed Fields
- The only packed decimal field is the transaction sequence number.
It is treated in the same way as a character field and is usually
taken from the application records. However:
- If no application record is found, the packed decimal field appears as packed decimal zeros.
- If multiple application records are found, the packed decimal field is taken from the first one in the sort order. Because the sort order within the network unit-of-work is in reverse stop time, the first one in the sort order is usually the one with the latest stop time.
- Time of Day Fields
- Time of day fields include the task start time and the task stop
time. The earliest start time of any record and the latest stop time
of any record are used. (Exception: if a time is incorrectly set
to hexadecimal zero, it is not used). Normally, the difference between
the start and stop time is the length of time it took to complete
the entire unit-of-work (response time). This might not be accurate
due to unsynchronized STCK values across multiple systems. The only other time of day field is processed as a special field:
- DFHTASK T132 RMUOWID
- The identifier of the local unit of work (unit of recovery) for this task.
The local unit of work (unit of recovery) is taken from application records only. If no application record is found, the local unit of work field appears as hexadecimal zeros.
- Stopwatch Fields
- Stopwatch fields are the fields that CICS uses to measure elapsed time such as dispatch
time, CPU time, or terminal control wait time. These fields are added
together. However, each stopwatch is actually a combination of the
three different components of the stopwatch field:
- The first component is the elapsed time measured, and is calculated by adding all of the field time values in the input records.
- The second field is one byte of flags CICS uses to indicate errors. The field is OR'd together so that the result contains any flags that were turned on in any of the input records.
- The third field is a three-byte counter that counts the number
of intervals that were timed, and is calculated by adding all of the
field count values in the input records. Note: Whenever fields are added together, it is possible to get an overflow. If an overflow condition occurs, CICS PA catches the error and forces the result to remain as the highest value that will fit within the field.
- Accumulator Fields
- The accumulator fields are calculated by adding all of the field
values in the input records, except eighteen special fields, which
are:
- DFHSOCK A292 SONPSHWM
- The non-persistent socket high-water mark.
- DFHSOCK A293 SOPSHWM
- The persistent socket high-water mark.
- DFHSTOR A033 SCUSRHWM
- The high-water mark of USER storage below 16MB.
- DFHSTOR A106 SCUSRHWM
- The high-water mark of USER storage above 16MB.
- DFHSTOR A116 SCUSRHWM
- The high-water mark of CICS storage below 16MB.
- DFHSTOR A119 SCUSRHWM
- The high-water mark of CICS storage above 16MB.
- DFHSTOR A087 PCSTGHWM
- The program storage high-water mark.
- DFHSTOR A108 PC24BHWM
- The program storage high-water mark below 16MB.
- DFHSTOR A139 PC31AHWM
- The program storage high-water mark above 16MB.
- DFHSTOR A143 PC24CHWM
- The CDSA program storage high-water mark below 16MB.
- DFHSTOR A142 PC31CHWM
- The ECDSA program storage high-water mark above 16MB.
- DFHSTOR A160 PC24SHWM
- The SDSA program storage high-water mark below 16MB.
- DFHSTOR A161 PC31SHWM
- The ESDSA program storage high-water mark above 16MB.
- DFHSTOR A162 PC24RHWM
- The RDSA program storage high-water mark below 16MB.
- DFHSTOR A122 PC31RHWM
- The ERDSA program storage high-water mark above 16MB.
- DFHTASK A064 TASKFLAG
- The transaction error flags for this transaction.
- DFHTASK A164 TRANFLAG
- The CICS transaction definition and status information flags for the transaction.
- DFHTERM A165 TERMINFO
- The CICS terminal information for the transaction.
For the high-water mark fields, the highest value from any record within the network unit-of-work is used.
Note: This provides a true high-water mark except for one condition: if two tasks within the same network unit-of-work run concurrently, it is not possible to determine the total high-water mark. The tasks peak at different times.The transaction error flags special accumulator field is a fullword field used as an indicator of error conditions. Instead of being added together, this field is OR'd together. The result has a flag turned on if it was turned on in any record within that network unit-of-work.
The transaction definition and status information flags field is taken from application records only. If no application record is found, the transaction flags field appears as hexadecimal zeros.
The terminal information is a four byte field containing terminal or session information for the task's principal facility. This information is taken from terminal owning records (TOR) only; if no terminal owning record is found, the terminal information field appears as hexadecimal zeros.
- User Fields
- The five user fields added by CICS PA are:
- CICSPA A001 TOTRECS
- The total number of input records that were added to produce this record
- CICSPA A002 APPLRECS
- The total number of application program records that were added to produce this record
- CICSPA A003 TRANROUT
- The total number of terminal-owning region records that were added to produce this record
- CICSPA A004 FUNCSHIP
- The total number of function shipping request records that were added to produce this record
- CICSPA A005 DPLRECS
- The total number of function shipping distributed program link (DPL) request records that were added into this record. This field is a subset of the total number of function shipping requests field.
These CICS PA user fields are always present.
- User-Specified
- User fields can also be specified on the CROSSsystem command.
When specified, these user fields are added to the dictionary and
the cross-system output record. Note: It is possible that the input data might not include the standard CICS fields or the user fields that you requested. If this occurs, the cross-system performance records created by CICS PA will still contain these fields. However, the values within the fields are null (hexadecimal zeros).
- APPLID Limitations
- Because
the input data sets typically contain CMF records from many CICS systems, the APPLID of the
output data set cannot be made to match the input data. Instead,
it is set to MULTIPLE to indicate that this data contains information
from multiple CICS systems
with different APPLIDs. You can override this by specifying the SYSID operand.
Note: Do not use the APPLID of MULTIPLE for any of your online systems. This allows you to determine if the data you are processing is from CMF or from CICS PA simply by checking the APPLID.
- CMF Requirements
- Because only CMF performance class records contain the token field
that associates the record with a network unit-of-work, only CMF performance
records are processed by the cross-system function of CICS PA.
Within a single logical record, CMF can block several types of data. Within each type of data, CMF can block many data rows. CICS PA does not block the data within the logical record. This means that for every record there is a single unit of data.
Note: A user typically concatenates, as input for the Cross-System Work Extract, two or more unloaded SMF data sets containing CMF performance class records. An example of this would be data sets from a terminal owning region, an application owning region, and a data base owning region.You should not merge a Cross-System Work Extract data set with another CMF data set, as the resulting records would not contain useful data. However, if you do, be aware of the following:- The five user fields added to the Cross-System record will no longer accurately reflect the overall total for that network unit-of-work. The totals in the Cross-System record are lost and will only reflect the totals from the additional CMF data set.
- Any user fields included in the original Cross-System extract are not included in the final Cross-System data set unless they are specified on the command input.
- Due to the manner in which the different field types are combined, some of the final Cross-System records might not be correct. See How CICS PA creates Cross-System records to understand the possible results when combining CMF records with cross-system records.
Recommendation
It is recommended that the Cross-System Work Extract created from the CMF performance class records from two or more systems should not be concatenated with other CMF files. The results of such a concatenation are questionable as to their use. The Cross-System Extract data set can be used by itself as input to the CICS PA Performance Reports (especially the List, List Extended, Summary, and Totals reports) to monitor the total amount of resources used by a transaction within a single or across multiple CICS systems.