With Performance Test for Mainframe Servers, you can generate basic, predefined reports and build custom reports that contain information you specify.

Both custom and basic report generation require the same steps. However, assets necessary to generate basic reports are much easier to build. In fact, Performance Test provides sample reporting assets for each basic report. This section describes how to generate both types of report.

Reporting overview

Generating reports requires collecting data from an unattended playback job, sorting the collected data, and submitting a report generation job. After you have a sorted data collection, you can generate as many reports as needed at any time. You can even generate reports that compare data from different playback jobs. See TCP/IP Unattended Playback to learn about collecting, sorting, and saving unattended playback data.

A reporting job is controlled by the following input statements:

• CONTROL statements (optional), which provide general processing information for a group of reports.
• REPORT statements, which define the information to report and potentially the layout of the report.

Store these statements in members of the system-level reporting library or your personal reporting library. Plug the library and member names into any of the sample reporting jobs that Performance Test provides, modify or insert necessary DD statements, and submit the job. The rest of this section provides general instructions for creating reports. Each step includes a cross-reference to the section detailing the given task.

To set up and run a reporting job using any of the sample reporting jobs:

1. Verify that the assets in the system-level reporting control library suit your needs. If necessary, build additional assets and store them in either the system-level or your personal library. See Creating and Managing Reporting Control Assets.

2. Select the appropriate sample reporting job and customize as necessary. See Preparing the Reporting Job.

   • Add a job card.
   • Edit the values of the SET statements at the top.
   • Supply a DD statement for each REPORT statement in the REPORT member that is to be written to a data set or HFS file.

   Important

   Do not add a DD statement for reports written to SYSOUT. The ESREPT1 reporting procedure supplies a SYSOUT DD statement.

   
   

   • To run a baseline report (a report that compares two databases), supply a DD statement for the baseline database.
   • To mask information for an HTML Exception Report, supply a DD statement for each masking statement data set to be used during the reporting job.

   Important

   Each sample reporting job provides DD statements corresponding to the parameters on the REPORT statements in the specified report member. Modify if necessary.

3. Submit the Job. See Submitting the Job.

Creating and managing reporting control assets

Performance Test provides a system-level report control library complete with several types of reporting assets:

• Sample JCL to generate basic reports
• REPORT statements
• CONTROL statements.

The following table lists the contents of the system-level reporting library.

Contents of System-Level Reporting Library

Organize your personal report control library as follows.

• One member for each report or set of reports to generate in a given job.
• One member for each report CONTROL statement.

CONTROL statement

Reporting CONTROL statements are optional. They provide processing information for a group of REPORT statements. For example, to run several reports of the same type, set the report type on the CONTROL statement so you do not have to specify it on each REPORT statement.

Most of the parameters available on CONTROL statements are also available on REPORT statements. If the same parameter is defined on both the CONTROL and REPORT statements, the REPORT statements take precedence. For example, if CONTROL specifies table and REPORT specifies form, then form is used instead of table.

Store each CONTROL statement in a separate member to apply the statement to an entire reporting job. When you use one of the sample jobs to generate your reports, Performance Test assembles the statements from specified CONTROL and REPORT members in the appropriate order. For example, if your REPORT member contains two REPORT statements, Performance Test assembles the input statements as:

CONTROL
  REPORT
  REPORTHowever, if you are generating several reports in a given job, you may need multiple CONTROL statements — one for each group of reports. In this case, store the CONTROL statements in the reporting member itself. Be sure to position the CONTROL statement before the applicable REPORT statements.

For example, to run three reports with one set of processing options and two with another, you can:

• Create two REPORT members, A and B, each containing the applicable REPORT statements. Create two CONTROL members, Table and Form, each containing a single CONTROL statement. Then run two reporting jobs.

  Job1 Processes	Job2 Processes
  CONTROL (from member Table)   REPORT (from member A)   REPORT (from member A)   REPORT (from member A)	CONTROL (from member Form)   REPORT (from member B)   REPORT (from member B)

• Create one REPORT member containing REPORT statements that provide all of the necessary processing parameters and run a single job.

DATABASE(DATABASE|ddname)

Follow the DATABASE parameter with the DD name for the collected, sorted data to use for report generation. DATABASE is the default value. The ESREPT1 procedure, used by the sample jobs, supplies a DD statement that defines the SET SORTED data set as “DATABASE”. Thus, the default should suffice if you did not alter the DD statement in the procedure.

LAYOUT(TABLE|FORM)

LAYOUT specifies whether the report type will be TABLE or FORM.

TABLE produces a row, column oriented report (Sample Message Report in Table Layout). If you do not specify a layout, TABLE is used.

Sample Message Report in Table Layout

TYPE(TEXT|CSV|HTML)

Follow TYPE with either TEXT, HTML, or CSV (comma separated value). You can generate custom reports in any of these formats. Some basic reports support only HTML, others support TEXT and HTML. Basic reports do not support CSV format. Refer to the REPORT statement for the desired basic report. If you do not specify a type, TEXT is used.

BREAK(EJECT|NEXT)

BREAK only applies to TEXT and HTML reports with a FORM layout. For:

• TEXT reports, follow the parameter with EJECT to begin each record on a new page, or NEXT to continue reporting on the next line.
• HTML, follow the parameter with EJECT to begin each record in a new HTML table or NEXT to continue reporting on the next line of the same HTML table.

If you do not specify breaking conditions, EJECT is used.

MAXLINES(60|n)

MAXLINES only applies to TEXT reports. Follow MAXLINES with the maximum number of lines to print on each page. The value must be between 30 and 9999. If you do not specify MAXLINES, 60 is used.

FIELDDEPTH(99|n)

FIELDDEPTH only applies to TEXT and CSV reports. Use it to truncate the printing of large fields, some of which may contain up to two gigabytes of data. Follow FIELDDEPTH with the number of lines of message data to print. For example, FIELDDEPTH(1) results in one line of data per message.

REPORT statements for basic reports

Performance Test offers the following basic reports:

• HTML Exception Report: Compares the response messages and reports differences.
  • A standard exception report compares “actual” response messages to “expected” response messages from a single data collection.
  • A baseline exception report compares “actual” response messages from two data collections. The baseline “actuals” are used as “expected” values for comparison.
• Response Time Summary: Reports the amount of time it took each group of related messages to occur (for example, the time that elapsed from the first byte of the request to the last byte of the response).
• Script Time Summary: Reports the time it took for each script to play back and provides additional timing statistics for the playback job.

HTML exception REPORT statement

The following syntax diagram shows all of the parameters available on the REPORT statement for the HTML Exception Report. See HTML Exception Report for a report sample and detailed information including field definitions. Also, refer to your system-level reporting control library, members: ESRREXCP (standard exception report statement sample), ESRREXCB (baseline exception report statement sample), ESRREXCM (exception report with masking sample).

COMPARE

The COMPARE parameter is required to generate an HTML Exception Report.

BASELINE(ddname)

Use the optional BASELINE parameter to identify the DD name of the baseline database to use for comparison. If you do not specify a baseline, the report compares the “actual” responses to “expected” responses from the data collection specified on the SET SORTED statement in the reporting job. That is, it reports the differences between the responses resulting from playback to the responses recorded in the script.

MASK(ddname)

Use the optional MASK parameter to identify the DD name of the masking statement or the sequential data set or PDS member containing the masking statements. Masking statements prevent specified information from being compared. See Masking Statements.

STOPON(n)

Use the optional STOPON parameter to automatically end report generation after the specified number of mismatches have occurred. For example, if you specify STOPON(5), Performance Test stops reporting after the fifth mismatch. Valid values are 1 to 9999.

TITLE(‘title’)

Use the optional TITLE parameter to specify a title to appear at the top of the report and in the title bar of the browser window. If you do not specify a title, the report is titled “Performance Test for Mainframe Servers - Exception Report”.

INTO(ddname)

Use the INTO parameter to specify the DD name of the HFS file to write the HTML report to. This parameter is required.

Masking statements

Use data masking to prevent comparison of specified TCP/IP message data. For example, mask date and time fields to prevent generating mismatches for data that you expect to be different. Data masks are statements that specify qualification criteria and stipulate the positions to mask if the criteria is met. Each statement consists of a WHEN and a MASK clause.

Store all of the masking statements for a given report in a sequential data set or PDS member. Specify a DD name on the MASK parameter of the REPORT statement. In the reporting job, supply a corresponding DD statement that points to the data set.

The syntax of a masking statement is as follows:

POSITION1

Specify the starting position of the data to evaluate for masking qualification.

RO

Specify the relational operator (RO) to use for qualifying data for masking. You may use either the RO code or symbol. Valid operators for:

• Character, Hexadecimal, or Packed Decimal data are:

• Binary data are:

VALUE

Specify the data value that completes the comparison argument. If the argument is true, Performance Test masks the data specified by the MASK clause. Place the value in single quotations and precede it with one of the following data type indicators:

• C (character), for example, C'Smith'
  Character mask values are case-sensitive. For example, messages containing Smith match the mask value above, while message containing SMITH do not.
• X (hexadecimal), for example, X'0CDF'
  Hexadecimal masking values must consist of an even number of hexadecimal digits (0-9, A-F).
• P (packed decimal), for example, P'0001'
  Packed decimal mask values must consist of decimal digits and may be preceded by an optional sign (+-). Additionally, they must be fewer than 32 bytes.
• M (binary masks), for example, M'11000000'
  Binary mask values must consist of eight binary digits that identify the bits within the specified byte (POSITION1 in WHEN clause) to consider for masking. In the example above, Performance Test will examine the first two bits of the specified byte.

POSITION2:LENGTH2

Specify the starting position and length of the data to mask. Specify multiple positions and lengths by inserting a comma between each POSITION:LENGTH parameter. For example, the following masking statement masks columns 4 through 11, 45 and 46 when columns 5 and 6 contain 03.

Response time and script timing REPORT statements

The REPORT statements for the Response Time and Script Timing Reports are virtually the same except for the basic REPORT keyword.

The following syntax diagram shows all of the parameters available on the basic REPORT statement.

For basic reports, follow REPORT with RESPONSETIME to generate a Response Time Summary report or SCRIPTTIME to generate a Script Timing Summary report. See Script Timing Summary and Response Time Summary for a sample of each report and detailed information including field definitions. Also, refer to your system-level reporting control library, members: ESRRRESP (response time report statement sample) and ESRRSCRT (script time report statement sample).

TYPE(TEXT|HTML)

Use the optional TYPE parameter to specify the format (TEXT or HTML) of the report file. If you do not specify a type, Performance Test uses the type specified on the CONTROL statement if it is either HTML or TEXT. If CSV is specified on the CONTROL or REPORT statement, you will receive an error. If you do not specify a type on the CONTROL or REPORT statement, or you are not using a CONTROL statement, TEXT is used.

TITLE(‘title’)

Use the optional TITLE parameter to specify a title that will appear at the top of the report. The title will appear in the title bar of the browser window if you are generating an HTML report. If you do not specify a title, the report will be called “Performance Test for Mainframe Servers - Response Time Summary” or “Performance Test for Mainframe Servers - Script Timing Summary” depending on the basic report keyword you select.

INTO(ddname)

Use the INTO parameter to specify the DD name for the data set or HFS file that the report will be written to. This parameter is required.

Be sure there is a corresponding DD statement in the reporting job. If your destination is SYSOUT, do not add a DD statement. The reporting procedure supplies a DD statement for SYSOUT.

REPORT statement for custom reports

Just as there are five collection and reporting tables, there are five types of custom reports:

• PLAYBACK reports
• SOCKETS reports
• SCRIPT reports
• CONNECTION reports
• MESSAGE reports.

Your report can contain any combination of the fields from a given collection and reporting table if you collected and saved the fields during unattended playback. For example, report all fields from the PLAYBACK table to produce a Playback Summary. See TCP/IP Data Collection and Reporting Tables for a list of the fields available for each report type.

Although you cannot include fields from multiple tables on a single report, you can generate multiple reports from the same data collection in the same reporting run. For instance, you cannot include a PLAYBACK field on a SOCKETS report, but you can generate a PLAYBACK report and a SOCKETS report from the same data collection at the same time. Create a REPORT statement for each report and save them in the same reporting member. Then use one of the sample reporting jobs to generate the reports.

You can build custom comparison reports by including the same reporting fields from multiple unattended playback data collections. Qualify comparison fields with the DD names of the applicable data collection. For example, to compare the message counts from three playback data collections with DD names PLAY1, PLAY2, and PLAY3, create a report member containing the following statement and store it in your reporting control library:

REPORT FIELDS(-
 MESSAGESETCOUNT,-
 PLAY1.MESSAGESETCOUNT,-
 PLAY2.MESSAGESETCOUNT-
 )-
FROM(CONNECTION) INTO(SYSOUT)Use this reporting member in a reporting job that uses the third data collection. That is, the SET SORTED statement at the top of the job is set to PLAY3. See Preparing the Reporting Job.

The following syntax diagram shows all fields available on the custom REPORT statement.

LAYOUT(value from CONTROL LAYOUT|TABLE|FORM)

LAYOUT specifies whether the report will be in table (row, column) or form (one line per record) format. Sample Message Report in Table Layout and Sample Message Report in Form Layout show the same report in both TABLE and FORM layout.

TYPE(value from CONTROL TYPE|TEXT|HTML|CSV)

TYPE specifies the format of the report — either Text, HTML, or CSV. Text reports are written in EBCDIC and the LINK function is not valid. HTML reports support the LINK function, which tells Performance Test to write that field’s value to a separate file. A reference to that separate file appears in the HTML report as a link.

TITLE(‘title’)

Use the optional TITLE parameter to specify a title for the report. If you do not specify a title, then the report is titled “Performance Test for Mainframe Servers - Table Report”, where Table is the collection and reporting table specified on the FROM clause.

FIELDS

See TCP/IP Data Collection and Reporting Tables to select the fields you wish to report. In order to report a field, you must have collected it during unattended playback. Even if you collected all possible fields, every field is not always available for reporting. For example, message header fields cannot be sent by an application during a particular transmission, and therefore would not be available to put in a report.

Use long or short field names to specify the fields to include in the report. The field labels in the report appear as specified on the statement. For example, if the statement includes short field names, the report will contain short field names. Additionally, the fields appear in the report in the same order as specified on the REPORT statement.

To report on every available field for a given table, use an asterisk (*) on the FIELDS parameter - FIELDS(*).

Built-in function fields (AVG, MIN, MAX, SUM, etc.) are not automatically included by using FIELDS(*). These fields must be explicitly requested in the format FIELDS(*,AVG(xxxx)).

Any field names not fully qualified with a database name use the database name supplied on the FROM keyword. If no database name is available on the FROM keyword, the value supplied, or defaulted, by CONTROL DATABASE is used.

FROM

FROM specifies the type of report to produce. The table name specified in the FROM keyword is used to resolve field names specified by FIELDS(*) and to validate the field names specified in the FIELDS keyword. The optional database qualifier can be used as explained in the FIELDS description.

WHERE

Use the WHERE clause to provide criteria for reporting only the data you need. For example, to report all fields from the MQGROUP table for the second of five groups in the reporting job, construct the REPORT statement as:

SUBSTR

Produces a substring of the first argument. The second argument is the starting position of the substring, and may have a minimum value of one (1). The third argument is optional and is the length of the substring. If it is absent, the remainder of the string is the new substring. The behavior of the SUBSTR function matches the behavior of the REXX SUBSTR function.

The SUBSTR function is only valid on character fields. Other usage causes an error at statement parsing time and ends the reporting jobstep.

SUBSTRX

The SUBSTRX keyword works the same way as the SUBSTR keyword, but displays the value of the argument in hexadecimal characters.

DIFFERENCE

(DIFF) produces a number indicating the first byte position in a string that is different from another string. The two arguments are the byte strings to be compared. The strings may contain any values, including non-printable characters. Two strings that are identical result in a value of zero (0). The SUBSTR and DIFFERENCE functions may be nested as “DIFFERENCE(SUBSTR(...))”.

LINK

Indicates that a field’s value should be shown as an HTML link in a report rather than shown directly in the report. There is an exception for a non-HTTP protocol report. The LINK field with message headers and bodies (RQHS-RequestHeaders, RSHS-ResponseHeaders, EXHS-ExpResponseHeaders, RQBD-RequestBody, RSBD-ResponseBody and EXBD-ExpResponseBody) for non-HTTP protocol will be displayed in four-line hexadecimal format. If LAYOUT(FORM) is specified, it will be displayed with IFORM so that it will be shown in the message report itself. The SUBSTR and LINK functions may be nested as “LINK(SUBSTR(...))”.

Preparing the reporting job

Performance Test provides the following sample reporting jobs:

• ESRJCL1 — Generates a standard HTML Exception Report.
• ESRJCL2 — Generates a baseline HTML Exception Report.
• ESRJCL3 — Generates a standard HTML Exception Report with masking.
• ESRJCL4 — Generates a Response Time Summary Report.
• ESRJCL5 — Generates a Script Timing Summary Report.

Each of these samples contains a series of SET statements that identify the reporting assets to use for the job. They also supply DD statements corresponding to the applicable REPORT statement parameters. Although these samples support generating specific basic reports, you can use any sample to generate any type of report. This section explains how to prepare a reporting job.

To prepare a reporting job:

1. Open one of the sample reporting jobs in an ISPF Edit session. Sample Reporting Job ESRJCL4 shows sample job ESRJCL4.
2. Insert a job card at the top of the sample.
3. Edit the values of the SET statements. See the SET statement definitions following the reporting job sample illustration.

4. Each sample job provides DD statements that correspond to the applicable parameters on the REPORT statement from the specified reporting member. Modify these statements to point to your data sets or HTML files.
   If you plug your own reporting assets into the SET statements, insert DD statements for each:

   • REPORT statement in the specified REPORT member that is to be written to a data set for HFS file. Do not add DD statements for reports written to SYSOUT. The reporting procedure ESREPT1 provides a DD statement for SYSOUT.
   • Baseline database that is to be used for comparison reports.
   • Masking statement data set that is to be used for an HTML Exception Report.

   Refer to the “flower box” showing a sample DD statement defining an HFS path and a sample statement defining a data set.

5. When finished preparing the JCL, submit the job. See Submitting the Job.

Sample Reporting Job ESRJCL4

SET statement definitions

SET EXEC

Identifies the JCL procedure to use for the reporting job. All samples specify ESREPT1. If necessary, override with your own procedures.

SET REPTDS

Identifies the report control library containing the assets you are using for the job. This statement must point to the library where the REPORT and report CONTROL members specified on the SET REPTCNTL and SET REPTMEM statements reside.

SET SORTED

Identifies the database to use for reporting. Complete this statement with the name of the data set that was collected and sorted during an unattended playback job. The ESREPT1 procedure assigns DD name DATABASE to the data set you plug in here.

SET REPTCNTL

Identifies the report CONTROL member to use for the job. Each sample job specifies sample member ESRCTH, which produces an HTML report in table format. Override it with:

• Any report CONTROL member stored in the library specified on the SET REPTDS statement.
• NONE if a reporting CONTROL member is not required. If the specified REPORT member provides all of the necessary control information, a report CONTROL member is not necessary.

SET REPTMEM

Identifies the REPORT member to use for the job. Each sample job supplies a sample member from the system-level reporting library. Creating and Managing Reporting Control Assets provides a list and description of each sample asset. Plug in the name of the desired reporting member from the library specified on SET REPTDS.

Submitting the job

To submit the reporting job, open the log file in an ISPF Browse or Edit session, type SUBMIT on the Command line, and press Enter.

In the message report for the protocol ECI and TCP, the contents of RQBD, RSBD, and EXBD can contain either EBCDIC or ASCII data. By providing a PARM '-O1', the message report can be generated with the opposite encoding.

When the executed JCL is still available in SDSF after submit, edit the JCL and add
PARM '-O1' as follows:

change

//REPORT EXEC PGM=TCPPBRPT,REGION=4Mto

//REPORT EXEC PGM=TCPPBRPT,REGION=4M,PARM='-O1'.This JCL line is located in the ESREPT1 member.

For an ECI message report, LINK(RQBD), LINK(RSBD) and LINK(EXBD) retain their original codepage if the content is ASCII, and as a result, the HTML report on the Web will display with the Windows codepage. The link file is defined with an .eci extension. By setting the file type for .eci to notepad in folder options, the link will automatically open notepad with .eci files.

Reading and navigating basic reports

This section provides report samples and detailed information including field definitions for each of the basic reports.

HTML exception report

A standard HTML Exception Report compares the TCP/IP response messages that occurred during playback (“actual”) to the response messages recorded in the script (“expected”).

A baseline HTML Exception Report compares “actual” response messages from two unattended playback data collections. The “actuals” from the baseline database are used as “expected” values for comparison.

The following table shows a mismatch summary and HTML Exception Report Mismatch Detail shows the corresponding mismatch detail.

HTML Exception Report Mismatch Summary (Top of Report)

Field definitions

The title specified on the REPORT statement or the default report title (Performance Test for Mainframe Servers - Exception Report) appears across the top of the window and in the title bar. The following fields provide information about the playback job. In a baseline report, they come from the database entered on the SET SORTED statement in the log file.

Run Date

The date and time that the unattended playback job was executed.

SYSID

The LPAR where the playback job was executed.

Jobname

The playback job name.

Jobnumber

The playback job number.

Socket Number

The number of the socket the message was played back in. Sockets are numbered sequentially.

Script Number

The number of the script containing the reported message. Scripts are numbered sequentially within the SOCKET.

Script Name

The name of the script containing the reported message.

Connection ID

The connection number where the reported message occurred. Connection IDs are numbered sequentially in the script.

Message Number

The reported message’s number. Messages are numbered sequentially within a Connection ID.

Server IP Address and Port

Server address and port where the reported message was played back. For offline playback jobs, this is the address and port where the reported message occurred during recording. IPv6 and IPv4 IP address formats are both valid.

Client IP Address and Port

Client address and port where the reported message was played back. For offline playback jobs, this is the address and port where the reported message occurred during recording. IPv6 and IPv4 IP address formats are both valid.

Bypassed Fields Message

If any messages were not compared, an error message appears after the summary with a bypassed message count. Performance Test bypasses a message if no corresponding message to compare it against exists. For example:

• If a connection fails during playback, there is no “actual” response to collect. Since there is no “actual” response, the message is bypassed.
• If one data collection, in a baseline report, contains more messages than the other, the additional messages are bypassed.

HTML Exception Report Mismatch Detail

Field definitions

Each group of “expected” and “actual” messages is preceded by the associated Sockets Number, Script Number, Script Name, Connection ID, Message Number, Server IP Address and Port, and Client IP Address and Port. These are the same fields presented in the summary at the top of the report. See Field Definitions. Additionally, all fields displayed under the “expected” message also display under the “actual” message. Although the values they present may be different, the field definitions are the same.

Expected response message

The “expected” TCP/IP response message. In a standard exception report, this comes from the script. In a baseline report, this comes from the baseline data collection. If the baseline was generated from an:

• Online playback, this is the response message that resulted from the playback.
• Offline playback, this is the response message from the script.

Mismatches are highlighted. Masked information displays in green text.

Response Body Byte Count

The number of bytes in the “expected” response message.

Response Status Code

The “expected” message’s TCP/IP Status Code.

Response Reason Phrase

The “expected” message’s TCP/IP Reason Phrase.

Response Headers

The “expected” message’s HTTP response header information.

Actual Response Message

The “actual” TCP/IP response message. In a standard exception report, this is the response message that resulted from the playback. In a baseline report, this comes from the baseline data collection. If the baseline was generated from an:

• Online playback, this is the response message that resulted from the playback.
• Offline playback, this is the response message from the script.

Mismatches are highlighted. Masked information displays in green text.

Message Start Time

The date and time the reported message was received.

Actual Request Message

The TCP/IP request message related to the preceding response messages. This section only appears if there is a correlating request message.

Script timing summary

A Script Timing Summary Report shows the amount of time it took for each script to play back and provides additional timing statistics for the playback job.

Generate an HTML or TEXT version of the report. View the HTML version with a supported Web browser.

The following figure shows an HTML Script Timing Summary followed by field definitions.

HTML Script Timing Summary Report

Field definitions

The title you specified on the REPORT statement or the default report title, Performance Test for Mainframe Servers - Script Timing Summary Report, displays across the top of the report. In an HTML version, the report title also appears in the title bar of the browser window.

Run Date

The date and time that the playback job was executed. This field only appears on the HTML version of the report.

The LPAR where the playback job was executed. This field only appears on the HTML version of the report.

Jobname

The playback job name. This field only appears on the HTML version of the report.

Jobnumber

The playback job number. This field only appears on the HTML version of the report.

Socket Number

The number of the SOCKET that the reported script was played back in. Sockets are numbered sequentially.

Script Name

The name of the script.

Number

The number of the script being reported. Scripts are numbered sequentially within SOCKETS.

Start Time

The date and time playback began for the given script.

Finish Time

The date and time playback completed for the given script.

Duration

The amount of time it took for the given script to play back.

Socket Total

A row of statistics for each SOCKET played back.

Number

The total number of scripts within the SOCKET.

Minimum Duration

The shortest playback duration in the SOCKET.

Maximum Duration

The longest playback duration in the SOCKET.

Average Duration

The average of all playback durations in the SOCKET.

Report Total

A row of statistics for the entire playback job.

Number

The total number of scripts played back.

Minimum Duration

The shortest playback duration in the job.

Maximum Duration

The longest playback duration in the job.

Average Duration

The average of all playback durations in the job.

Response time summary

A Response Time Summary Report shows the amount of time it took each group of related messages to occur. For example, the amount of time it took to receive the response from the time the correlating request was sent.

You can generate an HTML or TEXT version of the report. View the HTML version with a supported Web browser.

The following figure shows an Response Time Summary. Field definitions follow the illustration.

 HTML Response Time Summary Report

Field definitions

The title you specified on the REPORT statement or the default report title (Performance Test for Mainframe Servers - Response Time Summary Report) appears across the top of the report. In an HTML version, the report title also appears in the title bar of the browser window.

Run Date

The date and time that the playback job was executed. This field only appears on the HTML version of the report.

The LPAR where the playback job was executed. This field only appears on the HTML version of the report.

Jobname

The playback job name. This field only appears on the HTML version of the report.

Jobnumber

The playback job number. This field only appears on the HTML version of the report.

Socket Number

The number of the SOCKET that the reported script was played back in. Sockets are numbered sequentially.

Script Name

The name of the script.

Connection ID

The number of the connection that the reported message was played back on. Connections are numbered sequentially within the script.

Number

The number of the message being reported. Messages are numbered sequentially within the script.

Start Time

The date and time the reported message began playing back.

Finish Time

The date and time the reply to the message completed.

Duration

The amount of time it took for the given message set to play back.

Total

A row of statistics for the given script.

Number

The total number of messages within the script.

Minimum Duration

The shortest response duration within the script.

Maximum Duration

The longest response duration within the script.

Average Duration

The average of all response durations for the given script.

Socket Total

A row of statistics for each SOCKET played back.

Number

The total number of request/response message sets within the SOCKET.

Minimum Duration

The shortest response duration in the SOCKET.

Maximum Duration

The longest response duration in the SOCKET.

Average Duration

The average of all response durations in the SOCKET.

Report Total

A row of statistics for the entire playback job.

Number

The total number of request/response message sets played back.

Minimum Duration

The shortest response duration in the job.

Maximum Duration

The longest response duration in the job.

Average Duration

The average of all response durations in the job.