Reversing Playback (PLAY_TO) (MQ)

This scenario demonstrates using the PLAY_TO parameter to reverse playback. That is, Performance Test for WebSphere MQ plays MQ_GETs as MQ_PUTs and vice versa. In this scenario, the purpose of reversing playback is to populate a queue with requests that were retrieved by the subject application during recording.

The Credit Bureau Processing program is driven by a remote (off-site) application, PDA018. PDA018 PUTs requests to a remote queue that uses channel initiators (CHINs) to transmit the request to the Credit Bureau Inquiry Queue. The Credit Bureau Processing Program then GETs the request from the local inquiry queue and PUTs its responses to a remote response queue.

Activity Captured in Sample Script SCRPT001

Testing the Credit Bureau Processing Program requires replicating the activity that drives the program. However, it may be inconvenient to play back activity at the remote location. To test without involving the remote location, capture the Credit Bureau Processing Program’s activity, build a script containing only the GETs, and play back the script in reverse to PUT the recorded requests into the inquiry queue. Once the request are in the queue, the Credit Bureau Processing Program will automatically GET the requests and begin processing.

This scenario teaches you how to use the PLAY_TO parameter. Therefore, this section details only the steps necessary to repopulate the queue. However, if you wanted to validate application processing in this scenario, you would:

1. Initiate a Global Recording to capture the Credit Bureau Processing Program activity resulting from repopulating the queue. Begin recording before playing back the script in reverse.
2. Create a script from that capture containing only the MQ_PUTs.
3. Run an analyze job on the script and save the sorted data.
4. Create a script from the initial recording repository (REPOS3 in this scenario) containing only the MQ_PUTs.
5. Run an analyze job on the script and save the sorted data.
6. Generate a Baseline Comparison Report using the two data collections.

Additionally, this scenario exemplifies using the QUEUE_MANAGER parameter to override the queue manager in the script. That is, the activity in the sample repository REPOS3, was actually recorded on a production system containing queues with the same name as the test system. Use a queue manager override to play the scripts back on the test system.

This scenario requires modifying the LOG file before submitting the unattended playback job. The rest of this section provides a list of supporting sample files, describes the filtering required to generate the script, and details the log file edits required to perform the unattended playback job.

Use the filtering information provided in this discussion to generate scripts from sample repository REPOS3. 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: REPOS3
• Log: LOGPT000
• Script: SCRPT001

Filters

REPOS3 contains Credit Bureau Processing Program activity from the production environment that uses queue manager O530. Apply the following filter during script creation to generate script containing only the GETs issued by the Credit Bureau Processing Program.

Filter 1

Log editing requirements

In the log file used to run the unattended playback job:

• Add the QUEUE_MANAGER(M530) parameter to the MQGROUP statement to play back the script on the test system (M530) instead of the production system (O530).
• Add the PLAY_TO(CONNECTION_ID(2)) parameter to the MQGROUP statement to reverse the playback of CONNECTION_ID(2) activity.

Refer to sample LOGPT000 to see these edits.