Playback file design

Each data recording is written to an external variable or fixed-blocked sequential data set. These data sets can be concatenated together if it makes sense to do so to allow several recordings to be executed as one replay suite. However, it is just as valid to execute each recording as a separate replay job, each of which refers to its specific recording.

No matter how these recordings are used, they adhere to the same structure for the records. Within the data set are a series of records from the recording. These records are variable or fixed in length and when reading the records, the operating system will provide the normal length prefix. This document will discuss the data located beyond this length prefix information.

The maximum length of a physical stored record is 32756 bytes. However, it is possible that the length of the data captured during an interaction will exceed this physical length. Because of this possibility, intercepted data may need to be split across several physical records. This allows for unlimited data to be collected during a recorded interaction.

For performance reasons, data will be compressed using a simple repeated character/halfword technique. This technique is reasonably effective in reducing the size of the stored data.

Each record starts with a 4-character prefix. This prefix defines what subsystem the record is associated with. For example, a prefix of CICS indicates this record is from a CICS call, a prefix of DB2S indicates the calls is from Db2, etc. In all cases the last character of this prefix is used to determine whether the record is a single record or part of a longer logical record that required splitting. If the last character of the 4-character prefix is “S”, then the record is a single record that is not split. If the last character is “B” then this record is the beginning record of a split record group. Following the “B” record, there will be 0 or more “C” records which are now considered part of the larger group. Finally, there will be an “E” record which will be the ending record in the group. To reconstruct the entire block, a user would concatenate the entire “B” record, followed by the “C” and “E” records after first removing their 4-character prefix and adjusting their length down by 4. Finally change the “B” to an “S” in the 4-character prefix to make the next tables understandable.

Once the logical record has been reconstructed, then the entire record must be decompressed. To do this a left-to-right scan of the entire record is done looking for bytes that are in the x’B0’-x’BF’ range. If the byte is in this range, then it means that the following byte or halfword is to be repeated an appropriate number of times. The x’B0’-x’BF’ byte is not to be written as part of the decompressed data: it is a compression control byte. If the original data contained bytes in the x’B0’-x’BF’ range, then they will have been prefixed by a x’B0’ compression control byte, followed by the original data byte that needs to be written in this x’B0’-x’BF’ range.

The following table shows the outcome of this repetition.

After the data decompression is finished, the logical record will be either a record created by a program-to-program interception or a record from a subsystem. The prefix area is different for these 2 record types.

For program-to-program interceptions, the prefix area will be:

For subsystem recorded data, the prefix area will be:

After the prefix area will be a list of arguments for the recorded data. There are several types of arguments, each with their own identifier. Arguments to the application call have the letter “A” as the 1st byte of the name, followed by the hex 3-byte integer value for the argument number, starting at 0. Other argument names are: EIB, CMA, CWA, TUA, TWA (for CICS subsystems), SQPL, SQCA (for Db2 subsystems), and PAIB, PPCB, SPAS (for IMS subsystems). At the end of each reconstructed record is the END argument.

Each argument has this format.