Organizing variable data in CTEs

You must determine how you will organize the variable portion (CTEVDATA) of the information in the CTEs. This information discusses the following methods:

Using a fixed-field format
Making each entry unique
Using a key-length data format.

You might combine these methods to produce other methods.

Using a fixed-field format: If you need the same type of data in every CTE, you can have one fixed definition of a trace entry. For example:

Offset 0  - ASID
Offset 2  - Module name
Offset 10 - Flags
Offset 14 - Return code

You might want to start every CTE with a few fixed fields, and follow that with variable data. Using fixed-field formats for CTEs allows for a smaller format table, and fewer lines of code, because you will not need separate format table entries to support each trace entry.

Making each entry unique: In this case, each CTE contains data that is unique, which requires unique formatting support and requires a larger format table than fixed-field formats. The advantage is that you can capture whatever data you require for a particular CTE.

Using key-length data format: With key-length data format, you define a key that identifies the data type, and the length indicates where the next key resides. This method is useful when your application supports a number of data types, but only a select number of these data types will be in each CTE.

Here is an example of a key-length data format:

KEY = 1 means ASID
LENGTH = 2 allows 2 bytes for an ASID in hexadecimal
DATA = 2 hexadecimal bytes for an ASID

Based on the above example, the formatting program will format an ASID when the key is 1. This method provides flexible and low-cost formatting (there is less code to format). One disadvantage is that you consume extra storage in the CTE for the key and length fields, and might consume extra instructions in the path that creates the CTEs.