Creating and Managing Playback Control Assets (MQ)

You can add unattended playback input statements directly to the log file used to execute an unattended playback job. However, saving the statements in library members preserves your work for reuse. Statements added to the log file are concatenated to the statements in the members called by the log file. If a parameter is defined on multiple statements of the same type, the value from the last statement processed takes precedence. For example, if the statement in the called CONTROL member specifies OFFLINE and THOPT(2) (think option 2) and you add a CONTROL statement specifying THOPT(3), BMC AMI DevX Performance Testfor WebSphere MQ plays back the script offline using think option 3.

Performance Test for WebSphere MQ ships with JCL that your installer uses to establish system-level playback and report control libraries along with some members containing basic CONTROL, COLLECT and REPORT statements. When generating the log file, Performance Test for WebSphere MQ defaults system-level library and member names for the asset calls. However you can override these defaults with your own library and member names. Organize your personal libraries in the same fashion as the system-level libraries.

The playback control library should contain:

• One member for each unattended playback CONTROL statement. Performance Test for WebSphere MQ provides the following basic CONTROL members for the system-level playback control library:

  • Playback — contains a CONTROL statement with no specified parameters.
  • Analyze — contains a CONTROL statement with the OFFLINE keyword.

  For more information about CONTROL statement parameters, see CONTROL statement.

• A member for each set of collection criteria. Performance Test for WebSphere MQ provides a member called COLLECT that collects all information available.

The log files generated by Performance Test for WebSphere MQ are also playback assets. Consider storing them in your personal playback control library. The system-level playback control library contains log file samples that correspond to the testing scenarios discussed in Testing Scenarios.

The report control library should contain:

• One member for each report or set of reports you would like to generate in a given job. Performance Test for WebSphere MQ provides a variety of basic REPORT members.
• One member for each report CONTROL statement. Report CONTROL statements define general report processing information. Performance Test for WebSphere MQ provides a member called MQRCTT that generates a text based report in table format, which supports the Default Script Analysis report (Script Analysis Report).

See Reporting to learn more about reporting assets.

Create your own assets and store them in either the system-level or your personal playback and reporting control libraries. Give each member a name indicative of its purpose.

The rest of this section provides syntax diagrams and parameter descriptions for each of the CONTROL, MQGROUP, SCRIPT, AND COLLECT unattended playback input statements:

Use these sections to construct statements for your own playback assets or to edit statements generated by Performance Test for WebSphere MQ. See Testing Scenarios for several detailed examples that may help you conceptualize the purpose of the available parameters.

Attribute Precedence

MQ scripts contain any or all of the following connection attributes:

• QUEUE_MANAGER
• PUT_TO
• GET_FROM
• REPLY_TO_QUEUE

If you do not specify values for any of these attributes on the unattended playback input statements, Unattended Playback uses the attributes from the script. However, your testing may call for playing back the script using different queues or queue managers. Specify any of these attributes on your CONTROL, MQGROUP, and/or SCRIPT statements to override the given attributes in the script. Consider the hierarchy of the statements when defining these attributes.

For example, set the QUEUE_MANAGER parameter on the CONTROL statement to have all of the MQGROUPs and SCRIPTs in the playback job use the same QUEUE_MANAGER. If the attribute is defined on more than one statement, the setting from the lowest level statement takes precedence. For example, you define the QUEUE_MANAGER parameter on the CONTROL statement to accommodate most of the MQGROUPs and SCRIPTs in the job. However, you need one SCRIPT in the job to use another QUEUE_MANAGER. Specify the QUEUE_MANAGER on the given SCRIPT statement to override the job-level attribute.

CONTROL statement

CONTROL statements provide general processing information for the unattended playback job. Place each CONTROL statement in a separate member in either the system-level or your personal playback control library. The system-level playback control library contains a Playback member and an Analyze member. They are virtually the same CONTROL statement except Analyze uses the OFFLINE parameter.

CACHE|CACHEOFF

CACHE instructs Performance Test for WebSphere MQ to store scripts in memory. Specifying CACHE may provide efficiencies when the COUNT and REPEAT keywords are used.

GET_FROM(queue_name|model:stem)

The default input queue for the entire WebSphere MQ playback. This can be either a dynamic queue (queue_name) or model:stem, where model is the name assigned to a set of attributes that define the queue, and stem is the beginning of the queue name. This parameter can be overridden using the GET_FROM parameter on the MQGROUP and/or SCRIPT statement or, on a Connection ID basis, using the GET_FROM_QUEUE parameter inside the PLAY_TO or PLAY_AS parameter on the MQGROUP and/or SCRIPT statements.

OFFLINE

Tells Performance Test for WebSphere MQ to analyze the script for the sole purpose of building a report database - no actual information is played to an application. You do not need to be attached to an application when creating a report using the OFFLINE parameter.

ON_MSG_ID

Controls the way MQ messages are related to one another for reporting purposes. Normally, Performance Test for WebSphere MQ uses the correlation ID, and in some cases the message ID, to group request messages with correlating reply messages. When ON_MSG_ID is specified, messages are related solely on the message ID. Use this option to track particular messages as they move through the application.

OWNERNAME(owner_name)

Entered by the user as a note concerning who created this playback or other reminder information. Must be 0 to 255 characters.

PLAYBACKNAME(playback_name)

Entered by the user as a note concerning what the playback is about or other reminder information. Must be 0 to 255 characters.

PUT_TO(queue_name|model:stem)

The default output queue for the entire WebSphere MQ playback. This can be either a dynamic queue (queue_name) or model:stem, where model is the name assigned to a set of attributes that define the queue, and stem is the beginning of the queue name. This parameter can be overridden using the PUT_TO parameter on the MQGROUP and/or SCRIPT statement or, on a Connection ID basis, using the PUT_TO_QUEUE parameter inside the PLAY_TO or PLAY_AS on the MQGROUP and/or SCRIPT statements.

QUEUE_MANAGER(queue_manager_name)

The queue manager to use for WebSphere MQ playback. Refer to Reversing Playback (PLAY_TO) and Overriding Queues (FROM_QUEUE/TO_QUEUE) for detailed testing examples that include this parameter.

REPLY_TO_QUEUE(queue_name|model:stem)

The default replyTo queue for the WebSphere MQ playback. This can be either a dynamic queue (queue_name) or model:stem, where model is the name assigned to a set of attributes that define the queue, and stem is the beginning of the queue name. The default reply_to_ queue is used by the playback when a reply_to_queue is found in the WebSphere MQ message header, and the user has requested to associate request/reply messages (see WebSphere MQ Create Scripts - Create Options Screen (1 of 2), under “Where should details be stored?”).

REXXOFF|REXXON(FULL|PARTIAL|NOSUB)

Enables or disables REXX support. REXX clauses can be used outside of script tags to perform tasks such as replacing recorded application data during playback. Additionally, REXX variables can be used within the script tags to replace MQMD field values. Both of these uses demand greater system resources during playback. Improve playback performance by specifying the appropriate REXXON/REXXOFF value for the level of support you require:

• REXXOFF disables REXX processing altogether, which improves playback performance with regard to speed and CPU and memory usage. This is the default.
• REXXON(FULL) enables REXX processing of scripts. This option supports all uses of REXX within the script. If REXXON is specified without a value, REXXON(FULL) is used.
• REXXON(PARTIAL) enables limited use of REXX within the script. This option allows the use of REXX variables for the following MQMD field values: MSGID, CORRELID, and USERIDENTIFIER. It also support the use of REXX clauses between script tags.
• REXXON(NOSUB) prevents REXX processing for script tag substitutions. That is, with this option, you cannot use REXX variables within the script tags. However, REXX clauses inserted between script tags are still supported.

RLOG(*|destination)

To write your REXX say statements to a data set rather than standard output, specify RLOG. RLOG specifications can be wild cards. This generates unique names for each replay ID.

For example, RLOG(myrolog.rpl*) generates data sets containing REXX log information that are named MYRLOG.RPL0001.

You can also use a number of question marks, ‘?’, to hold the replay ID in the data set name. For example, RLOG(myrolog.rpl??) generates data sets containing REXX log information that are named MYRLOG.RPL01.

If the RLOG specification is a single character, Performance Test for WebSphere MQ assumes it to be a SYSOUT class. RLOG data can be stored in a PDSE or in a data set member. To override a default RLOG data set allocation, add an //RLOGDD statement to your JCL as shown below.

SET_REXX_STREAM_VARIABLES(NO|YES)

Enables the use of the Performance Test for WebSphere MQ 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 WebSphere MQ 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 for WebSphere MQ waits for I/O completion. If no I/O finishes in the STDWAIT interval, all outstanding I/O is cancelled for that specific script. Performance Test for WebSphere MQ retries the connections up to the number of attempts set in the CONNECTION_ATTEMPTS parameter (TCP/IP only). Performance Test for WebSphere MQ retries any other I/O twice. Once all attempts are made to complete the I/O, if still unsuccessful, Performance Test for WebSphere MQ takes the action set on the ERROR_ACTION parameter (TCP/IP only).

Measured in hundredths of a second, as nnn. This value is taken from the slow start value used in Application Profiling. Default value is 001 (1/100th of a second).

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

Enter the think time in HH:MM:SS.nnnnnnn format. For example, THINK(1) is one second of think time. THINK(10:10.10) is 10 minutes + 10 seconds+ 1/10th of a second.

THOPT(1|2|3)

Sets a think-time option.

• 1: Play at full speed. The transactions are played back as fast as the system can run them. This is the default.
• 2: Think time recorded in the script. Think time is simulated using the difference between each <TIME> tag in the script.
• 3: User-set think time. Indicates that the think time is the amount set by the THINK parameter.

Refer to Controlling Playback Timing (USESTIME and THOPT) for a detailed example.

THPCT(100|percent)

Sets a think time percentage. This parameter is valid only in conjunction with THOPT(2) or THOPT(3). The default is 100 percent.

TRACE(sysout_class|dataset)

TRACE allows you to trace internal Performance Test for WebSphere MQ information. If the TRACE specification is a single character, Performance Test for WebSphere MQ assumes it to be a SYSOUT class.

A data set specification can contain wildcard characters. A single asterisk (*) tells Performance Test for WebSphere MQ to insert the current ReplayID with enough leading zeros to create a 4-digit number. ReplayID is the unique ID assigned by Performance Test for WebSphere MQ to each message.

One or more question marks (?) tells Performance Test for WebSphere MQ to insert the current ReplayID with enough leading zeros so that the number is the same length as the number of question marks.

• no wild cards are allowed in this data set
• produces ABC.DEF

• no wild cards allowed in the data set or member
• produces ABC.DEF(XYZ)

• both ?? and * are wild cards
• produces ABC01.DEF0001

USESTIME

When specified, Performance Test for WebSphere MQ sends data to its partner in the order in which it was captured relative to the STIME parameter on the MQGROUP statement. For example, the following STIME parameters result in the second group playing back five minutes after the first.

See Synchronizing Group Playback (USESTIME) and Controlling Playback Timing (USESTIME and THOPT) for detailed examples.

MQGROUP statement

MQGROUP defines playback parameters for a group of scripts. All groups are processed simultaneously. The Create MQ Scripts option generates MQGROUP statements in the log file based on the script create options you select. Modify or add statements to your log files to control playback. See Playing Back Multiple Scripts Serially and Playing Back Scripts Simultaneously (Multiple Groups) for comprehensive MQGROUP examples.

COUNT(1|number_of_copies)

Specifies the number of times to start playback. Use REPEAT to play back sequentially. Use COUNT to play back simultaneously. See Repeating Simultaneous Playback (Count and Repeat) for a detailed example.

GET_FROM(queue_name|model:stem)

The default input queue for the WebSphere MQ playback for this MQGROUP statement. This can be either a dynamic queue (queue_name) or model:stem, where model is the name assigned to a set of attributes that define the queue, and stem is the beginning of the queue name. If a GET_FROM_QUEUE is found on the following SCRIPT statement with no applicable PLAY_TO or PLAY_AS, then the queue listed on this GET_FROM is used.

GET_FROM_QUEUE(queue_name|model:stem)

When encountering an MQ_GET,  for WebSphere MQ performs the MQGET on the queue specified by the GET_FROM_QUEUE if specified. This parameter is only used in conjunction with PLAY_AS or PLAY_TO.

PLAY_AS(CONNECTION_ID(id)ON(queue_name))

As recorded, a script contains a series of WebSphere MQ events. These events are played through a CONNECTION_ID. This CONNECTION_ID represents a connection between the queue manager and an application and acts as an application from a WebSphere MQ playback perspective. Events in the script act under their CONNECTION_ID. To use WebSphere MQ applications, the user must tell Performance Test for WebSphere MQ whether to play the script as an application, or to play the script to an application. Using the PLAY_AS statement instructs Performance Test for WebSphere MQ to play the script in the direction recorded in the script, as if Performance Test for WebSphere MQ was the application generating the data in the script.

When encountering an MQ_GET, Performance Test for WebSphere MQ performs an MQGET. When encountering an MQ_PUT, Performance Test for WebSphere MQ PUTs that scripted message to the PUT_TO_QUEUE if specified. Additionally, when encountering an MQ_GET, Performance Test for WebSphere MQ performs the MQGET to retrieve the message on the queue specified by the GET_FROM_QUEUE if specified. PLAY_AS is the default.

PLAY_TO(CONNECTION_ID(id)ON(queue_name))

As recorded, a script contains a series of WebSphere MQ events. These events are played through a CONNECTION_ID. This CONNECTION_ID represents a connection between the queue manager and an application and acts as an application from a WebSphere MQ playback perspective. Events in the script act under their CONNECTION_ID. To use WebSphere MQ applications, the user must tell Performance Test for WebSphere MQ whether to play the script as an application, or to play the script to an application. Using the PLAY_TO statement reverses the direction of script play causing Performance Test for WebSphere MQ to act as though it is receiving the data generated from the application. PLAY_TO is useful when a script is created based on queue activity requested by a server, for example a CICS region, and you want to test the server application using that script. To test the server application, Performance Test for WebSphere MQ prepares the queues used by the server application so that the server application can access the messages on the queues. Specify an asterisk (*) on the CONNECTION_ID parameter value to reverse the playback of all connection IDs in the script. See Playing Back with PLAY_TO(CONNECTION_ID(*)) for further examples.

For the CONNECTION_ID specified when encountering an MQ_GET in the script, Performance Test for WebSphere MQ PUTs that scripted message, making it available to the application. If specified, Performance Test for WebSphere MQ PUTs that message to the PUT_TO_QUEUE. Additionally, when encountering an MQ_PUT in the script, Performance Test for WebSphere MQ performs an MQ_GET to retrieve the record written by the application, from the GET_FROM_QUEUE if specified. If there is a PLAY_TO with a GET_FROM_QUEUE or a PUT_TO_QUEUE for a connection, then the connection ID listed on the PLAY_TO is used. If these parameters appear on both the SCRIPT and MQGROUP statements, then the SCRIPT statement parameters are used. See Reversing Playback (PLAY_TO) and Overriding Queues (FROM_QUEUE/TO_QUEUE) for detailed testing examples that include this parameter.

The ON parameter limits the MQ transaction, PUT or GET, being reversed to the one that uses the queue specified in the ON parameter only.

PUT_TO(queue_name|model:stem)

The default output queue for the WebSphere MQ playback. This can be either a dynamic queue (queue_name) or model:stem, where model is the name assigned to a set of attributes that define the queue, and stem is the beginning of the queue name. If a PUT_TO_QUEUE is found on the SCRIPT statement with no applicable PLAY_TO or PLAY_AS, then the queue listed on this PUT_TO or GET_FROM is used.

PUT_TO_QUEUE(queue_name|model:stem)

When encountering an MQ_PUT, Performance Test for WebSphere MQ PUTs that scripted message to the PUT_TO_QUEUE if specified. This parameter is only used in conjunction with PLAY_AS or PLAY_TO.

QUEUE_MANAGER(queue_manager_name)

The queue manager to use for WebSphere MQ playback. See the Reversing Playback (PLAY_TO) scenario, which includes a queue manager override example.

REPEAT(1|number_of_iterations)

Tells Performance Test for WebSphere MQ to repeat playback the specified number of times.

REPLY_TO_QUEUE(queue_name|model:stem)

The default replyTo queue for the WebSphere MQ playback. This can be either a dynamic queue (queue_name) or model:stem, where model is the name assigned to a set of attributes that define the queue, and stem is the beginning of the queue name. The default reply_to_ queue is used by the playback when a reply_to_ queue is found in the WebSphere MQ message header, and the user has requested to associate request/reply messages. See WebSphere MQ Create Scripts - Create Options Screen (1 of 2), under “Where should details be stored?”.

REPLY_TO_QMGR(qmgr_name)

The default reply_to_qmgr is used by the playback to allow the user to specify where reply messages are placed.

SKIP(JOB(jobname,jobname,...))

SKIP(CONNECTION_ID(connection_ID,connection_ID,..))

A list of job names or connection IDs used to determine if individual script records should be used in the playback. When a script record associated with one of the jobs or connection IDs in the list is found in the script, it is skipped. Jobnames can be up to eight characters. Use both JOB and CONNECTION_ID, but they must be on two separate SKIP statements.

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

Tells Performance Test for WebSphere MQ how long to wait between the start of MQGROUP and the commencement of playback. Use STARTDLY to stagger the start of playbacks using multiple MQGROUP statements. For example, to wait five seconds, enter STARTDLY(5).

STIME(‘timestamp’)

The recorded start time of the activity in the script. This timestamp is created by the script create program. The format of the timestamp is:

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

Enter the think time in HH:MM:SS.nnnnnnn format. For example, THINK(1) is one second of think time. THINK(10:10.10) is 10 minutes + 10 seconds+ 1/10th of a second.

THOPT(1|2|3)

Sets a think-time option.

• 1: Play at full speed. The transactions are played back as fast as the system can run them. This is the default.
• 2: Think time recorded in the script. Think time is simulated using the difference between each <TIME> tag in the script.
• 3: User-set think time. Indicates that the think time is the amount set by the THINK parameter.

Refer to Controlling Playback Timing (USESTIME and THOPT) for a detailed example.

THPCT(100|percent)

Sets a think time percentage. This parameter is valid only in conjunction with THOPT(2) or THOPT(3). The default is 100 percent.

TRACE(sysout_class|dataset)

TRACE enables you to trace internal Performance Test for WebSphere MQ information. If the TRACE specification is a single character, Performance Test for WebSphere MQ assumes it to be a SYSOUT class.

A data set specification can contain wildcard characters. A single asterisk (*) tells Performance Test for WebSphere MQ to insert the current ReplayID with enough leading zeros to create a 4-digit number. ReplayID is the unique ID assigned by Performance Test for WebSphere MQ to each message.

One or more question marks (?) tells Performance Test for WebSphere MQ to insert the current ReplayID with enough leading zeros so that the number is the same length as the number of question marks.

• no wild cards allowed in this data set
• produces ABC.DEF

• no wild cards allowed in the data set or member
• produces ABC.DEF(XYZ)

• both ?? and * are wild cards
• produces ABC01.DEF0001

SCRIPT statement

SCRIPT statements define playback parameters for the script. An unattended playback can contain one or more script statements. The script statements within a group are processed sequentially. The Create MQ Scripts option generates SCRIPT statements in the log file based on the script create options you select. Modify SCRIPT statements in the log file.

GET_FROM(queue_name|model:stem)

The default input queue for the WebSphere MQ playback for this SCRIPT statement. This can be either a dynamic queue (queue_name) or model:stem, where model is the name assigned to a set of attributes that define the queue, and stem is the beginning of the queue name. If a GET_FROM_QUEUE is found on this SCRIPT statement with no applicable PLAY_TO or PLAY_AS, then the queue listed on this GET_FROM is used.

GET_FROM_QUEUE(queue_name|model:stem)

When encountering an MQ_GET, Performance Test for WebSphere MQ performs the MQGET on the queue specified by the GET_FROM_QUEUE if specified. This parameter is only used in conjunction with PLAY_AS or PLAY_TO.

PLAY_AS(CONNECTION_ID(x)ON(queue_name)

As recorded, a script contains a series of WebSphere MQ events. These events are played on a CONNECTION_ID. This CONNECTION_ID represents a connection between the queue manager and an application and acts as an application from a WebSphere MQ playback perspective. Events in the script act under their CONNECTION_ID. To use WebSphere MQ applications, the user must tell Performance Test for WebSphere MQ whether to play the script as an application, or to play the script to an application. Using the PLAY_AS statement requests Performance Test for WebSphere MQ to play the script in the direction recorded in the script, as if Performance Test for WebSphere MQ was the application generating the data in the script.

When encountering an MQ_GET, Performance Test for WebSphere MQ performs an MQGET. When encountering an MQ_PUT, Performance Test for WebSphere MQ PUTs that scripted message to the PUT_TO_QUEUE if specified. Additionally, when encountering an MQ_GET, Performance Test for WebSphere MQ performs the MQGET to retrieve the second on the queue specified by the GET_FROM_QUEUE if specified. PLAY_AS is the default.

PLAY_TO(CONNECTION_ID(x)ON(queue_name)

As recorded, a script contains a series of WebSphere MQ events. These events are played through a CONNECTION_ID. This CONNECTION_ID represents a connection between the queue manager and an application and acts as an application from a WebSphere MQ playback perspective. Events in the script act under their CONNECTION_ID. To use WebSphere MQ applications, you must tell Performance Test for WebSphere MQ whether to play the script as an application, or to play the script to an application. Using the PLAY_TO statement reverses the direction of script play causing Performance Test for WebSphere MQ to act as though it is receiving the data generated from the application. PLAY_TO is useful when a script is created based on queue activity requested by a server, for example a CICS region, and you want to test the server application using that script. To test the server application, Performance Test for WebSphere MQ prepares the queues used by the server application so that the server application can access the messages on the queues.

For the CONNECTION_ID specified, when encountering an MQ_GET in the script, Performance Test for WebSphere MQ PUTs that scripted message, making it available to the application. If specified, Performance Test for WebSphere MQ PUTs that message to the PUT_TO_QUEUE. Additionally, when encountering an MQ_PUT in the script, Performance Test for WebSphere MQ performs an MQGET to retrieve the record written by the application, from the GET_FROM_QUEUE if specified. If there is a PLAY_TO with a GET_FROM_QUEUE or a PUT_TO_QUEUE for a connection, then the connection ID listed on the PLAY_TO is used. If these parameters appear on both the SCRIPT and MQGROUP statements, then the SCRIPT statement parameters are used.

The ON parameter limits the MQ transaction, PUT or GET, being reversed to the one that uses the queue specified in the ON parameter only.

PUT_TO(queue_name|model:stem)

The default output queue for the WebSphere MQ playback for this Script Statement. This can be either a dynamic queue (queue_name) or model:stem, where model is the name assigned to a set of attributes that define the queue, and stem is the beginning of the queue name. If a PUT_TO_QUEUE is found on the SCRIPT statement with no applicable PLAY_TO or PLAY_AS, then the queue listed on this PUT_TO or GET_FROM is used.

PUT_TO_QUEUE(queue_name|model:stem)

When encountering an MQ_PUT, Performance Test for WebSphere MQ PUTs that scripted message to the PUT_TO_QUEUE if specified. This parameter is only used in conjunction with PLAY_AS or PLAY_TO.

QUEUE_MANAGER(queue_manager_name)

The default queue manager for WebSphere MQ playback.

REPEAT(1|number_of_iterations)

Tells Performance Test for WebSphere MQ to repeat playback the specified number of times.

REPLY_TO_QMGR(qmgr_name)

The default reply_to_qmgr is used by the playback to allow the user to specify where reply messages are placed.

REPLY_TO_QUEUE(queue_name|model:stem)

The default replyTo queue for the WebSphere MQ playback. This can be either a dynamic queue (queue_name) or model:stem, where model is the name assigned to a set of attributes that define the queue, and stem is the beginning of the queue name. The default reply_to_ queue is used by the playback when a reply_to_ queue is found in the WebSphere MQ message header, and the user has requested to associate request/reply messages. See WebSphere MQ Create Scripts - Create Options Screen (1 of 2), under “Where should details be stored?”.

SKIP(CONNECTION_ID(xx,yy,zz,...))

A list of connection IDs used to determine if individual script records should be used in the playback. When a script record associated with one of the connection IDs in the list is found in the script, it is skipped. Jobnames can be up to eight characters. To use both JOB and CONNECTION_ID, but they must be on two separate SKIP statements.

SKIP(JOB(xxxxxxxx,yyyyyyyy,zzzzzzzz,...))

A list of jobnames used to determine if individual script records should be used in the playback. When a script record associated with one of the jobs in the list is found in the script, it is skipped. Jobnames can be up to eight characters. To use both JOB and CONNECTION_ID, but they must be on two separate SKIP statements.

COLLECT statement

The COLLECT statement defines the information to collect during the unattended playback. Create a member for each set of collection criteria (one or more collect statements) in either the system-level or your personal playback control library.

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.

See Data Collection and Reporting Tables to determine which tables and fields to collect or to locate short field names.

FROM

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

WHERE

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