lrt_display_buffer

Correlating Functions

Saves buffer information to an output file.

int lrt_display_buffer( const char* bufferName, const char* bufferPtr, long actualLen, long expectedLen );

bufferName The name of the buffer.
bufferPtr A pointer to the buffer.
actualLen The actual length of the data observed during replay.
expectedLen The expected length of the data as observed during recording.

The lrt_display_buffer function stores information about the buffer into an output file, section_name.out. The file contains a buffer description for each of the send and reply buffers. The information is displayed in the following format for buffer type and index buffer contents:

sbuf_1 "SCertReq"

sbuf_1 "..."

A series of one or more non-printable characters are designated by an ellipsis (...). For reply type buffers, lrt_display_buffer also lists the position (offset) of the characters within the buffer.

rbuf_1,26 "SCertRep"

rbuf_1,34 "..."

When you record a script, VuGen generates several files, init.rec, run.rec, and end.rec, containing the buffer contents retrieved during recording.

When you execute a script, lrt_display_buffer generates several output files, init.out, run[x].out, and end.out. A separate file is created for each iteration, for example run1.out, run2.out, etc. These files contain the buffer contents retrieved during replay. Note that the .rec and .out files have the same format.

If the lrt_display_buffer function detects an error during replay, it terminates the script execution. For details, see Error detection options for lrt_display_buffer below.

When the error is detected, VuGen issues a message to the execution log prompting you to compare the .rec with the corresponding .out file. VuGen uses a utility wdiff to compare the files and locate the inconsistencies between them. You can use then use this information for correlating data. For more information, see the Virtual User Generator Help Center.

Error detection pptions for lrt_display_buffer

You can customize VuGen by setting error detection criteria for lrt_display_buffer. You set the option in the script's cfg file, located in the script's directory. In the [TUXEDO] section, specify TuxReplyErrorCheck=option. (If the TUXEDO section is not present, add it). Use one of the following options:

Error Detection TuxReplyErrorCheck=option
PeopleSoft return codes (default)
PS_CHECK
Inconsistency in Reply buffer sizes (between record and replay).
SIZE_CHECK
Absence of Reply buffer
NO_CHECK

The first option checks for PeopleSoft internal return codes.

The second option tells lrt_display_buffer to compare the sizes of the reply buffer between record and replay. If there is a mismatch between the size of the buffers, the function detects an error.

The third option tells lrt_display_buffer to check for the presence of reply buffers during replay. If a buffer was received during recording, but not during replay, the function detects an error.

 

Return Values

If the function succeeds, it returns 0. Otherwise, the function returns a non-zero value and the replay of the script is terminated.

Parameterization

Parameterization is not applicable to this function.

Example

In the following example, lrt_display_bufferindicates that during recording a 41-byte request buffer was sent to the server and a 51-byte reply buffer was received. sends information about the send and reply buffers to the init.out file.

Contents of init.c

Copy code
    lrt_display_buffer("sbuf_1", data_0, 41, 41);
    tpresult_int = lrt_tpcall("GetCertificate",
        data_0,
        41,
        &data_1,
        &olen,
        TPSIGRSTRT);
    lrt_display_buffer("rbuf_1", data_1, olen, 51);

During replay the size of this buffer is indicated by the variable olen.

Contents of init.out

Example:  

sbuf_1 sent 41 bytes

sbuf_1 ")"

sbuf_1 "..."

sbuf_1 "SCertReq"

sbuf_1 "..."

sbuf_1 "PS"

sbuf_1 "..."

sbuf_1 "PS"

sbuf_1 "..."

rbuf_1 received 51 bytes (expected 51 bytes)

rbuf_1,0 "3"

rbuf_1,1 "..."

rbuf_1,26 "SCertRep"

rbuf_1,34 "..."

rbuf_1,36 "&"

rbuf_1,37 "..."

51 bytes were received both during recording and replay.