Play back your scripts to test your TCP/IP applications. During playback, Performance Test for Mainframe Servers executes the activity that is identified as CLIENT in the script. If you collect the appropriate playback information, you can generate reports that compare the server activity resulting from playback (actual) to the server activity recorded in the script (expected).

Unattended Playback is a batch-driven function that requires control statements. Write the statements from scratch, or save time by editing the Connection Log that is optionally generated during script creation. After the statements are prepared, customize the provided JCL sample and submit the job. Unattended Playback automatically generates a text-based Error Summary report to help you troubleshoot playback issues. You can also generate an interactive HTML version of the report if your installer enabled web reporting.

 Creating playback control statements

Each playback control statement you write can be used for client testing or server testing. TCP/IP Unattended Playback control statements include:

• CONTROL — Provides playback control information for all scripts in the job.
• SOCKETS — Provides playback control information for a group of scripts.
• SCRIPT — Provides playback control information for a specific script.
• COLLECT — Defines the playback information to collect for reporting for server testing only.

Playback requires one SCRIPT statement for each script and at least one SOCKETS statement. By default, all SOCKETS play back simultaneously and the SCRIPTS listed under a SOCKETS statement play back consecutively. This supports playing back groups of related scripts in parallel. For example, to simulate two users performing different activity at the same time, construct the statements as follows:

CONTROL
 SOCKETS
 SCRIPT(SCRPT1)
 SCRIPT(SCRPT2)
 SOCKETS
 SCRIPT(SCRPT4)
COLLECT (*) FROM (PLAYBACK)
COLLECT (*) FROM (MESSAGE)Be mindful of transaction interdependence when building multiple SOCKETS statements. For example, two scripts contain transactions that access the same customer record. If each script appears under a different SOCKETS statement, one of the transactions may fail during playback because the customer record is in use by the other transaction.

Playback control statements provide parameters for controlling all aspects of playback including overriding the connection information in the scripts. Specify a server IP address or port on one of the playback control statements to play back scripts in an environment other than the one they were captured in. For example, regression testing may require playing back activity in a test environment that was captured in a production environment. If you do not specify connection parameters on any of the playback statements, Performance Test uses the information found on the <CONNECT> tag in the script.

Consider statement hierarchy when defining your playback control statements. The CONTROL, SOCKETS, and SCRIPT statements offer many of the same parameters. If a parameter is defined on more than one statement, the parameter on the lowest-level statement takes precedence. For example, the following statements result in SCRPT1 and SCRPT2 using server address 10.10.0.200, while SCRPT3 uses 0.0.0.0.

CONTROL
 SOCKETS SERVER_ADDRESS(10.10.0.200)
 SCRIPT(SCRPT1)
 SCRIPT(SCRPT2)
 SCRIPT(SCRPT3) SERVER_ADDRESS (0.0.0.0)Although you can write Unattended Playback statements from scratch, it is typically faster and easier to modify the Connection Log (Sample TCP/IP Connection Log) that is optionally generated during script creation. The log contains one SOCKETS and one SCRIPT statement for each script created. Each SOCKETS statement always includes an:

• ID parameter that provides a value for correlating entries on performance and comparison reports with the associated SOCKETS statements.
• STIME parameter that states the start time and date of the first connection in the script.

The rest of the SOCKETS statement parameters vary depending on the contents of the script. If a connection attribute is the same for all connections in the script, the attribute is written into the SOCKETS statement as a parameter. For example, if all connections use the same protocol, the SOCKETS statement includes the PROTOCOL parameter. The parameters are written into the statements as comments so you can review and easily override their values. Remove the comment indicator — the asterisk (*) at the beginning of the line — for all modified parameters that you require for playback.

   Sample TCP/IP Connection Log

• Add a CONTROL statement before the first SOCKETS statement to define job-level attributes. For example, insert a CONTROL statement with the REXXON attribute to enable the use of REXX in all of the scripts in the job.
• Add or remove SOCKETS statements to achieve the script grouping required for your testing needs.
• Add, remove, or modify the parameters on the generated statements to meet your testing needs.
• Add COLLECT statements to define the reporting information to collect during playback for server testing.

 Define statements for client testing

This section provides a syntax diagram for each playback control statement for client testing. If you are unfamiliar with syntax diagrams, see Reading Syntax Diagrams. Parameter definitions follow the diagrams.

  CONTROL statement

You can use the CONTROL statement to provide job-level playback parameters and connection attribute overrides. If you include a CONTROL statement, place it before the first SOCKETS statement.

The following syntax diagram shows all of the available CONTROL statement parameters.

CACHE|CACHEOFF

CACHE instructs Performance Test to store scripts in memory during playback to improve performance. CACHEOFF disables script caching and is the default.

CONNECTION_ATTEMPTS(1|count)

The number of times Performance Test tries to connect to a partner. If the connection is not made after the specified number of attempts, Performance Test will perform the action specified on the ERROR_ACTION parameter.

DB2_USERID(‘user_ID’)

Overrides the user ID in the Db2 Connect CONTENT. The quotes are required.

DB2_PASS(‘ password’ )|DB2_NPASS(encrypted_password )

Overrides the password in the Db2 Connect CONTENT. The password must be a plain text password or a password using Performance Test encryption. The quotes are required. The encrypted_password must be in the form of 'hh...hh'X where hh is a valid hexadecimal value.

ECI_USERID(‘user_ID’ )

Overrides the user ID in the ECI CONTENT. The quotes are required.

ECI_PASS(‘password’ )|ECI_NPASS(encrypted_password )

Overrides the password in the ECI CONTENT. The password must be a plain text password or a password using Performance Test encryption. The quotes are required. The encrypted_password must be in the form of 'hh...hh'X where hh is a valid hexadecimal value.

ERROR_ACTION(MESSAGE|NOMESSAGE,STOP_CONNECTION|STOP_SCRIPT|STOP_SOCKETS|STOP_PLAYBACK|RETRY)

Specifies which messages Performance Test produces and the action it takes when a socket I/O error occurs (including connection failures, lost connections, and read/write failures). Options are:

MESSAGE

Print warning and socket I/O error messages.

NOMESSAGE

Suppress warning and socket I/O error messages.

STOP_CONNECTION

Stop the playback on the connection that the error occurred on. Continue the playback on the other connections in the script.

STOP_SCRIPT

Stop the playback of the script.

STOP_SOCKETS

Stop the playback under the SOCKETS statement. When COUNT(x) is included on the SOCKETS statement, all x of the playbacks are stopped when a socket I/O occurs.

STOP_PLAYBACK

Stop the playback.

RETRY

Retry playing back the script.

IMS_USERID(‘ user_ID’ )

Overrides the user ID in the IMS Connect CONTENT. The quotes are required.

IMS_PASS(‘ password’ )|IMS_NPASS( encrypted_password )

Overrides the password in the IMS Connect CONTENT. The password must be a plain text password or a password using VTAM Dark Field encryption. The quotes are required. The encrypted_password must be in the form of 'hh...hh'X where hh is a valid hexadecimal value.

OFFLINE

Plays back scripts without connecting to the partner or performing any I/O. This allows you to generate reports for analyzing script content. Be sure to include COLLECT statements in the JCL.

OWNERNAME( owner_name )

Provides reporting information. The OWNERNAME (OWNA) field on the playback reports displays the information specified on this keyword. Enter up to 256 characters.

PLAY(CLIENT)

Tells the playback program to function as a client.

PLAYBACKNAME( playback_name )

Provides reporting information. The PLAYBACKNAME (PLNA) field on the playback reports displays the information specified on this keyword. Enter up to 256 characters.

PROTOCOL(CTG|DB2C|ECI|HTTP|HTTPS|IMSC|TCP)

Identifies the protocol used to play back the scripts in the given job. Use this parameter to override the protocol identified on the <CONNECT> tag in the script. Valid values are CTG, DB2C, ECI, HTTP, HTTPS, IMSC, and TCP.

REXXOFF|REXXON

Enables or disables support for REXX logic in the scripts. If your scripts contain REXX logic, specify REXXON.

RLOG(*| destination )

Specifies where to write the output from REXX SAY statements added to your scripts. Supply a single-character sysout class, a PDSE and member, or a sequential data set.

Generate a separate data set or PDSE member for each thread of replay by including wildcard characters in the data set or member name. Valid wildcard characters include:

• Asterisk (*) — Playback replaces the asterisk with a four-digit value representing the current replay value padded with leading zeros. For example, RLOG(MRRLOG.RPLY*) generates MYRLOG.RPLY0001, MYRLOG.RPLY0002, etc. Playback allows one asterisk per data set name qualifier or member name, in any position except the first character.
• Question mark (?) — Playback replaces a string of one or more question marks with the current replay value. For example, RLOG(MYRLOG.RPLY??) generates MYRLOG.RPLY01, MYRLOG.RPLY02, etc. Include at least one question mark for each digit of the maximum replay value. For example, if the replay value will reach 20, insert at least two consecutive question marks. Playback truncates the replay value or pads it with leading zeros if there are more or fewer question marks than the number of digits in the replay value. Playback allows up to seven consecutive question marks per data set name qualifier or member name, in any position except the first character.

If you specify a data set or PDSE member that does not exist, Performance Test allocates it with default values. To override default allocation values, add an RLOG DD statement to the playback JCL.

SET_REXX_STREAM_VARIABLES(NO|YES)

Enables the use of the Performance Test predefined REXX variables during playback. The variables return information about the playback. Incorporate them into REXX logic that you add to your scripts to control the way the scripts play back. For example, use them to dynamically replace data in the script during playback. See Performance Test for Mainframe Servers REXX Variables. Since this is not necessary for replay, the default value for this parameter is NO.

STDWAIT(15| hh:mm:ss.nnn )

The longest time that Performance Test waits for I/O completion. If no I/O finishes in the STDWAIT interval, all outstanding I/O is canceled for that specific script. Performance Test retries the connections up to the number of attempts set in the CONNECTION_ATTEMPTS parameter and retries any other I/O twice. If still unsuccessful after all attempts are made to complete the I/O, Performance Test takes the action set on the ERROR_ACTION parameter.

If you do not include the STDWAIT parameter, Performance Test uses the default value of 15 seconds.

THINK(0| hh:mm:ss.nnn )

Sets the amount of think time to wait after receiving a server message before sending the next client message. This keyword accepts hours, minutes, and seconds separated by colons (:) — HH:MM:SS. However, seconds is the only required value and you can specify fractions of a second by providing a decimal value. For example, THINK(1) is one second of think time. THINK(10:14.5) is ten minutes, fourteen and a half seconds of think time.

This keyword is only available if THOPT3 is specified. If you do not supply this keyword when using think option three, playback does not wait.

THOPT(1|2|3)

Specifies which option to use for simulating think time. Specify a value of:

• 1 to play back at full speed.
• 2 to play back using the think time recorded in the script. Think time is simulated based on the differences between the values of the <TIME> tags in the script. Include the THPCT keyword to stipulate a percentage of recorded think time. For example, THOPT(2) THPCT(50) causes playback to use half of the difference between the <TIME> tags in the script.
• 3 to play back using an arbitrary value that is specified with the THINK and THPCT keywords. For example, THOPT(3) THINK(5) causes playback to wait five seconds after receiving a server response before sending the next client message.

THPCT(100| percent )

Specifies the percentage of think time to use for playback. This parameter applies to think time options THOPT(2) and THOPT(3). It works differently depending on the selected option. If you specify:

• THOPT(2), THPCT is the percentage of the think time recorded in the script.
• THOPT(3), THPCT is the percentage of the value specified on the THINK keyword. For example, THOPT(3) THINK(10:3) THPCT(50) results in five minutes, one and a half seconds of think time.

If you do not supply the THPCT keyword, playback uses the default value of 100%.

TRACE( sysout_class|dataset )

Produces diagnostic information regarding Performance Test internal behavior. Contact BMC Support prior to using this option.

Use TRACE to specify the location for the output. Supply a single-character sysout class, a PDSE and member, or a sequential data set.

Generate a separate data set or PDSE member for each thread of replay by including wildcard characters in the data set or member name. Valid wildcard characters include:

• Asterisk (*) — Playback replaces the asterisk with a four-digit value representing the current replay value padded with leading zeros. For example, TRACE(MYTRACE.RPLY*) generates MYTRACE.RPLY0001, MYTRACE.RPLY0002, etc. Playback allows one asterisk per data set name qualifier or member name in any position except the first character.
• Question mark (?) — Playback replaces a string of one or more question marks with the current replay value. For example, TRACE(MYTRACE.RPLY??) generates MYTRACE.RPLY01, MYTRACE.RPLY02, etc. Include at least one question mark for each digit of the maximum replay value. For example, if the replay value will reach 20, insert at least two consecutive question marks. Playback truncates the replay value or pads it with leading zeros if there are more or fewer question marks than the number of digits in the replay value. Playback allows up to seven consecutive question marks per data set name qualifier or member name, in any position except the first character.

If you specify a data set or PDSE member that does not exist, Performance Test allocates it with default values. To override default allocation values, add a TRACE DD statement to the playback JCL.

USE_PIPELINING(NO|YES)

Enables support of message pipelining for playback of DB2C, ECI, and IMSC scripts. USE_PIPELINING(YES) causes playback to send multiple messages to the server before receiving responses. NO is the default value.

USE_HTTP_PIPELINING(NO|YES)

Enables support of message pipelining for playback of HTTP and HTTPS scripts. USE_HTTP_PIPELINING(YES) causes playback to send multiple messages to the server before receiving responses. NO is the default value.

USESTIME

Provides control of playback initiation time for each SOCKETS statement supplied in the job. If USESTIME is specified, Performance Test initiates playback of each SOCKETS relative to the STIME values supplied on the SOCKETS statements.

 SOCKETS Statement

You can use the SOCKETS statement to define a group of scripts to play back and to provide playback parameters for that group. Place the applicable SCRIPT statements under each SOCKETS statement in the order that they should be played back. Place the SOCKETS statements after the CONTROL statement. For more information regarding statement hierarchy, see Creating Playback Control Statements.

The following syntax diagram shows all of the available SOCKETS statement parameters. Parameter definitions follow the diagram.

COUNT(1| n )

Specifies the number instances to play back concurrently. For example, COUNT(5) plays the SOCKETS back five time concurrently. If COUNT is not specified, Performance Test plays back one instance of the SOCKETS.

Use COUNT and REPEAT together to create the volume of traffic necessary for your testing. For example, to simulate two users executing the same activity at the same time, repeated five times in a row, specify COUNT(2) REPEAT(5).

CONNECTION_ATTEMPTS(1| count )

The number of time Performance Test tries to connect to a partner. If the connection is not made after the specified number of attempts, Performance Test will perform the action specified on the ERROR_ACTION parameter.

CTG_APPLID(' application_ID ')

Overrides the application ID in the CTG CONTENT. The quotes are required.

CTG_PROGID(' program_ID ')

Overrides the program ID in the CTG CONTENT. The quotes are required.

DB2_RDBNAM(' database_name ')

Overrides the relational database name in the Db2 Connect CONTENT.

DB2_USERID(' user_ID ')

Overrides the user ID in the Db2 Connect CONTENT. The quotes are required.

DB2_PASS(' password ')|DB2_NPASS( encrypted_password )

Overrides the password in the Db2 Connect CONTENT. The password must be a plain text password or a password using Performance Test encryption. The quotes are required. The encrypted_password must be in the form of 'hh...hh'X where hh is a valid hexadecimal value.

ECI_PROGID(' program_ID ')

Overrides the program ID in the ECI CONTENT. The quotes are required.

ECI_USERID(' user_ID ')

Overrides the user ID in the ECI CONTENT. The quotes are required.

ECI_PASS(' password ')|ECI_NPASS( encrypted_password )

Overrides the password in the ECI CONTENT. The password must be a plain text password or a password using Performance Test encryption. The quotes are required. The encrypted_password must be in the form of 'hh...hh'X where hh is a valid hexadecimal value.

ERROR_ACTION(MESSAGE|NOMESSAGE,STOP_CONNECTION|STOP_SCRIPT|STOP_SOCKETS|STOP_PLAYBACK|RETRY)

This parameter specifies the message that Performance Test produces and the action it takes when a socket I/O error occurs (including connection failures, lost connections, and read/write failures). Options are:

MESSAGE

Print warning and socket I/O error messages.

NOMESSAGE

Suppress warning and socket I/O error messages.

STOP_CONNECTION

Stop the playback on the connection where the error occurred. Continue the playback on the other connections in the script.

STOP_SCRIPT

Stop the playback of the script.

STOP_SOCKETS

Stop the playback under the SOCKETS statement. When COUNT(x) is included on the SOCKETS statement, all x of the playbacks are stopped when a socket I/O occurs.

STOP_PLAYBACK

Stop the playback.

RETRY

Retry playing back the script.

ID( id_number )

The ID value provides a way to correlate entries on performance and comparison reports with the associated SOCKETS statement. This value can be added, deleted, or changed by the user. If this parameter is not specified on the SOCKETS statement, the field does not appear on the report.

PROTOCOL(CTG|DB2C|ECI|HTTP|HTTPS|IMSC|TCP)

Identifies the protocol used to play back the scripts in the given SOCKETS. This keyword overrides a PROTOCOL defined on the CONTROL statement, if specified. Otherwise, it overrides the value on the <CONNECT> tags in the script. Valid values are CTG, DB2C, ECI, HTTP, HTTPS, IMSC, and TCP.

IMS_DSTORE(' datastore ')

Overrides the datastore in the IMS Connect CONTENT. The quotes are required.

IMS_TRANS(' transaction_code ')

Overrides the transaction code in the IMS Connect CONTENT. The quotes are required.

IMS_USERID(' user_ID ')

Overrides the user ID in the IMS Connect CONTENT. The quotes are required.

IMS_PASS(' password ')|IMS_NPASS( encrypted_password )

Overrides the password in the IMS Connect CONTENT. The password must be a plain text password or a password using VTAM Dark Field encryption. The quotes are required. The encrypted_password must be in the form of 'hh...hh'X where hh is a valid hexadecimal value.

REPEAT(1| n )

Defines the number of times to repeat playback of the given SOCKETS. For example, REPEAT(6) causes the SOCKETS to play back six times in a row. If you do not specify REPEAT, Performance Test plays back the SOCKETS one time.

Use COUNT and REPEAT to create the volume of traffic necessary for your testing. For example, to simulate two users executing the same activity at the same time, repeated five times in a row, specify COUNT(2) REPEAT(5).

Specifies where to write the output from REXX SAY statements added to your scripts. Supply a single-character sysout class, a PDSE and member, or a sequential data set.

Generate a separate data set or PDSE member for each thread of replay by including wildcard characters in the data set or member name. Valid wildcard characters are:

• Asterisk (*) — Playback replaces the asterisk with a four-digit value representing the current replay value padded with leading zeros. For example, RLOG(MRRLOG.RPLY*) generates MYRLOG.RPLY0001, MYRLOG.RPLY0002, etc. Playback allows one asterisk per data set name qualifier or member name, in any position except the first character.
• Question mark (?) — Playback replaces a string of one or more question marks with the current replay value. For example, RLOG(MYRLOG.RPLY??) generates MYRLOG.RPLY01, MYRLOG.RPLY02, etc. Include at least one question mark for each digit of the maximum replay value. For example, if the replay value will reach 20, insert at least two consecutive question marks. Playback truncates the replay value or pads it with leading zeros if there are more or fewer question marks than the number of digits in the replay value. Playback allows up to seven consecutive question marks per data set name qualifier or member name, in any position except the first character.

If you specify a data set or PDSE member that does not exist, Performance Test allocates it with default values. To override default allocation values, add an RLOG DD statement to the playback JCL.

SERVER_ADDRESS(ASIS| IP Address )

Specifies a server address for all of the scripts within the SOCKETS to access. Supply an IPv6 or IPv4 IP address. This keyword overrides the server addresses shown on the <CONNECT> tags in the scripts.

SERVER_PORT(ASIS| Port Number )

Specifies a server port for all of the scripts within the SOCKETS to access. Supply a port number value between 0 and 65535. This keyword overrides the server ports shown on the <CONNECT> tags in the scripts.

SET_REXX_STREAM_VARIABLES(NO|YES)

Specifies whether the TCPIP_ACTUAL, TCPIP_EXPECTED, TCPIP_ACTUAL_LENGTH, TCPIP_EXPECTED_LENGTH and CONNECTION_NBR should be set during the playback. Performance Test sets REXX variables when the reporting data is gathered for message completion. Copying data to these variables is unnecessary if you never reference these variables within a script. The default value is NO.

STARTDLY(0| hh:mm:ss.nnn )

Tells Performance Test how long to wait between the start of SOCKETS and the commencement of playback. You can use STARTDLY to stagger the start of playbacks using multiple SOCKETS statements. For example, to wait five seconds, enter STARTDLY(5).

STDWAIT(15| hh:mm:ss.nnn )

The longest time that Performance Test waits for I/O completion. If no I/O finishes in the STDWAIT interval, all outstanding I/O is canceled for that specific script. Performance Test retries the connections up to the number of attempts set in the CONNECTION_ATTEMPTS parameter. Performance Test retries any other I/O twice. After all attempts are made to complete the I/O, and if still unsuccessful, Performance Test takes the action set on the ERROR_ACTION parameter.

If you do not include the STDWAIT parameter, Performance Test uses the default value of 15 seconds.

STIME( time_stamp )

Defines a value that Performance Test uses to determine when to start playing back the SOCKETS relative to the other SOCKETS in the job. If the USESTIME keyword is specified on the CONTROL statement, Performance Test staggers playback initiation of each SOCKETS based on the difference in the STIME values.

Supply a date-time stamp inside single quotation marks in the following format: YYYY/MM/DD_HH:MM:SS.NNNNNN. To ensure proper formatting, copy and paste an STIME value from the script and modify it as necessary.

This is an optional keyword. If USESTIME is specified on the CONTROL statement, but the STIME keyword is not defined on the SOCKETS statement, playback uses the first STIME in the script.

If USESTIME is not specified on the CONTROL statement, Performance Test ignores this keyword.

THINK(0| hh:mm:ss.nnn )

Sets the amount of think time (for example, the amount of time to wait after receiving a server message before sending the next client message). This keywords accepts hours, minutes, and seconds separated by colons (:) — HH:MM:SS. However, seconds is the only required value and you can specify fractions of a second by providing a decimal value. For example, THINK(1) is one second of think time. THINK(10:14.5) is ten minutes, fourteen and a half seconds of think time.

This keyword is only available if THOPT3 is specified. If you do not supply this keyword when using think option three, playback does not wait.

THOPT(1|2|3)

Specifies which option to use for simulating think time. Enter a value of:

• 1 to play back at full speed.
• 2 to play back using the think time recorded in the script. Think time is simulated based on the differences between the values of the <TIME> tags in the script. Include the THPCT keyword to stipulate a percentage of recorded think time. For example, THOPT(2) THPCT(50) causes playback to use half of the difference between the <TIME> tags in the script.
• 3 to play back using an arbitrary value that is specified with the THINK and THPCT keywords. For example, THOPT(3) THINK(5) causes playback to wait five seconds after receiving a server response before sending the next client message.

THPCT(100| percent )

Specifies the percentage of think time to use for playback. This parameter applies to think time options: THOPT(2) and THOPT(3). It works differently depending on the selected option. If you specify:

• THOPT(2), THPCT is the percentage of the think time recorded in the script.
• THOPT(3), THPCT is the percentage of the value specified on the THINK keyword. For example, THOPT(3) THINK(10:3) THPCT(50) results in five minutes, one and a half seconds of think time.

If you do not supply the THPCT keyword, playback uses the default value of 100%.

TRACE( sysout_class | dataset )

Produces diagnostic information regarding Performance Test internal behavior. Contact BMC Support prior to using this option.

Indicate the location for the output. Specify a single-character sysout class, a PDSE and member, or a sequential data set.

Generate a separate data set or PDSE member for each thread of replay by including wildcard characters in the data set or member name. Valid wildcard characters include:

• Asterisk (*) — Playback replaces the asterisk with a four-digit value representing the current replay value padded with leading zeros. For example, TRACE(MYTRACE.RPLY*) generates MYTRACE.RPLY0001, MYTRACE.RPLY0002, etc. Playback allows one asterisk per data set name qualifier or member name, in any position except the first character.
• Question mark (?) — Playback replaces a string of one or more question marks with the current replay value. For example, TRACE(MYTRACE.RPLY??) generates MYTRACE.RPLY01, MYTRACE.RPLY02, etc. Include at least one question mark for each digit of the maximum replay value. For example, if the replay value will reach 20, insert at least two consecutive question marks. Playback truncates the replay value or pads it with leading zeros if there are more or fewer question marks than the number of digits in the replay value. Playback allows up to seven consecutive question marks per data set name qualifier or member name, in any position except the first character.

If you specify a data set or PDSE member that does not exist, Performance Test allocates it with default values. To override default allocation values, add a TRACE DD statement to the playback JCL. For example:

USE_PIPELINING(NO|YES)

Enables support of message pipelining for playback of DB2C, ECI, and IMSC scripts. USE_PIPELINING(YES) causes playback to send multiple messages to the server before receiving responses. NO is the default value.

USE_HTTP_PIPELINING(NO|YES)

Enables support of message pipelining for playback of HTTP and HTTPS scripts. USE_PIPELINING(YES) causes playback to send multiple messages to the server before receiving responses. NO is the default value.

  SCRIPT statement

You can use SCRIPT statements to specify which scripts to play back and to provide playback parameters for each script. Place SCRIPT statements, in the order that they should be played back, under a SOCKETS statement. For information on statement hierarchy and to learn how to group SCRIPT statements, see Creating Playback Control Statements.

The following syntax diagram shows all of the available SCRIPT statement parameters. Parameter definitions follow the diagram.

scriptname

Identifies the SCRIPT (member name of the script in the script data set) to be played back.

PROTOCOL(CTG|DB2C|ECI|HTTP|HTTPS|IMSC|TCP)

Identifies the protocol used to play back the script. This keyword overrides a PROTOCOL defined on the SOCKETS and CONTROL statements, if specified. Otherwise, it overrides the value on the <CONNECT> tags in the script. Valid values are CTG, DB2C, ECI, HTTP, HTTPS, IMSC, and TCP.

REPEAT(1| n )

Defines the number of times to repeat playback of the given SCRIPT. For example, REPEAT(6) causes the SCRIPT to play back six times in a row. REPEAT can be specified on both SOCKETS and SCRIPT statements. For example, the following statements result in script2 playing back six times, twice within each repeat of the SOCKETS.

SOCKETS REPEAT(3)
 SCRIPT(script1)
 SCRIPT(script2) REPEAT(2)
 SCRIPT(script3)If you do not specify REPEAT on the SOCKETS or SCRIPT statements, Performance Test plays back the SCRIPT one time.

SERVER_ADDRESS(ASIS| IP Address )

Specifies a server address to access for the given script. Supply an IPv6 or IPv4 address. This keyword overrides the SERVER_ADDRESS defined on the SOCKETS statement, if specified. Otherwise, it overrides the server addresses shown on the <CONNECT> tags in the scripts.

SERVER_PORT(ASIS| Port Number )

Specifies a server port to access for the given script. Supply a port number value between 0 and 65535. This keyword overrides the SERVER_PORT defined on the SOCKETS statement, if specified. Otherwise, it overrides the server ports shown on the <CONNECT> tags in the scripts.

 COLLECT statement

You can specify the information to collect during the playback job and generate reports from the collected information by including one or more COLLECT statements in the playback job.

FIELDS

Follow this keyword with:

• An asterisk to collect all fields from the collection and reporting table you specify on the FROM keyword. Collecting all field ensures the optimum reporting flexibility.
• A comma-separated list of fields, in long or short format, from the collection and reporting table you specify on the FROM keyword. This option minimizes storage overhead and processing time. Incorporate the SUBSTR keyword to collect a specified number of bytes from a specific field. The following example collects the first 20 bytes of the Expected Response Header field (EXHS) and all of the Message ID field (MSID).

COLLECT FIELDS(SUBSTR(EXHS,20),MSID) FROM(MESSAGE)Refer to TCP/IP Data Collection and Reporting Tables, to determine which tables and fields to collect or to locate short field names.

Follow the FROM keyword with the name of the collection and reporting table that owns the fields specified on the FIELDS keyword. For a list of available tables, see TCP/IP Data Collection and Reporting Tables.

WHERE

Use the WHERE clause to provide criteria for collecting only required data. For example, to collect all fields from the SOCKETS table for the second of five sockets in the playback job, construct the COLLECT statement as follows:

 Define statements for server testing

This section provides a syntax diagram for each playback control statement written for server testing. If you are unfamiliar with syntax diagrams, see Reading Syntax Diagrams. Parameter definitions follow the diagrams.

  CONTROL statement

Use the CONTROL statement to provide job-level playback parameters and connection attribute overrides. If you include a CONTROL statement, place it before the first SOCKETS statement.

The following syntax diagram shows all of the available parameters for the CONTROL statement. Parameter definitions follow the diagram.

CACHE|CACHEOFF

CACHE instructs Performance Test to store scripts in memory during playback to improve performance. CACHE is the default. To disable script caching, specify CACHEOFF.

ERROR_ACTION(MESSAGE|NOMESSAGE,STOP_CONNECTION|STOP_SCRIPT|STOP_SOCKETS|STOP_PLAYBACK|RETRY)

ERROR_ACTION specifies which messages Performance Test produces and the action it takes when a socket I/O error occurs (including connection failures, lost connections, and read/write failures). MESSAGE prints and NOMESSAGE suppresses warning and socket I/O error messages. STOP_CONNECTION stops playback on the connection where the error occurred but continues playback on the other connections in the script. STOP_SCRIPT stops script playback. STOP_SOCKETS stops playback under the SOCKETS statement. When COUNT(x) is included on the SOCKETS statement, all x playbacks are stopped when a socket I/O occurs. STOP_PLAYBACK stops playback. RETRY retries playing back the script.

PLAY(SERVER|SERVER_IPV6)

PLAY(SERVER) tells the playback program to function as an IPv4 server. PLAY(SERVER_IPV6) tells the playback program to function as an IPv6 server.

PROTOCOL(TCP|EB2C)

PROTOCOL identifies the protocol used to play back the scripts in the given job. Valid values are TCP (default) and DB2C.

REXXOFF disables and REXXON enables support for REXX logic in scripts. If your scripts contain REXX logic, specify REXXON.

RLOG(*| destination )

RLOG specifies where to write the output from REXX SAY statements added to your scripts. Supply a single-character sysout class, a PDSE and member, or a sequential data set.

Generate a separate data set or PDSE member for each thread of replay by including wildcard characters in the data set or member name. Valid wildcard characters include:

• Asterisk (*) — Playback replaces the asterisk with a four-digit value representing the current replay value padded with leading zeros. For example, RLOG(MRRLOG.RPLY*) generates MYRLOG.RPLY0001, MYRLOG.RPLY0002, etc. Playback allows one asterisk per data set name qualifier or member name, in any position except the first character.
• Question mark (?) — Playback replaces a string of one or more question marks with the current replay value. For example, RLOG(MYRLOG.RPLY??) generates MYRLOG.RPLY01, MYRLOG.RPLY02, etc. Include at least one question mark for each digit of the maximum replay value. For example, if the replay value will reach 20, insert at least two consecutive question marks. Playback truncates the replay value or pads it with leading zeros if there are more or fewer question marks than the number of digits in the replay value. Playback allows up to seven consecutive question marks per data set name qualifier or member name, in any position except the first character.

SERVER_PORT(n)

SERVER_PORT specifies which port the playback server will be listening on.

LISTENWAIT(120|hh:mm:ss:nnn)

LISTENWAIT specifies in seconds or in hh:mm:ss:nnn format, the longest that the listener will wait for connects sent by clients. The default value is 120 seconds. When you enter hours, minutes, or fractions along with seconds (separated by a colon), the individual numbers cannot be longer than two digits each (excluding fractions).

SET_REXX_STREAM_VARIABLES(NO|YES)

SET_REXX_STREAM_VARIABLES enables the use of Performance Test predefined REXX variables during playback. The variables return information about the playback. You can incorporate them into REXX logic that you add to your scripts to control the way the scripts play back. For example, you can use them to dynamically replace data in the script during playback (see Performance Test for Mainframe Servers REXX Variables). Since this is not required for replay, the default value for this parameter is NO.

STDWAIT(15| hh:mm:ss.nnn )

STDWAIT is the longest time that Performance Test waits for I/O completion. If no I/O finishes in the STDWAIT interval, all outstanding I/O is canceled for that specific script. Performance Test retries the connections up to the number of attempts set in the CONNECTION_ATTEMPTS parameter. Performance Test retries any other I/O twice. After all attempts are made to complete the I/O, and if still unsuccessful, Performance Test takes the action set on the ERROR_ACTION parameter.

If you do not include the STDWAIT parameter, Performance Test uses the default value of 15 seconds.

TRACE( sysout_class|dataset )

TRACE produces diagnostic information regarding Performance Test’s internal behavior. Contact BMC Support prior to using this option.

Specify the location for the output as a single-character sysout class, a PDSE and member, or a sequential data set.

Generate a separate data set or PDSE member for each thread of replay by including wildcard characters in the data set or member name. Valid wildcard characters include:

• Asterisk (*) — Playback replaces the asterisk with a four-digit value representing the current replay value padded with leading zeros. For example, TRACE(MYTRACE.RPLY*) generates MYTRACE.RPLY0001, MYTRACE.RPLY0002, etc. Playback allows one asterisk per data set name qualifier or member name, in any position except the first character.
• Question mark (?) — Playback replaces a string of one or more question marks with the current replay value. For example, TRACE(MYTRACE.RPLY??) generates MYTRACE.RPLY01, MYTRACE.RPLY02, etc. Include at least one question mark for each digit of the maximum replay value. For example, if the replay value will reach 20, insert at least two consecutive question marks. Playback truncates the replay value or pads it with leading zeros if there are more or fewer question marks than the number of digits in the replay value. Playback allows up to seven consecutive question marks per data set name qualifier or member name, in any position except the first character.

If you specify a data set or PDSE member that does not exist, Performance Test allocates it with default values. To override default allocation values, add a TRACE DD statement to the playback JCL.

USE_PIPELINING(NO|YES)

USE_PIPELINING enables support of message pipelining for playback of DB2C scripts. USE_PIPELINING(YES) causes playback to send multiple messages to the client before receiving responses. NO is the default value.

USESTIME

USESTIME provides control of playback initiation time for each SOCKETS statement supplied in the job. If USESTIME is specified, Performance Test initiates SOCKETS playback relative to the STIME values supplied on each SOCKETS statement.

 SOCKETS statement

You can use the SOCKETS statement to define the script to play back and to provide playback parameters for that script. Place the applicable SCRIPT statements under each SOCKETS statement, in the order that they should be played back. Place SOCKETS statements after the CONTROL statement. For more information regarding statement hierarchy, see Creating Playback Control Statements.

The following syntax diagram shows all of the available SOCKETS statement parameters. Parameter definitions follow the diagram.

CLIENT_ADDRESS(n.n.n.n|n:n:n:n:n:n:n:n)

This parameter specifies the IP address that this SOCKET will accept connections from. IPv6 or IPv4 IP address formats are both valid.

COUNT(1|n)

Specifies the number of instances to serve. For example, COUNT(5) will serve five client requests. If COUNT is not specified, Performance Test serves one instance of the SOCKETS.

ERROR_ACTION(MESSAGE|NOMESSAGE,STOP_CONNECTION|STOP_SCRIPT|STOP_SOCKETS|STOP_PLAYBACK|RETRY)

ERROR_ACTION specifies which messages Performance Test produces and the action it takes when a socket I/O error occurs (including connection failures, lost connections, and read/write failures). MESSAGE prints and NOMESSAGE suppresses warning and socket I/O error messages. STOP_CONNECTION stops playback on the connection where the error occurred but continues playback on the other connections in the script. STOP_SCRIPT stops script playback. STOP_SOCKETS stops playback under the SOCKETS statement. When COUNT(x) is included on the SOCKETS statement, all x playbacks are stopped when a socket I/O occurs. STOP_PLAYBACK stops playback. RETRY retries playing back the script.

ID( id_number )

The ID value provides a way to specify which connection in a script should be used based on the ID parameter of the <CONNECT> tag in the script. Otherwise, the first connection found in the script will be used.

RLOG(*| destination )

RLOG specifies where to write the output from REXX SAY statements added to your scripts. Supply a single-character sysout class, a PDSE and member, or a sequential data set.

Generate a separate data set or PDSE member for each thread of replay by including wildcard characters in the data set or member name. Valid wildcard characters include:

• Asterisk (*) — Playback replaces the asterisk with a four-digit value representing the current replay value padded with leading zeros. For example, RLOG(MRRLOG.RPLY*) generates MYRLOG.RPLY0001, MYRLOG.RPLY0002, etc. Playback allows one asterisk per data set name qualifier or member name, in any position except the first character.
• Question mark (?) — Playback replaces a string of one or more question marks with the current replay value. For example, RLOG(MYRLOG.RPLY??) generates MYRLOG.RPLY01, MYRLOG.RPLY02, etc. Include at least one question mark for each digit of the maximum replay value. For example, if the replay value will reach 20, insert at least two consecutive question marks. Playback truncates the replay value or pads it with leading zeros if there are more or fewer question marks than the number of digits in the replay value. Playback allows up to seven consecutive question marks per data set name qualifier or member name, in any position except the first character.

If you specify a data set or PDSE member that does not exist, Performance Test allocates it with default values. To override default allocation values, add an RLOG DD statement to the playback JCL.

SET_REXX_STREAM_VARIABLES specifies whether TCPIP_ACTUAL, TCPIP_EXPECTED, TCPIP_ACTUAL_LENGTH, TCPIP_EXPECTED_LENGTH, and CONNECTION_NBR should be set during playback. Performance Test sets REXX variables when the reporting data is gathered for message completion. Copying data to these variables is unnecessary if these variables are never referenced within a script. The default value is NO.

STDWAIT(15| hh:mm:ss.nnn )

STDWAIT is the longest time that Performance Test waits for I/O completion. If no I/O finishes in the STDWAIT interval, all outstanding I/O is canceled for that specific script. Performance Test retries the connections up to the number of attempts set in the CONNECTION_ATTEMPTS parameter. Performance Test retries any other I/O twice. After all attempts are made to complete the I/O, and if still unsuccessful, Performance Test takes the action set on the ERROR_ACTION parameter.

If you do not include the STDWAIT parameter, Performance Test uses the default value of 15 seconds.

STIME( time_stamp )

STIME defines a value that Performance Test uses to determine the order that SOCKETS statements are served. If the USESTIME keyword is specified on the CONTROL statement, Performance Test staggers connection of each SOCKETS based on the order of the STIME values.

Supply a date-timestamp inside single quotation marks in the following format: YYYY/MM/DD_HH:MM:SS.NNNNNN. To ensure proper formatting, copy and paste an STIME value from the script and modify it as necessary.

STIME is an optional keyword. If USESTIME is specified on the CONTROL statement, but the STIME keyword is not defined on the SOCKETS statement, playback uses the first STIME in the script.

If USESTIME is not specified on the CONTROL statement, Performance Test  ignores this keyword.

TRACE( sysout_class | dataset )

TRACE produces diagnostic information regarding Performance Test internal behavior. Contact BMC Support prior to using this option.

Specify the location for the output as a single-character sysout class, a PDSE and member, or a sequential data set.

Generate a separate data set or PDSE member for each thread of replay by including wildcard characters in the data set or member name. Valid wildcard characters include:

• Asterisk (*) — Playback replaces the asterisk with a four-digit value representing the current replay value padded with leading zeros. For example, TRACE(MYTRACE.RPLY*) generates MYTRACE.RPLY0001, MYTRACE.RPLY0002, etc. Playback allows one asterisk per data set name qualifier or member name, in any position except the first character.
• Question mark (?) — Playback replaces a string of one or more question marks with the current replay value. For example, TRACE(MYTRACE.RPLY??) generates MYTRACE.RPLY01, MYTRACE.RPLY02, etc. Include at least one question mark for each digit of the maximum replay value. For example, if the replay value will reach 20, insert at least two consecutive question marks. Playback truncates the replay value or pads it with leading zeros if there are more or fewer question marks than the number of digits in the replay value. Playback allows up to seven consecutive question marks per data set name qualifier or member name, in any position except the first character.

If you specify a data set or PDSE member that does not exist, Performance Test allocates it with default values. To override default allocation values, add a TRACE DD statement to the playback JCL.

USE_PIPELINING(NO|YES)

UE_PIPELINING enables support of message pipelining for playback of DB2C scripts. USE_PIPELINING(YES) causes playback to send multiple messages to the client before receiving responses. NO is the default value.

USE_HTTP_PIPELINING(NO|YES)

USE_HTTP_PIPELINING enables support of message pipelining for playback of HTTP and HTTPS scripts. USE_HTTP_PIPELINING(YES) causes playback to send multiple messages to the server before receiving responses. NO is the default value.

  SCRIPT statement

You can use SCRIPT statements to specify which scripts to play back and to provide playback parameters for each script. Place SCRIPT statements under a SOCKETS statement in the order that they should be played back. For information on statement hierarchy and to learn how to group SCRIPT statements, see Creating Playback Control Statements.

For client testing, there is only one SCRIPT statement under a SOCKETS statement.

scriptname

Identifies the SCRIPT (member name of the script in the script data set) to be played back.

  Preparing the playback job

Performance Test provides sample JCL to:

• Execute an unattended playback job (SQQFSAMP member TCPRUN).
• Sort the information collected during playback. Sorting collected information is required for reporting (SQQFSAMP member TCPPBSRT).

Separate samples are provided for flexibility. You can sort and save the collected information as soon as playback finishes or later when you are ready to generate reports.

To prepare a playback and sorting job:

1. Copy SQQFSAMP members TCPRUN (TCPRUN-Sample TCP/IP Playback JCL) and TCPPBSRT (TCPPBSRT-Sample JCL to Sort Data Collected During Playback) into your personal JCL libraries.

2. Open TCPRUN in a file editing tool such as ISPF Edit.
   

   TCPRUN-Sample TCP/IP Playback JCL

   ********************************* Top of Data **********************************
   //* JOB CARD INFORMATION GOES HERE
   //* HOWEVER BE SURE TO RUN WITH REGION=0M
   //UPROCS  JCLLIB ORDER=('COMPWARE.QQF800.SQQFSAMP')
   //********************************************************************
   //*  TCPPLAY PROC IS SHIPPED WITH THE SAMPLES
   //********************************************************************
   //GO      EXEC PROC=TCPPLAY,MEM=TCPPBMN,GPARM='POSIX(ON)/'
   //*
   //*           INPUT STATEMENTS, INCLUDING THE RECORDED LOG
   //*
   //GO.SYSIN    DD DSN=HPER.TEST.SCRIPTS(LOG00001),DISP=SHR
   //*
   //*           INPUT SCRIPTS, RECORDED INTO HPER.TEST.SCRIPTS.
   //*
   //GO.SYSLIB   DD DSN=HPER.TEST.SCRIPTS,DISP=SHR
   //*
   //*           IF INPUT DETAIL IS SPLIT, THEN UPDATE THE SERVER,
   //*           CLIENT AND COMBINED DD STATEMENTS APPROPRIATELY.
   //*
   //GO.SERVER   DD DSN=HPER.TEST.SCRIPTS,DISP=SHR
   //GO.CLIENT   DD DSN=HPER.TEST.SCRIPTS,DISP=SHR
   //GO.COMBINED DD DSN=HPER.TEST.SCRIPTS,DISP=SHR
   //*
   //*           USED FOR REPORTING DATA COLLECTION.
   //*           ONLY REQUIRED IF 'COLLECT' STATEMENTS ARE IN SYSIN.
   //*           DDNAME MAY BE ALTERED BY 'CONTROL DATABASE' STATEMENT.
   //*
   //GO.DATABASE DD DISP=(,CATLG),
   //*           DSN=VP.USER1.TCP.UNSORTED.DATA,
   //*           UNIT=SYSDA,SPACE=(CYL,(5,1)),
   //*           DCB=(RECFM=VB,BLKSIZE=9004,LRECL=9000)
   //*
   //GO.HTMLLOG  DD PATHOPTS=(ORDWR,OCREAT),
   //        PATHMODE=(SIRWXU,SIRWXG,SIRWXO),
   //        PATH='/u/p9/compuware/summary.htm'
   //GO.SYSABEND DD SYSOUT=*
3. Insert job statement information at the top of the sample.
4. Ensure UPROCS points to the procedures library that contains the TCPPLAY procedure. See your Systems Administrator for this information.
5. Modify the following DD statements:
   • On the SYSINDD statement, either supply the data set name containing the customized Connection Log or replace the data set name statement with inline playback control statements.
   • On the SYSLIBDD statement, supply the data set name containing the script members.

   • If the scripts contain the server and client detail data, insert an asterisk (*) before GO on the SERVER, CLIENT, and COMBINEDDD statements to turn the lines into script comments.
     If the server and client detail data is stored externally, in the same data set, modify the COMBINED DD statement and comment the SERVER and CLIENT DD statements.
     If the server and client detail data is stored in separate data sets, modify the respective DD statements and comment the COMBINED DD statement.
     
     

     Important

     On the COMBINED , or CLIENT and SERVER DD statements, supply the PSDE name only. Do not specify a member name. The member name is provided on the <DETAIL> tag within the scripts.

   • If the SYSIN DD statement does not include COLLECT statements, insert an asterisk before GO on the DATABASE DD statement. Otherwise, supply a data set name to store the information collected during playback and remove the asterisk comment indicator at the beginning of the line. If the data set name does not exist, remove the asterisks from allocation parameter lines and modify as necessary.
   • To generate an interactive HTML version of the Playback Error Summary report (here), supply an HFS path on the HTMLLOG DD statement. Otherwise, insert an asterisk at the beginning of each line of the statement.
6. The job is ready to execute playback. If you do not want to sort the collected data, submit the job. See Submitting the Job. Otherwise, complete the remaining instructions.

7. Copy TCPPBSRT and insert it at the end of the playback JCL.
   

    TCPPBSRT-Sample JCL to Sort Data Collected During Playback

   ********************************* Top of Data **********************************
   //*PLACE YOUR JOBCARD BEFORE THIS STATEMENT
   //*
   //*
   //*    HIPERSTATION TCPIP PLAYBACK REPORT DATA SORT
   //*
   //*
   //JOBLIB   DD DISP=SHR,DSN=COMPWARE.QQF800.SQQFLOAD
   //TCPSORT EXEC PGM=TCPPBSRT,REGION=4M
   //*
   //SYSOUT   DD DUMMY
   //*
   //UNSORTED DD DISP=SHR,
   //         DSN=VP.USER1.TCP.UNSORTED.DATA
   //*
   //SORTED   DD DISP=(,CATLG),
   //         UNIT=SYSDA,SPACE=(CYL,(5,1)),
   //         DSN=VP.USER1.TCP.SORTED.DATA
   //*
   //WORK     DD UNIT=VIO,SPACE=(CYL,(5,1))
   //*
   //SORTWK01 DD UNIT=VIO,SPACE=(CYL,(5,1))
   //SORTWK02 DD UNIT=VIO,SPACE=(CYL,(5,1))
   //SORTWK03 DD UNIT=VIO,SPACE=(CYL,(5,1))
   //*
8. The sample is set up to run as a separate job. To make it a step in the playback job, change JOBLIB to STEPLIB, cut the line and insert it below the TCPSORT line, and point it to the Performance Test load library at your installation. See your Systems Administrator for this information.
9. On the SORTED DD statement, supply the name of the data set for storing the sorted data.
10. Submit the job. See the next section, Submitting the Job, for submission options and job step return code information.

  Submitting the job

After the job is prepared, you can submit it in one of the following ways:

• Submit the job from the ISPF Edit session to execute it immediately. Type SUB on the Command line and press Enter.
• Schedule the job to run at a specific time. Refer to your job scheduler’s documentation for help.

After the job has completed, review the return codes to see if playback completed successfully or to determine the cause of failure.

 Review playback return codes

Performance Test reports an MVS return code for each step of a playback job. The return code is a numeric value specifying whether the job step completed successfully and to what degree. See the next section, Playback Return Code Descriptions, for a complete list of TCP/IP return codes.

The location of your return codes depends on your system configuration. On some systems, with the correct job statement parameter, return codes display in the user’s TSO session. On others, they are written to a job log. For help locating your return codes, see your systems administrator.

Performance Test also writes the following informational messages to the SYSPRINT upon job completion.

TCPSRPL-0051I Play complete for Replay=1 - Return Code=xxxx.TCPPBMN-0007I Maximum return code=xxxxMessage TCPSRPL-0051I reports the return code from the specified playback session (Replay). Performance Test produces one of these messages for each playback session in the job step.

Playback Sessions for a SOCKETS statement with COUNT(2) REPEAT(3)

Message TCPPBMN-0007I reports the maximum return code from all of the playback sessions in the job step. This is the value that Performance Test returns as the job step completion code.

If the SOCKETS statement contains multiple scripts, Performance Test returns the value set by the last script processed. Incidentally, playback terminates SOCKETS processing if it encounters a non-zero return code. For example, Performance Test reports the return code from the LOGOFF script in the following SOCKETS, unless LOGON or TEST produce a non-zero return code.

  Playback return code descriptions

Performance Test writes the following information to SYSPRINT:

• A return code message for each playback session in the job step.
• A message indicating the maximum return code for the job step.
• Playback status, warning, and error messages.

  Troubleshooting with the playback error summary

Performance Test's playback function automatically generates an Error Summary Report, in text format, for all playback jobs. Use this report to troubleshoot playback errors. View it with a spool display facility such as IBM SDSF.

The summary contains all of the error messages and significant warning messages that occurred during the playback. Use the time stamps from the messages in the summary as search criteria for locating the area of the playback log where the event occurred. This feature requires an ERRORLOG DD statement in the playback JCL. Position the ERRORLOG DD statement ahead of the Playback Log SYSOUT DD to ensure that the summary appears at the top of the report.

Playback Error Summary Report (HTML Format)

The error summary appears at the top of the browser window and the message log at the bottom. The time stamps on the messages in the summary are hyperlinked to the message in the playback log. Click an error or warning message’s time stamp to position the log accordingly. The target error/warning message is highlighted for easy recognition. Scroll up or down to see messages generated before and after the error.