Lost records

If there is not enough storage for a new trace record, either in the TCP/IP stack collection buffer or in the trace instance staging buffer, the new trace data is discarded and the NMI creates a lost record to indicate this situation. The NMI also creates lost records to keep up with high trace activity when the NMI bypasses trace records that are written incompletely. Depending on how quickly new trace records are created in the collection or staging buffer and how often the application invokes the RCCGetRecords request to retrieve records from the staging buffer, the lost record might represent several discarded trace records.

If records are being lost in the staging buffer when a trace is stopped, the lost record information is not written to the staging buffer as a lost record until the trace is started again. If you change the filters before starting the trace again, the information in this lost record might represent data that does not match your current set of filters. Before returning to the application, the RCCGetRecords request checks whether records are currently being lost in the staging buffer. If they are being lost, the request sets the RCGRFLossState flag in the RCCGetInfo structure and returns the current lost record information in the RCGRLostStats section of the structure.

Lost trace records are also provided in the form of cte trace records. The ctefmtid value of the lost record indicates whether it represents trace records lost from the collection buffer or the staging buffer.

Lost records in the staging buffer and lost records in the collection buffer differ in the following aspects:

Staging buffer
- The lost records represent trace records that matched the filter values that the trace instance specified.
- The RCLOFirstRecTime and the RCLOLastRecTime field values indicate the time interval during which records were lost. You can use the trace type count fields in the lost records to determine how many trace records of each trace type were lost during the time interval.
Collection buffer
- The lost records might represent trace records that matched the filter values that the trace instance specified, or might represent trace records that did not match such specified filter values. However, the lost records are written to the staging buffer of all active trace instances regardless of whether they represent the matching trace records.
- The RCLOFirstRecTime and the RCLOLastRecTime field values are the same and represent the approximate time that trace records were being lost in the collection buffer. You can use the trace type count fields in the lost records to determine how many trace records of each trace type were lost by that time.

The RCCLost structure defines the real-time data portion of a lost record.

Table 1. RCCLost structure
Offset	Field	Length	Format	Description
0(X'0')	RCLOEye	4	EBCDIC	RCLO eyecatcher
4(X'4')	RCLOVer	1	Binary	Version
5(X'5')		1	Binary	Reserved
6(X'6')	RCLOLen	2	Binary	Length of RCCLost structure
8(X'8')	RCLOStats	32	Binary	Lost record information
8(X'8')	RCLSFirstRecTime	8	Binary	For staging buffer lost records, the TOD timestamp when first record was discarded. For collection buffer lost records, the approximate time when records were being lost.
16(X'10')	RCLSLastRecTime	8	Binary	For staging buffer lost records, the TOD timestamp when last record was discarded. For collection buffer lost records, this field contains the same value as the RCLSFirstRecTime field.
24(X'18')	RCLSPktCount	4	Binary	The count of lost packet trace records.
28(X'1C')	RCLSDatCount	4	Binary	The count of lost data trace records.
32(X'20')	RCLSLostCollCount	4	Binary	The count of collection buffer lost records that were discarded from the staging buffer.
36(X'24')		4	Binary	Reserved
40(X'28')		16	Binary	Reserved