Synchronizing Group Playback (USESTIME) (MQ)

This scenario demonstrates synchronizing MQGROUP playback. Normally, all MQGROUPs in the job begin playing back at the same time. However, you can stagger group playback to accommodate application timing requirements. For example, if the transactions in the scripts belonging to the first group must begin execution before the transactions in the second group, use the USESTIME CONTROL statement parameter to delay playback of the second group.

Each MQGROUP statement bears an STIME parameter that indicates when that first transaction in the group began. The USESTIME 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.

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

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 with each instance beginning three minutes later than the previous instance. Track the response times from each group to ensure that application resources are available when the second and third groups begin playing back.

Activity Captured in Sample Script SCRTS001

During playback, generate a:

• Script Timing Summary and Response Time Summary to review the remote processing performance.
• HTML Exception Report to compare recorded remote processing responses to the responses received during playback. You can also generate an 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. To compare the scripts you generate to the sample scripts, run an analyze job on each script saving the sorted data. 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: LOGTS000
• Script: SCRTS001

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 PDA018’s credit inquiry and response retrieval activity. See Activity Captured in Sample Script SCRTS001 to view 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:

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 parameter, as shown in LOGTS000, or add the parameter 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 why you need to do this and how.