Example: Analyze the RW trace data

The example in Figure 1 shows the data stream received during a distributed SQL query function. This particular trace was run at the application requester (AR) end of the connection. Therefore, the associated program module that produced the data is QRWSQRY.

For more information about the interpretation of Distributed Relational Database Architecture™ (DRDA^®) data streams, see the Distributed Relational Database Architecture Reference and the Distributed Data Management Level 4.0 Architecture Reference books. These documents are available on the Web at www.opengroup.org/dbiop/index.htm.

The trace data follows the colon (:) marking the end of the trace point identifier. In this example, the first six bytes of the data stream contain the DDM data stream structure (DSS) header. The first two bytes of this DSS header are a length field. The third byte, X'D0' is the registered SNA architecture identifier for all DDM data. The fourth byte is the format identifier (explained in more detail later). The fifth and sixth bytes contain the DDM request correlation identifier.

The next two bytes, X'0010' (decimal 16) give the length of the next DDM object, which in this case is identified by the X'2205' which follows it and is the code point for the OPNQRYRM reply message.

Following the 16-byte reply message is a six-byte DSS header for the reply objects that follow the reply message. The first reply object is identified by the X'241A' code point. It is a QRYDSC object. The second reply object in the example is a QRYDTA structure identified by the X'241B' code point (split between two lines in the trace output). As with the OPNQRYRM code point, the preceding two bytes give the length of the object.

Looking more closely at the QRYDTA object, you can see a X'FF' following the X'241B' code point. This represents a null SQLCAGRP (the form of an SQLCA or SQL diagnostic area that flows on the wire). The null form of the SQLCAGRP indicates that it contains no error or warning information about the associated data. In this case, the associated data is the row of data from an SQL SELECT operation. It follows the null SQLCAGRP. Because rows of data as well as SQLCAGRPs are nullable, however, the first byte that follows the null SQLCAGRP is an indicator containing X'00' that indicates that the row of data is not null. The meaning of the null indicator byte is determined by the first bit. A 1 in this position indicates null. However, all 8 bits are usually set on when an indicator represents a null object.

The format of the row of data is indicated by the preceding QRYDSC object. In this case, the QRYDSC indicates that the row contains a nullable SMALLINT value, a nullable CHAR(3) value, and a non-nullable double precision floating point value. The second byte past the null SQLCAGRP is the null indicator associated with the SMALLINT field. It indicates the field is not null, and the X'0001' following it is the field data. The nullable CHAR(3) that follows is present and contains 111. The floating point value that follows next does not have a X'00' byte following it, since it is defined to be not nullable.

A second row of data with a null SQLCAGRP follows the first, which in turn is followed by another six-byte DSS header. The second half of the format byte (X'2') contained in that header indicates that the corresponding DSS is a REPLY. The format byte of the previous DSS (X'53') indicated that it was an OBJECT DSS. The ENDQRYRM reply message carried by the third DSS requires that it be contained in a REPLY DSS. The ENDQRYRM code point is X'220B'. This reply message contains a severity code of X'0004', and the name of the RDB that returned the query data ('DB2ESYS').

Following the third DSS in this example is a fourth and final one. The format byte of it is X'03'. The 3 indicates that it is an OBJECT DSS, and the 0 that precedes it indicates that it is the last DSS of the chain (the chaining bits are turned off).

The object in this DSS is an SQLCARD containing a non-null SQLCAGRP. The first byte following the X'2408' SQLCARD code point is the indicator telling us that the SQLCAGRP is not null. The next four bytes, X'00000064', represents the +100 SQLCODE which means that the query was ended by the encounter of a 'row not found' condition. The rest of the fields correspond to other fields in an SQLCA. The rest of the fields correspond to other fields in an SQLCA or SQL diagnostic area. The mapping of SQLCAGRP fields to SQLCA and SQL diagnostic area fields can be found in the Distributed Relational Database Architecture Reference book. This document is available at the Open Group Web site (www.opengroup.org/dbiop/index.htm)