Controlling Playback Timing (USESTIME and THOPT) (MQ)

This scenario demonstrates controlling how fast each MQGROUP plays back and when, in relationship to the other groups, they begin playing back. Normally, all MQGROUPs in the job begin playing back at the same time as fast as the system allows. However, you can simulate live user activity by having groups play back in the order and at approximately the same speed as they were recorded.

Each MQGROUP statement bears an STIME parameter that indicates when that first transaction in the group began. The USESTIME playback CONTROL statement parameter forces playback of the groups relative to each group’s STIME. For example, if the STIME for the first group is one hour earlier than the STIME in the second group, the second group begins playing back an hour after the first.

The STIME is the same for each group if you are playing back the same script in different groups. Apply the USESTIME parameter and modify the STIME to stagger playback.

The think option 2, THOPT(2), playback CONTROL statement parameter forces the group to play back at approximately the same speed as it was recorded. Each transaction within a script bears a <TIME> tag that indicates when the transaction was recorded. Performance Test for WebSphere MQ uses the difference between <TIME> tags to determine the amount of time to wait before playing the next transaction.

This scenario entails capturing activity from the entire customer order and credit inquiry application (Flowchart for the Sample Customer Order And Credit Inquiry Application), generating a script containing only the activity produced by the PDA018 Credit Inquiry Program, and playing back the script three times beginning three minutes apart and at recorded speed. Track the response times from each group to ensure that the application responds similarly when the second and third groups begin playing back.

Activity Captured in Sample Script SCRTD001

During playback, generate:

• A Script Timing Summary and Response Time Summary to review the remote processing performance and ensure application resources are available when subsequent groups play back.
• An HTML Exception Report to compare recorded application responses to the responses received during playback or to compare response times in the script to response times in the playback. You can also generate a custom comparison report in TEXT or CSV format.

This scenario requires modifying the LOG file before submitting the unattended playback job.

The rest of this section details each step required to achieve the scenario except for capture. Use the filtering information provided in this discussion to generate scripts from sample repository REPOS1. If you wish to compare the scripts you generate to the sample scripts, run an analyze job on each script saving the sorted data and generate a baseline HTML Exception Report to ensure that the script you created contains the same activity as the sample script. See Analyzing and Comparing Scripts.

Supporting sample files

The sample files supporting this scenario include:

• Repository: REPOS1
• Log: LOGTD000
• Script: SCRTD001

Filters

REPOS1 contains activity for the entire customer order and credit inquiry program (Flowchart for the Sample Customer Order And Credit Inquiry Application). Apply the following filters during script creation to generate a script containing the credit inquiry of PDA018 and response retrieval activity. Refer to Activity Captured in Sample Script SCRTD001 to see the application flow of PDA018 and the names of the queues it uses.

Filter 1

Filter 2

Script and log editing requirements

To stagger multiple playbacks of the same MQGROUP and play each group back at the speed it was recorded:

1. Copy and paste the MQGROUP statements as many times as desired to play the group back.
2. Modify the STIME for each group.
3. Either add a CONTROL statement directly to the log file that bears the USESTIME and THOPT(2) parameters, as shown in LOGTD000, or add the parameters to the CONTROL statement in the playback control member specified on the SET ACTION statement (top of log file).

If the MQGROUP contains more than one script, strip the MQ_DISCONNECTs out of each script and save them in a separate PDS member. Add a SCRIPT statement to the end of the group to replay the member containing the disconnects. See Playing Back Multiple Scripts Serially to find out how and why you need to do this.