Hiperstation for WebSphere MQ User Guide

Transcription

Hiperstation
Hiperstation for WebSphere MQ
User Guide
Release 8.0.1
ii
Please direct questions about Hiperstation
or comments on this document to:
Compuware Customer Support
http://go.compuware.com/
This document and the product referenced in it are subject to the following legends:
Copyright 1994-2013 Compuware Corporation. All rights reserved. Unpublished rights
reserved under the Copyright Laws of the United States.
U.S. GOVERNMENT RIGHTS-Use, duplication, or disclosure by the U.S. Government is
subject to restrictions as set forth in Compuware Corporation license agreement and as
provided in DFARS 227.7202-1(a) and 227.7202-3(a) (1995), DFARS 252.227-7013(c)(1)(ii)
(OCT 1988), FAR 12.212(a) (1995), FAR 52.227-19, or FAR 52.227-14 (ALT III), as
applicable. Compuware Corporation.
This product contains confidential information and trade secrets of Compuware
Corporation. Use, disclosure, or reproduction is prohibited without the prior express
written permission of Compuware Corporation. Access is limited to authorized users. Use
of this product is subject to the terms and conditions of the user’s License Agreement
with Compuware Corporation.
Compuware, Hiperstation, Hiperstation for VTAM, Hiperstation for Mainframe Servers,
Hiperstation for WebSphere MQ, QAHiperstation+, QAPlayback, File-AID, File-AID for
DB2, File-AID for IMS, File-AID/MVS, and File-AID/RDX are trademarks or registered
trademarks of Compuware Corporation.
ISPF, CICS, DB2, DFSMS, MVS/ESA, MVS/SP, MVS/XA, OS/390, RACF, REXX, VTAM,
BookManager, MQSeries, WebSphere MQ, zSeries, and z/OS are trademarks or registered
trademarks of International Business Machines Corporation.
Adobe® Reader® is a trademark of Adobe Systems Incorporated in the United States
and/or other countries.
All other company and product names are trademarks or registered trademarks of their
respective owners.
CWQIUG8A
October 25, 2013.
iii
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Accessing Hiperstation Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiii
HTML Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
BookManager Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
PC Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Mainframe Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Known-Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Using this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Hiperstation for WebSphere MQ User Guide Overview . . . . . . . . . . . . . . . xv
Notation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Using Wild Cards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Reading Syntax Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Installing Windows Accessibility Features . . . . . . . . . . . . . . . . . . . . . . . . . xix
Selecting Font and Font Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Changing Color and Contrast. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Setting Cursor Blink Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Using Keyboard Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Accessibility Exceptions Work Arounds . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Known Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
FrontLine Support Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Contacting Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii
Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii
Corporate Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii
Chapter 1. Product Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Hiperstation for WebSphere MQ Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Chapter 2. Global Recording Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Adding a Global Recording Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Monitoring and Maintaining Existing Requests . . . . . . . . . . . . . . . . . . . . . . . . 2-6
View Session Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Monitor All Existing Requests (Administrator Access) . . . . . . . . . . . . . . . . 2-9
Using the Global Recording Batch Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Create a Global Recording Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Global Recording Request Parameter Syntax . . . . . . . . . . . . . . . . . . 2-11
Global Recording Request Parameters . . . . . . . . . . . . . . . . . . . . . . . . 2-12
Check the Status of Existing Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Manage Existing Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Retrieve Parameters from an Existing Request . . . . . . . . . . . . . . . . . . . . . 2-22
Generate a Request Parameters Skeleton . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
Troubleshoot Failed Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
iv
Merging Capture Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
Chapter 3. Scripts and Subset Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Creating Scripts and Subset Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Script and Subset Repository Creation Overview . . . . . . . . . . . . . . . . . . . 3-1
Generate a Capture Segment Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Establish Filtering Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Header Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
Header Filter Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Message Data Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Import Filters and Options Command . . . . . . . . . . . . . . . . . . . . . . 3-12
Specify Source Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Define Event Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Define Detail Data Storage and Output Requirements . . . . . . . . . . . . . . 3-15
Event Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
Specify a Subset Repository Dataset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
Specify Other Output Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23
Select a Processing Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24
Script Create JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25
Browsing and Editing Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26
Browse a Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26
Structure Data Type Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27
Parameters Common to Most Script Tags . . . . . . . . . . . . . . . . . . . . 3-29
<CONTENT> Tag for Inline Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30
<CONTENT> Tag for External Data . . . . . . . . . . . . . . . . . . . . . . . . . 3-31
<DETAIL> Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32
<MQ_BACKOUT...> Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32
<MQ_CLOSE...> Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32
<MQ_COMMIT...> Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33
<MQ_CONNECT...> Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33
<MQ_DISCONNECT...> Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34
<MQ_GET...> Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34
<MQ_INQUIRE...> Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34
<MQ_OPEN...> Tag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35
<MQ_PUT...> Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36
<MQ_PUT1...> Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36
<MQ_SET...> Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37
<TIME> Tag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37
<VERSION> Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37
Edit a Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38
Script Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-39
<REPLACE> Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-40
Offset and Length Determination Macros . . . . . . . . . . . . . . . . . . . . 3-41
Hiperstation for WebSphere MQ REXX Variables . . . . . . . . . . . . . . 3-44
Editing MQ Message Data with File-AID/MVS . . . . . . . . . . . . . . . . . . . . . . . . 3-47
Assign a PF Key to MAPD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-47
Map an Individual Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48
Map an Entire Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49
Access MAPD Help Panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50
Troubleshoot Message Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50
Chapter 4. Interactive Playback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introducing Interactive Playback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a New Interactive Playback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generating a Playback from a Script Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing Playback Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Environment Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-1
4-1
4-2
4-4
4-5
4-5
v
MQ Group Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Script Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Submitting Your Playback for Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Selecting a Previously Saved Playback to Review . . . . . . . . . . . . . . . . . . . . . . . 4-14
Deleting a Playback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
Generating Playback Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
WebSphere MQ - Basic Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
WebSphere MQ - Custom Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
Chapter 5. Unattended Playback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Unattended Playback Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Creating and Managing Playback Control Assets . . . . . . . . . . . . . . . . . . . . . . . 5-2
Attribute Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
CONTROL Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
MQGROUP Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
SCRIPT Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
COLLECT Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
Preparing the Log File for Unattended Playback . . . . . . . . . . . . . . . . . . . . . . . 5-16
MQ Log STEPLIB Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
Submitting the Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21
Review Playback Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21
Playback Return Code Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . 5-22
Troubleshooting with the Playback Error Summary . . . . . . . . . . . . . . . . . . . . 5-24
Chapter 6. Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
Reporting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
Creating and Managing Reporting Control Assets. . . . . . . . . . . . . . . . . . . . . . . 6-2
CONTROL Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
REPORT Statements for Basic Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
HTML Exception REPORT Statement . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
Response Time and Script Timing REPORT Statements . . . . . . . . . . . 6-8
REPORT Statement for Custom Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
Preparing the Log File for Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
Submitting the Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
Reading and Navigating Basic Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
HTML Exception Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17
Script Timing Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20
Response Time Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-21
Reading Custom Reports (Field Definitions) . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24
Chapter 7. Archive Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
Introducing the Archive Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
Using Hiperstation as a Security Monitoring Tool . . . . . . . . . . . . . . . . . . . 7-1
Implementing Hiperstation as a Security Monitoring Tool . . . . . . . . . . . . 7-1
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Using the Archive Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Chapter 8. Testing Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
Understanding the Example Application’s Data Flow . . . . . . . . . . . . . . . . . . . . 8-1
Playing Back Multiple Scripts Serially . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
Supporting Sample Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
Script and Log Editing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
Playing Back Scripts Simultaneously (Multiple Groups) . . . . . . . . . . . . . . . . . . 8-6
Supporting Sample Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7
Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
Log Editing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
vi
Repeating Simultaneous Playback (Count and Repeat) . . . . . . . . . . . . . . . . . . 8-9
Supporting Sample Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
Script and Log Editing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
Synchronizing Group Playback (USESTIME) . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
Controlling Playback Timing (USESTIME and THOPT) . . . . . . . . . . . . . . . . . 8-14
Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16
Reversing Playback (PLAY_TO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17
Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18
Log Editing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
Overriding Queues (FROM_QUEUE/TO_QUEUE) . . . . . . . . . . . . . . . . . . . . . 8-19
Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21
Omitting Specified Activity (SKIP(CONNECTION_ID)) . . . . . . . . . . . . . . . . . 8-22
Playing Back with PLAY_TO(CONNECTION_ID(*)) . . . . . . . . . . . . . . . . . . . . 8-24
Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-26
Replacing Script Data with a Static Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-28
Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
Script Edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
Log Edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-33
Replacing Script Data Dynamically. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-33
Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-35
Script Edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-35
Log Edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-38
Expanding Data During Playback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-38
Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-40
Script Edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-40
Log Edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-46
Replacing Data During Repeated Concurrent Playback . . . . . . . . . . . . . . . . . 8-47
Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-48
Script Edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-49
Log Edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-52
Analyzing and Comparing Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-52
Chapter 9. Hiperstation for WebSphere MQ Profile Defaults . . . . . . . . . . . . . . . .
WebSphere MQ Profile Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing WebSphere MQ Profile Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Playback WebSphere MQ Profile Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-1
9-1
9-6
9-8
vii
Appendix A. Data Collection and Reporting Tables . . . . . . . . . . . . . . . . . . . . . . .
PLAYBACK Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PLAYBACK Report Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PLAYBACK Statistic Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MQGROUP Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MQGROUP Report Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MQGROUP Statistic Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MQSCRIPT Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MQSCRIPT Report Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MQSCRIPT Statistic Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MQMESSAGESET Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MQMESSAGESET Report Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MQMESSAGESET Statistic Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MQOPENQUEUE Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MQOPENQUEUE Report Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MQMESSAGE Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MQMESSAGE Report Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A-1
A-1
A-1
A-2
A-2
A-3
A-3
A-3
A-4
A-4
A-4
A-5
A-5
A-5
A-6
A-6
A-6
Appendix B. Hiperstation for WebSphere MQ Samples Index . . . . . . . . . . . . . . . B-1
Playback Control Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-1
Basic Playback Control Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-1
Sample Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-1
Reporting Control Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-2
JCL to Create Web Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-2
REPORT and Reporting CONTROL Statements . . . . . . . . . . . . . . . . . . . . .B-2
Script Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-3
Repository Datasets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-3
Samples Library (SQQFSAMP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-4
Playback and Reporting JCL and JCL SYSIN . . . . . . . . . . . . . . . . . . . . . . . .B-4
Global Recording Batch Interface JCL and XML . . . . . . . . . . . . . . . . . . . .B-4
Appendix C. Customer Support Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
Appendix D. Script Create Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-1
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-1
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1
viii
ix
Figures
2-1.
2-2.
2-3.
2-4.
2-5.
2-6.
2-7.
2-8.
2-9.
2-10.
2-11.
2-12.
3-1.
3-2.
3-3.
3-4.
3-5.
3-6.
3-7.
3-8.
3-9.
3-10.
3-11.
3-12.
3-13.
3-14.
3-15.
3-16.
3-17.
3-18.
3-19.
3-20.
3-21.
4-1.
4-2.
4-3.
4-4.
4-5.
4-6.
4-7.
4-8.
4-9.
4-10.
4-11.
4-12.
4-13.
4-14.
4-15.
4-16.
4-17.
4-18.
4-19.
4-20.
4-21.
4-22.
4-23.
Hiperstation for WebSphere MQ Main Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2
Global Recording Requests Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3
Global Recording - Monitor MQ Requests Screen . . . . . . . . . . . . . . . . . . . . . . . . . .2-3
WebSphere MQ Data Collect Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3
WebSphere MQ - MQ Filtering Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4
WebSphere MQ Data Collect - Output Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5
Global Recording - Monitor MQ Requests Screen . . . . . . . . . . . . . . . . . . . . . . . . . .2-7
Global Recording - Active WebSphere MQ Sessions Screen. . . . . . . . . . . . . . . . . . .2-8
DCIJCL — Sample JCL to Add or Manage Requests. . . . . . . . . . . . . . . . . . . . . . . .2-10
SQQFSAMP Member DCIADXMQ (Part 1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . .2-13
SQQFSAMP Member DCIADXMQ (Part 2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . .2-14
Sample Repository Merging JCL: SYSPLEX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-25
SQQFSAMP Member MCSREPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3
Capture Summary Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4
WebSphere MQ Header Filters Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5
WebSphere MQ - Header Filter Detail Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7
WebSphere MQ - MQ Filtering Detail Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-9
WebSphere MQ Create Scripts - Import from JCL Screen . . . . . . . . . . . . . . . . . . .3-12
MQ Create Scripts - Import Member List Screen . . . . . . . . . . . . . . . . . . . . . . . . . .3-13
WebSphere MQ Create Scripts - Input Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-14
WebSphere MQ Create Scripts - Grouping Screen . . . . . . . . . . . . . . . . . . . . . . . . .3-15
WebSphere MQ Create Scripts - Create Options Screen (1 of 2) . . . . . . . . . . . . . .3-15
WebSphere MQ Create Scripts - Create Options Screen (2 of 2) . . . . . . . . . . . . . .3-17
HTML Event Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-19
WebSphere MQ Create Scripts - Subset Output . . . . . . . . . . . . . . . . . . . . . . . . . . .3-22
Allocate Dataset Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-22
WebSphere MQ Create Scripts - Output Screen . . . . . . . . . . . . . . . . . . . . . . . . . . .3-23
WebSphere MQ Create Scripts - Process Screen . . . . . . . . . . . . . . . . . . . . . . . . . . .3-25
WebSphere MQ Create Scripts - Save JCL File . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-26
LOCPOS Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-43
BRULE Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-43
BRULES Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-44
WebSphere MQ Playback - Selection Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1
WebSphere MQ Playback - Datasets Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2
WebSphere MQ Script Dataset List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3
WebSphere MQ Playback - Script Member List Screen . . . . . . . . . . . . . . . . . . . . . .4-3
WebSphere MQ Playback - Setup Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4
WebSphere MQ Playback - Log File Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5
Environment Options Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5
Environment Processing Options Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6
Environment Timing Options Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7
WebSphere MQ Options Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8
MQGROUP Options Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8
MQGROUP Processing Options Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9
MQGROUP Timing Options Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10
MQGROUP WebSphere MQ Options Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10
Script Options Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-11
Script Processing Options Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-11
Script WebSphere MQ Options Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12
WebSphere MQ Playback - Submit Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-13
WebSphere MQ Playback - Save JCL File Screen . . . . . . . . . . . . . . . . . . . . . . . . . .4-13
WebSphere MQ Playback - Save Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14
Hiperstation for WebSphere MQ Main Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-15
WebSphere MQ Reporting - Selection Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-15
x
4-24.
4-25.
4-26.
4-27.
4-28.
4-29.
5-1.
5-2.
5-3.
5-4.
5-5.
6-1.
6-2.
6-3.
6-4.
6-5.
6-6.
6-7.
7-1.
8-1.
8-2.
8-3.
8-4.
8-5.
8-6.
8-7.
8-8.
8-9.
8-10.
8-11.
8-12.
8-13.
8-14.
8-15.
8-16.
8-17.
8-18.
8-19.
8-20.
8-21.
8-22.
8-23.
8-24.
8-25.
8-26.
8-27.
8-28.
9-1.
9-2.
9-3.
9-4.
9-5.
9-6.
9-7.
9-8.
9-9.
C-1.
C-2.
WebSphere MQ Reporting Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-15
WebSphere MQ - Basic Reports Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16
Custom Report Parameters Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-17
Table Report Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-17
Form Report Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18
Custom Report Locations Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18
Sample Log File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-17
Sample ETRMGPAR PNLSRC Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-18
Sample MQ Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-19
Script Analysis Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-21
Playback Error Summary Report (HTML Version) . . . . . . . . . . . . . . . . . . . . . . . . .5-24
Sample MQGROUP Text Report in Table Layout. . . . . . . . . . . . . . . . . . . . . . . . . . .6-4
Sample MQGROUP Text Report in Form Layout. . . . . . . . . . . . . . . . . . . . . . . . . . .6-5
Sample Log File Prepared for Reporting Job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-15
HTML Exception Report Mismatch Summary (Top of Report) . . . . . . . . . . . . . . .6-17
HTML Exception Report Mismatch Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-18
HTML Script Timing Summary Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-20
HTML Response Time Summary Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-22
Hiperstation Archive Recording Setup Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2
Flowchart for the Sample Customer Order And Credit Inquiry Application . . . . .8-3
Activity Captured in Sample Script SCRMS000 . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4
Activity Captured in Sample Scripts SCRMG001, SCRMG002, SCRMG003 . . . . . .8-7
Activity Captured in Sample Script SCRCR001 . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9
Activity Captured in Sample Script SCRTS001. . . . . . . . . . . . . . . . . . . . . . . . . . . .8-12
Activity Captured in Sample Script SCRTD001 . . . . . . . . . . . . . . . . . . . . . . . . . . .8-15
Activity Captured in Sample Script SCRPT001 . . . . . . . . . . . . . . . . . . . . . . . . . . .8-17
Activity Captured in Sample Script SCRTQ001 . . . . . . . . . . . . . . . . . . . . . . . . . . .8-20
Activity from REPOS1 to Play Back . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-23
Activity Replicated by PLAY_TO(CONNECTION_ID(*)) . . . . . . . . . . . . . . . . . . . .8-25
Credit Inquiry Activity Captured in Filtered Script FDDSD000. . . . . . . . . . . . . . .8-29
Data Replacement Logic at End of Sample Script FDDSD000 . . . . . . . . . . . . . . . .8-31
Variable Initialization in Sample Script FDDSD000 (Top) . . . . . . . . . . . . . . . . . . .8-32
Procedure Call in Sample Script FDDSD000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-33
Credit Inquiry Activity Captured in Filtered Script FDDDD000 . . . . . . . . . . . . . .8-34
Sample Script FDDDD000 with Logic to Read in External Information . . . . . . . .8-36
Data Replacement Logic at End of Sample Script FDDDD000. . . . . . . . . . . . . . . .8-37
Procedure Call in Sample Script FDDDD000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-38
Credit Inquiry Activity Captured in Filtered Script FDDDD001 . . . . . . . . . . . . . .8-39
Sample Script FDDDD001 with Logic to Allocate an External File . . . . . . . . . . . .8-41
Sample Script FDDDD001 with Data Collection Logic . . . . . . . . . . . . . . . . . . . . .8-42
Sample Script FDDDD001 with EXECIO and EXIT Statements. . . . . . . . . . . . . . .8-43
Sample Script FDDED000 with Logic to Read in External Information . . . . . . . .8-44
Data Replacement Logic at End of Sample Script FDDED000 . . . . . . . . . . . . . . . .8-45
Procedure Call in Sample Script FDDED001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-46
Credit Inquiry Activity Captured in Filtered Script FDDPD000 . . . . . . . . . . . . . .8-47
Sample Script FDDPD000 with Logic to Read in External Information . . . . . . . .8-49
Data Replacement Logic at End of Sample Script FDDPD000 . . . . . . . . . . . . . . . .8-51
Hiperstation for WebSphere MQ Profile Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1
WebSphere MQ Record/Script Create Defaults - Record Settings . . . . . . . . . . . . . .9-2
WebSphere MQ Record/Script Create Defaults - Script Create Settings. . . . . . . . . .9-3
WebSphere MQ Record/Script Create Defaults - Output Datasets. . . . . . . . . . . . . .9-5
WebSphere MQ Record/Script Create Defaults - Script Create Exec. Options. . . . .9-6
Auditing Defaults for WebSphere MQ Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7
MQ Interactive Playback Defaults Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10
Hiperstation - Diagnostics Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
Customer Support Diagnostic Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2
xi
Tables
3-1.
5-1.
5-2.
6-1.
D-1.
Structure Data Types Fields, Field Value Formats, and Associated Script Tags . . .3-28
Playback Sessions for a MQGROUP Statement with COUNT(2) REPEAT(3) . . . . .5-22
Hiperstation for WebSphere MQ Internal Return Codes . . . . . . . . . . . . . . . . . . . .5-23
Report Field Names and Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-24
Script Create Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-1
xii
xiii
Introduction
Intro1
3
2
Compuware is committed to providing user-friendly documentation in a variety of
electronic formats. This section describes the available formats and how to access them,
provides an overview of this manual and describes the conventions used within, and the
resources available to help you.
Accessing Hiperstation Documentation
The Hiperstation documentation included in the installation package contains Release
Notes in HTML format and manuals in Portable Document Format (PDF):
• Release Notes — Provides recent information for the Hiperstation product. In this
file, you can quickly access system requirements, technical notes, customer support
contact information, and a list of the new features available in the release. The
Release Notes may be updated throughout the life cycle of a release with the most
current version located on FrontLine for easy access to the latest product
information.
• Hiperstation Installation Guide — Provides installation and customization
procedures.
• Hiperstation for VTAM User Guide — Explains how to use Hiperstation for VTAM to
test 3270 and LU0 applications.
• Hiperstation for WebSphere MQ User Guide— Explains how to use Hiperstation for
WebSphere MQ to test WebSphere MQ applications.
• Hiperstation for Mainframe Servers User Guide — Explains how to use Hiperstation
for Mainframe Servers to test APPC and TCP/IP applications.
• Hiperstation Auditor User Guide — Explains how to use the Hiperstation Archive
Function.
• Hiperstation Automated Testing Vehicle (ATV) Manager User Guide — Explains how to
use the Hiperstation ATV Manager to manage your testing environment and test
cases.
• Hiperstation Messages and Codes — Explains the messages and codes that
Hiperstation produces.
• Hiperstation Scripting Reference — Introduces advanced script editing concepts and
provides reference information for technical users.
• Hiperstation Reference Summary — Summarizes the commands used in Hiperstation
for VTAM’s Domain Traveler and Session Demo features.
• Master Index — This file contains the combined index entries from all of the
Hiperstation manuals provided in PDF format. To use this file, all of the book files
and the master index file must be located in the same directory. Open the master
index file and click on an index entry. It will open the appropriate book at the
desired page.
View and print these files with Adobe Reader. Download a free copy of the latest version
of the reader from Adobe’s web site: http://www.adobe.com.
Note:
With a few minor exceptions, PDF files comply with the requirements of section
508 of the Rehabilitation Act of 1973. Refer to the Accessibility preface in any of
the user guides for information.
xiv
For your convenience, Compuware also provides the Hiperstation manuals in the
following formats:
• Hypertext Markup Language (HTML)
• BookManager Softcopy (BOO, BKI, BKS)
Access these formats on FrontLine, Compuware’s Customer Support Web site at
http://frontline.compuware.com.
1. Log-in.
2. Select the desired product.
3. Click the Documentation link on the left selection bar.
4. Select the desired release. FrontLine presents a documentation index containing links
to each of the product’s manuals in all of the available formats.
HTML Files
View HTML files with any standard Web browser. Simply click the HTML link on the
selected FrontLine documentation page.
Note:
As you review the HTML content, you may encounter the known issue regarding
screens and other graphic figures in which the image may be cropped along the
left or bottom edge.
BookManager Files
FrontLine provides three types of BookManager files:
• Books (.BOO) — The Hiperstation manuals provided with this release of the product.
• Bookshelf (.BKS) — A bookshelf providing links to all of the Hiperstation books.
• Bookindex (.BKI) — A file that facilitates bookshelf-level searches in BookManager
READ, (z/OS platform). Softcopy Reader (PC platform) does not use or recognize this
file.
The way you access and use these files depends on the platform on which you intend to
use them. This section provides access and use instructions for PC and z/OS platforms. It
also describes some known issues that you may encounter on either platform.
PC Access
View BookManager files on the PC with IBM Softcopy Reader. Download a free copy of
the reader from IBM’s Web site: http://www.ibm.com.
Note:
Several known formatting issues exist with the PC readers. For best results, view
the BookManager files on the mainframe. See “Mainframe Access” on page xv for
more information.
If the Softcopy Reader is installed, you can view the book files (.BOO) by clicking the
BkMgr link on the selected FrontLine Documentation page. However, this method
requires logging onto FrontLine each time you need to access a book. Alternatively, you
can download all of the .BKS and .BOO files. Whenever you need to access a manual,
simply open the bookshelf and double-click the manual title.
Make these files available to the user groups that have PCs by copying them to a shared
location on the network.
Introduction
xv
Mainframe Access
View BookManager files on the mainframe with IBM BookManager READ.
To make the files available on the mainframe:
1. Download all of the BookManager files.
2. Transfer the bookshelf file as text. Replace the PC file extension with the host file
extension BKSHELF.
3. Transfer the book and book index files (BOO and BKI) as binary, fixed block files with
a logical record length (LRECL) of 4096. Replace the PC file extensions with the host
file extensions BOOK and BKINDEX respectively.
Known-Issues
While using BookManager files on either platform, you may encounter the following
known issues:
• Cross-references may have formatting information in plain text after the reference.
For example:
"Chapter 2, 'Hiperstation Installation Overview' Title_Chapter[xd3 Default
Font".
Also, some or all of the cross-reference text may be missing.
• Screens may be too close to the figure captions above them.
• Screens may not have graphic borders.
• Numbered text within a table may not be formatted properly. Text may be rightjustified in cells that should be left-justified.
If you are using the Softcopy Reader on the PC, you may encounter the following
additional formatting issues:
• Note text may be preceded by a bullet instead of the word, Note and the first letter
may appear in bold text.
• In the navigation frame, the book's Index may appear as a sub-topic under the last
chapter.
• Some cross-references may not be hyperlinked or may be missing entirely.
• Text, steps in numbered procedures, and bullets may be improperly indented.
If you are working on a PC, consider using the PDF or HTML files instead.
Using this Manual
Hiperstation for WebSphere MQ User Guide Overview
This manual provides comprehensive information to teach you how to use Hiperstation
for WebSphere MQ. Its organization reflects testing process:
• Chapter 1, “Product Overview” describes test capabilities and provides an overview
of Hiperstation for WebSphere MQ’s main functions.
• Chapter 2, “Global Recording Requests” describes how to create a recording request
and monitor existing requests.
xvi
• Chapter 3, “Scripts and Subset Repositories” describes how to create scripts and
subset repositories, and how to review and edit MQ message data within a script or
detail file, and how to read and edit script contents.
• Chapter 4, “Interactive Playback” describes how to play back your scripts
interactively.
• Chapter 5, “Unattended Playback” describes how to create and manage the assets
necessary for playback and how to play back and analyze scripts.
• Chapter 6, “Reporting” describes how to generate basic and custom reports.
• Chapter 7, “Archive Functions” describes the Hiperstation archive function. For
additional information about the archive function, see the Hiperstation Auditor User
Guide.
• Chapter 8, “Testing Scenarios” details common testing scenarios and provides
instruction for using the corresponding samples to learn how to use Hiperstation for
WebSphere MQ.
• Chapter 9, “Hiperstation for WebSphere MQ Profile Defaults” provides
information on how to edit your Hiperstation for WebSphere MQ profile settings.
• Appendix A, “Data Collection and Reporting Tables” lists all of the reporting fields
and tables that can be collected during unattended playback.
• Appendix B, “Hiperstation for WebSphere MQ Samples Index” lists and describes
the sample playback and reporting control assets, scripts and repositories, and other
samples that ship with this release.
• Appendix C, “Customer Support Diagnostics” explains how to run a Customer
Support Diagnostic Report that lists all PTFs applied to your installation.
• Appendix D, “Script Create Parameters” lists all script creation parameters.
Notation Conventions
This document uses the following notations to describe Hiperstation screens and the
information you enter on those screens:
• Technical revisions made to this document are indicated by revision bars in the left
margin, as shown here.
• Sample screens generally show only the information appropriate to the
accompanying text, for example:
ZOOM:PF23 ---------------------- Hiperstation ------------------- LINE 1 OF 24
COMMAND ===> record
SCROLL ===> HALF
Record OFF Play OFF Journal OFF Compare Log OFF autoDoc OFF
***USR2312
WELCOME TO CICS/MVS *** 10:11:42
• Blank lines or standard footings, as shown below, are usually omitted from screen
illustrations.
Press ENTER to begin recording,
Use END to cancel setup.
• Information you enter is printed in boldface.
• Words defined within paragraphs are italicized.
• The phrase “select an option” refers to typing a slash next to one of the presented
options and pressing Enter.
Introduction
xvii
Using Wild Cards
Many of the fields on the Hiperstation for WebSphere MQ screens support wildcard
characters for including ranges of criteria. Following is an example, using wildcard
characters for dataset names:
– Asterisk (*): Insert the asterisk in place of the dataset name (DSN) qualifier
characters that should be substituted with incremental values during repository
selection. This wildcard pads to 8 characters. For example, enter
USER.REP*.DATABASE with first=1 and last=3 to create scripts/subset repositories
from source repositories:
USER.REP00001.DATABASE
– Question mark (?): Insert a question mark for each DSN qualifier character that
should be substituted with incremental values during repository selection. For
example, enter USER. REP??.DATABASE with first=9 and last=11 to create
scripts/subset repositories from source repositories:
USER.REP09.DATABASE
USER.REP10.DATABASE
USER.REP11.DATABASE
For information on specific fields or specific screens, see the online help.
Command Syntax
Hiperstation uses statements and commands that you will learn about later. This section
describes text conventions used in statement and command descriptions. It also explains
how to read syntax diagrams.
• Keywords are shown in UPPERCASE letters. Enter keywords and special characters as
shown. If a command or statement name can be abbreviated, the description shows
only the abbreviation in uppercase letters.
Find string [NEXT|PREV|ALL]
The uppercase F in the command FIND means that you can enter the FIND command
either as FIND or F.
• Variables and generic descriptions of parameter values are shown in lowercase letters.
• Vertical bars (|) are separators between mutually exclusive options.
• Brackets ([ ]) indicate optional parameters. All parameters not enclosed in brackets
are required.
• Ellipses (…) indicate that the value can be repeated.
Reading Syntax Diagrams
Syntax diagrams define primary command syntax.
A parameter is either a keyword or a variable.
All KEYWORDs are shown in uppercase characters and must be spelled exactly as shown.
You cannot substitute another value. If any part of a KEYWORD is shown in lowercase
characters, that part is optional.
Variables are user-specified values and are printed in lowercase italics. For example,
dataset-name indicates you are to substitute a value.
xviii
The syntax for commands is described in diagrams that help you visualize parameter use.
The following example shows a command and a parameter:
Read the diagrams from left to right and from top to bottom. These symbols help you
follow the path of the syntax:
indicates the beginning of a statement.
indicates the statement is continued on the next line.
indicates the statement is continued from the previous line.
indicates the end of a statement.
Required parameters appear on the horizontal line (the main path). Optional parameters
appear below the main path. Default parameters appear above the main path and are
optional. The command executes the same regardless of whether the default parameter is
included.
Vertically stacked parameters are mutually exclusive. If you must choose a parameter, one
item of the stack appears on the main path. If the parameters are optional, the entire
stack appears below the main path. If a parameter in a stack is the default, it appears
above the main path.
If the same parameters are used with several commands, their syntax may be documented
in a separate diagram. In the command syntax, these common parameters are indicated
with separators before and after the parameter name.
An arrow returning to the left indicates a repeatable item. If the arrow contains a comma,
separate the repeated items with a comma.
Accessibility
In accordance with section 508 of the Rehabilitation Act of 1973, Compuware has
committed to making its products and services easier to use for everyone including
people with disabilities.
Introduction
xix
Hiperstation is a mainframe application that runs on IBM’s OS/390 and z/OS operating
systems. It has an ISPF interface that is accessed with IBM 327x-type terminals or with
3270 terminal emulator software. Since the mainframe environment offers few
accessibility features, Compuware has focused its attention, with regard to accessibility,
on 3270 terminal emulator software running on personal computers (PCs) with Microsoft
Windows 2000 or more current. Hiperstation supports, with a few exceptions, Microsoft
Windows accessibility features and Window-based Assistive Technology (AT) software
and devices, such as Braille devices, screen readers, magnifiers, etc.
Note: Hiperstation is intended for use by mainframe software developers, programmers,
and testers. Much of the input and output used or produced by Hiperstation,
such as Job Control Language (JCL) and hexadecimal contents or dumps of
memory, are not easily understood by the general public. Unfortunately, as in the
case of hexadecimal dumps, data in these formats can be confusing to screen
readers and therefore confusing to the people who use them. Effective use of this
application requires the specialized knowledge of a mainframe systems software
developer or programmer.
Hiperstation accessibility was evaluated using:
• Freedom Scientifics’ JAWS screen reader
• Attachmate Corporation’s myExtra Presentation Services tn3270 emulator
• Microsoft’s Windows accessibility features
• Adobe Reader using the “Read Out Loud” function
This evaluation not only identified accessibility exceptions, but revealed emulator and
screen reader compatibility issues that in some cases can be remedied through
appropriate configuration.
Installing Windows Accessibility Features
Microsoft Windows operating systems offer several accessibility features to aid
individuals who have difficulty typing or using a mouse, who are blind or have low
vision, or who are deaf or are hard-of-hearing. Install these features during setup or later
using the Windows installation disks. Refer to the “accessibility” topics in the Windows
Help system for information on installing and using these features. Visit the Microsoft
Web site, http://www.microsoft.com/enable, for additional information and tutorials.
Selecting Font and Font Size
Microsoft Windows and emulator software packages offer font and font size settings to
accommodate users with low vision. The emulator software’s tool bars and dialog boxes
typically use the font specified in the operating system, while the terminal presentation
uses the font and font size specified in the emulator. To change the font or font size:
• Presented on the toolbars and dialog boxes, refer to the Windows Help system.
• Presented in the terminal window, refer to the emulator’s documentation or Help.
Some screen readers recommend certain fonts and font sizes for compatibility. For
example, Freedom Scientifics recommends setting the font to a common or “plain” font
such as Lucida, Courier, or Times New Roman, and setting the font size to 10 points or
smaller. Refer to the screen reader’s documentation or Help for these recommendations.
Changing Color and Contrast
Color and contrast settings can assist users with low vision. ISPF and most emulator
software packages offer color and contrast settings. If you are accessing Hiperstation with
a terminal, use ISPF settings. Otherwise, adjust the color and contrast in the emulator
software. Refer to ISPF Help or the emulator’s documentation or Help.
xx
Setting Cursor Blink Rate
The blink rate of the cursor can affect users with photosensitive epilepsy. Additionally,
some screen readers require a specific blink rate. Some readers automatically adjust the
blink rate while others expect you to adjust the rate. Refer to:
• The Microsoft Windows Help to find out how to set the cursor blink rate.
• The screen reader’s documentation or Help to find out the recommended blink rate.
Using Keyboard Shortcuts
Keyboard access to application functions support users who cannot use a mouse.
Microsoft Windows provides keyboard access to all functions within the operating
system, such as:
• Displaying or hiding the Windows Start Menu
• Showing the Desktop
• Minimizing all windows
• Searching for files
• Accessing the help system
• Controlling the behavior of the Windows accessibility features, for example, toggling
the listening status to the microphone, or cycling focus backward and forward.
Most Windows-based applications also provide keyboard access to their functions. The
combination of keys required to execute a given function is called a keyboard shortcut.
Refer to the “Keyboard Shortcuts” topics in the Windows Help system for a complete list
of Windows shortcuts. For a list of the shortcuts that are available in the emulator
software or any third-party accessibility tool, such as the JAWS screen reader, refer to the
software’s documentation or Help.
Accessibility Exceptions Work Arounds
During Hiperstation accessibility evaluation, some exceptions were encountered where
some accessibility features or AT were not fully supported. The causes of and solutions for
these exceptions are currently under investigation by Compuware Corporation.
Known Exceptions
Accessibility exceptions include:
• Function Key (F Key) information at the bottom of the screen is not read by the
screen reader on some screens. This is believed to be caused by an external interface.
See “Solutions” for a viable work-around.
• Some system error and warning messages are not read by the screen reader when
issued. Believed to be caused by an external interface. See “Solutions” for a viable
work-around.
• Some pop-up dialog boxes or windows do not capture exclusive focus and are not
read correctly by the screen reader. This is believed to be caused by an external
interface. No known solution is currently available.
• System error and warning messages do not capture visual focus for the screen
magnifier. This is believed to be caused by an external interface. No known solution
is currently available.
• Some entry and display fields lack individual labels. When entry fields are accessed
using the Tab key, the entire individual line is read.
Introduction
xxi
• Current Web-based reports are not easily navigated using the keyboard and lack table
element coordinate tags. Additionally, some of these reports contain color-coded
elements — for example, the color of some elements conveys meaning.
Solutions
When the screen reader fails to read the F Key information upon entry to a new screen,
do one of the following:
• Use the arrow keys to move the cursor down to the lines with the F Key information.
The screen reader reads each line as the cursor is placed on it.
• Press the Page Up key for the screen reader to reread the entire screen.
When the screen reader fails to read an error or warning message, an audio alert occurs if
this feature is enabled on your system. Press the Up key to place the cursor on the line
containing the error message, usually on the top or title line. The screen reader reads the
line and its error message individually.
Getting Help
Compuware provides a variety of support resources to make it easy for you to find the
information you need.
FrontLine Support Web Site
You can access online information for Compuware products via our FrontLine support
site at http://frontline.compuware.com.
FrontLine provides access to critical information about your Compuware products. You
can review frequently asked questions, read or download documentation, access product
fixes, or e-mail your questions or comments. The first time you access FrontLine, you are
required to register and obtain a password. Registration is free.
Compuware now offers User Communities, online forums to collaborate, network, and
exchange best practices with other Compuware solution users worldwide. Go to
http://groups.compuware.com to join.
Contacting Customer Support
If you have difficulty with Hiperstation, refer to the information in the appropriate user’s
guide for help or consult with the Hiperstation technical representative at your site. If
the problem persists, please obtain the following information before calling Compuware:
1. The release number of the product being used
2. The release number of the transaction processing utility (such as CICS, IMS/DC, or
ISPF) being used
3. The operating system being used to help determine operating system dependencies
4. If an abend occurs, note the displacement and the module in which it occurs, and if
possible, obtain a copy of the system dump.
5. The sequence of issued transactions and/or commands that resulted in the problem
and the data type involved.
Phone
• USA and Canada: 1-800-538-7822 or 1-313-227-5444.
xxii
• All other countries: Contact your local Compuware office. Contact information is
available at http://frontline.compuware.com.
Web
You can report issues via the Report and Track Calls tab on the FrontLine home page.
Note:
Please report all high-priority issues by phone.
Mail
Hiperstation for WebSphere MQ Customer Support
Compuware Corporation
One Campus Martius
Detroit, MI 48226-5099
Corporate Web Site
To access Compuware’s site on the Web, go to http://www.compuware.com.
The Compuware site provides a variety of product and support information.
Note: Hiperstation provides a report that helps Customer Support diagnose an issue. See
Appendix C, “Customer Support Diagnostics” for details. Although it is not
required, generating the report before calling may expedite diagnosis.
1-1
Chapter 1.
Product Overview
Chap 1
Hiperstation for WebSphere MQ Overview
Hiperstation for WebSphere MQ is a powerful testing tool used to perform a variety of
functions. For example:
• Application Developers can use it to unit test new features.
• Quality Assurance personnel can use it to perform system, integration, and regression
testing to validate application functions.
• System Programmers can use it to verify Transmission Queue, Channel Initiator
(CHIN), and System Queue settings.
• MQ Administrators can use it to test triggers, verify queue definitions, and ensure the
overall integrity of the MQ environment.
• System Security or Audit personnel can use it to record all activity occurring on the
system for audit purposes.
Regardless of your testing requirements, you must fully understand the structure of your MQ
environment in order to use Hiperstation for WebSphere MQ.
Note:
It is very important to understand that Hiperstation for WebSphere MQ will,
when told, attempt to GET or PUT messages to or from trigger queues,
transmission queues, and system queues. In some cases this will be protected by
security, but most of the time it will not. For example, if Hiperstation for
WebSphere MQ captures a channel initiator getting a message from the transmit
queue and subsequently does a PLAY_TO of that, Hiperstation will attempt to
reload the transmit queue with an outbound message. This might not be what
you want. Another example: when replaying CICS GETs from a trigger queue,
playback could GET a trigger that does not belong to that application.
The four basic functions involved in MQ testing are:
• Recording activity — capture all application MQ traffic regardless of the application
type (batch, CICS, IMS, WebSphere Application Server, and so on) or record specified
activity based on queue managers, queues, jobnames, time frames, and so on.
• Creating scripts from recorded activity — filter captured activity to generate scripts
for various types of testing. Scripts contain formatted information that you can read
and Hiperstation for WebSphere MQ can process. Add REXX logic to:
– create dynamic scripts that facilitate data-driven testing. For example, create a
script that performs an account inquiry, then add REXX logic that reads
hundreds of account numbers from an external file and performs the inquiry on
each account.
– create a smart script that modifies application flow based on message content.
For example, add logic to an account inquiry script to have Hiperstation for
WebSphere MQ terminate playback if the inquiry returns a “system busy”
message.
1-2
• Playing back scripts — play back a script against the application being tested to
compare recorded application responses to live application responses. Test both
client and server with the same script by reversing the direction of playback. You can
also use this feature to build testing baselines or analyze script contents for
comparison reporting.
• Reporting — generate basic, predefined reports or build custom reports containing
the information you specify, presented the way you indicate. Generate TEXT, CSV, or
HTML reports in table or form layout.
Subsequent chapters within this manual detail each of these tasks. The last chapter
provides several comprehensive testing scenarios to help you understand the full range of
testing capabilities, as well as to teach you how to use Hiperstation for WebSphere MQ.
This release ships with samples that support these scenarios. Use the samples, along with
the appropriate instructional chapters, to replicate the tasks involved in each scenario.
For example, using the sample capture repository and scripts and subset repositories,
create scripts with the filtering specifications from a given scenario. Then verify your
work by using the reporting samples to generate a report that compares the sample
scripts to the scripts you created.
2-1
Chapter 2.
Global Recording Requests
Chap 2
Recording MQ activity is the first step of testing. Use the Monitor MQ Requests option
or the Global Recording Batch Interface to create and monitor recording requests.
Recorded activity is written to a sequential dataset or series of datasets referred to as a
capture repository. Testing scripts are then generated from the capture repository. Save
time by merging related repositories before generating scripts. For example, capturing
activity across multiple systems (LPARs), results in at least one repository per system.
Rather than generating scripts from each repository, merge them first, then generate
scripts.
Note:
Hiperstation for WebSphere MQ now supports disabling of User Key CSA
allocation. See the IBM publication, MVS Initialization and Tuning Reference, for
more information.
Adding a Global Recording Request
Important Note:
Repository datasets may contain sensitive information such as account numbers, payroll
information, credit card information, or clear text passwords. The scripts generated from
the repositories are formatted for browsing as well as playback. Ensure security by
implementing external security rules for all repository, script, and detail datasets.
Capture all MQ activity on the LPAR (logical partition) for the duration of the Global
Recording Started Task or limit capture to any or all of the following criteria:
•
•
•
•
•
•
Time frame
Queue Manager
Queue/Object name
Jobname
Completion Code
Reason Code
Selecting capture criteria that supports the testing you need to perform requires a
thorough understanding of triggers, trigger monitors, initiation queues, transmission
queues, channel initiators (CHIN), SYSTEM queues, and how they are implemented in
your environment. The following list provides Global Recording considerations regarding
these aspects of MQ messaging.
Note:
It is very important to understand that Hiperstation for WebSphere MQ will,
when told, attempt to GET or PUT messages to or from trigger queues,
transmission queues, and system queues. In some cases this will be protected by
security, but most of the time it will not. For example, if Hiperstation for
WebSphere MQ captures a channel initiator getting a message from the transmit
queue and subsequently does a PLAY_TO of that, Hiperstation will attempt to
reload the transmit queue with an outbound message. This might not be what
you want. Another example: when replaying CICS GETs from a trigger queue,
playback could GET a trigger that does not belong to that application.
2-2
• Triggers, Trigger Monitors, and Initiation Queues
When queue triggers are activated, the activity generated by WebSphere MQ to put
the trigger message into the appropriate initiation queue is not visible, and therefore
cannot be recorded by Global Recording. Trigger monitors, however, appear as
normal jobs or transactions to Global Recording. When creating a recording request,
it is your responsibility to ensure that trigger monitor activity (including jobs or
transactions initiated by the trigger monitor) is not recorded if it is not wanted in the
script.
• Transmission Queues
Normally, transmission queue activity is not directly part of a WebSphere MQ
application stream. If you need to record and play back MQ activity to or from a
transmission queue, be aware that the channel initiator can execute asynchronous
MQ API functions against that transmission queue independent of user applications.
It is your responsibility to ensure that the collected data and scripts contain only the
desired information.
• Channel Initiator (CHIN)
The CHIN is usually a long-running task. This means that some of the MQ_CONN,
MQ_DISC, MQ_OPEN, or MQ_CLOSE activities related to the MQ sessions being
recorded may not be readily available within the recording time frame.
• SYSTEM Queues
Be aware that MQ API activities to and from many MQ SYSTEM queues are available
to Global Recording. It is your responsibility to secure those queues from
unauthorized or inadvertent record or playback sessions.
To add a recording request:
1. From the Hiperstation Product Menu, select option 3 Hiperstation for
WebSphere MQ. The Hiperstation for WebSphere MQ Main Menu appears (Figure 21).
Figure 2-1. Hiperstation for WebSphere MQ Main Menu
----------------Option ===>
Hiperstation for WebSphere MQ - Main Menu
-----------------
Product Release: 08.00.01
1
2
3
4
5
6
Monitor MQ Requests
Create MQ Scripts
Playback MQ Scripts
MQ Playback Reporting
MQ Archive Requests
MQ Archive Web Reports
Add/Review your MQ recording requests
Create MQ scripts from a repository
Execute and save playbacks of MQ scripts
Report on database created from playback
Add, Review or Terminate MQ archive requests
Manage MQ archive web reports
2. Select option 1 Monitor MQ Requests. If recording requests do not exist for your user
ID, the Global Recording * Requests screen appears (Figure 2-2).
2-3
Figure 2-2. Global Recording Requests Screen
------------------------- Global Recording * Requests ------------------------COMMAND ===>
******************************************************************************
*
*
*
No Global Recording Requests were found for your User ID.
*
*
*
******************************************************************************
Enter END to exit, ENTER to add a new request.
3. Press Enter to add a request or use END to exit the screen.
If your user ID has existing requests, the Global Recording - Monitor MQ Requests
screen appears (Figure 2-3). If there are no existing requests, the WebSphere MQ Data
Collect screen appears (Figure 2-4).
Figure 2-3. Global Recording - Monitor MQ Requests Screen
Hiperstation ------- Global Recording - Monitor MQ Requests ------- Row 1 of 1
Command ===>
Scroll ===> PAGE
Line commands are: (C)ancel, (F)orce, (P)Stop, (R)estart, (D)isable,
(S)elect, (U)pdate, (A)dd, (V)iew, or
(9)Switch repositories
Request
Active
Total
Owner
Sessions Sessions
------- -------- -------USER005
*******************************
Repository
Dataset
-------------------------------------------USER005.TEST.MQREC.REPOS01
BOTTOM OF DATA ********************************
4. Place the cursor on the line next to any existing request, type A and press Enter. The
WebSphere MQ Data Collect screen (Figure 2-4) appears.
Figure 2-4. WebSphere MQ Data Collect Screen
Hiperstation ------------- WebSphere MQ Data Collect --------- Row 1 to 8 of 8
Command ===>
Scroll ===> PAGE
Make changes to data collection criteria below or select a filter to edit the
expanded fields. Use OK command when complete.
Restrict script input to
HH : MM :
Start Time . . 00 : 00 :
End Time . . . 00 : 00 :
certain times:
SS
MM / DD / YYYY
00
Start Date . . 00 / 00 / 0000
00
End Date . . . 00 / 00 / 0000
Line commands are: (S)elect, (R)epeat, (D)elete, or (I)nsert
S
*
_
_
_
_
_
_
_
_
*
Ftr
***
001
002
003
004
005
006
007
008
***
Act QMGR Queue/Object name
Jobname Comp Reas
**** **** ******************************************** ******** **** ****
INCL *
**** **** ******************************************** ******** **** ****
2-4
5. Create filters to capture or omit activity based on queue manager, queue/object
name, jobname, completion code, or reason code. Hiperstation for WebSphere MQ
requires at least one filter containing queue manager criteria. Complete only the
fields for desired filtering criteria. Events that match all criteria on any of the include
filters and none of the criteria on any of the exclude filters are captured. EXCLUDEs
take precedence over INCLUDEs.
6. To limit capture to a specific time frame, enter a start and end time and date. To
begin recording immediately and terminate it at your request, leave these fields
blank. Valid date ranges are January 1, 2001 through December 31, 2040.
7. Enter line commands in the S column to add new filters, to copy or delete existing
filters, or to access filter detail screens. Delete cannot be used if the selected filter is
the only filter in the filter list, or if the filter is currently being used by an active
Global Recording request. Repeat is useful for creating several similar filters. Insert
adds a new filter containing default values, and the total number of filters cannot
exceed 999. Select displays the MQ Filtering Detail screen (Figure 2-5) for the selected
filter.
Figure 2-5. WebSphere MQ - MQ Filtering Detail
Hiperstation ------------- WebSphere MQ - MQ Filtering Detail ---------------Command ===>
Review and/or Edit this filter. Use END when complete.
Filter number . . . . 001 of 001
Filter action . . . . Include (Include or Exclude)
Field Name
*********************
Queue manager name .
Queue/Object name . .
Jobname . . . . . . .
Completion code . . .
Reason code . . . . .
Note:
RO
**
EQ
EQ
Filtering Criteria
******************************************************
OM*
TARGET.*
The MQ Filtering Detail screen contains the same information as the
WebSphere MQ Data Collection screen, however, some of the fields
accommodate longer entries. Use this screen to enter long queue manager
and queue names or to modify the relational operator (RO) used for each of
the selected filter’s criteria.
By default, all filtering criteria use the EQ (equals to) relational operator. In the RO
field, enter any of the following two-letter codes or symbols for the relational
operator you require:
RO
RO Code
RO Symbol
Equal to
EQ
== or =
Not equal
NE
¬= or !=
Less than
LT
<
Greater than
GT
>
Less than or equal to
LE
<=
Greater than or equal to GE
>=
When you are done, use END to return to the WebSphere MQ Data Collect screen.
8. Fill in the rest of the fields for the filter.
2-5
To include a range of criteria or all queue managers, use the asterisk (*) wildcard
character. If you do not want an entire range, create separate filters for each of the
applicable criteria.
a. Type INCL or EXCL in the Act field. INCL captures the event. EXCL excludes the
event from capture.
b. The QMGR field is required. Enter the name of the queue manager to capture or
exclude from capture. Wildcards are supported.
c. Enter the Queue or Object Name to capture or exclude from capture. Wildcards
are supported. Leave blank to capture or omit activity from all queues belonging
to the specified queue managers.
d. Enter the Jobname to capture or exclude from capture. Wildcards are supported.
Leave this field blank if you do not wish to filter by jobname. The jobname is
defined by the application that creates the MQ message.
e. In the Comp field, enter the numeric completion code associated with the
jobnames you wish to capture or omit from capture. Valid values are 0 (successful
completion), 1 (warning - partial completion), or 2 (call failed). Leave this field
blank if you do not wish to filter by completion code.
f. In the Reas field, enter the numeric reason code associated with the jobnames
you want to capture or omit from capture. Numeric reason code 0 = no reason
code. Other reason codes can be from 2001 to 2360 and are listed in IBM’s
WebSphere MQ Application Programming Reference Guide. Leave this field blank if you
do not wish to filter by reason code.
9. When you have finished entering filtering criteria, type OK on the command line
and press Enter. The WebSphere MQ Data Collect - Output screen appears (Figure 26).
Figure 2-6. WebSphere MQ Data Collect - Output Screen
Hiperstation ------------ WebSphere MQ Data Collect - Output -----------------Command ===>
Choose where to store the data, then press ENTER to continue.
Repository dataset:
Dataset name . . . . . . 'USER005.TEST.MQREC.REPOS??'
First and last number . 01
15
(Needed if wildcard in dataset name)
Re-use repository options: (Enter "/" to select)
Delete existing data
/ Append to existing data
Overwrite existing data when all segments are full
Amount of data to use:
Message data from GETs . . . ALL
Message data from PUTs . . . ALL
(ALL or number of bytes)
10. Fill in the fields on this screen to specify where to store captured data, whether to
append or overwrite existing data, and to limit the number of message bytes to
capture for each PUT or GET.
You can store all captured data in one large sequential dataset or segment the dataset
to make data more accessible. Once a segment is full, Global Recording closes that
segment and begins writing captured data to the next specified segment. Switch
segments during recording to access recently captured data without interrupting
recording. See “Monitoring and Maintaining Existing Requests” on page 2-6.
a. In the Repository dataset fields, type a Dataset name for the dataset to use for
storing captured information. To create a segmented dataset, use the asterisk (*)
or question mark (?) wildcard characters in the dataset name field and define a
range with the First and last number fields:
2-6
Note: Begin each segment of the dataset name with an alpha character (A-Z) or
@#$, including segments with wildcard characters.
b. In the Re-use repository options section, select one of the following options:
• Delete existing data deletes all information in the specified repository or
repository segment. Use this option to replace existing repository datasets.
• Append to existing data begins writing new data at the end of existing data.
• Overwrite existing data when all segments are full begins overwriting data
in the first specified segment, once the last specified segment is full. If you
do not select this option, recording terminates once the last segment is full.
This field applies to segmented repositories only.
Note:
Overwrite deletes all existing data in a segment before writing new
data to that segment. It does not delete data until Global Recording
locates and processes activity that matches the request criteria. If no
activity matches, the dataset is not overwritten.
c. Amount of data to use defines the amount, in bytes, of GET and PUT messages
to capture. These options support application debugging and reduce the demand
on system resources. For example, if you need to inspect the first 200 bytes of
message data for debugging purposes, specify 200 on both sub-parameters. If you
are testing transaction speed and want to avoid storing and processing
unnecessary data, limit capture of GET messages. If your testing requires
comparing actual and expected values during playback, enter 'ALL'.
11. Press Enter to continue.
12. If you specified a dataset that has not been allocated, the Allocate a WebSphere MQ
Repository screen appears. If necessary, modify the default values and press Enter to
allocate the dataset. All repository segments are allocated with the same settings.
If you specified a dataset that has been migrated, the Recover Migrated Data Set
screen appears. Press Enter to recover the dataset or END to cancel recovery and
reenter dataset information.
If the dataset has already been allocated, the Global Recording - Monitor MQ
Requests screen appears. See the next section, “Monitoring and Maintaining Existing
Requests”.
Monitoring and Maintaining Existing Requests
The Monitor MQ Requests screen (Figure 2-7) typically displays all of the recording
requests that you have created. However, if you access this screen as an administrator, it
displays all existing recording requests created by all users. See “Monitor All Existing
Requests (Administrator Access)” on page 2-9. Active recording requests are highlighted.
Note:
For definitions of the fields on this screen, see the online help.
2-7
Figure 2-7. Global Recording - Monitor MQ Requests Screen
Hiperstation ------- Global Recording - Monitor MQ Requests ------- Row 1 of 1
Command ===>
Scroll ===> PAGE
Line commands are: (C)ancel, (F)orce, (P)Stop, (R)estart, (D)isable,
(S)elect, (U)pdate, (A)dd, (V)iew, or
(9)Switch repositories
Request
Active
Total
Owner
Sessions Sessions
------- -------- -------USER005
*******************************
Repository
Dataset
-------------------------------------------USER005.TEST.MQREC.REPOS01
BOTTOM OF DATA ********************************
You can use this screen to add, cancel, force, stop, restart, disable, update, or view a
recording request, switch capture repository segments, and view session information.
Place the applicable line command next to the selected request and press Enter.
• C (cancel) cancels and deletes the request. All buffered information is also deleted,
which may result in partially recorded business transactions. To avoid losing
important data, STOP the request and wait until the request terminates before issuing
the CANCEL command. Use ISPF file management tools to delete any repository or
repository segments created by the request.
• F (force) terminates recording immediately and deactivates the request. This option
may result in partially recorded business transactions. To terminate capture of new
sessions, but allow capture to finish for in-flight sessions, use STOP instead.
Note: If the request specifies segmented repositories, the Force command will cause
an automatic switch to a new segment.
• P (stop) stops capture of new sessions and deactivates the request. Global Recording
continues to capture all sessions that are in-flight at the time the STOP is issued.
• R (restart) restarts the request. The request becomes active as soon as the time frame
specified within the request is met. Use this option to activate an inactive request.
Note:
Starting with Release 2.4, security is checked not only at program start, but
also whenever a global recording request is restarted. If security has changed
for the request owner or rules have been changed, requests that ran before
may no longer run.
• D (disable) disables the selected request. Use this option to prevent the request from
automatically starting when the Global Recording started task is brought up or when
the request’s start time is reached. Disabled requests present an asterisk(*) next to the
dataset name. STOP or FORCE the request prior to disabling it.
• S (select) displays a list of all objects and connections currently being captured. See
the next section, “View Session Information”.
• U (update) presents request information for update. Recording must be terminated
and the request must be inactive. Issue a STOP or FORCE to terminate recording and
deactivate the request. Once editing is complete, issue a RESTART command to
reactivate the request.
• A (add) adds a request. See “Adding a Global Recording Request” on page 2-1.
• V (view) views the selected request. The request cannot be modified in view mode.
• 9 (switch repositories) closes the current repository segment and begins writing to
the next segment. Use this feature to access recently recorded information without
interrupting capture.
2-8
Note: If you selected Overwrite existing data when all segments are full (Figure 26 on page 2-5), Hiperstation for WebSphere MQ begins writing data to the
first segment after the last segment is full. If the first segment is in use,
Hiperstation for WebSphere MQ produces a “Dataset Full” message and
begins writing to the next segment.
View Session Information
View an active request’s session information to verify recording criteria. If you see
activity you did not intend to capture, Cancel, Force, or Stop the request. If you Force the
request, you can Update it and Restart it.
Each line on the Active WebSphere MQ screen represents a “session”. It shows both:
• Object sessions (MQ_OPEN through MQ_CLOSE)
• Connection sessions (MQ_CONNECT through MQ_DISCONNECT or
MQ_ENDTHREAD)
At times, this screen shows connection sessions that do not appear to be related to the
activity your applications create. For example, a connection session could be shown for a
queue manager even though your application has never opened a queue managed by that
queue manager. This can occur because the events that cause tracking of a connection
session (MQ_CONNECT, MQ_COMMIT, and MQ_BACKOUT) do not have an associated
queue name, only a queue manager name. Hiperstation for WebSphere MQ displays these
connection sessions because they might eventually be associated with a queue name, on
an MQ_OPEN or MQPUT1 call, that matches your filtering criteria.
Data for connection sessions (MQ_CONNECT, MQ_COMMIT, MQ_BACKOUT,
MQ_DISCONNECT, and MQ_ENDTHREAD events) is written to your repository in ONLY
two cases:
• A filter matches the queue manager name and the recording request has the queue
name fully wildcarded (for example, QNAME=*), or
• A filter matches the queue manager name and there is an active object session, an
MQ_OPEN was seen, but not an associated MQ_CLOSE, that also matches the
filtering criteria.
Only connection-oriented events that occur within the bounds of an object-oriented
session are considered to be “of interest” if the filtering criteria contains an explicit
queue name. If you want a complete record of all events, fully wildcard the queue name.
1. To view session information, type S next to an active request on the Monitor MQ
Requests screen and press Enter. The Global Recording - Active WebSphere MQ
Sessions screen appears (Figure 2-8).
2. Press End to return to the Monitor MQ Requests screen.
Figure 2-8. Global Recording - Active WebSphere MQ Sessions Screen
Hiperstation --- Global Recording - Active WebSphere MQ Sessions -- Row 1 of 1
Command ===>
SCROLL ===> CSR
---- -------------------------------------- Session Start Last Update at Total
QMGR Queue/Object Name
MM/DD HH:MM:SS MM/DD HH:MM:SS Bytes
---- -------------------------------------- -------------- -------------- ----MQ06 *
07/31 13:47:42 07/31 13:47:42
0
******************************* BOTTOM OF DATA ********************************
Note:
For a definition of the fields on this screen, see the online help.
2-9
Monitor All Existing Requests (Administrator Access)
Providing you have the appropriate authority, you can access the Monitor MQ Requests
option as an administrator. Use this feature to monitor and manage all existing recording
requests. See your Hiperstation installer if you need administrator access.
Note: If you need to update or restart a request, you can also require authority to update
the script and/or repository datasets specified in the recording request. Your
Hiperstation installer enables the security validation, while your Security
Administrator maintains the authorities.
To see all of the existing recording requests:
1. On the Command line of the Hiperstation for WebSphere MQ - Main Menu, type
ADMIN and press Enter. The screen title updates to indicate administrator access
mode.
2. Select the Monitor MQ Requests option and press Enter. The Monitor MQ Requests
screen appears (Figure 2-7 on page 2-7).
Using the Global Recording Batch Interface
Hiperstation for WebSphere MQ provides a batch interface to Global Recording. Use it
along with a job scheduler to automate capture initiation and termination. For example,
to initiate recording every morning at 8:00 AM and terminate it at 5:00 PM, create a job
to RESTART the request and a job to STOP the request. Use a job scheduler to submit the
jobs at the appropriate times.
Use the online and batch interfaces together. For example:
• Create a recording request with the online interface, then manage it with scheduled
jobs.
• Initiate recording with the batch interface, then use the Monitor MQ Requests option
view a list of sessions being capture.
Create a Global Recording Request
This section explains how to create a Global Recording request, check the status of
existing requests, manage existing requests, retrieve parameters from an existing request,
generate a request parameters skeleton, and troubleshoot failed jobs.
Global Recording writes captured activity to a specified dataset or range of datasets called
a capture file or a repository. Testing scripts are generated from the capture repository.
To capture activity, create a recording request. If you specify a time-frame for the request,
it becomes active at the designated start time. If you do not specify a time-frame, it
becomes active immediately. Capture begins when all of the criteria for an active request
are met.
Creating a Global Recording request with the batch interface involves defining the
parameters of the request. Parameters are defined in extensible markup language (XML).
The batch interface’s XML parser provides limited syntax support. Be sure to review
“Global Recording Request Parameter Syntax” on page 2-11 prior to writing or modifying
parameters.
To create a Global Recording request with the batch interface:
1. Define the Global Recording request parameters. See “Global Recording Request
Parameters” on page 2-12.
2-10
2. Use SQQFSAMP member DCIJCL (Figure 2-9 on page 2-10) to execute the ADD
request function.
a. Insert job statement information at the top of the sample.
b. Make sure the UPROCS statement points to the procedures library that contains
DCIPROC.
c. After the request is created, the batch interface returns a request key that contains
information about the request. Use the request key as input for request
management jobs (see “Manage Existing Requests” on page 2-20). The key is
written to the location specified on the FEEDBACK DD. To save the key in your
personal library, specify a sequential dataset, PDS(E) and member, or a generation
data group (GDG).
Note:
Allocate the dataset or GDG with a fixed block record format and an 80
byte record length.
d. On the SYSTSIN DD statement, make sure ADD is specified on the PARM
keyword.
e. On the SYSIN DD statement, either supply the name of the dataset containing
the request parameters or enter the parameters in-line.
Note:
In-stream parameters cannot exceed 80 bytes. If you edited the
parameters on a PC and copied them back to a dataset exceeding 80
bytes, point the DD to the dataset rather than pasting the parameters
into the job.
Figure 2-9. DCIJCL — Sample JCL to Add or Manage Requests
********************************* Top of Data **********************************
//* INSERT JOB CARD HERE...............................................
/*JOBPARM SYSAFF=sysn
//*********************************************************************
//* JCL TO ADD OR MODIFY 3270, APPC, TCP/IP, OR WEBSPHERE MQ GLOBAL
*
//* RECORD REQUESTS.
*
//*
*
//* UPROCS:
DATASET THAT CONTAINS THE DCIPROC.
*
//*
*
//* FEEDBACK: OUTPUT XML THAT MAY BE USED AS INPUT TO SUBSEQUENT
*
//*
STEPS.
*
//*
*
//* SYSTSIN: TSO BACKGROUND INPUT STREAM.
*
//*
ISPSTART PGM(QACDCIP) - EXECUTE THE GLOBAL RECORD
*
//*
BATCH INTERFACE (GRBI)
*
//*
PARM(command) - IS THE COMMAND PASSED TO THE GRBI
*
//*
*
//* SYSIN:
XML INPUT.
*
//*
*
//*********************************************************************
//UPROCS JCLLIB ORDER=('COMPWARE.SQQFSAMP')
<-REVIEW
//DCI
EXEC PROC=DCIPROC
//FEEDBACK DD *
//SYSTSIN DD *
ISPSTART PGM(QACDCIP) PARM(ADD)
<-REVIEW
/*
//SYSIN
DD DISP=SHR,DSN=COMPWARE.SQQFSAMP(DCIADXMQ)
<-REVIEW
******************************** Bottom of Data ********************************
3. After the job is prepared, 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. See your job scheduler’s
documentation for help.
2-11
Note: DCI produces real return codes, as opposed to always returning a zero value. This
allows you to determine whether global record or archive record requests started.
It also allows JCL creation where job steps may or may not be executed based on
whether the DCI request succeeded.
Global Recording Request Parameter Syntax
Global Recording request parameters are defined in XML. Write the parameters from
scratch or start with a sample or a generated parameter set. Store the parameters in a
dataset or paste them right into the JCL. Use a standard file editing tool to modify the
parameters.
Note: The batch interface contains a proprietary XML parser that supports a limited set
of XML elements. It recognizes only the syntax described in this section.
Most recording request XML parameters are comprised of an opening tag, followed by a
value and a closing tag. Opening and closing tags must be contained in angle brackets.
The closing tag must be proceeded by a back slash inside the angle brackets. For example:
<Queue_Manager> '*' </Queue_Manager>
If the parameter’s value contains spaces, it must be placed in single quotation marks. In
the samples and generated parameter sets, the parameter values always appears inside
single quotes.
Some parameters require a format indicator followed by a value supplied in single
quotation marks. For example, the Request ID tag accepts a hexadecimal or character
value. Indicate the format of the value by placing an X or a C before the value, outside of
the quotation marks.
<Request_ID> C'HS_REQ'</Request_ID>
The batch interface ignores spaces between the tag and the tag’s value. For example, the
following parameter is interpreted the same way as the previous Queue Manager
parameter example:
<Queue_Manager>
</Queue_Manager>
'*'
To make the samples and generated parameter sets easier to read, most parameters are
formatted with the opening tag and value on one line and the closing tag on the
following line.
XML parameters are hierarchal. That is, some parameters have a group of related subparameters. For example, the Start_Time, End_Time, Start_Date and End_Date are subparameters of the Scheduled_Capture parameter. Sub-parameters must be nested within
opening and closing parent parameter tags. For example,
<Scheduled_Capture>
<Start_Date>
'00/00/0000'
</Start_Date>
<Start_Time>
'00:00:00'
</Start_Time>
<End_Date>
'00/00/0000'
</End_Date>
<End_Time>
'00:00:00'
</End_Time>
</Scheduled_Capture>
Depending on the request you are creating, there may be several levels of nesting. For
example, all of the MQ Global Recording request parameters are sub-parameters of the
<MQS> protocol parameter. The start and end time and date parameters are subparameters of Scheduled_Capture, which is a sub-parameter of the <MQS> protocol
parameter.
2-12
<MQS>
<Request_ID>
C'MY_REQ'
</Request_ID>
<Scheduled_Capture>
<Start_Date>
'00/00/0000'
</Start_Date>
<Start_Time>
'00:00:00'
</Start_Time>
</MQS>
Note:
This example shows tag nesting. It is not a complete set of request parameters.
Indenting nested tags is not necessary. However, it makes editing much easier. In the
samples and generated parameter sets, each level of nesting is indented one space.
Finally, an XML stream can contain comments that the batch interface ignores.
Comment text must be prefixed with an opening angle bracket, an exclamation point
and two dashes and followed with two dashes and closing angle bracket. For example:

Global Recording Request Parameters
Global Recording request parameters are defined in XML. Start with one of the following:
• The parameters from an existing request. See “Retrieve Parameters from an Existing
Request” on page 2-22.
• A parameters skeleton. See “Generate a Request Parameters Skeleton” on page 2-23.
• SQQFSAMP member DCIADXMQ: Contains all available MQ Global Recording
request parameters.
• SQQFSAMP member DCIADDMQ: Contains a subset of commonly used MQ
recording request parameters.
Store the parameters in a sequential dataset or a PDS member in your personal library or
write them directly in the JCL. Use a standard file editing tool such as ISPF Edit to write
or modify the parameters.
Notes:
a. XML tags are case-sensitive. Make sure the ISPF Caps function is set to off when
editing the parameters. Type CAPS OFF on the Command line and press Enter.
b. To work with a parameters file on the PC:
• Use the IBM utility IEBGENER to copy the dataset into an HFS file.
• FTP the file to the PC. To avoid EBCDIC to ASCII translation issues, transfer
the file as 'text'.
Use an XML editor, such as Notepad, to edit the tags. Pay attention to syntax
interpretation. The Global Recording batch interface cannot recognize tags that
have been reformatted based on the viewer’s interpretation. For example, some
editors format tags that have no values as follows <tag/>. Encase blank values in
single quotes to avoid this particular interpretation issue. All tags must conform
to the syntax rules described in “Global Recording Request Parameter Syntax” on
page 2-11.
To avoid record truncation when transferring the parameters back to the
mainframe, copy them into a fixed block dataset with a logical record length that
supports the longest record.
2-13
This section provides an illustration of sample DCIADXMQ (Figure 2-10) and defines all
of the available MQ Global Recording request parameters. Parameter hierarchy is shown
and defined within the parameter definitions.
Figure 2-10. SQQFSAMP Member DCIADXMQ (Part 1 of 2)
********************************* Top of Data **********************************
<MQS>
<Request_ID>
X'000000000000'
</Request_ID>
<Scheduled_Capture>
<Start_Date>
</Start_Date>
<Start_Time>
</Start_Time>
<End_Date>
</End_Date>
<End_Time>
</End_Time>
'00/00/0000'
'00:00:00'
'00/00/0000'
'00:00:00'
<Capture_File>
<Dataset>
'COMPWARE.SAMPLE.CAPTURE.FILE*'
</Dataset>
<First_Number>
'1'
</First_Number>
<Last_Number>
'10'
</Last_Number>

<Initial_Disposition>
'APPEND'
</Initial_Disposition>
2-14
Figure 2-11. SQQFSAMP Member DCIADXMQ (Part 2 of 2)
<Allocation>
<Management_Class>
</Management_Class>
<Storage_Class>
</Storage_Class>
<Volume_Serial>
</Volume_Serial>
<Device_Type>
</Device_Type>
<Data_Class>
</Data_Class>
<Space_Units>
</Space_Units>
<Primary_Quantity>
</Primary_Quantity>
<Secondary_Quantity>
</Secondary_Quantity>
<Block_Size>
</Block_Size>
</Allocation>
</Capture_File>
<Recording_Options>
<Reuse_Capture_File>
</Reuse_Capture_File>
</Recording_Options>
<Data_To_Keep>
<Data_From_GETS>
</Data_From_GETS>
<Data_From_PUTS>
</Data_From_PUTS>
</Data_To_keep>
''
''
''
'SYSDA'
''
'TRKS'
'10'
'5'
'9004'
'NO'
'ALL'
'ALL'
<MQS_Capture_Filters>
<Filter Record="1">

<Action>
'INCLUDE'
</Action>

<Queue_Manager_RO>
'EQ'
</Queue_Manager_RO>
<Queue_Manager>
'*'
</Queue_Manager>
<Queue_Object_Name_RO> ''
</Queue_Object_Name_RO>
<Queue_Object_Name>
''
</Queue_Object_Name>
<Jobname_RO>
''
</Jobname_RO>
<Jobname>
''
</Jobname>
<Comp_Code_RO>
''
</Comp_Code_RO>
<Comp_Code>
''
</Comp_Code>
<Reason_Code_RO>
''
</Reason_Code_RO>
<Reason_Code>
''
</Reason_Code>
</Filter>
</MQS_Capture_Filters>
</MQS>
******************************** Bottom of Data ********************************
Protocol Parameter Tag
MQS
Identifies the type of Global Recording request to add. This is a parent tag to all other
parameters described in this section. Begin and end the XML input stream with
opening and closing MQS tags.
2-15
General Request Parameter Tags
Request ID
The ID of the Global Recording request. To assign a request ID, supply a six-byte
hexadecimal or character value in single quotes. Place a format indicator in front of
the value outside of the quotation marks. X indicates hexadecimal values and C
indicates character values. For example:
– <Request_ID> X'010203040506' </Request_ID>
– <Request_ID> C'HSREQ1'</Request_ID>
The batch interface pads hexadecimal values that are less than six bytes with zeros
and character values that are less than six bytes with spaces.
This tag is optional. If you do not supply a request ID, the system assigns one when
the request is created.
Scheduled Capture Parameter Tags
Scheduled_Capture
Sets a start time and duration for the request. The request activates at the defined
start time and date and remains active until the specified end time and date, unless
the capture repository fills up and the Reuse_Capture_File tag is set to 'NO'.
Omit this entire block of tags if you want capture to begin immediately and remain
active indefinitely.
The following parameters are Scheduled_Capture sub-parameters. Supply the
applicable parameters between the opening and closing Scheduled_Capture tags.
Start_Date
The date the request is to be activated. Specify a two digit month, a two digit day,
and a four digit year separated by forward slashes: 'MM/DD/YYYY'.
If you specify a start date with no time, the request activates at the beginning of
the given day — that is, midnight (00:00:00).
Start_Time
The time the request is to be activated. Specify a two digit hour, a two digit
minute, and a two digit second separated by colons: 'HH:MM:SS'.
If you specify a start time, a start date is required.
If you do not specify a start time or date, the request activates immediately.
End_Date
The month, day, and year to deactivate the request. Specify a two digit month, a
two digit day, and a four digit year separated by forward slashes: 'MM/DD/YYYY'.
If you specify an end date with no time, the request deactivates at the end of the
given day — that is, midnight (24:00:00).
End_Time
The time the request is to be deactivated. Specify a two digit hour, a two digit
minute, and a two digit second separated by colons: 'HH:MM:SS'.
If you do not specify an end time or date, the request remains active until you
STOP, FORCE or CANCEL it or until the repository is full if you did not set the
Reuse_Capture_File tag to 'YES'.
If you specify an end time, an end date is required.
2-16
Capture File Parameter Tags
Capture_File
Defines the dataset to use for storing the captured data.
The following parameters are Capture_File sub-parameters. Supply the applicable
parameters between the opening and closing Capture_File tags.
Dataset
The name of the dataset to use for storing captured information. This is a
required parameter. It accepts 44 characters.
To create a segmented capture file, use either the asterisk (*) or question mark (?)
wildcard characters in the dataset name. Define a range for the wildcard
characters with the First_Number and Last_Number tags:
Note: Begin each segment of the dataset name with an alpha character (A-Z) or
@#$, including segments with wildcard characters.
First_Number
Defines the first value to use for wildcard characters specified on the Dataset tag.
Supply a value up to seven digits. If you did not use a wildcard, do not include
this tag.
Last_Number
Defines the last value to use for wildcard characters specified on the Dataset tag.
Supply a value up to seven digits. If you did not use a wildcard, do not include
this tag.
Initial Disposition
Indicates whether to append or overwrite data contained in the specified dataset.
Valid values are 'APPEND' or 'OVERWRITE'. This tag is unnecessary if the
specified dataset does not exist. If the specified dataset does exist, and you do not
provide an initial disposition value, Global Recording appends the new data to
the existing data.
Note: The dataset is overwritten when Global Recording captures and processes
activity that matches the request criteria. If no activity matches, the
dataset is not overwritten.
Allocation
Allocation parameters for the capture file dataset. If you do not supply allocation
parameters and the specified dataset does not exist, the batch interface allocates
it with default values set by the installer. Generally, the default values are
appropriate. However, you can override any or all of the default parameters by
using the following Allocation sub-parameters.
Supply the applicable parameters between the opening and closing Allocation
tags.
Management_Class
The management class to apply to the new dataset. Management classes are
defined by the storage administrator at your site.
Storage_Class
The storage class to apply to the new dataset. Storage classes are defined by
the storage administrator at your site.
Volume_Serial
The serial number of the volume on which the dataset is to be stored.
2-17
Device_Type
The type of device on which the dataset is to be stored. Can be a generic unit
such as 'SYSDA'.
Data_Class
The data class to apply to the new dataset. Data classes are defined by the
storage administrator at your site.
Space_Units
The type of units used to store the data. Valid values are: TRKS (Tracks), CYLS
(Cylinders), BLKS (Blocks), BYTES, KB (kilobytes), or MB (megabytes). Space
units combined with the primary and secondary quantities define the
amount of space allocated for the dataset.
Primary_Quantity
The number of space units to allocate initially. Once Global Recording fills
the primary quantity, it allocates the secondary quantity.
Secondary_Quantity
The number of space units to allocate after the primary quantity is full.
Block_Size
The maximum length, in bytes, of the blocks of data that the system reads in
as it processes a dataset.
Recording Option Parameter Tags
Recording_Options
Defines recording request actions.
The following parameter is a Recording_Options sub-parameter. If you supply this
tag, be sure to place it between the opening and closing Recording_Options tags.
Reuse_Capture_File
This parameter applies to segmented capture files only. It causes Global
Recording to continue capturing activity after the capture file segments are full.
After the last segment fills, Global Recording begins writing to the first segment
again, replacing the oldest captured activity.
To enable this option, supply this tag with a value of 'YES'. If you omit this tag or
supply it with a value of 'NO', recording terminates after the last segment is full.
Data To Keep Tags
Data_To_Keep
Defines the amount, in bytes, of GET and PUT message data to capture. These
options support application debugging and reduce the demand on system resources.
For example, if you need to inspect the first 200 bytes of message data for debugging
purposes, specify 200 on both sub-parameters. If you are testing transaction speed
and want to avoid storing and processing unnecessary data, limit capture of GET
messages.
If your testing requires comparing actual and expected values during playback,
specify 'ALL' or omit these parameters altogether.
The following parameters are Data_to_Keep sub-parameters. Supply the applicable
parameters between the opening and closing Data_to_Keep tags.
Data_From_GETS
The number of bytes to capture from each GET message. This is an optional
parameter. If you omit this tag, Global Recording captures all message data.
2-18
Data_From_PUTS
The number of bytes to capture from each PUT message. This is an optional
parameter. If you omit this tag, Global Recording captures all message data.
MQS Capture Filter Tags
Filter Record="x"
Defines a filter for recording. Capture or ignore activity based on queue manager,
queue/object name, jobname, completion code, or reason code.
Supply this tag with a filter number enclosed in double quotation marks. For
example, <Filter Record="1">. To create multiple filters, copy this block of tags and
increment the value of x for each filter.
The batch interface requires at least one filter, containing minimally the
Queue_Manager sub-parameter. All other sub-parameters are optional. If you want to
record all MQ activity on the system, create a filter and specify a wildcard on the
Queue_Manager parameter. For example:
<Filter Record="1">
<Queue_Manager> ‘*’
</Queue_Manager>
</Filter>
Each sub-parameter, except Action, has a corresponding relational operator (RO)
parameter. Use these parameters to indicate how events are evaluated for each
filtering criterion. Valid values are:
– 'EQ' for Equal to
– 'NE' for Not Equal
– 'LT' for Less Than
– 'GT' for Greater Than
– 'LE' for Less than or Equal to
– 'GE' for Greater than or Equal to
Specify the RO based on your MQ environment and your recording needs. For
example, to capture all events handled by a specific queue manager, except the
events from a specific queue, set the Queue_Manager_RO to EQ and the
Queue_Object_name_RO to NE and supply the queue manager and queue names on
the corresponding tags.
If you do not supply an RO value for a given parameter, Global Recording uses EQ.
The following parameters are Filter Record="x" sub-parameters. Nest the applicable
sub-parameters between an opening <Filter Record="x"> tag and a closing </Filter>
tag.
Action
The action that Global Recording is to take when an MQ event matches all of the
filter’s criteria. Supply a value of 'INCLUDE' or 'EXCLUDE'.
Global Recording captures events that match all criteria on any of the “include”
filters and none of the criteria on any of the “exclude” filters. If an event does
not match any filter or if matches both an “include” and “exclude” filter, it is not
captured.
It you omit the parameter, Global Recording assumes the filter is an “include”
filter.
Queue_Manager_RO
The relational operator used to evaluate events based on the Queue_Manager
value.
2-19
Queue_Manager
The name of the queue manager to capture or exclude from capture. This is a
required parameter. Supply:
• A specific queue manager.
• A range of queue managers by supplying the beginning of the queue
manager name followed by an asterisk (*).
• All queue managers by supplying a single asterisk or omitting the tag
altogether.
Queue_Object_Name_RO
The relational operator used to evaluate events based on the Queue_Object_name
value.
Queue_Object_Name
The queue or object name to capture or exclude from capture. Specify:
• A specific queue/object name.
• A range of queues/objects by supplying the beginning of the queue/object
name followed by an asterisk (*).
• All queues/objects by supplying a single asterisk or omitting the tag
altogether.
Jobname_RO
The relational operator used to evaluate events based on the Jobname value.
Jobname
The jobname to capture or exclude from capture. Specify:
• A specific job name.
• A range of job names by supplying the beginning of the job name followed
by an asterisk (*).
• All job names by supplying a single asterisk or omitting the tag altogether.
Note:
The jobname is defined by the application that creates the MQ message.
Comp_Code_RO
The relational operator used to evaluate events based on the Comp_Code value.
Comp_Code
The numeric completion code associated with the jobnames you need to capture
or omit from capture. Valid values are 0 (successful completion), 1 (warning partial completion), or 2 (call failed).
Reason_Code_RO
The relational operator used to evaluate events based on the Reason_Code value.
Reason_Code
The numeric reason code associated with the jobnames you need to capture or
omit from capture. Numeric reason code 0 = no reason code. Other reason codes
can be from 2001 to 2360 and are listed in IBM’s WebSphere MQ Application
Programming Reference Guide.
Check the Status of Existing Requests
Use the KEYS function to:
2-20
• Check the status of a specific Global Recording request.
• Generate status information for all of your existing Global Recording requests that
you created. You can also use this feature to locate a forgotten request ID.
Each request has an associated request key that consists of the following information:
• Protocol — The protocol of the activity that the request is to record.
• Status — The status of the request (Stopped, Active, or Disabled).
• Request ID — The six byte ID assigned to the request.
• Capture File — Name of the capture file (also known as Repository Dataset).
This is the same information that the batch interface returns when you create a request.
In fact, if you are checking the status of a specific request, use the returned request key as
the input for the KEYS function.
Use SQQFSAMP member DCIJCL (Figure 2-9 on page 2-10) to execute the KEYS function.
1. Insert job statement information at the top of the sample.
2. Make sure the UPROCS statement points to the procedures library that contains
DCIPROC.
3. Keys are written to the location defined by the FEEDBACK DD statement. To save the
key in your personal library, specify a sequential dataset, PDS(E) and member, or a
generation data group (GDG)
Note:
Allocate the GDG with a fixed block record format and an 80 byte record
length.
4. On the SYSTSIN DD statement, specify KEYS on the PARM keyword.
5. KEYS function parameters are also defined in XML. The parameters required differ
depending on the information you need to produce.
– To check the status of a specific request, the KEYS function requires the protocol,
request ID, and capture file associated with the request. On the SYSIN DD, either
supply the name of the dataset containing the request key or enter the
parameters in-line. For example:
// SYSIN DD *
<MQS>
<Request_ID>
C'HS_REQ’
</Request_ID>
<Capture_File>
<Dataset>
‘USER253.MQ.HS.REC??’
</Dataset>
</Capture_File>
</MQS>
If the ADD request FEEDBACK went to SYSOUT, copy and paste the request key
from the JES job log.
– To generate status information for all of the existing MQ requests that you
created, the KEYS function requires the protocol parameter. For example:
// SYSIN DD *
<MQS>
</MQS>
6. Submit the job.
Manage Existing Requests
Use the batch interface request management functions to:
2-21
• Stop recording
• Delete or update a request
• Restart an inactive request
• Disable a request to prevent it from automatically restarting
• Switch the capture file segment to review captured activity without interrupting
recording.
All of these functions require information found in the request key that the batch
interface returns when you create a request. If you do not have the request key but you
know the request ID and capture file name, write the parameters directly into the job. If
you do not know this information, use the KEYS function to produce a list of existing
requests. See “Check the Status of Existing Requests” on page 2-19.
Use SQQFSAMP member DCIJCL (Figure 2-9 on page 2-10) to execute request
management functions.
Note:
DCIJCL contains the FEEDBACK DD statement that supports request creation.
Request management functions do not write output to this DD. To see request
modification messages, review the PRGLOG DD in the JES job log.
DCIPROC.
3. On the SYSTSIN DD statement, specify one of the following request management
functions on the PARM keyword:
CANCEL
Cancels and deletes the request. All buffered information is also deleted, which
may result in partially recorded business transactions. To avoid losing important
data, STOP the request and wait until the request terminates before issuing the
CANCEL command.
Use ISPF file management tools to delete any repository or repository segments
created by the request.
FORCE
Terminates recording immediately and deactivates the request. This option may
result in partially recorded business transactions. To terminate capture of new
sessions, but allow capture to finish for in-flight sessions, use STOP instead.
STOP
Stops capture of new sessions and deactivates the request. Global Recording
continues to capture all sessions that are in-flight at the time the STOP is issued.
RESTART
Restarts the request. The request becomes active as soon as the time frame
specified within the request is met. Use this option to activate an inactive
request.
DISABLE
Disables the request. When the Global Recording started task is brought up, all
requests, except disabled requests, are restarted.
Note:
SWITCH
STOP or FORCE the request prior to disabling it.
2-22
Closes the capture file segment that is currently being written and opens the
next segment. This option is available only if the capture file dataset name
contains a wildcard character (* or ?).
4. The request management functions require the protocol, request ID, and capture file
associated with the request. On the SYSIN DD, either supply the name of the dataset
containing the request key or enter the parameters in-line. For example:
// SYSIN DD *
<MQS>
<Request_ID>
C'HS_REQ’
</Request_ID>
<Capture_File>
<Dataset>
</Dataset>
</Capture_File>
</MQS>
5. Submit the job.
Note:
The batch interface does not supply an update function. Use a combination of
other functions to modify a request.
1. Use the VIEW function to retrieve the parameters from the request. See
“Retrieve Parameters from an Existing Request” on page 2-22.
2. Modify the parameters. See “Global Recording Request Parameters” on page
2-12 for parameter definitions.
3. Use the STOP, FORCE, or CANCEL functions to stop recording.
4. If you use STOP or FORCE to stop recording, wait for recording to terminate,
then use CANCEL to delete the request.
5. Use the ADD function to create a new request using the modified parameters.
Execute steps 3-5 as separate jobs or separate steps within a single job.
Retrieve Parameters from an Existing Request
The VIEW function writes the parameters from a specified request to a location you
define. Use it to:
• Review or validate a request’s parameters.
• Save time adding a new request. Rather than writing Global Recording request
parameters from scratch, retrieve the parameters from a similar request and modify
them to meet your needs.
• Update a request. Retrieve the parameters from the request you need to update.
Modify the parameters. STOP the request. CANCEL the request. ADD a new request
using the modified parameters.
Note:
If there are no existing requests, you do not specify a request ID, or the specified
request ID does not exist, the VIEW function produces a request parameters
skeleton, which is a complete set of parameters with default values.
Use SQQFSAMP member DCIJCL (Figure 2-9 on page 2-10) to execute the VIEW function.
DCIPROC.
3. The batch interface writes VIEW function output to the location specified on the
FEEDBACK DD. To save the VIEW output in your personal library, specify a
sequential dataset, PDS(E) and member, or a generation data group (GDG)
Note:
2-23
length.
4. On the SYSTSIN DD statement, specify VIEW on the PARM keyword.
5. When retrieving parameters from a specific request, the VIEW function requires the
protocol, request ID, and capture file associated with the request. On the SYSIN DD,
either supply the name of the dataset containing the request key or enter the
parameters in-line. For example:
// SYSIN DD *
<MQS>
<Request_ID>
C'HS_REQ’
</Request_ID>
<Capture_File>
<Dataset>
</Dataset>
</Capture_File>
</MQS>
6. Submit the job.
Generate a Request Parameters Skeleton
If there are no existing requests, you do not specify a request ID, or the specified request
ID is not found, the VIEW function produces a request parameters skeleton. A request
parameters skeleton is a complete set of Global Recording parameters with default values.
Generate a skeleton to:
• Save time creating a new request.
• See all of the available parameters.
• Reference the syntax of a particular tag.
Use SQQFSAMP member DCIJCL (Figure 2-9 on page 2-10) to execute the VIEW function.
DCIPROC.
3. The batch interface writes VIEW function output to the location specified on the
FEEDBACK DD. To save the VIEW output in your personal library, specify a
sequential dataset, PDS(E) and member, or a generation data group (GDG)
Note:
length.
4. On the SYSTSIN DD statement, specify VIEW on the PARM keyword.
5. On the SYSIN DD, supply the opening and closing protocol tags for the type of
request you need to create. For example:
// SYSIN DD *
<MQS>
</MQS>
Troubleshoot Failed Jobs
An ISPF background task initiates and terminates the Global Recording batch interface.
ISPF issues a return code for the background task. Do not confuse this return code with
the Global Recording batch interface’s return code. The batch interface writes its return
code to the PRGLOG DD. Providing your installer accepted the default, PRGLOG resides
in the JES job log.
2-24
The Global Recording batch interface adds and modifies recording requests based on the
parameters you supply. The Global Recording started task executes the requests. The
batch interface reports messages pertaining to request creation or modification, while the
started task reports messages pertaining to recording. Locate:
• Batch interface status and error messages in the PRGLOG in the JES job log.
• Global Recording started task error and status message in the JES job log and SYSTEM
log.
Merging Capture Repositories
Hiperstation for WebSphere MQ provides an MVS batch utility that combines the
information in two or more specified repositories. It orders the activity by time stamp. If
you need to generate scripts from multiple repositories, save time by merging the
repositories first. For example, rather than generating scripts four times from repositories
captured on four different systems (LPARs), merge the repositories and generate scripts
once.
To merge two or more repositories:
1. Copy member SYSPLEX from the samples library, typically SQQFSAMP, to your
personal JCL library.
2. Open SYSPLEX (Figure 2-12 on page 2-25) with a standard editing tool such as ISPF
Edit.
3. Place job statement information at the top of the sample.
4. Make sure the STEPLIB DD points to the Hiperstation load library and the C and C++
LE datasets at your installation.
5. On the REPIN DD statement, specify the repositories to be merged. Place each fully
qualified repository dataset name on a separate line. If the repository is segmented,
supply the repository name with the appropriate wildcard characters, followed by a
space, then a ‘first’ value, a space, and a ‘last’ value. ‘First’ and ‘last’ are numeric
values between 1 and 9999999. ‘First’ must be lower than ‘last’. These values are used
to resolve the repository segment dataset names.
6. On the SYSIN DD statement, supply the job parameters, as shown in the sample, or
the name of the dataset containing the job parameters. Whether the parameters are
defined inline or in an external dataset, put each parameter on a separate line. For
the parameters that require a value, follow the parameter name with a space, then an
equals sign (=), another space, and then the value.
Parameter definitions follow Figure 2-12 on page 2-25.
7. Submit or schedule the job. To submit the job immediately, type SUB on the
Command line and press Enter.
2-25
Figure 2-12. Sample Repository Merging JCL: SYSPLEX
********************************* Top of Data **********************************
//*....... JOB ...PLACE YOUR INSTALLATION'S JOBCARD HERE...
//*********************************************************************
//*********************************************************************
//SYSPLEX EXEC PGM=SYSPLEXM,REGION=0M,PARM='0'
//STEPLIB DD DSN=COMPWARE.SQQFLOAD,DISP=SHR
//
DD DISP=SHR,DSN=CEE.SCEECPP
//
DD DISP=SHR,DSN=CEE.SCEERUN
//SYSPRINT DD SYSOUT=*
//CEEDUMP DD SYSOUT=*
//*********************************************************************
//* REPIN IS WHERE THE REPOSITORY SETS TO BE MERGED ARE ENTERED.
//* EACH SET IS ENTERED ON A NEW LINE WITH THE FORMAT:
//* <DATASET_SPECIFICATION> <FIRST_INTEGER> <LAST_INTEGER> <IGNORED>
//*********************************************************************
//REPIN
DD *
COMPWARE.SYS1.REPOS1*
1
10
1
10
1
10
1
10
/*
//*********************************************************************
//* REQUIRED:
//* REP_MERGE
= FULLY QUALIFIED REPOSITORY SET SPECIFICATION, USING
//*
* (ASTERISK) AND ? (QUESTION MARK) AS APPROPRIATE.
//*
EXAMPLE: BFHCXY0.HTTP1*.REPOS
//* OPTIONAL:
//* FIRST
= REPOSITORY SET SPECIFICATION FIRST NUMBER. DEFAULT 0.
//* LAST
= REPOSITORY SET SPECIFICATION LAST NUMBER. DEFAULT 0.
//* REP_SPACE
= CAPTURE FILE SPACE UNIT. MUST BE TRK(DEFAULT) OR CYL.
//* REP_UNIT
= CAPTURE FILE UNIT NAME. DEFAULT IS SYSDA.
//* REP_PRI
= CAPTURE FILE PRIMARY SPACE, IN CAP_SPACE UNITS.
//* REP_SEC
= CAPTURE FILE SECONDARY SPACE, IN CAP_SPACE UNITS.
//* REP_STORCLAS = CAPTURE FILE SMS STORAGE CLASS - SYSTEM DEFAULT.
//* REP_DATACLAS = CAPTURE FILE SMS DATA CLASS - SYSTEM DEFAULT.
//* REP_MGMTCLAS = CAPTURE FILE SMS MANAGEMENT CLASS - SYSTEM DEFAULT.
//* MAX_MSG_SIZE = MAXIMUM SIZE UNSEGMENTED REPOSITORY MESSAGE HANDLED
//*
BY CONVERTER. UNITS ARE 1K, DEFAULT IS 32 (32,768).
//* TCP
= ALLOWS TCP REPOSITORIES TO BE USED. APPC AND MQ
//*
ARE ALSO VALID VALUES. DEFAULT MQ.
//*********************************************************************
//SYSIN
DD *
REP_MERGE = COMPWARE.MERGED.NEWREP*
/*
******************************** Bottom of Data ********************************
SYSPLEX Job Input Parameters
REP_MERGE
The dataset to contain the merged repositories. This parameter is required. Specify a
fully qualified repository dataset name. The utility dynamically allocates this dataset,
so be sure to supply a DSN that does not exist. To segment the new repository, specify
the dataset name with the appropriate wildcard characters and supply a FIRST and
LAST parameter (discussed next).
FIRST
The first value to use for resolving the wildcard characters specified in the repository
name. Supply a value between 1 and 999999999. The default value is 0. If the
specified repository name does not contain a wildcard character (* or ?), do not
supply this parameter.
LAST
The last value to use for resolving the wildcard characters specified in the repository
name. Supply a value between 1 and 999999999. The default value is 0. If the
specified repository name does not contain a wildcard character (* or ?), do not
supply this parameter.
2-26
REP_SPACE
The type of units used to store the data. Valid values are: TRK (Tracks) or CYL
(Cylinders). Space units combined with the primary and secondary quantities define
the amount of space allocated for the dataset.
REP_UNIT
The type of device on which the dataset is to be stored. This value can be up to eight
characters long. The default value, if the parameter is not specified, is SYSDA.
REP_PRI
The number of space units (tracks or cylinders) to allocate initially. Specify a value
between 1 and 99999. If not specified, the default value of 1 is used. Once the utility
fills the primary quantity, it allocates the secondary quantity (REP_SEC).
REP_SEC
The number of space units to allocate after the primary quantity is full. Specify a
value between 1 and 99999. If not specified, the default value of 1 is used.
REP_STORCLAS
The storage class to apply to the output dataset. Storage classes are defined by the
storage administrator at your site. This is an optional parameter and has no default
value.
REP_DATACLAS
The data class to apply to the output dataset. Data classes are defined by the storage
administrator at your site. They provide default values for dataset definition
parameters such as SPACE, RECFM, and LRECL. This is an optional parameter and has
no default value.
REP_MGMTCLAS
The management class to apply to the output dataset. Management classes are
defined by the storage administrator at your site. They control attributes of SMS
managed datasets such as migration, back up, compression, retention period, and
space reclamation. This is an optional parameter and has no default value.
MAX_MSG_SIZE
The maximum size of an application message handled by this utility. Specify the size,
in kilobytes, of the largest message expected. Valid values are 1 to 99999. For
example, MAX_MSG_SIZE = 64 indicates that the first 65,536 bytes of each message
will be processed. This is an optional parameter. If not specified, the utility uses 32K
as the default.
MQ/TCP/APPC
The record-type selection parameter. This parameter indicates the type of record to
select from the input repository. Valid value are MQ, TCP, and APPC. If no recordtype selection parameter is supplied, the utility uses MQ.
Note:
This utility supports both Hiperstation for WebSphere MQ and Hiperstation
for Mainframe Servers. The TCP and APPC record-type selection parameters
apply to merging repositories captured with Hiperstation for Mainframe
Servers.
3-1
Chapter 3.
Scripts and Subset Repositories
Chap 3
Creating Scripts and Subset Repositories
Repositories contain recorded activity in a compressed format. Scripts contain formatted,
human-readable data generated from a repository. Play back the scripts you create to test
applications that use MQ messaging or browse them to review MQ data flows.
Once you have recorded activity, use the Create MQ Scripts option to:
• Build testing scripts from the capture repository.
• Generate subset repositories containing specified activity.
• Generate logs and reports such as script logs that list all of the scripts created, detail
data files that contain the contents of the message buffers, and event summaries
(CSV or HTML format) that list all of the events that match your filtering criteria.
Hiperstation for WebSphere MQ processes the entire repository during script creation.
The larger the repository, the longer it takes to create scripts. Additionally, scripts require
more storage than raw data. Minimize script creation time and storage overhead by
generating subset repositories containing only the desired activity. Store the data as a
repository until you need to create testing scripts.
When you are ready to create scripts, save time and spare system resources by identifying
the repository segments of interest. Script only the segments you need instead of the
entire capture repository. The Capture Segment Summary indicates when recording
began and ended for each segment of the specified repositories. Review the report with a
file browsing tool such as ISPF Browse or import it into a spreadsheet or database for easy
manipulation.
Script and Subset Repository Creation Overview
Creating scripts and/or subset repositories requires several steps. Before creating a script,
identify the type of testing you plan to perform and determine the kind of activity
required to support that testing. This section describes the script/subset repository
creation options to help you plan your testing and navigate the screens in the Create MQ
Scripts facility.
1. Establish filtering criteria (page 3-4). Include or exclude activity from the repository
based on any of the following criteria:
•
Time/Date Ranges
•
UserIdentifier
•
PutApplType
•
Queue Manager
•
Completion Code
•
ApplIdentityData
•
Queue/Object Name
•
Detail Data (message contents)
•
ApplOriginData
•
Type of Event
•
Reason Code
•
PutDate
•
Jobname
•
Put APPlName
•
PutTime
2. Select the repository or repository segments to use for creating scripts/subset
repositories (page 3-13). If you are not sure which segments contain the information
you need to script, generate a Capture Segment Summary (page 3-2).
3. Define event grouping for script creation (page 3-14). Create one script containing all
activity or a separate script for each:
3-2
–
–
–
–
–
Queue manager
Connection
Object (queue)
Jobname or/and
Event type
If you select more than one grouping option, Hiperstation for WebSphere MQ
generates a script for each combination. For example, if you select jobname and
object, and you have two jobs that use the same three queues, you would get 6
scripts.
4. Define:
– Script storage requirements (page 3-15). Do you want to store:
• Detail data (message content) in the script PDSE member?
• All detail data in separate a PDSE member?
• GET detail, PUT detail, and the scripts separately?
The script contains links to the details if the details are stored externally.
– Output requirements (page 3-17). Do you want to generate:
• A script log containing results of script generation, and the JCL and SYSIN
for playback and reporting?
• Scripts?
• Detail data files (message contents)?
• An event summary showing the events that match the specified filtering
criteria?
Do you want to append or overwrite existing files of the given type?
5. If you are creating a subset repository, specify a single dataset to contain the entire
repository or a range of datasets to segment the repository (page 3-22).
6. Specify the output dataset names for the other selected output (page 3-23).
7. Select a processing option (page 3-24): submit the job for batch processing, edit the
job, or process the job in TSO foreground. Optionally, specify a file to store the
script/subset repository creation JCL.
Use the facility in an iterative fashion to build your testing scripts. For example, on your
first pass, generate an Event Summary and review the activity in a specified repository to
help determine filtering criteria. On the second pass, set your filtering criteria and
generate another Event Summary to confirm your selections. On the third pass, generate
a subset repository containing the filtered events that you can create scripts from at any
anytime, and save your script/subset repository creation JCL. On the last pass, generate
the scripts and script log to test your application.
Hiperstation for WebSphere MQ retains your field selections in your ISPF profile. After
you process your first request, press End to step backward through the screens for the
next iteration. After you exit the facility, import filters, options, or both, providing you
saved the script/subset repository creation JCL.
Generate a Capture Segment Summary
The Capture Segment Summary report shows when recording began and ended for each
segment of one or more specified capture repositories. Use it to help you identify the
information contained in each segment. For example, if you need to script activity that
was captured on Monday morning from 8:00 am to 12:00 pm, but you are not sure which
repository segment contains the information, generate this report.
3-3
Import the report into a spreadsheet or database for easy manipulation. For example,
generate the report against every repository on the system, import it into a spreadsheet,
and use it as an index. Sort the spreadsheet by repository name or dates.
To generate a Capture Summary Report:
1. Locate sample member MCSREPT (Figure 3-1) in the Hiperstation samples library,
SQQFSAMP, or in your site’s JCL library.
3. Make sure the STEPLIB DD statement points to the Hiperstation load library at your
installation.
4. To write the report to a new or existing dataset, replace SYSOUT=* on the CAPSUM
DD statement with the appropriate dataset information. The logical record length of
the dataset must be minimally 132 bytes.
5. Supply report creation parameters after the SYSIN DD * statement. Place each
parameter on a separate line. Parameter definitions follow Figure 3-1.
Figure 3-1. SQQFSAMP Member MCSREPT
********************************* Top of Data **********************************
//*....... JOB ...PLACE YOUR INSTALLATION'S JOBCARD HERE...
//********************************************************************
//*---------------------------------------------------------------- *
//*
*
//* HIPERSTATION MANAGE CAPTURE SEGMENTS REPORT EXECUTION
*
//*
*
//*---------------------------------------------------------------- *
//********************************************************************
//*
*
//* THE FOLLOWING ITEM MUST BE CHANGED FOR SITE SPECIFICS:
*
//*
*
//* NOTE 1: NAME OF THE HIPERSTATION LOAD LIBRARY.
*
//*
*
//* SYSIN DD IS USED TO PROVIDE REPORT PARAMETERS
*
//*
*
//* NOTE 2: LIST THE REPORT PARAMETERS INCLUDING
*
//*
THE REPOSITORY OR REPOSITORIES YOU WISH TO REPORT ON
*
//*
*
//********************************************************************
//REPORT EXEC PGM=MCSREPT
//STEPLIB DD DISP=SHR,DSN=COMPWARE.QQF800.SQQFLOAD
<==NOTE 1
//SYSPRINT DD SYSOUT=*
//CAPSUM
DD SYSOUT=*
//SYSIN
DD *
<==NOTE 2
GMT
DSN=USERID.TEST.MULTSEG.REPOSIT*
FIRST=1
LAST=3
DSN=USERID.TEST.REPOSITX
******************************** Bottom of Data ********************************
– The optional NORECALL parameter prevents recall of migrated datasets for
report creation. This parameter, if specified, must precede all DSN parameters.
– The optional GMT parameter reports timestamps in Greenwich Mean Time
(GMT). If omitted, Hiperstation reports the time values based on the system’s
local time. If you are reporting on repositories captured on systems in different
time zones, include the GMT parameter to avoid confusion over time
adjustment. For example, a repository that was captured at 8:00 AM EST is sent to
an office in California. If the report is run in California without the GMT
parameter, the start time shows 05:00:00 due to adjustment for the three hour
difference in time zones. With the GMT parameter, the report shows 13:00:00
regardless of the system on which the report is generated. This parameter, if
specified, must precede all DSN parameters.
– The DSN parameter specifies the name of the capture repository. To report on
multiple segments of a given repository, specify the dataset name with the same
3-4
wildcard characters as specified in the Global Recording request. Then supply the
FIRST and LAST parameters. To report on multiple repositories, include a DSN
parameter, and, if applicable, a FIRST and LAST parameter for each repository.
The FIRST and LAST parameters must follow the dataset name to which they
apply. For example,
DSN=USER25.MQ.REPOS??
FIRST=01
LAST=10
DSN=USER25.TCPIP.REPOS08
DSN=USER25.3270.REPOS??
FIRST=01
LAST=05
– The FIRST parameter is the first value used and the LAST parameter is the last
value used to resolve the wildcards in the repository name specified on the
preceding DSN parameter.
6. Submit the job.
Review the report with a file browsing tool such as ISPF Browse. If the report is large,
consider importing it into a spreadsheet or database application for easy
manipulation. For example, import it into a spreadsheet and sort by start time.
If you include the GMT parameter on the report creation job, ‘ALL TIMES GMT’
appears at the top of the start date and time column.
Figure 3-2. Capture Summary Report
HIPERSTATION - CAPTURE SEGMENT SUMMARY
USER25.TEST1.REPOS01
ALL TIMES GMT
12/21/06 20:08:23
12/21/06 20:10:39
12/21/06 20:23:18
12/21/06 20:10:14
12/21/06 20:23:14
12/21/06 20:31:35
Access the Create MQ Scripts Option
To access Create MQ Scripts, select option 2 on the Hiperstation for WebSphere MQ Main
Menu (Figure 2-1 on page 2-2) and press Enter.
The WebSphere MQ Header Filters screen appears (Figure 3-4 on page 3-5).
Establish Filtering Criteria
Hiperstation for WebSphere MQ supports two types of filtering:
• Header filters for filtering MQ events based on the MQ message header information,
such as queue manager, object ID, jobname, and so on.
• Message data filters for filtering MQ events based on message data content.
Depending on the granularity of filtering required, you may need to create several filters.
For example, to include the activity on two different queue managers, create a separate
filter for each. Together, the filters are known as a filter set. The filter set is saved at the
end of the script/subset repository creation process. You can import the filter set the next
time you create scripts or subset repositories.
Events that match all of the criteria on any one of the include filters and none of the
criteria on any of the exclude filters, are written into the script or subset repository.
Note:
EXCLUDE takes precedence over INCLUDE.
The filter set is compared to all MQ events EXCEPT:
• MQ_CONNECT
3-5
• MQ_OPEN
• MQ_CLOSE
• MQ_DISCONNECT
These four events are written into the scripts or subset repositories if the events they
support match the filter criteria. For example, if an MQ_GET matches an include filter’s
criteria, it and the corresponding MQ_CONNECT, MQ_OPEN, MQ_CLOSE, and
MQ_DISCONNECT are written into the script.
Consider the events you wish to include or to exclude when defining your criteria. If you
define criteria that does not apply to a specific type of event, Hiperstation for
WebSphere MQ considers it a mismatch and will not select it for inclusion/exclusion. For
example, if you define PutApplType criteria on an include filter, MQ_SET events will not
appear in the script because they do not have a PutApplType parameter and therefore do
not match the filter.
Header Filters
Use the Header Filters screen to create, edit, import, and delete WebSphere MQ header
filters.
To maintain WebSphere MQ header filters:
1. From the Hiperstation for WebSphere MQ Main Menu, select option 2 Create MA
Scripts (Figure 3-3).
----------------Option ===>
-----------------
1
2
3
4
5
6
Monitor MQ Requests
Create MQ Scripts
Playback MQ Scripts
MQ Archive Requests
The WebSphere MQ - Header Filters screen appears (Figure 3-4).
Figure 3-4. WebSphere MQ Header Filters Screen
Hiperstation --------- Websphere MQ - Header Filters --------- Row 1 to 8 of 8
Command ===>
Scroll ===> PAGE
Make changes to the MQ Header filtering criteria below or select a filter to
edit the expanded fields. Use OK command when complete, or IMPORT to load
settings from JCL.
Restrict script input to
HH : MM :
Start Time . . 00 : 00 :
End Time . . . 00 : 00 :
certain times:
SS
MM / DD / YYYY
00
Start Date . . 00 / 00 / 0000
00
End Date . . . 00 / 00 / 0000
Line commands are: (S)elect, (R)epeat, (D)elete, (I)nsert, or (M)essage Data
S Ftr M Act QMGR Queue/Object Name
Evnt Jobname UserIdent
Comp Reas
***** * **** **** *********************** **** ******** ************ **** ****
001
INCL M530
002
INCL
SET
003
INCL *
004
005
006
007
008
3-6
2. Import a filter, discussed on page 3-12, or create a new filter. Complete only the fields
for the criteria you wish to use for filtering.
Note: Do not use quotes around filter values. Doing so will generate invalid records,
which will create errors when script create executes.
Many of the fields on this screen support the asterisk (*) wildcard character for
including ranges of criteria. If you do not want an entire range, create separate filters
for each of the applicable criteria.
If any of the field names are too long, leave the field blank and use the S line
command to go to the MQ Filtering Detail screen (Figure 3-5 on page 3-7).
a. Fill in the Start and End Date and Time to specify a time period for generating
scripts or subset repositories. Valid date ranges are from January 1, 2001 through
December 31, 2040. Hiperstation for WebSphere MQ populates these fields with
imported settings or the last specified values. Zero out all values if you do not
want to filter activity based on time and date.
b. M (Message Data Filter) field displays an addition symbol (+) if a message data
filter is associated with the header filter or a question mark (?) if an imported
filter contains invalid data values. Type M next to the filter and press Enter to see
the Message Data Filter screen. If you are not sure which value to edit, press End
to have Hiperstation for WebSphere MQ present an error message in the upper
right corner of the screen. Make your corrections and press End to return to the
Header Filter screen.
c. In the Act field, enter INCL or EXCL to include or exclude MQ events that match
the filter criteria.
d. In the QMGR field, specify the name of the queue managers to include in or
exclude from the script or subset repository. Wildcards are supported.
e. In the Queue/Object Name field, specify the queue or object names to include in
or exclude from the script or subset repository. Wildcards are supported.
f. In the Evnt field, enter the type of MQ event to include in or exclude from your
script or subset repository. Valid event types are PUT (includes PUT1), GET, SET,
CMIT, INQ, or BACK.
g. Enter the jobnames associated with the events to include in or exclude from the
script or subset repository. The jobname is part of the message’s origin
information and is defined by the application that created the message.
Wildcards are supported.
h. In the UserIdent field, enter the user identifiers associated with the events to
include in or exclude from the script or subset repository. The user identifier is
part of the message’s origin information and it is defined by the application that
created the message. Wildcards are supported.
i. In the Comp field, enter the numeric completion code associated with the events
to include in or exclude from the script or subset repository. Valid values are 0
(successful completion), 1 (warning - partial completion), or 2 (call failed).
j. In the Reas field, enter the numeric reason code associated with the events to
include in or exclude from the script or subset repository. Numeric reason code 0
= no reason code. Other reason codes can be from 2001 to 2360 and are listed in
IBM’s WebSphere MQ Application Programming Reference Guide.
3. To increase the granularity of the header filters or to add message data filtering
information, enter the appropriate line commands and press Enter. You can enter
multiple line commands at the same time. When you press Enter, the commands are
processed sequentially.
S (select) presents the selected header filter’s detail screen, which offers additional
filtering criteria and longer fields for QMGR and Queue/Object name. See “Header
Filter Detail” on page 3-7.
3-7
R (repeat) creates a copy of the selected filter. Use this to quickly create several
similar filters. I (insert) adds a new blank filter after the selected filter. You can create
up to 999 filters.
D (delete) deletes an existing filter. This command cannot be used if the selected
filter is the only filter in the filter list.
M (message data) presents the message data filter associated with the given header
filter. Use this screen to define criteria for filtering events based on MQ message data.
See “Message Data Filters” on page 3-9.
The IMPORT command imports selected options from a dataset containing script
create JCL. The IMPORT command displays the WebSphere MQ Create Scripts Import from JCL screen. See “Import Filters and Options Command” on page 3-12,
for more information.
4. When you have finished defining filter criteria, type OK on the Command line and
press Enter to continue. Go to “Specify Source Repository” on page 3-13.
Header Filter Detail
Use the Header Filter Detail screen to specify long queue manager and queue/object ID
names or to increase the granularity of the selected filter.
To add or edit header filter detail:
1. In the S column, on the Header Filter screen (Figure 3-4 on page 3-5), type an S next
to the desired header filter and press Enter. The Header Filter Detail screen appears.
2. Complete the fields for only the criteria that you want to filter.
Figure 3-5. WebSphere MQ - Header Filter Detail Screen
Hiperstation ---------WebSphere MQ - Header Filter Detail --------------------Command ===>
Review and/or Edit this filter. Use END when complete.
Filter number
Filter action
001 of 008
Include
(Include or Exclude)
Field Name
RO Filtering Criteria
******************* ** ********************************************************
Queue manager name EQ *
Queue/Object name
Jobname
Event
PutApplName
PutApplType
ApplIdentityData
ApplOriginData
Completion code
Reason code
PutDate
PutTime
UserIdentifier
Note: Do not use quotes around filter values. Doing so will generate invalid records,
which will create errors when script create executes.
The Filter Number field displays a value assigned to this filter that you cannot
change.
a. The Filter Action field displays the filter action specified on the Header Filter
screen. It indicates whether the messages that match the selected filter will be
included in or excluded from the script or subset repository. Modify if necessary.
Valid values are Include and Exclude.
3-8
b. In the RO field, enter the relational operator to apply to the filtering criteria. EQ
is the default. Enter the two letter code or symbol for the required operator. Valid
operators are:
RO
RO Code
RO Symbol
Equal to
EQ
== or =
Not equal
NE
¬= or !=
Less than
LT
<
Greater than
GT
>
LE
<=
Greater than or equal to
GE
>=
c. Specify a Queue Manager Name to include in or exclude from the script or
subset repository. Wildcards are supported.
d. Specify an Queue or Object Name to include in or exclude from the script or
subset repository. Wildcards are supported.
e. Enter the Jobname associated with the MQ activity. Wildcards are supported.
f. In the Event field, enter the type of activity to include in or exclude from the
script or subset repository. Valid values are GET, PUT (includes PUT1), SET, INQ,
CMIT, or BACK.
g. In the PutApplName field, enter the name of the application responsible for
putting the message on the queue to include or exclude associated activity.
h. In the PutApplType field, enter the type of application, without the proceeding
‘MQAT_’, responsible for putting messages on the queue to include or exclude
associated activity. Valid types are: AIX, CICS, CICS_BRIDGE, CICS_VSE, DOS,
DQM, GUARDIAN, IMS, IMS_BRIDGE, JAVA, MVS, NOTES_AGENT, NSK, OS2,
OS390, OS400, QMGR, UNIX, VMS, VOS, WINDOWS, WINDOWS_NT, XCF,
DEFAULT, UNKNOWN, USER_FIRST, USER_LAST, and NO_CONTEXT. User
defined types are not supported other than the USER_FIRST/USER_LAST range
values.
i. In the ApplIdentityData field, enter the application identity data from the
message origin information to include or exclude the associated activity.
ApplIdentityData is defined by the application that created the message.
j. In the ApplOriginData field, enter the application origin data from the message
origin information to include/exclude associated activity. ApplOriginData is
defined by the application that created the message.
k. Enter the numeric Completion Code associated with the events to include in or
exclude from the script or subset repository. Valid values are 0 (successful
completion), 1 (warning - partial completion), or 2 (call failed).
l. Enter the numeric Reason Code associated with the events to include in or
exclude from the script or subset repository. Numeric reason code 0 = no reason
code. Other reason codes can be from 2001 to 2360 and are listed in IBM’s
WebSphere MQ Application Programming Reference Guide.
m. In the PutDate and PutTime fields, specify an include/exclude message by the
date and time they were PUT on the queue. Valid date format is YYYYMMDD and
and valid time format is HHMMSSTH and they must both be numeric.
n. In the UserIdentifier field, enter the user identifiers associated with the events
to include in or exclude from the script or subset repository. The user identifier is
part of the message’s origin information. It is defined by the application that
created the message. Wildcards are supported.
3-9
3. When all fields on this screen are filled in, press End to save the work and either
return to the WebSphere MQ -Header Filter screen, or go to the next selected filter’s
Header Filter Detail or Message Data Filter screen, discussed next, depending on the
line command entered. To exit the screen without saving your work, type CANCEL
on the Command line and press Enter.
Message Data Filters
Use message data filters to include or exclude MQ events based on information in the
MQ message data, the data tagged <CONTENT> in MQ scripts. Create, edit, or delete
message data filters with the WebSphere MQ - Message Data Filters screen.
Note: To include or exclude complete transactions, be sure the filtering criteria appears
in the messages of all MQ events involved in the transactions. If the transaction
includes non-message events such as CMIT, BACK, SET, or INQ, add a header
filter for each desired event type. Be aware that all events of the specified type
will be included/excluded.
Message filters are associated with the header filters and assume the header filter’s
ACTION property (Include or Exclude). If you want an “Include” message data filter,
associate it with an “Include” header filter.
To maintain message data filters:
1. In the S column, on the Header Filter screen (Figure 3-4 on page 3-5), type an M next
to the desired header filter and press Enter. The Message Data Filter screen appears
(Figure 3-6).
Figure 3-6. WebSphere MQ - MQ Filtering Detail Screen
Hiperstation ---------- WebSphere MQ - Message Data Filters -- Row 1 to 8 of 8
Command ===>
Scroll ===> PAGE
Review and/or Edit the Message Data filters below. Use END when complete.
MQ Header filter number . . : 001
Filter action . . . . . . . : INCLUDE
Line commands are: (R)epeat, (D)elete, or (I)nsert
S
*
_
_
_
_
_
_
_
_
POS
*****
00001
00020
00024
_____
_____
_____
_____
_____
LEN
*****
00014
00004
00001
_____
_____
_____
_____
_____
RO
**
EQ
VA
NZ
__
__
__
__
__
Filtering criteria
***********************************************************
C'Hiperstation'
P
M'F0'
___________________________________________________________
___________________________________________________________
___________________________________________________________
___________________________________________________________
___________________________________________________________
The MQ Header filter number field displays the arbitrary value assigned as a unique
ID to the associated header filter. The Filter action field displays the filter action
specified on the associated header filter. It indicates whether the messages that
match the selected filter will be included in or excluded from the script and/or subset
repository. You cannot modify these fields.
2. Fill in the rest of the fields on this screen to create your message data filters.
a. In the POS field, specify the starting position, relative to one, of the message data
that you want Hiperstation for WebSphere MQ to consider for filtering. This
value must be between 1 and 32768 (32K).
Note:
When you save your work, this screen sorts the filter by position values.
3-10
b. The LEN (length) field behaves differently depending on the type of filter:
• Text, Character, and Hexadecimal filters: Specify the number of data bytes,
up to 256, to consider for filtering.
For filters with relational operators EQ, NE, LT, LE, GT, or GE, leave this field
blank to have Hiperstation for WebSphere MQ calculate the value. If you
specify a length longer than the filtering criteria, it pads Text and Character
criteria with blanks and Hexadecimal criteria with nulls (x'00').
For filters with relational operators CO (Contains) or NC (Not Contains),
specify a length or enter 0 (zero) and set the POS field to 1 to have
Hiperstation for WebSphere MQ search the entire message.
• Zoned Decimal filters: Enter the length of the data to consider for filtering.
This field is required — valid values are between 1 and 15.
• Packed Decimal filters: Specify a data length between 1 and 16 or leave this
field blank to have Hiperstation for WebSphere MQ determine the length
based on start position and the first packed sign digit in the filtering criteria.
• Mask Data filters: Leave this field blank. Mask data is always 1
byte/character (8 bits) long.
c. Enter the two-letter code or symbol, if applicable, for the relational operator (RO)
to apply to the filtering criteria. ROs behave differently depending on the filter
type. Valid operators for:
– Text, Character, and Hexadecimal filters are:
Conditional
RO Codes
RO Symbol
Description RO
EQ
== or =
Equal To
NE
¬= or !=
Not Equal
LT
<
Less Than
GT
>
Greater Than
LE
<=
Less Than or Equal To
GE
>=
Greater Than or Equal To
CO
not applicable
Contains — Hiperstation for WebSphere MQ scans the data
range stipulated with the POS and LEN fields for the value
specified in the filtering criteria field.
NC
not applicable
Not contains — Hiperstation for WebSphere MQ scans the data
range stipulated with the POS and LEN fields to ensure value
specified in the filtering criteria field is not present.
3-11
– Zoned or Packed Decimal filters are:
Conditional
RO Codes
RO Symbol
Description RO
EQ
== or =
Equal To
NE
¬= or !=
Not Equal
LT
<
Less Than
GT
>
Greater Than
LE
<=
Less Than or Equal To
GE
>=
Greater Than or Equal To
VA
not applicable
Valid — Hiperstation for WebSphere MQ scans the specified
data range for valid zoned or packed decimal values depending
on the filter type.
NV
not applicable
Not valid — Hiperstation for WebSphere MQ scans the specified
data range for invalid zoned or packed decimal values
depending on the filter type.
– Mask filters are:
BIT RO
Codes
EQ
RO Symbol
Bit RO
== or =
Specified bits are all ones
NE
¬= or !=
Specified bits are all zeros
NO
not applicable
Specified bits are not all ones
NZ
not applicable
Specified bits are not all zeros
MX
not applicable
Specified bits are mixed ones and zeros
d. In the Filtering Criteria field, enter the filter type followed by the filtering
criteria enclosed in single quotes. If you do not specify a filter type, Hiperstation
for WebSphere MQ assumes the information in this field is Text filtering criteria.
Valid filter types are:
• T for Text, for example, T'SMITH'
Text filters are not case-sensitive. For example, SMITH, smith, Smith all
match the filtering criteria specified above.
• C for Character, for example, C'Smith'
Character filters are case-sensitive. For example, messages containing Smith
match the filter, while message containing SMITH do not.
• X for Hexadecimal, for example, X'0CDF'
The filtering criteria value must consist of an even number of hexadecimal
digits (0-9, A-F).
• N for Zoned Decimal, for example, N or N'0001'
If the relational operator is VA (Valid) or NV (Not Valid), enter only the filter
type. For all other relational operators, the filtering criteria value must
consist of decimal digits and can be preceded by an optional sign (+-).
• P for Packed Decimal, for example, P or P'0001'
If the relational operator is VA (Valid) or NV (Not Valid), enter only the filter
type. The filtering criteria value must consist of decimal digits and can be
preceded by an optional sign (+-).
• M for Mask, for example, M'11000000' or M'C0'
The filtering criteria value must consist of 8 binary or 2 hexadecimal digits,
that identify the bits, within the specified byte (POS fields), to consider for
filtering. In the example above, Hiperstation for WebSphere MQ examines
the first 2 bits of the specified byte.
3-12
3. Enter the desired line commands in the S field. You can enter multiple line
commands at the same time. When you press Enter, the commands are processed
sequentially. R (repeat) creates a copy of the selected filter. Use this to quickly create
several similar filters. I (insert) adds a new blank filter after the selected filter. You
can create up to 999 filters. D (delete) deletes an existing filter. This command
cannot be used if the selected filter is the only filter in the filter list.
4. When finished, press End to validate and save your work. Hiperstation for
WebSphere MQ either returns to the WebSphere MQ - Header Filter screen (Figure 3-4
on page 3-5) or presents the next selected filter’s Header Filter Detail or Message Data
Filter screen depending on the line commands you entered on the WebSphere MQ Header Filter screen. To exit the screen without saving your work, type CANCEL on
the Command line and press Enter.
If there are any invalid settings, Hiperstation for WebSphere MQ presents a short
error message in the upper right corner of the screen. Press the Help key to see
extended error message information. Correct the setting and press End again.
Import Filters and Options Command
To save time with script or subset repository creation, import:
• Existing filters, and/or
• Script/subset repository create options (the options specified on the script/subset
repository create screens)
To import filters, options, or both:
1. On the Header Filters screen (Figure 3-4 on page 3-5), type IMPORT on the Command
line and press Enter. The WebSphere MQ Create Scripts - Import from JCL screen
appears.
Note:
Press End to exit the screen without saving your work.
Figure 3-7. WebSphere MQ Create Scripts - Import from JCL Screen
Hiperstation ------- WebSphere MQ Create Scripts - Import from JCL -----------Command ===>
Specify the dataset containing MQ Create Scripts JCL and the items to import,
then press ENTER to continue.
What should be
3 1. Import
2. Import
3. Import
WebSphere
Project
Group .
Type .
Member
imported? (Enter number to select)
filters only
options only
all parameters
MQ Create Scripts JCL dataset:
. . . VPTST12
. . . JCL
. . . JCL
. . .
Other Data Set Name:
Data Set Name . . .
2. On the line under What should be imported?, enter:
– 1 to import filters from the specified JCL. The Header Filters screen will reflect
the imported filters — all other screens remain unchanged.
– 2 to import all of the options from the specified JCL. The filters remain
unchanged, while all other screens reflect the selections from the specified JCL.
– 3 to import the filters and options from the specified JCL.
3-13
Specify the name of the sequential dataset, or PDS(E) and member name containing
the filters and/or options to import. To browse and/or select a member from a list, do
not specify the member name. Press Enter to continue.
3. If you entered a PDS without a member name, Hiperstation for WebSphere MQ
presents the WebSphere MQ Create Scripts - Import Member List screen (Figure 3-8).
Select the member to import and press Enter. Ensure the selection by browsing the
member first.
Figure 3-8. MQ Create Scripts - Import Member List Screen
Hiperstation -- MQ Create Scripts - Import Member List -- Row 00001 of 00051
Command ===>
Scroll ===> PAGE
Select a member to IMPORT then press ENTER or END to return.
Line Commands are: (B)rowse or (S)elect
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
Name
BACKLVL
CAJSCR00
CAJSCR01
CAJSCR02
CAJSCR03
CAJSCR04
CAJSCR05
CAJ1
CAJ3
CAJ30000
CAPTEST
CAP10000
CNOLD
CN1
DEMOS000
DEV1
Prompt
Size
132
11531
11531
5600
99
5675
175
160
137
1070
2388
2388
131
130
245
121
Created
2007/09/05
2007/09/05
2007/09/05
2007/09/09
2007/09/09
2007/09/09
2007/09/09
2007/07/02
2007/07/02
2007/07/02
2007/06/27
2007/06/24
2007/05/16
2007/05/16
2006/12/10
2006/01/20
Changed
2007/09/05 16:40:44
2007/09/05 12:55:00
2007/09/05 14:41:00
2007/09/09 16:43:00
2007/09/09 16:43:00
2007/09/09 16:43:00
2007/09/09 16:43:00
2007/07/02 12:31:13
2007/07/02 15:29:59
2007/07/02 15:58:00
2007/06/27 16:04:29
2007/06/24 15:14:00
2007/05/16 13:02:53
2007/06/04 12:15:48
2006/12/10 10:32:00
2006/01/23 13:37:26
ID
USERID
USERID
USERID
USERID
USERID
USERID
USERID
USERID
USERID
USERID
USERID
USERID
USERID
USERID
USERID
USERID
4. Hiperstation for WebSphere MQ validates that the specified dataset contains script
create JCL and that the parameters are semantically correct instream data (DD*). If
so, it returns to the Header Filters screen (Figure 3-4 on page 3-5).
– If the specified member does not contain the appropriate JCL, Hiperstation for
WebSphere MQ cancels the import and issues an error message.
– If the member contains valid script create JCL but invalid parameters, it presents
an error message identifying the erroneous parameters. Correct the JCL and
import the filters and/or options again.
Note:
IMPORT does not validate parameter values. Hiperstation for WebSphere MQ
checks them as you pass the screens specific to the parameters. For example,
filter parameters are validated when you type OK on the Command line of the
Header Filters screen (Figure 3-4 on page 3-5) and press Enter. Hiperstation for
WebSphere MQ presents error messages in the upper right corner of the screen
identifying missing or invalid parameter values. It also displays a hash symbol
(#) in the fields of the missing values. Replace the hash symbols and correct any
inaccurate values as you pass through the screens.
Specify Source Repository
You can access the WebSphere MQ Create Scripts - Input screen (Figure 3-9) by typing OK
on the Command line of the Header Filters screen and pressing Enter. Use it to specify a
repository containing captured WebSphere MQ data to use for generating your scripts or
subset repositories. Fill in the fields and press Enter to continue.
3-14
Figure 3-9. WebSphere MQ Create Scripts - Input Screen
Hiperstation --------- WebSphere MQ Create Scripts - Input -----------------Command ===>
Specify the repository to use as input, then press ENTER to continue.
Repository dataset:
Dataset name 'USERID1.TEST.REPOS'
First and last number ._______ _______(Needed if wildcard in dataset name)
Amount of data to use:
Message data from GETs...ALL
Message data from PUTs...ALL
1. In the Dataset name field, enter the name of the repository to use for generating
your scripts/subset repositories. To select a range of source repositories, use the
asterisk (*) or question mark (?) wildcards in the dataset name designation and define
a range with the First to last number fields.
Note:
You cannot use the wildcard as the first character in any of the dataset name
segments. For example: ‘USERID1.TEST.REP*’ is valid, but ‘USERID1.TEST.*’ is
not.
2. You can specify an Amount of data to use to minimize the size of your scripts by
truncating GET and/or PUT message detail, that is, data tagged <CONTENT> in MQ
scripts. This option supports tasks such as debugging and stress testing. For example,
if you are manually inspecting scripts for debugging purposes and need to see only
the first 200 bytes of message data, truncate to 200. If you are stress testing and
interested in only the transaction speed, not data comparison, truncate GET
messages to reduce script size and demand on DASD storage. Enter ALL to include all
message detail or indicate the number of bytes, between 0-9999999, to include.
If you are intending to play back and compare actual with expected values, select
ALL. If you truncate PUT messages, your scripts may not play back properly. If you
truncate GET messages, your scripts may play back, but comparing actual to expected
values may not be possible.
Define Event Grouping
Hiperstation for WebSphere MQ can generate one script containing filtered events
ordered as they were captured or separate scripts containing filtered events grouped by
queue manager, connection, jobname, object, and/or event. Selecting more than one
grouping criteria results in a separate script for each combination.
Determine your grouping selection based on the nature of your application and the types
of testing you need to perform. For example:
• If you want to separate recorded events by CICS region, select Jobname as jobname is
always that of the CICS region.
• If each program you are testing has its own queue, group by Object to generate
scripts for testing each application independently.
• If you are testing a batch application, select Jobname and/or Connection to generate
testing scripts.
• If you want to fill the queue with PUT and PUT1 messages to prepare for application
load testing, group by Event. Play the PUT and PUT1 scripts before playing the GET
script to ensure each transaction is completed.
• If your queue managers process specific types of activity, and you want to test the
applications responsible for that activity, select Queue Manager.
3-15
Although you can use event grouping for several purposes, it is primarily used to create
scripts for stress, load, and concurrency testing. Later in this process, you can generate a
Script Log to run a playback job. The Script Log contains one MQGROUP and SCRIPT
statement for each script created. All MQGROUPs play back simultaneously. Be mindful
of transaction interdependence. For example, while recording you request a record, then
update the record. If your grouping selection places the inquiry transaction in one script
and the update in another, the inquiry transaction may play back after the update,
resulting in a “miscompare”. Depending on the focus of your testing, this may not be an
issue.
The WebSphere MQ Create Scripts - Grouping screen appears (Figure 3-10) after you
specify the repository and press Enter on Figure 3-9 on page 3-14. On the line next to
option 1, enter the number of the grouping selection you require. If you enter 2, type a
slash (/) next to the desired grouping criteria.
Press Enter to continue.
Figure 3-10. WebSphere MQ Create Scripts - Grouping Screen
Hiperstation -------- WebSphere MQ Create Scripts - Grouping -----------------Command ===>
Choose how to group data among scripts, then press ENTER to continue.
Create a new script for each:
2
1. One script for everything
2. New combination of (one or more)
_ Queue manager
/ Connection
_ Object (queue)
/ Jobname
_ Event
Define Detail Data Storage and Output Requirements
After defining event grouping and pressing Enter, the WebSphere MQ Create Scripts Create Options (1 of 2) screen appears (Figure 3-11). Use this screen and the next to
define script detail data storage requirements and output requirements.
Figure 3-11. WebSphere MQ Create Scripts - Create Options Screen (1 of 2)
Hiperstation --- WebSphere MQ Create Scripts - Create Options (1 of 2) ------Command ===>
Where should details be stored? (Enter number to select)
1 1. Merge all details into the script
2. Separate details from script, PUT and GET data together
3. Separate details from script, PUT and GET data split
Script processing options: (Enter "/" to select)
/ Suppress time stamps in script
/ Translate detail data from ASCII to EBCDIC
_ Translate sample data from ASCII to EBCDIC
_ Include default MQAPI Script Tag parameters
Description:
1. In the Where should details be stored? section, enter the number for the desired
detail storage option, type a slash (/) next to the appropriate processing options and
press Enter.
3-16
Scripts are comprised of MQ verbs and associated detail data (data tagged
<CONTENT>). Store each script in one PDSE member containing the MQ verbs
merged with the detail data, or store the detail data separately for easy viewing and
editing. See “Editing MQ Message Data with File-AID/MVS” on page 3-47. When the
details are stored separately, the script contains MQ verbs and links to the associated
detail.
Merge all details into the script: This option writes the MQ verbs and the associated
detail, or <CONTENT>, data into the same PDSE member.
Separate details from script, PUT and GET data together: This option writes two
PDSE members: one containing all detail data, and one containing the script. Display
or edit detail data with a file formatting tool such as File-AID/MVS. See “Editing MQ
Message Data with File-AID/MVS” on page 3-47.
Separate details from script, PUT and GET data split: This option write three PDSE
members. One containing the:
– script (MQ verbs with links to associated data)
– GET data
– PUT data
2. In the Script processing options section, select any or all of the listed processing
options.
– Suppress time stamps in script: This option omits time stamps from the MQ
verbs making the script easier to browse for auditing purposes. However,
Hiperstation for WebSphere MQ uses the time stamps to synchronize playback.
Do not use this option if you intend to play back your scripts.
– Translate detail data from ASCII to EBCDIC: This option converts the content
of ASCII messages, based on the CodedCharSetId field of the MQMD, to EBCDIC.
This makes it easier to display and edit detail data in ISPF. This option has no
effect on messages already in EBCDIC. Hiperstation for WebSphere MQ adds the
TRANSLATE=A2E keyword to the script tag to indicate that translation has
occurred for a particular message. During playback, these messages are converted
back to ASCII.
– Translate sample data from ASCII to EBCDIC: When you store script and detail
data separately, Hiperstation for WebSphere MQ includes a single line, or sample,
of the detail data in the script for reference purposes. This option converts ASCII
sample data, based on the CodedCharSetId field of the MQMD, to EBCDIC. Select
this option if you plan to view your scripts in ISPF.
– Include default MQAPI Script Tag parameters: This option writes your
application's entire MQ API parameter set into the script. Normally, Hiperstation
for WebSphere MQ saves space in the script by omitting parameters with default
settings. Use this option to ensure all parameters are set appropriately.
3. Enter a Description up to 53 characters that describe the scripts or subset
repositories you are creating. This description appears at the top of the MQ Script Log
and at the top of each script.
The second WebSphere MQ Create Scripts - Create Options screen appears.
3-17
Figure 3-12. WebSphere MQ Create Scripts - Create Options Screen (2 of 2)
Hiperstation --- WebSphere MQ Create Scripts - Create Options (2 of 2) ------Command ===>
What should be created? (Enter "/" to select)
Log entries
/ Script entries
/ Detail entries
Event summary entries in CSV format
Event summary entries in HTML format
/ Subset repository
Allow overwrite of any
Replace existing
/ Replace existing
/ Replace existing
Replace existing
members? (Enter "/" to select)
log members
script members
detail members
event summary members
4. In the What should be created? section, place a slash (/) next to the appropriate
selections and press Enter to continue.
– Log entries: This option produces an MQ Script Log that lists every script
Hiperstation for WebSphere MQ created. Each entry consists of an MQGROUP
and SCRIPT statement. It not only reports the results of script creation, but also
contains the JCL and SYSIN for playing back the scripts. Depending on your
testing requirements, you may need to modify it before playback. See “Preparing
the Log File for Unattended Playback” on page 5-16.
– Script entries: This option generates MQ testing scripts based on the
information you have provided in the previous screens.
– Detail entries: This option generates MQ detail, or <CONTENT>, data. If you are
generating scripts you intend to play back, select this option.
– If you are generating scripts and you elected to store detail data separately, but
fail to select this option, the scripts will contain an unresolved detail tag, for
example, <DETAIL COMBINED ???>. Generate the detail data. Then replace the
question marks on the detail tag in the script with the DD associated with the
dataset containing the detail.
– Event summary entries in CSV format: This option produces a comma
delimited summary of events that match the selected filtering criteria. Use this
report for tasks such as reviewing the events in a specific repository prior to
filtering or verifying the accuracy of your filtering selections prior to creating
scripts/subset repositories. This version can be imported into a spreadsheet or
database program.
– Event summary entries in HTML format: This option produces an interactive
HTML summary of events that match the selected filtering criteria. This version
of the report contains detailed information that you access by clicking links. Use
this report for tasks such as verifying the accuracy of filtering selections or
troubleshooting application or messaging issues.
Note: The event summary options are mutually exclusive. Select the format that
suits your needs. See “Event Summary” on page 3-18 for a detailed
discussion of both formats.
– Subset repository: This option produces a new repository containing the filtered
activity in a compressed format. Build smaller repositories containing specified
information to reduce storage overhead and script creation effort.
5. In the Allow overwrite of any members? section, select the items you would like
Hiperstation for WebSphere MQ to overwrite when generating the selected output.
The choices include:
– Replace existing log members
3-18
– Replace existing script members
– Replace existing detail members
– Replace existing event summary members
Event Summary
Use the Event Summary to determine and validate filtering criteria prior to generating
scripts and subset repositories.
• Before you enter filtering criteria, generate an Event Summary to review the contents
of the capture repository.
• After you enter filtering criteria, before you generate the scripts/subset repositories,
create another Event Summary to validate your filtering criteria selections.
Produce the Event Summary in CSV or HTML format, as previously described. Both
versions list all events that match the specified filtering criteria. The HTML version
provides additional connection sequence information that is hyperlinked to event detail.
As such, this section describes the HTML version.
The HTML Event Summary is comprised of three frames:
• Title frame — appears across the top of the browser window. It presents a title and
general information about the Event Summary.
• Connection Sequence frame — appears below the Title frame, on the left side of the
browser window. Initially, it presents an expandable list of Connection IDs. Click the
plus sign (+) next to a connection to see the MQ events that occurred on that
connection. Expand the MQ_OPEN events to see the associated GETs, PUTs, SETs,
INQUIREs, and CLOSEs. Click any MQ event to see the event’s detail.
• Detail frame — appears below the Title frame and to the right of the Connection
Sequence frame. Initially, it presents all events that match the specified filtering
criteria, in chronological order. When you click an MQ event in the Connection
Sequence frame, the event’s detail displays in this frame.
3-19
Figure 3-13. HTML Event Summary
The Title frame contains the run date and time of the job in which the Event Summary
was created, the LPAR in which the job that created the Event Summary was run, the
name of the job in which the Event Summary was created, the number of the job in
which the Event Summary was created, and the repository dataset from which the Event
Summary was created.
The Connection Sequence links list all MQ events that match the specified filtering
criteria, in hierarchal order. That is,
• MQ_CONNECT calls contain: MQ_OPENs, MQ_PUT1s, MQ_COMMITs,
MQ_BACKOUTs, and MQ_DISCONNECTs.
• MQ_OPEN calls contain: MQ_GETs, MQ_PUTs, MQ_SETs, MQ_INQUIREs, and
MQ_CLOSEs.
The list initially shows only the MQ_CONNECT calls. Click the plus sign (+) preceding
MQ_CONNECT to see the events that occurred on the given connection ID. Once the
connection information is expanded, the plus sign becomes a minus sign (-). Click the
minus sign to hide the connection’s event list. Expand and collapse MQ_OPEN calls the
same way.
Note:
Hiperstation for WebSphere MQ synthesizes missing MQ_CONNECT, MQ_OPEN,
MQ_CLOSE, and MQ_DISCONNECT calls. For example, if recording begins after
the CONNECTION and OPEN occurs, Hiperstation for WebSphere MQ
synthesizes both calls based on the captured events related to the MQ_OPEN or
MQ_CONNECT. All synthesized events are marked with an asterisk (*).
Click any event to display the event’s detail in the Detail frame.
The following list shows all possible event links. The values in the parentheses after the
call correlate to the Connection ID, Object ID, and Position columns on the Time
Sequence Event Summary (see Figure 3-13 on page 3-19).
3-20
MQ_CONNECT(connection ID)-queue manager name
Connection ID is the identifier that Hiperstation for WebSphere MQ assigns each
connection during recording. All connections, including synthesized connections,
are numbered sequentially within the repository.
MQ_OPEN(connection ID, object ID)
Connection ID indicates the connection on which the OPEN occurred. Object ID is
the identifier that Hiperstation for WebSphere MQ assigned to the MQ_OPEN during
recording. All object-level events (MQ_OPEN and MQ_PUT1), including synthesized
event, are numbered sequentially within the repository. For example, MQ_OPEN(5,8)
is the eighth object-level event in the recording and took place on the fifth
connection.
MQ_PUT1(connection ID, object ID)
Connection ID indicates the connection on which the PUT1 occurred. Object ID is
the identifier that Hiperstation for WebSphere MQ assigned to the MQPUT1 during
recording. All object-level events (MQ_OPEN and MQ_PUT1), including synthesized
event, are numbered sequentially within the repository. For example, MQ_PUT1(5,9)
is the ninth object-level event in the recording and took place on the fifth
connection.
MQ_COMMIT(connection ID,,position)
Connection ID indicates the connection on which the COMMIT occurred. Position
indicates the position of this call relative to other COMMITs within the connection.
For example, MQ_COMMIT(6,,2) is the second COMMIT that occurred on the sixth
connection.
MQ_BACKOUT(connection ID,,position)
Connection ID indicates the connection on which the BACKOUT occurred. Position
indicates the position of this call relative to other BACKOUTs within the connection.
For example, MQ_BACKOUT(6,,2) is the second BACKOUT that occurred on the sixth
connection.
MQ_GET(connection ID, object ID, position)
Connection ID indicates the connection on which the GET occurred. Object ID
indicates the MQ_OPEN in which the GET occurred. Position indicates the position
of this call relative to other events within the OPEN. For example, MQ_GET(5,8,2) is
the second event in the eighth OPEN on the fifth connection.
MQ_PUT(connection ID, object ID, position)
Connection ID indicates the connection on which the PUT occurred. Object ID
indicates the MQ_OPEN in which the PUT occurred. Position indicates the position
of this call relative to other events within the OPEN. For example, MQ_PUT(5,4,2) is
the second event in the fourth OPEN on the fifth connection.
Message Detail
Link to the MQ_GET or MQ_PUT message content. Message content appears in Detail
frame.
MQ_INQUIRE(connection ID, object ID, position)
Connection ID indicates the connection on which the INQUIRE occurred. Object ID
indicates the MQ_OPEN in which the INQUIRE occurred. Position indicates the
position of this call relative to other events within the OPEN. For example,
MQ_INQUIRE(5,8,2) is the second event in the eighth OPEN on the fifth connection.
MQ_SET(connection ID, object ID, position)
Connection ID indicates the connection on which the SET occurred. Object ID
indicates the MQ_OPEN in which the SET occurred. Position indicates the position of
this call relative to other event within the OPEN. For example, MQ_SET(5,8,2) is the
second event in the eighth OPEN on the fifth connection.
3-21
MQ_CLOSE(connection ID, object ID)
Connection ID and Object ID are the same as the corresponding MQ_OPEN.
MQ_DISCONNECT(connection ID)
Connection ID is the same as the corresponding MQ_CONNECT.
The Detail Frame provides completion and reason codes as well as current and true
lengths. All other fields correspond to MQ header fields. Refer to IBM WebSphere MQ
documentation.
Completion Code
Numeric completion code for the given call:
– 0 indicates that the call completed successfully.
– 1 indicates that the call partially completed.
– 2 indicates the call failed.
Reason Code
Numeric reason code for the given call. 0 indicates that there was no reason code.
Other reason codes can be from 2001 to 2360, and are listed in IBM’s WebSphere MQ
Application Programming Reference Guide.
Current Length
Length of the message associated with the given MQ_GET, MQ_PUT, or MQ_PUT1, up
to the maximum length specified on the WebSphere MQ Create Script - Input screen
(Figure 3-9 on page 3-14).
True Length
Actual length of the message associated with the given MQ_GET, MQ_PUT, or
MQ_PUT1.
Specify a Subset Repository Dataset
1. If you:
– did not create a subset repository, the WebSphere MQ Create Scripts - Output
screen appears next. See “Specify Other Output Datasets” on page 3-23.
– created a subset repository, the WebSphere MQ Create Scripts - Subset Output
screen appears next (Figure 3-14 on page 3-22).
Specify a single dataset to contain the entire repository or a range of datasets to
segment the repository. Hiperstation for WebSphere MQ writes the new repository
data to the first specified dataset. If the dataset contains data, it adds the new data to
the end of existing data until it completes repository creation or the dataset is full. If
there is more data to write, it continues writing to the next specified dataset.
Hiperstation for WebSphere MQ reports progress with messages indicating the
opening and closing of datasets.
Note:
To overwrite an existing repository dataset, delete the dataset first.
2. Fill in the fields and press Enter to continue or press End to return to the previous
screen without designating a dataset.
3-22
Figure 3-14. WebSphere MQ Create Scripts - Subset Output
Hiperstation ---------- WebSphere MQ Create Scripts - Subset Output ----------Command ===>
Specify the subset repository to create, then press ENTER to continue.
Subset repository dataset:
Dataset name . . . . . 'USER005.MQSERIES.SUBALP*'
10
(Needed if wildcard in dataset name)
First and last number . 0
3. In the Dataset name field, enter the name of the sequential dataset to contain the
subset repository you are generating. To create a segmented repository, use the
asterisk (*) and question mark (?) wildcards and specify a wildcard range with the
First and last number fields:
If you imported options, Hiperstation for WebSphere MQ populates all fields on this
screen with the settings saved in the options file. Otherwise, the:
– Dataset name field defaults to the last specified dataset.
– First and last number fields default to previously specified values. If you have
never used this feature before, Hiperstation for WebSphere MQ populates the
fields with the values specified on the WebSphere MQ Create Scripts - Input
screen (Figure 3-9 on page 3-14).
If the first specified dataset does not exist, Hiperstation for WebSphere MQ presents
the Allocate Dataset screen (Figure 3-15). It populates the:
– Space units, Primary quantity, and Secondary quantity fields with allocation
values from the originating (input) repository.
– Block size with the default value of 9004.
4. Fill in the field and press Enter to continue or END to exit the screen without
allocating the file.
Figure 3-15. Allocate Dataset Screen
Hiperstation -------------------- Allocate Dataset----------------------------Command ===>
Press ENTER to allocate a dataset or END to exit without allocation
Dataset name: USER005.MQSERIES.SUBALP00
SMS Management class.
SMS Storage class . .
Volume serial . . .
Device type . . . .
SMS Data class. . . .
Space units . . . .
Primary quantity. .
Secondary quantity.
Block size. . . . . .
Note:
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
SYSDA
TRKS
1
1
9004
(BLKS, TRKS, or CYLS)
(in above units)
(in above units)
For segmented repositories, Hiperstation for WebSphere MQ automatically
allocates subsequent datasets, if they do not exist, with the allocation
parameters of the first dataset.
If you elected to generate other output such as your scripts, log, event summary, etc.,
the WebSphere MQ Create Scripts - Output screen appears next. See “Specify Other
Output Datasets” on page 3-23. Otherwise, the WebSphere MQ Create Scripts Process option screen appears. See “Select a Processing Option” on page 3-24.
3-23
Specify Other Output Datasets
If you did not create a subset repository, the WebSphere MQ Create Scripts - Output
screen appears (Figure 3-16) after defining output requirements (Figure 3-12 on page
3-17). Otherwise, it appears after specifying the subset repository dataset (Figure 3-14 on
page 3-22).
Use this screen to specify dataset names for generated output. If available, Hiperstation
for WebSphere MQ populates the fields with either previously defined or imported
information. It also marks required rows with an asterisk (*) that appears between the
Dataset name and Prefix fields.
Figure 3-16. WebSphere MQ Create Scripts - Output Screen
Hiperstation -------- WebSphere MQ Create Scripts - Output ----------------Command ===>
Enter the output dataset names, member name prefixes, member name suffixes,
and DDnames. Rows marked with * are required.
Script Datasets:
Log: . . . . . . 'USERID.TEST.LOG'_____________________________ *
Prefix: PRLOG
Suffix: 0000001
Script:. . . . . 'USERID.TEST.SCRIPT'__________________________ *
Prefix: PRSCRT Suffix: 0000001
Combined detail: 'USERID.TEST.DETAIL'__________________________
Suffix: 0000001 DDname: ________
Prefix: PRDET
GET detail:. . . ______________________________________________
Prefix: ______ Suffix: 0000000 DDname: ________
PUT detail:. . . ______________________________________________
Prefix: ______ Suffix: 0000000 DDname: ________
Event summary: . ______________________________________________
Suffix: 0000000
Prefix:
1. Enter a PDSE name, without a member name, for each row marked with an asterisk
(*). If you do not enclose the PDSE name in single quotes, Hiperstation for
WebSphere MQ prefixes it with your TSO prefix, typically your user ID, at processing
time.
Note: If you selected Event Summary in HTML format on the WebSphere MQ Create
Scripts - Create Options (2 of 2) screen (Figure 3-12 on page 3-17), specify an
existing HFS path in this field, instead of a PDSE. Also, HFS paths are
case-sensitive.
2. Enter a one- to six-character member name prefix for each row marked with an
asterisk (*). Provide a prefix that makes it easy for you to identify the type of data
stored in the members of the given dataset. Hiperstation for WebSphere MQ uses the
prefix and suffix to create complete member names. For example, prefix payroll
system testing scripts with PRTEST and set the suffix to 01 to generate members
PRTEST01, PRTEST02, and so on.
Note:
Make sure the combined number of characters for prefix and suffix does not
exceed eight.
3. Enter a one- to seven-numeral member name suffix for each row marked with an
asterisk (*). Hiperstation for WebSphere MQ uses the prefix and suffix to create
complete member names for the information stored in the given dataset. If it creates
more than one member for the dataset, it increments the suffix to create unique
member names. For example, your grouping selection produces three scripts. If the
prefix is set to PRTEST and suffix is set to 01, Hiperstation for WebSphere MQ
generates members PRTEST01, PRTEST02, PRTEST03.
4. Enter a one- to eight-character DD name for detail datasets marked with an asterisk
(*). Hiperstation for WebSphere MQ creates a <DETAIL> tag in the script that points
3-24
to the DD names you specify. It uses this information to locate the detail data during
playback.
Note:
The playback JCL contained in the log will include the DD names you enter
here. If you compose your own playback JCL, instead of using the JCL from
the log, be sure to include the same DD names.
5. Press Enter to continue.
If you enter a dataset name that does not exist, the Allocate Dataset screen appears. The
fields on this screen default to imported values or to the last specified values. Set the
record length (LRECL) for:
• Log datasets to 76 or higher.
• Script datasets to 76 or higher. To minimize CPU utilization and the amount of time
it takes to generate the scripts, set this value to 256 or higher.
• Detail datasets equal to or greater than the maximum MQ message length.
Note: Messages longer than the detail dataset LRECL will span multiple lines. If the
dataset contains messages that span multiple lines, the MAPD command,
discussed on page 3-47, will not allow you to map the entire detail dataset
into File-AID/MVS for editing. However, you will be able to map individual
messages.
• CSV event summary datasets to 158 or more.
Block size must be minimally the record length plus four — 32760 is the maximum
allowable value. Leave this field empty to have the system calculate block size for you.
Fill in the fields and press Enter to allocate the dataset or press End to exit the screen
without allocating the dataset.
If more datasets require allocation, Hiperstation for WebSphere MQ presents the
allocation screen for the next dataset. Otherwise, it presents the WebSphere MQ Create
Scripts - Process screen, discussed next.
Select a Processing Option
After you select all of your script/subset repository creation options, Hiperstation for
WebSphere MQ presents the WebSphere MQ Create Script - Process screen (Figure 3-17).
Use this screen to:
• Specify how to process your request for script and/or subset repository creation.
• Access the Save JCL File screen to save your script/subset repository creation JCL.
Note:
By default, the maximum message size that Script Create processes is 32K.
Increase this value by adding a parameter to the JCL prior to submitting the job.
Select option 2 and insert the MQCSMSG = 'value' into the list of SYSIN
parameters.
3-25
Figure 3-17. WebSphere MQ Create Scripts - Process Screen
Hiperstation ------- WebSphere MQ Create Scripts - Process -----------------Command ===>
Select a processing option, or type SAVE on the Command line to save the
Create Scripts JCL to a dataset.
Select an option:
1. Submit batch job
2. Edit batch job
3. Process in foreground
X. Exit
Job statement information for batch job:
===> //JOBNAME JOB (ACCOUNT),'NAME'
===> //*
===> //*
===> //*
1. Enter the desired processing option on the line next to the list and press Enter to
begin processing. Processing Job Options include:
– 1. Submit batch job: Processes the script/subset repository creation job in batch
mode. Refresh your screen to see job submit and confirm messages. When the job
is complete, Hiperstation for WebSphere MQ returns you to the WebSphere MQ
Create Scripts - Process screen (Figure 3-17).
– 2. Edit batch job: Opens up the batch job for editing before processing. If you
edit the job, type SUB or SUBMIT on the Command line and press Enter to
submit the job. For a list of Script Create parameters, see Appendix D, “Script
Create Parameters”. To exit the edit session without submitting the job, type
EXIT on the Command line and press Enter.
– 3. Process in foreground: Processes the script/subset repository creation job in
TSO foreground. Your TSO terminal session is not available for other work until
the script/subset repository creation process is complete. All status messages
appear on your TSO terminal.
– X. Exit: Use this option to exit this screen without submitting the job. Use the
End key to step backward through the panels. All parameters are retained in your
ISPF profile.
2. Enter batch JOB card information in the Job statement information for batch job
area. If you use option 2, you can edit this information again before job submission.
Note: The job card information you enter here appears at the top of the log file used
to run an unattended playback job or reporting job. Be sure to enter job card
information even if you are processing in the foreground.
3. Type SAVE on the command line and press Enter. The Save JCL File screen appears
(Figure 3-18 on page 3-26). This saves your script/subset repository creation JCL to
submit at a later time or to import the next time you create scripts/subset
repositories. Use End to exit the screen without processing the job.
Script Create JCL
Save the script/subset repository creation JCL to a dataset. The next time you create
scripts and/or subset repositories, import filters, creations options, or both. See “Import
Filters and Options Command” on page 3-12.
To save the script/subset repository creation JCL to a dataset:
1. On the WebSphere MQ Create Scripts - Process screen (Figure 3-17 on page 3-25),
type SAVE on the Command line and press Enter. The Save JCL File screen appears.
3-26
2. Supply a sequential dataset or PDSE and member to contain the JCL. Type a slash (/)
in the Replace existing member field if you would like to overwrite information in
the specified sequential dataset or PDSE member. Press Enter to continue or End to
exit the screen without saving the JCL.
Figure 3-18. WebSphere MQ Create Scripts - Save JCL File
Hiperstation ------- WebSphere MQ Create Scripts - Save JCL File
Command ===>
-------------
Enter the name of the dataset where JCL will be saved, then press ENTER
to continue.
MQ Create
Project
Group .
Type .
Member
Scripts JCL dataset:
. . .
. . .
. . .
. . .
Data Set Name . . . 'USER005.MQ.PRSCIPTS.CREATE.JCL(PR1)'
Save JCL Options: (Enter "/" to select)
/ Replace existing members
3. If you specify a dataset that does not exist, Hiperstation for WebSphere MQ prompts
you to allocate a file for the JCL. It defaults commonly used settings for the type of
file you specify. If necessary, change default values and/or fill in empty fields. Press
Enter to allocate the dataset and save the JCL.
4. Hiperstation for WebSphere MQ returns to the Process screen (Figure 3-17 on page
3-25) and presents the Parameters saved message in the upper right corner.
Browsing and Editing Scripts
Scripts are formatted to make browsing and editing activity easy. Scripts contain tagged
data that adheres to a set of syntax rules. Browsing a script requires understanding the
purpose and information provided by each script tag. Editing a script requires
understanding script tags, syntax rules, and the relationship between the information in
the script and the statements that run playback.
This section provides information to help you browse or edit a script.
Browse a Script
Browse scripted activity for tasks such as debugging an application, validating new
functionality, and verifying database changes. Use a standard text browsing tool such as
ISPF Browse to review the contents of a script.
This section defines all of the available Hiperstation for WebSphere MQ script tags. Each
definition includes a syntax diagram that shows all of the parameters of the given script
tag. Some of the script tags contain groups of parameters, or fields, referred to as
structure data types. As such, this section begins with an explanation of the structure
data types. The script tag syntax diagrams show the associated data types. Cross-reference
the syntax diagrams with the information discussed in “Structure Data Type Fields” on
page 3-27.
Additionally, a few parameters are common to most of the script tags. To minimize
repetition, they are defined before the script tags as well.
3-27
Structure Data Type Fields
Structure data types are groups of parameters or fields that contain information relevant
to a specific MQ object or function. For example, the MQ Get Message Options
(MQGMO) structure data type includes a series of fields relevant to the MQGET
performed by your application.
IBM has established default values for each of these fields. To minimize the length of the
scripts, Hiperstation for WebSphere MQ presents only the fields that deviate from the
default values unless you select the Include default MQAPI Script Tag parameters
option while creating scripts. This option is located on the “WebSphere MQ Create
Scripts - Create Options Screen (1 of 2)” on page 3-15.
Each of the structure data type fields requires a specific type of value, for example, some
require character strings, while others require numeric values. Although this information
is relevant to script editing, it is presented in this section for easy reference. Field value
formats include:
•
•
•
•
•
String of characters (already translated by WebSphere MQ)
Keyword as defined by IBM
Multiple keywords as defined by IBM
Whole number
Hexadecimal string
1234ABCD’X
If the value spans multiple lines, the REXX concatenation operator, ||, appears
immediately before the comma on all lines except the last.
MQMD = ‘D4F5F2F040404040404040400000000140404040404040404’X||,
‘40404040404040404040404040404040400000000000000000000000000000’X||,
‘FFFFFF000000000000000000000000000000000000000000000000’X,
Table 3-1 shows all of the fields associated with each structure data type, along with the
format of the field value. It also lists the Hiperstation for WebSphere MQ script tags that
present the given data type. Refer to the IBM WebSphere MQ documentation for field
definitions.
3-28
Table 3-1. Structure Data Types Fields, Field Value Formats, and Associated Script Tags
Structure Data Type
SDT Fields
Field Value Format
MQMD1
MQ Message Descriptor
Version
Number
Report
(In the scripts, these fields are prefixed
with the structure data type indicator. MsgType
For example, MQMD_VERSION.)
Expiry
Multiple keyword
Keyword
Hiperstation for
WebSphere MQ
Script Tags
MQ_PUT,
MQ_PUT1,
MQ_GET,
MQ_OPEN
Number or special keyword UNLIMITED
Note: Corresponds to the constant
MQEI_UNLIMITED
Feedback
Multiple keyword
Encoding
Hexadecimal
CodedCharSetId
Number
Format
String
Priority
Number
Persistence
Keyword
MsgId
Hexadecimal or special keyword NONE
Note: Corresponds to MQMI_NONE.
CorrelId
Note: Corresponds to MQCI_NONE
MQMD2
BackoutCount
Single number
ReplyToQ
String
ReplyToQMgr
String
MQ Message Descriptor
UserIdentifier
with the structure data type indicator. AccountingToken
For example, MQMD_VERSION.)
ApplIdentityData
String
(continued from previous page)
PutApplType
Keyword
PutApplName
String
PutDate
String
PutTime
String
ApplOriginData
String
GroupId
Hexadecimal
String
Note: Corresponds to MQGI_NONE
MsgSeqNumber
Number
MsgFlags
Number
MQ_PUT,
MQ_PUT1,
MQ_GET,
MQ_OPEN
3-29
Table 3-1. Structure Data Types Fields, Field Value Formats, and Associated Script Tags
Structure Data Type
1
MQOD
MQ Object Descriptor
SDT Fields
Field Value Format
Hiperstation for
WebSphere MQ
Script Tags
Version
Number
MQ_PUT1
ObjectType
with the structure data type indicator. ObjectName_Out
(corresponds to MQ
For example, MQOD_VERSION.)
parameter
ResolvedQName)
Keyword
String
ObjectName_In
(corresponds to MQ
parameter
ObjectName)
String
ObjectQMgrName
String
DynamicQName
String
AlternateUserId
String
MQPMO1
MQ Put Message Options
Version
Number
MQGMO1
MQ Get Message Options
Version
Options
Multiple keyword
String
with the structure data type indicator. ResolvedQName
For example, MQPMO_VERSION.)
ResolvedQMgrName String
Options
with the structure data type indicator. WaitInterval
For example, MQGMO_VERSION)
Signal1
Keyword
MQ_PUT,
MQ_PUT1
MQ_GET
Multiple keyword
Hexadecimal
Hexadecimal
Signal2
Hexadecimal
ResolvedQName
String
ReturnedLength
Number
MatchOptions
Multiple keyword
GroupStatus
String
1. Script create generates the structure data type in raw format (single field, in hexadecimal format) when it cannot
parse the structure into its component fields. This single field uses the same name as the structure data type.
Playback accepts either the parsed structure data type (with its component fields) or the raw format.
2. Script create generates the structure data type in raw format (single field, in hexadecimal format) when it cannot
parse the structure into its component fields. This single field uses the same name as the structure data type.
Playback accepts either the parsed structure data type (with its component fields) or the raw format.
Parameters Common to Most Script Tags
Most of the Hiperstation for WebSphere MQ script tags include any or all of the following
parameters:
Connection_ID=number
Relates scripted events to a connection to a queue manager. Each MQ_CONNECT tag
must have a unique CONNECTION_ID. This number is roughly equivalent to the
WebSphere MQ hConn (connection handle).
Object_ID=number
Relates scripted events to an open MQ queue. Each MQ_OPEN and MQ_PUT1 tag
must have a unique Object_ID. The parameter is present on all script tags except
3-30
MQ_CONNECT, MQ_DISCONNECT, MQ_COMMIT, and MQ_BACKOUT. This number
is roughly equivalent to the WebSphere MQ hObj (object handle).
CompCode=number
The numeric completion code returned by Hiperstation for WebSphere MQ.
Reason=number
The numeric reason code returned by Hiperstation for WebSphere MQ.
event_seq_num
Hiperstation for WebSphere MQ assigns a sequential value to the events in the script.
This number appears outside of the closing script tag bracket ‘>’. For example, the
following MQ_CLOSE is the 20th event in the script:
* MQ_CLOSE *
*
<TIME>2006/06/05_14:37:15.345744
<MQ_CLOSE,
CONNECTION_ID = 3,
OBJECT_ID = 6,
COMPCODE = 0,
REASON
= 0,
MQCO = (NONE)>20
This value is not necessary to play back a script. It simply provides context for script
editing.
<CONTENT> Tag for Inline Data
CONTENT tags present the message data associated with the recorded MQPUT, MQPUT1,
and MQGET calls. One or more CONTENT tags appears immediately after an MQ_PUT,
MQ_PUT1, or MQ_GET tag. If the length of the application data is greater than the
logical record length (LRECL) of the script dataset, the detail data is presented on a series
of consecutive CONTENT tags.
When detail data is merged into the script, known as inline data, the CONTENT tag has
no attributes and is immediately followed, on the same line, by a 12-byte header and
then the application's data bytes, known as detail data. In the following example,
“....00000007” is the CONTENT tag header and the detail data begin immediately after
“7”.
<CONTENT>....00000007.......XPPJOBM400...wæìÎUR÷...ö«.\.m÷G
4444CDDECDE60310FFFFFFFF0002000EDDDDCDFFF000A957EDE000C83E49EC
000C3653553E0241000000070A0210A77716244002076C86491308CA00B417
Note:
In ISPF Edit, type HEX ON on the Command line and press Enter to see the HEX
values for all of the bytes in the CONTENT tag.
The 12-byte header describes the CONTENT tag:
• The first two bytes indicate the length of the data following the CONTENT tag. This
value includes the 12-byte header and has a maximum value of X'7FF8' (32760).
Note:
If you are editing the script, make sure this number accurately reflects the
actual number of bytes in the dataset record plus twelve for the header. If the
data record is longer than this value, playback ignores the extra bytes. If the
data record is shorter than this value, playback pads it with EBCDIC blanks
(X'40').
3-31
• The third byte indicates the format of the CONTENT tag data. Its value is a
combination of all applicable formats from the following list.
–
–
–
–
–
–
X'20'
X'08'
X'04'
X'02'
X'01'
X'00'
indicates
indicates
indicates
indicates
indicates
indicates
an MQ script
the beginning of the CONTENT chain
the end of the CONTENT chain
truncated data
MQPUT data
MQGET data
For example, if the MQGET is comprised of three <CONTENT> tags, this byte’s value
on the:
– First tag is X'28', which indicates that this is data from an MQ script, that it is
MQGET data, and that it is the beginning of CONTENT chain.
– Second tag is X'20', which indicates this data is from an MQ script and that it is
MQGET data.
– Third tag is X'24', which indicates that this is data from and MQ script, that it is
MQGET data, and that it is the end of CONTENT chain.
If the CONTENT tag follows an MQ_PUT tag, this byte’s values on each CONTENT tag
is: X'29', X'21', and X'25' respectively.
• The fourth byte indicates the protocol of the given content data. In Hiperstation for
WebSphere MQ, the protocol value is always X'01'.
• The fifth through the twelfth bytes indicate the record number, beginning with
0000001 (X'F0F0F0F0F0F0F0F1'). This value increases by one for each subsequent
CONTENT tag.
Note:
If you use the “<REPLACE> Tag” on page 3-40 to replace application data during
playback, be mindful of this 12-byte header when calculating the offset.
Header: L L F P N N N N N N N N
Offset: 0 1 2 3 4 5 6 7 8 9 A B
Avoid manually calculating the data-replacement offset value by using the offset
determination macros that Hiperstation for WebSphere MQ provides (see “Offset
and Length Determination Macros” on page 3-41).
<CONTENT> Tag for External Data
Identifies the detail data records that are associated with the preceding MQ_PUT,
MQ_PUT1, or MQ_GET tag. The CONTENT tag includes only the FROM and TO
parameters when the detail data is stored in an external file.
FROM
A decimal number indicating the first label in the external file containing detail data
for this data flow.
TO
A decimal number indicating the last label in the external file containing detail data
for this data flow.
The value after the CONTENT tag is called 'sample data'. It is the first few bytes detail
data and is provided to support script browsing when the detail is stored separately. The
sample bytes are translated from ASCII to EBCDIC if you requested that option at script
creation time.
3-32
Whether the detail data is contained within the script or in an external file it is prefixed
by a 12-byte header that describes the affiliated CONTENT tag. See the description of the
12-byte header discussed in “<CONTENT> Tag for Inline Data” on page 3-30.
<DETAIL> Tag
Indicates the location of the detail data. Detail data are the bytes associated with the
recorded MQ_PUT, MQ_PUT1, and MQ_GET calls. This tag appears after the VERSION tag
at the beginning of the script.
COMBINED
Indicates that GET and PUT data is stored together in a single PDSE member, either
within the script, or in an external file. If the detail data is contained in the script,
the value of this parameter is an asterisk (*). If it is stored externally, the value is the
DD name of the external file, along with the PDSE member name, which is supplied
during script creation. If COMBINED is present, neither GET nor PUT appear on this
tag and cannot be added.
GET
Identifies where client data is located. The value is the DD name provided during
script creation.
PUT
Identifies where server data is located. The value is the DD name provided during
script creation.
Note: If, on the “WebSphere MQ Create Scripts - Create Options Screen (2 of 2)” on page
3-17, you do not select the Detail Entries option, a <DETAIL> tag appears in the
script, but the member name appears as three question marks (???). Edit the
script to provide the correct location or regenerate the script.
<MQ_BACKOUT...> Tag
Causes the queue manger to back out all of the MQ_GETs and MQ_PUTs that have
occurred since the last ‘syncpoint’.
For CONNECTION_ID, COMPCODE, REASON, and event_seq_num definitions, see
“Parameters Common to Most Script Tags” on page 3-29.
For more information about the MQBACK call and its parameters, refer to IBM’s
WebSphere MQ Application Programming Reference.
<MQ_CLOSE...> Tag
Relinquishes access to an object.
For CONNECTION_ID, OBJECT_ID, COMPCODE, REASON, and event_seq_num
definitions, see “Parameters Common to Most Script Tags” on page 3-29.
3-33
MQCO
MQ close options. The value of this parameter corresponds to the Options parameter
on the recorded MQCLOSE call. Valid values are NONE, DELETE, or DELETE_PURGE.
For more information about this tag and its parameters, refer to IBM’s WebSphere MQ
Application Programming Reference.
<MQ_COMMIT...> Tag
Tells the queue manager that the application has reached a syncpoint, and to make
permanent all of the MQ_GETs and MQ_PUTs that occurred since the last syncpoint.
definitions, see “Parameters Common to Most Script Tags” on page 3-29. For more
information about the MQCMIT call and its parameters, refer to IBM’s WebSphere MQ
Application Programming Reference.
<MQ_CONNECT...> Tag
Shows the start of an MQ connection. At playback time, the MQ_CONNECT tag starts an
MQ connection between Hiperstation for WebSphere MQ and a partner application.
QMGR_NAME
Name of the queue manager responsible for the given connection.
SYSTEM_NAME
Name of the system on which the connection occurred.
JOBNAME
Name of the job that initiated the connection.
STIME
The ‘start time’ (date and time) of the connection.
TRANSLATEA2E
Indicates that the detail data associated with the given connection was translated
from ASCII to EBCDIC during script creation. This parameter appears only if the
translation option was selected.
Note:
Hiperstation for WebSphere MQ synthesizes missing MQ_CONNECT tags during
script creation. For example, if capture begins after the connection is in progress,
the MQCONNECT call is not recorded. In an attempt to ensure successfully
playback, Hiperstation for WebSphere MQ inserts a synthesized MQ_CONNECT
tag into the script. Synthesized tags are preceded with a script comment for easy
identification, for example:
* SYNTHESIZED MQ_CONNECT TAG
3-34
If activity, other than the MQCONNECT call, is not recorded, playback results
may not be accurate. Review connections that begin with synthesized tags. Edit
or delete partially recorded activity.
<MQ_DISCONNECT...> Tag
Breaks the connection between the queue manager and the application.
Note: If a disconnection event was never seen for a particular MQ connection at capture
time, an MQ_DISCONNECT tag is "synthesized" for that connection and written
to the end of the script. These synthesized MQ_DISCONNECT tags are preceded
by a comment line like this:
* SYNTHESIZED MQ_DISCONNECT TAG
<MQ_GET...> Tag
Retrieves a message from an open local queue. This tag must follow and MQ_OPEN tag
with the same OBJECT_ID.
CRNTLEN
The length of the actual content. If you specified a truncation value on the
WebSphere MQ Create Scripts - Input screen (Figure 3-9 on page 3-14), this value may
be smaller than the TRUELEN value.
TRUELEN
The original length of the message retrieved from the queue. Corresponds to the
BufferLength value on the MQGET call.
MQGMO Options
See Table 3-1 on page 3-28.
MQMD Options
See Table 3-1 on page 3-28.
<MQ_INQUIRE...> Tag
Returns information about the attributes of an object.
3-35
SELECTORS
Multi-keyword constants corresponding to the array of selectors.
SELECTORCOUNT
Number of attributes requested.
CHARATTRS
The buffer in which character attributes are returned.
CHARATTRLENGTH
The length (in bytes) of the CharAttrs parameter.
INTATTRS
An array of IntAttrCount integer attribute values.
INTATTRCOUNT
The number of elements in the IntAttrs array.
For more information about the MQINQ call and its parameters, refer to IBM’s WebSphere
MQ Application Programming Reference.
<MQ_OPEN...> Tag
Establishes access to an object (queue). MQ_OPEN names the queue, namelist, process
definition, or queue manager, to be opened.
MQOD
See Table 3-1 on page 3-28 for a list of object descriptor fields.
MQOO
MQ open options. The value of this parameter corresponds to the Options parameter
on the MQOPEN call. For valid values, refer to IBM’s WebSphere MQ Application
Programming Reference.
If the repository does not contain an MQOPEN event and Script Create cannot find
queue name information, it generates an ObjectName_In and an ObjectName_Out field
containing a question mark ‘?’. Manually replace the question mark with the appropriate
object name to prevent the following playback error:
TCPSEVNT-0074E Replay=1 Invalid Script Parameter found data= ?
TCPPBUTL-0047E Invalid token found: MQOD_OBJECTNAME_IN ='?’
3-36
<MQ_PUT...> Tag
Puts a message on an open queue or distribution list.
CRNTLEN
The length of the actual message content. If you specified a truncation value on the
TRUELEN
The original length of the message as PUT to the queue. Corresponds to the
BufferLength value on the MQPUT call.
MQMD Options
See Table 3-1 on page 3-28 for a complete list of message descriptor fields.
MQPMO Options
See Table 3-1 on page 3-28 for a complete list of MQPUT message options.
For more information about the MQPUT call and its parameters, refer to IBM’s WebSphere
<MQ_PUT1...> Tag
Puts a single message on a queue, whether the queue is open or not.
CRNTLEN
The length of the actual message content. If you specified a truncation value on the
TRUELEN
The original length of the message as put to the queue. Corresponds to the
BufferLength value on the MQPUT1 call.
MQMD Options
See Table 3-1 on page 3-28 for a complete list of message descriptor fields.
MQOD Options
See Table 3-1 on page 3-28 for a complete list of MQPUT1 message options.
MQPMO Options
See Table 3-1 on page 3-28 for a complete list of MQPUT1 message options.
3-37
For more information about MQPUT1 calls and their parameters, refer to IBM’s WebSphere
<MQ_SET...> Tag
Changes the attributes of an object represented by a handle.
SELECTORS
Multi-keyword constants corresponding to the array of selectors.
SELECTORCOUNT
Number of attributes requested.
CHARATTRS
The buffer in which character attributes are returned.
CHARATTRLENGTH
The length (in bytes) of the CharAttrs parameter.
INTATTRS
An array of IntAttrCount integer attribute values.
INTATTRCOUNT
The number of elements in the IntAttrs array.
For more information about the MQSET call and its parameters, refer to IBM’s WebSphere
<TIME> Tag
Indicates the date and time of the event that follows the TIME tag. Depending on the
parameters specified on the playback statements, this tag can be used to control playback
timing.
The TIME value is relative to the system on which the scripts were created. It is not GMT.
The content of this tag is a time stamp with the format:
YYYY/MM/DD_HH:MM:SS.XXXXXX. For example:
<TIME>2006/01/30_13:02:42.246413
<VERSION> Tag
Identifies the version of the Hiperstation for WebSphere MQ script creation program that
created the script.
The VERSION tag appears only once in a script. The value after the VERSION tag is in the
form VV.RR.MM, for version, release, and modification level, respectively. For example:
3-38
<VERSION> 07.01.00
Notes:
1. Do not modify the version tag value. Doing so can cause unpredictable results during
playback.
2. The version number may be different than the product release number.
Edit a Script
Edit scripted activity to:
• Manipulate the way the scripts play back. For example, to stress test a function, edit
the script to isolate a single transaction, then play back several concurrent instances
repeatedly.
• Ensure successful playback. For example, if recording begins after a connection is
already in progress, the script may contain a partially recorded business transaction
that results in an application or playback error. Delete the unwanted activity from
the script.
• Alter information within the MQ data streams. For example, you have modified your
application to accept a longer product code. To test the application using a script
recorded before the modifications, edit the product code portion of the MQ_GET,
MQ_PUT, and MQ_PUT1 tag content.
Use ISPF Edit to edit your scripts. Insert the <REPLACE> tag to perform dynamic data
replacement during playback. For example, the script contains a series of transactions
preformed against a specific account. Providing the account number resides in the same
location in the MQ data streams, you can replace that account number in all of the
transactions by inserting one <REPLACE> tag in the appropriate location. Replace data in
a single MQ_GET, MQ_PUT, or MQ_PUT1 data stream or in a specified range of data
streams.
Add REXX logic to:
• Create dynamic scripts that facilitate data-driven testing or smart scripts that modify
application flow based on message content.
• Define custom MVS job step return codes for more definitive playback results.
Hiperstation for WebSphere MQ provides customized REXX variables that return
playback information. Incorporate the variables into your REXX routines. For example,
use the REXX variables that return the current playback count and repeat values to
control record substitution for data-driven testing.
This section of the manual details the elements necessary for basic script editing and
provides easy access to the Hiperstation for WebSphere MQ REXX variables.
For more advanced scripting concepts or a better understanding of REXX applications,
refer to the Hiperstation Scripting Reference. Additionally, consider reviewing “Replacing
Script Data Dynamically” on page 8-33. It provides a a comprehensive example that
includes the use of Hiperstation REXX variables and the <REPLACE> tag.
Notes:
1. Hiperstation for WebSphere MQ supports editing application data in the script or
detail file with File-AID/MVS. For more information, see “Editing MQ Message Data
with File-AID/MVS” on page 3-47.
2. Understanding the relationship between the information in the scripts and the
statements used to run playback can impact your editing decisions. For example,
scripts contain connection information that indicates the queue manager accessed by
each connection. Edit the script if you need to modify the queue manager on a
connection-by-connection basis. However, if you need to modify the queue manager
3-39
for all of the connections in the script, supply the QUEUE_MANAGER keyword on
the SCRIPT playback statement instead. Prior to editing your scripts, review the
information in Chapter 5, “Unattended Playback”.
Script Syntax Rules
Editing a script requires understanding script tags and syntax rules. If you are not
familiar with MQ script tags, see “Edit a Script” on page 3-38.
MQ script syntax rules:
• A script tag must be enclosed in angle brackets ‘<>’ and the tag name must be
adjacent the opening angle bracket ‘<‘. For example:
<TIME>
• Script tag parameters follow the tag name inside the angle brackets. The format of a
script tag parameter is parameter=value.
<MQ_OPEN CONNECTION_ID=6>
• A tag can have multiple parameters. Parameters on the same line must be separated
by one or more spaces. For example:
<MQ_OPEN CONNECTION ID=6 OBJECT_ID=2...
Parameters can appear on separate lines for easy reading. Each line must end with a
comma. For example:
<MQ_OPEN,
CONNECTION_ID=6,
OBJECT_ID=2,
• Script tag parameter values must be enclosed in single quotation marks if they need
to be interpreted as constants or if they contain characters other than: underscore(_),
uppercase A through Z, or 0 through 9. For example, the QMGR_NAME parameter
value is enclosed in single quotation marks because it must be interpreted as a
constant.
<MQ_CONNECT,
CONNECTION_ID = 1,
COMPCODE = 0,
REASON = 0,
QMGR_NAME = 'MMQM',
• If a parameter’s value spans multiple lines, each line must end with the REXX
concatenation character, ||, followed by a comma. For example,
CHAR_ATTRS = 'M530TOQM_TEST
'||,
**************************'||,
'
'**********************QT.M530TOQM_TEST
'||,
'
c2092.nl.compuware.com(30000)
'||,
'||,
'
'
'||,
'||,
'
'
'>940
• A script tag’s entire value must be on the same line as the closing bracket ‘>’. This is
especially important when editing CONTENT tags. If the value of the CONTENT tag
is longer than the LRECL of the script dataset, it must be separated into multiple
CONTENT records, each beginning with a 12-byte header that Hiperstation for
WebSphere MQ uses to reassemble the content at playback time. For detailed
information regarding the format of the 12-byte header, review “<CONTENT> Tag for
Inline Data” on page 3-30.
3-40
• Comment lines, used to provide detail or enhance formatting, must begin with an
asterisk and can appear anywhere in the script. For example, the following comment
lines provide spacing between blocks of event information and a description of the
next event in the script, which is a synthesized MQ_OPEN tag.
*
*
MQ_OPEN
*
*
* WARNING: MISSING DATA, SYNTHESIZED MQ_OPEN TAG
<TIME>2006/06/05_14:37:15.502234
<MQ_OPEN,
CONNECTION_ID = 4,
OBJECT_ID = 15,
• REXX clauses added to the script must precede the activity to which the logic applies.
They can be inserted between scripts tags, but not within a tag or the its value. For
example, insert the following do-loop and say statement before the first
MQ_CONNECT tag in the script and end the loop after the last MQ_DISCONNECT
tag.
do id# = 1 to 100
say ‘Starting connection # ‘id#
<MQ_CONNECT,
CONNECTION_ID=id#, ...,
>123
*
<TIME>2006/06/05_14:37:15.786640
<MQ_DISCONNECT,
CONNECTION_ID = 7,
COMPCODE = 0,
REASON
= 0>116
<MQ_DISCONNECT>
end
• A single REXX variable can be supplied as the value of a script tag parameter. For
example:
queue_manager='MMQG’,
<TIME>2006/06/05_14:38:13.963246
<MQ_CONNECT,
CONNECTION_ID = 8,
COMPCODE = 0,
REASON = 0,
QMGR_NAME = queue_manager,
SYSTEM_NAME = 'CW01',
JOBNAME = 'M210CHIN',
STIME = '2006/06/05_14:38:13.963246'>120
However, REXX variables cannot be supplied within the script tag’s value. That is,
they may not be the value or within the value following the tag’s closing angle
bracket ‘>’.
<REPLACE> Tag
The REPLACE tag replaces the information within the MQ data streams during playback.
Use this tag to supply new data, such as account numbers, user names, and so forth. For
advanced scripting concepts, such as data-driven testing, incorporate the REPLACE tag
into REXX logic that reads the replacement data from an external file, as described in
“Replacing Script Data Dynamically” on page 8-33.
The REPLACE tag can be applied to the CONTENT of a single MQ_GET, MQ_PUT, or
MQ_PUT1 tag or to a range of tags. If applied to a range, the REPLACE tag acts on the
CONTENT of all MQ_GET, MQ_PUT, and MQ_PUT1 tags within the range.
3-41
Insert the REPLACE tag before the MQ_GET, MQ_PUT, or MQ_PUT1 tag or group of tags
to which it applies. To establish a range, specify ALL on the TYPE parameter of the
REPLACE tag and insert another REPLACE tag at the end of the range. Specify DELETE on
the TYPE parameter of the closing REPLACE tag to terminate the action of the previous
REPLACE tag.
FIELD
Identifies where to begin replacing data within the subsequent CONTENT records
(offset) and what value to insert. Data replacement happens during playback
processing. The original value in the script or detail file is preserved.
The offset value is zero-based and should not include the 12-byte header at the
beginning of each CONTENT tag. For example,
<REPLACE FIELD=(0,'GET') LENGTH=3> replaces ‘XXP’ with ‘GET’ in the following
CONTENT record.
<CONTENT>....00000007XPPJOBM400...wæìÎUR÷...ö«.\.m÷G.......
4444CDDECDE60310FFFFFFFF0002000EDDDDCDFFF000A957EDE000C83E49EC
000C3653553E0241000000070A0210A77716244002076C86491308CA00B417
Specify one or more FIELD attributes on a given REPLACE tag. For example:
<REPLACE FIELD=(0,’CAT’) FIELD=(20,’DOG’)>
Note: Hiperstation for WebSphere MQ provides macros for easily determining offset
values. See “Offset and Length Determination Macros” on page 3-41.
TYPE
Indicates how to apply the data replacement.
– TYPE=ONE applies the data replacement to the next MQ_GET, MQ_PUT, or
MQ_PUT1. This is the default.
– TYPE=ALL applies the data replacement to all subsequent MQ_GETs, MQ_PUTs
and MQ_PUT1s. This is a global data replacement.
– TYPE=DELETE disables the global data replacement established by a previous
REPLACE tag with the TYPE=ALL parameter.
LENGTH
Sets the length of the replacement data stream. LENGTH=n, where n indicates the
number of bytes. If n is greater than the value defined on the FIELD parameter,
Hiperstation for WebSphere MQ pads the value with binary zeros (X'00'). If the
replacement value is shorter than the original message content, use the LENGTH
parameter to ensure the entire message is replaced. For example, if you are replacing
'ABC Corporation' with 'Smith Inc.' and you do not specify a length, the result of the
replacement is 'Smith Inc.ation'.
Note:
Hiperstation for WebSphere MQ provides macros for easily determining
length values. See “Offset and Length Determination Macros” on page 3-41.
Offset and Length Determination Macros
The <REPLACE> tag requires an offset value that indicates where to begin data
replacement. The offset value is zero-based and applies to the actual data stream. If a data
stream is longer than the LRECL of the script dataset, the data stream is broken into
3-42
multiple content records each beginning with the <CONTENT> tag and a 12-byte header.
For example:
000484
000485
000486
000487
000488
000489
000490
TRUELEN = 485>39
<CONTENT>
00000295GET /BonusPak2/db2/telco.htmls HTTP/1.1 Accept
<CONTENT>
00000296image/gif, image/x-xbitmap, image/jpeg, image/p
<CONTENT>
00000297jpeg, application/vnd.ms excel,application/vnd
<CONTENT>
00000298ms-powerpoint,application/msword, application/x
<CONTENT>
00000299-%hockwave-flash, */* Referer: http://cw01.comp
<CONTENT>
00000300uware.com/bp2atoc.html Accept-Language: en-us
The <CONTENT> tag and header should not be considered in the offset value. This can
make determining the offset somewhat difficult especially in multi-record content tags.
For example, the ‘G’ in ‘GET’ on line 485 is the first byte of application data and would
require an offset of 0 if replaced, while the ‘i’ in ‘image’ on line 486 is the 49th byte and
would require an offset of 48. Further, the REPLACE tag offers an optional length
parameter that indicates the number of bytes that the replacement data should occupy. It
is typically used when the replacement data is longer or shorter than the original data.
To ease offset and length determination, Hiperstation for WebSphere MQ provides the
following macros:
• LOCPOS — Displays the offset value based on the cursor’s position within a content
tag.
• BRULE — Displays a byte ruler for the selected content record.
• BRULES — Displays a byte ruler for all records in the selected content tag.
Note: Each time you execute a macro, you must type the macro name on the Command
line, then position the cursor and press Enter. To avoid having to repeatedly type
the macro name, you can assign a PF key. To assign a PF key, type KEYS on the
Command line of an ISPF Edit or View session. The ISPF Keylist Utility screen
appears. In the definition area next to the desired key, type a macro name. Refer
to the ISPF Keylist Utility Help to learn more about key mapping.
To use the offset and length determination macros:
1. Open the script or detail dataset with ISPF Edit.
2. Scroll through the script or detail data until the appropriate <CONTENT> record is in
view.
3. On the Command line, type of the macro name. If you assigned a PF key, skip this
step.
4. If using the LOCPOS macro, place the cursor on the first character of the data to be
replaced. If using either of the byte ruler macros, place the cursor anywhere in the
applicable CONTENT record.
5. Press Enter or the assigned PF key.
The LOCPOS macro displays the offset of the selected character in a pop-up window
located in the middle of the screen near the bottom (Figure 3-19).
3-43
Figure 3-19. LOCPOS Results
File Edit Edit_Settings Menu Utilities Compilers Test Help
------------------------------------------------------------------------------EDIT
USER005.MQ.SCRIPTS.NEW(SCRPT001) - 00.01
Columns 00001 00072
Command ===>
Scroll ===> PAGE
000099
MQMD_REPLYTOQ = 'CSQ4SAMP.B1.BA79A0D9B0C87080',
000100
MQMD_USERIDENTIFIER = 'USER005',
000101
MQMD_ACCOUNTINGTOKEN = ,
000102
'1A11E4E2C3E6E7D5F0F14BE3C3E6F0F0F4F2F679A0CADCE1C900010000000000'X,
000103
MQMD_PUTAPPLTYPE = CICS,
000104
MQMD_PUTAPPLNAME = 'H01AC054MVB1',
000105
MQMD_PUTDATE = '20031215',
000106
MQMD_PUTTIME = '19203907',
000107
MQPMO_OPTIONS = (DEFAULT_CONTEXT,NO_SYNCPOINT),
000108
MQPMO_RESOLVEDQNAME = 'CSQ4SAMP.B2.INQUIRY',
000109
MQPMO_RESOLVEDQMGRNAME = 'M520',
000110
CRNTLEN = 113,
000111
TRUELEN = 113>9
000112
<CONTENT>
00000001CSQ4BIIM
FIRST GALAC
000113
<CONTENT>
00000002TIC BANK
000114
<CONTENT>
00000003 7777777777011000
000115 *
+-------------+
000116 * MQ_GET *
| OFFSET = 43 |
000117 *
+-------------+
000118 <TIME>2003/12/15_15:20:39.213239
The BRULE macro displays a byte ruler above the selected content record (Figure 320). In the illustration, the offset of ‘B’ is 52, ‘A’ is 53, ‘N’ is 54, and so forth. Every
5th and 10th byte is indicated with a number on the ruler. When the offset value is
greater than 10, the number on the rules occupies two positions. In these cases, the
offset values apply to the character under the 0. For example, 50 appears over the
characters ‘IC’. The offset value of ‘I’ is 49 and ‘C’ is 50.
Figure 3-20. BRULE Results
------------------------------------------------------------------------------EDIT
Columns 00001 00072
Command ===>
Scroll ===> PAGE
000104
MQMD_PUTAPPLNAME = 'H01AC054MVB1',
000105
000106
000107
MQPMO_OPTIONS = (DEFAULT_CONTEXT,NO_SYNCPOINT),
000108
MQPMO_RESOLVEDQNAME = 'CSQ4SAMP.B2.INQUIRY',
000109
000110
CRNTLEN = 113,
000111
TRUELEN = 113>9
000112
<CONTENT>
00000001CSQ4BIIM
FIRST GALAC
======
DATA BELOW
48==>-50----5---60----5---70----5---80----5---90----5
000113
<CONTENT>
00000002TIC BANK
000114
<CONTENT>
00000003 7777777777011000
000115 *
The BRULES macro displays a byte rules above each record (line) of the selected
content tag (Figure 3-21).
3-44
Figure 3-21. BRULES Results
------------------------------------------------------------------------------EDIT
Columns 00001 00072
Command ===>
Scroll ===> PAGE
000109
000110
CRNTLEN = 113,
000111
TRUELEN = 113>9
======
DATA BELOW
0==>0----5---10----5---20----5---30----5---40----5-000112
<CONTENT>
00000001CSQ4BIIM
FIRST GALAC
======
DATA BELOW
48==>-50----5---60----5---70----5---80----5---90----5
000113
<CONTENT>
00000002TIC BANK
======
DATA BELOW
96==>--100----5---10-000114
<CONTENT>
00000003 7777777777011000
000115 *
Hiperstation for WebSphere MQ REXX Variables
The following predefined REXX variables return playback information. Incorporate these
variables into the REXX logic you add to your scripts to control the way they play back.
Note:
Understanding playback, especially the MQGROUP and SCRIPT statements is
integral to determining how to apply these variables. Additionally, do not forget
to set the REXXON and SET_REXX_STREAM_VARIABLES playback control
parameters to enable the use of these variables during playback. See “CONTROL
Statement” on page 5-3.
ACTUAL_COMPCODE
Returns the completion code (COMPCODE) of an MQ_PUT, MQ_PUT1, or MQ_GET
executed during playback. Place this variable after each script tag that executes a GET,
PUT, or PUT1 of interest. For example, to report the completion code for a particular GET
and PUT, incorporate this variable into REXX say statements placed after each of the
applicable script tags, as shown below:
<MQ_GET,
CONNECTION_ID = 2,
OBJECT_ID = 1,
COMPCODE = 0,
REASON = 0,
MQMD_VERSION = 1,
...>
say 'Comp code of GET = 'ACTUAL_COMPCODE'
<MQ_PUT
...>
say ‘Comp code of PUT = 'ACTUAL_COMPCODE'
EXPECTED_COMPCODE
Returns the completion code (COMPCODE) that was recorded in the script for an
MQ_PUT, MQ_PUT1, or MQ_GET executed during playback. Place this variable after each
script tag that executes a GET, PUT, or PUT1 of interest. For example, to see the actual
and expected completion codes for a particular GET, insert the following REXX say
statements after the MQ_GET tag that executes the call, as shown below:
<MQ_GET,
...>
say 'Comp code of GET = 'ACTUAL_COMPCODE'
say 'Expected comp code of GET = 'EXPECTED_COMPCODE'
3-45
ACTUAL_CORRELID
Returns the correlation ID (MQMD_CORRELID), in character format, from an MQ_PUT,
MQ_PUT1, or MQ_GET executed during playback. Place this variable after each script tag
that executes a GET, PUT, or PUT1 of interest. If the transaction does not complete
successfully, this variables returns ‘NULL’.
EXPECTED_CORRELID
Returns the correlation ID (MQMD_CORRELID) from the script, in character format, for
an MQ_PUT, MQ_PUT1, or MQ_GET executed during playback. Place this variable after
each script tag that executes a GET, PUT, or PUT1 of interest.
ACTUAL_MSG
Returns the content of the most recent message processed by Hiperstation for
WebSphere MQ. This variable’s value is similar to the MQMessageOutbound or
MQMessageInbound reporting fields, depending on whether an MQ_GET or MQ_PUT
was processed. See “Expanding Data During Playback” on page 8-38, for a detailed testing
example that uses this variable.
EXPECTED_MSG
Returns the content of an inbound MQ message that Hiperstation for WebSphere MQ is
expecting to receive. Normally, this is the content of an MQ_GET from your script.
However, if you reverse the direction of play back, it is the content from an MQ_PUT.
ACTUAL_MSGID
Returns the message ID (MQMD_MSGID) from the script, in character format, for an
MQPUT, MQPUT1, or MQGET executed during playback. Place this variable after each
script tag that executes a GET, PUT, or PUT1 of interest. If the transaction does not
complete successfully, this variables returns ‘NULL’.
EXPECTED_MSGID
Returns the message ID (MQMD_MSGID) from the script, in character format, for an
MQPUT, MQPUT1, or MQGET executed during playback. Place this variable after each
script tag that executes a GET, PUT, or PUT1 of interest.
ACTUAL_LENGTH
Returns the length of the most recent message processed by Hiperstation for
WebSphere MQ.
EXPECTED_LENGTH
Returns the length of an inbound MQ message that Hiperstation for WebSphere MQ
expects to receive.
ACTUAL_REASON
Returns the reason code (REASON) from an MQPUT, MQPUT1, or MQGET executed
during playback. Place this variable after each script tag that executes a GET, PUT, or
PUT1 of interest.
EXPECTED_REASON
Returns the reason code (REASON) from the script for an MQPUT, MQPUT1, or MQGET
executed during playback. Place this variable after each script tag that executes a GET,
PUT, or PUT1 of interest.
3-46
OBJECT_ID
Returns the current ID of the object (queue) associated with the activity that is playing
back. This variable’s value may be the same across multiple MQGROUPs, as it is pulled
from the script.
REPLAY_ID
Returns a sequential value for each instance of an MQGROUP replay. For example, an
MQGROUP statement with COUNT(2) REPEAT(3), replays two instances of a script
simultaneously, repeated three times, for a total of six unique replay IDs. Use REPLAY_ID
in volume testing to provide a unique message for each connection to your application.
For example, to test 1000 simultaneous customer requests accessing your application,
each with a different customer number and name:
1. Create an external file containing customer numbers and names with one customer
per line.
2. Add data replacement logic to your script, for example:
/* Access external file and parse customer info */
"EXECIO * DISKR CUSTFILE (STEM cust.FINIS"
parse var cust.REPLAY_ID 1 cust_nbr 11 cust_name
/* Replace content in script with info from file */
<REPLACE FIELD =(0,cust_nbr) FIELD =(10,cust_name)>
/* Send the message
*/
<MQ_PUT...
3. Set the count value in the MQGROUP statement to 1000, that is,
MQGROUP COUNT(1000). This generates 1000 unique customer requests by starting
1000 simultaneous sessions, all with unique REPLAY_IDs that correspond to the
customer information from your external file.
PUT_QUEUE_NAME
Returns the name of the queue most recently used for an MQ_PUT.
GET_QUEUE_NAME
Returns the name of the queue most recently used for an MQ_GET.
MQGROUP_COUNT_NBR
Returns the COUNT value of the current MQGROUP replay. For example, if the
MQGROUP statement specifies COUNT(3), the first instance returns COUNT = 1; the
second, COUNT = 2; the third, COUNT = 3. This value is set when the MQGROUP begins
execution.
Use this variable and MQGROUP_REPEAT_NBR to extend testing capability. See
“Replacing Data During Repeated Concurrent Playback” on page 8-47, for a detailed
example.
MQGROUP_REPEAT_NBR
Returns the REPEAT value of the MQGROUP replay. This value is set when a group begins
execution. Use MQGROUP_COUNT_NBR and MQGROUP_REPEAT_NBR to replace script
data on specific COUNTS and REPEATS. For example, to test three products (A, B, C) with
two accounts (1, 2).
Value
Repeat 1
All COUNTS execute simultaneously
COUNT 1
COUNT 2
COUNT 3
Product A, Account 1
Product B, Account 1
Product C, Account 1
Value
3-47
All COUNTS execute simultaneously
Repeat 2
(begins after Repeat 1
completes)
COUNT 1
COUNT 2
COUNT 3
Product A, Account 2
Product B, Account 2
Product C, Account 2
1. Create an external file for each parameter you want to replace. Each file should
contain one parameter value per line.
2. Add data replacement logic to your script, for example,
/* Access external files */
"EXECIO * DISKR PRODFILE (STEM product.FINIS"
"EXECIO * DISKR ACCTFILE (STEM account.FINIS"
product_nbr = product.MQGROUP_COUNT_NBR
account_nbr = account.MQGROUP_REPEAT_NBR
/* Replace content in script with info from file */
<REPLACE FIELD =(5,account_nbr) FIELD =(32,product_nbr)>
/* Send the message
*/
<MQ_PUT...
3. Set the count and repeat values in the MQGROUP statement, for example,
MQGROUP COUNT(3),REPEAT(2). This generates six unique customer requests,
each with a unique combination of product and account parameter values.
See “Replacing Data During Repeated Concurrent Playback” on page 8-47, for a more
detailed example.
SCRIPT_REPEAT_NBR
Returns the REPEAT value of the current script playback. This value is set to one when
the script begins execution, and increments with every repeat.
Editing MQ Message Data with File-AID/MVS
Review and edit MQ message data (data tagged <CONTENT> in the script) with:
• ISPF Edit or View.
• File-AID/MVS version 08.00, providing you are licensed.
Invoke File-AID/MVS from an ISPF Edit or View session to review and edit MQ message
data in a formatted context. For example, if the message data contains a numeric string
that represents a customer ID and account number, identifying the account number
portion of the string may be difficult in ISPF Edit and therefore editing, more error prone.
Use the MAPD command to invoke File-AID/MVS Edit and apply a record layout that
presents the information with labels you define, such as Customer ID and Account
Number. Edit information as necessary and exit File-AID/MVS to carry changes over to
the ISPF session. End the session to apply changes to the script/detail dataset. This
process is referred to as mapping message data into application data structures.
Note:
This feature supports a maximum message length of 32KB.
If MQ message data is stored in the script, map one message at a time. If it is stored in a
separate dataset, map individual messages or all messages in the dataset at once. Refer to
“Define Detail Data Storage and Output Requirements” on page 3-15.
Assign a PF Key to MAPD
Simplify editing individual messages by assigning a PF key to execute the MAPD
command. Access the ISPF Keylist Utility by typing KEYS on the Command line of an
3-48
ISPF Edit or View session. In the definition area next to the desired key, enter an
exclamation point (!) followed by MAPD (!MAPD). Refer to the ISPF Keylist Utility Help
to learn more about key mapping.
Note: The command prefix character may be different depending on the code page your
terminal used. The command prefix is the character that maps to hexadecimal
value X‘5A’. In the United States, the exclamation point is typically the correct
character. To determine the appropriate character, either refer to the code page
relevant to your terminal or use the HEX editing features of an ISPF Edit session.
Open an edit session, invoke HEX editing, type 5A in the edit area, and disable
HEX editing.
Map an Individual Message
Make sure the Maintain PDS Statistics option in File-AID/MVS is set to ADD before you
begin mapping. Refer to your File-AID/MVS manual or your system programmer for help.
To map individual messages:
1. Open the script or detail dataset in ISPF Edit or View.
Note:
ISPF View prompts for confirmation prior to writing changes back to the
script or detail data file.
2. Use standard ISPF commands to locate the message to map.
Note:
To view only the message data in a script file, type X ALL on the Command
line and press Enter; then type F <CONTENT> ALL and press Enter.
3. If you have not assigned a PF key for the MAPD command, place the cursor on the
Command line and enter an exclamation point (!) following by MAPD.
Note:
The command prefix (!) is required only for the first mapping in the session.
It is an ISPF standard for invoking a macro. Also, the command prefix may be
different depending on the code page your terminal used. In the United
States, the exclamation point is typically the correct character. See the note
in the “Assign a PF Key to MAPD” on page 3-47 discussion for more
information.
4. Position the cursor anywhere right of the line command area on the record you wish
to map and press the assigned PF key. If you did not assign a PF key, be sure MAPD is
on the Command line and the cursor is correctly positioned, then press Enter.
5. MAPD invokes File-AID/MVS. Refer to the File-AID/MVS documentation for help
with the screens it presents. With File-AID/MVS, you can apply a record layout,
generate XML from mapped data, XREF information, and filter information to see
only the activity needed to review or to edit.
Note:
MAPD creates a temporary dataset, with a 4-node naming convention
(USERID.MAPDTEMP.DATE.TIME), to pass mapped messages to
File-AID/MVS. File-AID/MVS writes changes to the temporary dataset. When
you leave File-AID/MVS, it passes your changes back to ISPF and deletes the
temporary dataset. Upon exiting ISPF, MAPD updates the script/detail
dataset.
If for some reason, the File-AID/MVS session is lost during edit, delete the
temporary dataset manually.
Additionally, you can use the temporary dataset as input to an XML
generation job. After you submit the job, exit the screen File-AID presents to
ensure the temporary dataset is available for use. Do not exit File-AID until
the job is complete.
3-49
Edit message content as necessary. Make sure Caps Lock is off when you enter
File-AID/MVS. If you edit a line and Caps Lock is on, File-AID coverts the entire line
to uppercase. Press Cancel to cancel your work and return to ISPF or End to exit
File-AID/MVS and transfer any changes to ISPF.
6. To exit the ISPF session without saving changes, press Cancel. To save the work in:
– An Edit session, press End.
– A View session, use the Create or Replace commands. Then press End to
terminate the session.
Map an Entire Data File
Make sure the Maintain PDS Statistics option in File-AID/MVS is set to ADD before you
begin mapping. Refer to your File-AID/MVS manual or your system programmer for help.
To map an entire data file:
1. Open the detail dataset in ISPF Edit or View.
Note:
ISPF View prompts for confirmation prior to writing changes back to the
script or detail data file.
2. Place your cursor on the Command line and press the PF key assigned to the MAPD
command. If you have not assigned a PF Key, place your cursor on the Command line
and type an exclamation point (!) followed by MAPD, then press Enter.
Note:
The command prefix (!) is required only for the first mapping in the session.
It is an ISPF standard for invoking a macro. Also, the command prefix may be
different depending on the code page your terminal used. In the United
States, the exclamation point is typically the correct character. See the note
in the “Assign a PF Key to MAPD” on page 3-47 discussion for more
information.
3. MAPD invokes File-AID/MVS. Refer to the File-AID/MVS documentation for help
with the screens it presents. With File-AID/MVS, you can apply a record layout,
generate XML from mapped data, XREF information, and filter information to see
only the activity needed to review or edit.
Note:
MAPD creates a temporary dataset, with a 4-node naming convention
(USERID.MAPDTEMP.DATE.TIME), to pass mapped messages to
File-AID/MVS. File-AID/MVS writes changes to the temporary dataset. When
you leave File-AID/MVS, it passes your changes back to ISPF and deletes the
temporary dataset. Upon exiting ISPF, MAPD updates the script/detail
dataset.
If for some reason, the File-AID/MVS session is lost during edit, delete the
temporary dataset manually.
Additionally, you can use the temporary dataset as input to an XML
generation job. After you submit the job, exit the screen File-AID presents to
ensure the temporary dataset is available for use. Do not exit File-AID until
the job is complete.
Edit message content as necessary. Make sure Caps Lock is off when you enter
File-AID/MVS. If you edit a line and Caps Lock is on, File-AID coverts the entire line
to uppercase. Press Cancel to cancel your work and return to ISPF or End to exit
File-AID/MVS and transfer any changes to ISPF.
CAUTION:
Deleting and inserting messages may cause unsynchronized playback.
3-50
The script contains a link to each message in the detail file that supports playing
back the script. If the detail file contains fewer or more messages than the script
calls, playback will become unsynchronized. When you exit File-AID/MVS,
Hiperstation for WebSphere MQ warns you if the message count has been altered.
If you replace messages by deleting and inserting, be sure the replacement messages
contain the same type of data as the original messages.
4. To exit the ISPF session without saving changes, press Cancel. To save your work in:
– An Edit session, press End.
– A View session, use the Create or Replace commands. Then press End to
terminate the session.
Access MAPD Help Panels
Access MAPD help panels, by typing MAPD space HELP or MAPD space question mark (?)
on the Command line in the ISPF Edit or View session and pressing Enter.
Troubleshoot Message Mapping
MAPD presents information, error, and warning messages in the ISPF session. Depending
on your ISPF settings, message content either appears on the first line of the display or in
a pop-up window. Most message are fairly intuitive. However, some may be more difficult
to troubleshoot. This section explains each message and provides the appropriate action
to take, if any.
Script Dataset Messages
'CURSOR NOT ON <CONTENT> - SEE USER’S GUIDE'
Explanation:
The dataset containing the message you are mapping is not a script dataset.
User Response: Press Enter to clear the message and Cancel to exit the ISPF session. Locate
the appropriate dataset and try again.
'DATA CHANGES DETECTED - EXTRA RECORD(S) IGNORED'
Explanation: You added one or more records while editing in File-AID/MVS. MAPD sent a
single message, so it expects to receive a single record.
System Action: MAPD ignores the additional records when transferring changes back to ISPF.
However, ISPF will reflect changes, if any, made to the originally mapped message.
'INVALID CONTENT LENGTH - SEE USER'SGUIDE'
Explanation:
While editing a script dataset the message length attribute byte was modified.
System Action: MAPD will not transfer data to File-AID/MVS if the message length does not
match the value of the length attribute byte.
User Response: Press Enter to clear the message. If editing was effected in the current ISPF
session, press cancel to exit the session without saving changes and try again.
'SCRIPT & DETAIL MUST BE COMBINED - SEE USER’S GUIDE'
Explanation: You are attempting to map from a script dataset that is stored separately from
the detail dataset (message data). It contains links to the message data and the first part of
each message for identification purposes. Refer to “Define Detail Data Storage and Output
Requirements” on page 3-15.
User Response: Press Cancel to exit the ISPF session. Locate the corresponding detail dataset
and map messages from there.
3-51
Detail Dataset Messages
'CURSOR NOT ON DETAIL RECORD' - SEE USER’S GUIDE
Explanation: You are either attempting to map from a dataset that is not a detail dataset or
you inadvertently altered a detail data sequence number.
User Response: Press Enter to clear the message. Then make sure you are in a detail file.
If you are in a detail file and inadvertently alter a sequence number in the current ISPF session,
cancel without saving your work and start over. If the sequence number was altered in another
ISPF session and saved, then regenerate the script and detail.
'LINE(S) DELETED - DETAIL OUT OF SYNC'
Explanation: While editing a detail dataset in File-AID/MVS, you deleted a record, which
causes an unsynchronized playback.
User Response:
dataset.
Press Cancel to exit the ISPF session without saving changes to the detail
'LINE(S) INSERTED - DETAIL OUT OF SYNC'
Explanation: While editing a detail dataset in File-AID/MVS, you inserted a record, which
causes an unsynchronized playback
User Response:
dataset.
Press Cancel to exit the ISPF session without saving changes to the detail
'MESSAGE DATA SPANS MULTIPLE LINES - SEE USER'S GUIDE '
Explanation: When the script was created, if the length of the MQ message data is longer
than the detail dataset’s logical record length (LRECL), the message spans more than one line.
This message appears when you try to map an entire file containing messages that span more
than one line.
User Response: Press Enter to clear the message. The cursor will position to the first
offending message. Map messages individually or regenerate the script and detail with an
LRECL equal to or greater than the maximum message length.
General Information and Error Messages
'32K MAXIMUM LRECL EXCEEDED'
Explanation: You are attempting to map a file containing messages larger than 32KB. The
maximum record length supported by MAPD is 32KB.
'COMMAND NOT FOUND'
Explanation: The ISPF Edit Macro invocation character is missing or incorrect. ISPF requires
the invocation character for the first use of the macro in a given session.
User Response: Prefix the MAPD command with the appropriate macro invocation character.
This is the character that maps to hexadecimal value X‘5A’. For devices using the EBCDIC
Code Page 037, the prefix character is an exclamation point (!).
'DATA CHANGES DETECTED'
Explanation:
This message informs you that data has been changed.
User Response: If you did not intend to change data, press Enter to clear the message and
Cancel to exit the ISPF session without saving the changes.
'INVALID PARAMETER'
Explanation: On the Command line, MAPD is followed by text that is not recognized as a
valid parameter.
User Response: Press Enter to clear the message. Remove characters following the MAPD
command and press Enter to resume work. Note: HELP or ‘?’ are the only valid MAPD
parameters.
'NO CHANGES DETECTED'
Explanation:
This message informs you that data has not been changed.
3-52
User Response:
Press Enter to clear the message and return to ISPF.
'NO DATA RETURNED FROM FILE-AID'
Explanation: You deleted the message in File-AID/MVS. File-AID/MVS had no data to return.
System Action:
No changes are made to the MQ message data.
User Response:
Press Enter to clear the message and return to the ISPF session.
4-1
Chapter 4.
Interactive Playback
Chap 4
Introducing Interactive Playback
Use interactive playback to:
• Play back scripts — execute the MQ API commands found in the script.
• Analyze scripts — process the script without executing the MQ API commands to
report information on the script’s contents.
In order to play back a Hiperstation for WebSphere MQ script, you must have created an
MQ script using the Create Scripts panels, (See Chapter 3, “Scripts and Subset
Repositories” for information on how to create a script.) The concept behind playback is
to recreate the traffic you captured to your script using the Global Record tool. Entering
information on these playback screens will generate batch JCL that can either be saved or
submitted for execution.
1. On the Hiperstation for WebSphere MQ Main Menu (Figure 4-1), select option 3
Playback MQ Scripts.
----------------Option ===>
-----------------
1
2
3
4
5
6
Monitor MQ Requests
Create MQ Scripts
Playback MQ Scripts
MQ Archive Requests
The WebSphere MQ Playback - Selection screen appears (Figure 4-2).
Figure 4-2. WebSphere MQ Playback - Selection Screen
--------------------- WebSphere MQ Playback - Selection
Command ===>
---------- Row 1 of 5
Primary commands:
C)reate Playback, G)enerate Playback from Script Log
Line commands...:
S)elect, P)lay or D)elete
S
-
Name
Playback Description
Date
-------- ------------------------------------------------------ ---------LFOF
03/29/07
LONG100
03/29/07
SFSFSF
03/29/07
TEST2
03/29/07
TEST88
03/29/07
******************************* Bottom of data ********************************
2. Select what you want to do:
4-2
– Create a new Playback by filling in the relevant information on the screens that
follow (see “Creating a New Interactive Playback” on page 4-2).
– Generate a Playback from a log dataset that was created in the script create job
(see “Generating a Playback from a Script Log” on page 4-4). The script dataset
and names will be extracted from the log allowing a playback to be instantly
created for a particular log.
– Play back a previously saved script (see “Submitting Your Playback for Execution”
on page 4-12).
– Delete a previously saved playback (see “Deleting a Playback” on page 4-14).
– Select a previously saved Playback to review (“Selecting a Previously Saved
Playback to Review” on page 4-14).
Creating a New Interactive Playback
1. On the WebSphere MQ Playback - Selection screen, type C (create) on the command
line and press Enter. The WebSphere MQ Playback - Datasets screen appears (Figure 43).
Figure 4-3. WebSphere MQ Playback - Datasets Screen
---------------------- WebSphere MQ Playback - Datasets
Command ===>
---------------------
Script Dataset:
Project . . . PLAYBAK
Group . . . . QA
Type . . . . #0000001
Other Partitioned Dataset:
Dataset Name. . . .
Define more than one Script Dataset(/)
Specify locations of playback outputs
Reporting Database(optional)
Generate Reporting Job ==>
Dataset Name. . . . ‘USERID.REPORT.DB’
Playback Error Log(if not SYSOUT=*):
Dataset Name. . . . ‘USERID.PLAYBACK.LOG
Press ENTER to continue,
END to cancel setup.
2. Enter the Script Dataset name of the script you want to play back. If your dataset
name does not conform to ISPF naming standards, enter the dataset name, in single
quotes, in the Other Partitioned Dataset field. Either Script Dataset or Other
Partitioned Dataset is a required field.
a. If you want to access multiple script datasets, enter a slash (/) in the Define more
than one Script Dataset field and press Enter. The WebSphere MQ Multiple
Script Dataset screen will appear (Figure 4-4).
4-3
Figure 4-4. WebSphere MQ Script Dataset List Screen
MQSFEDL --------------- WebSphere MQ Script Dataset List ---------------------Command ===>
Please supply the dataset(s) containing the scripts
to be used in this playback.
Additional Script Dataset Names:
Enter End to return to the previous menu.
You can enter up to six script dataset names. If the first character is a single quote
(‘), a fully qualified dataset name is expected. If the first character is not a single
quote, then the user ID is attached as a prefix or high-level qualifier. After you
enter all of the desired dataset names, press Enter to return to the WebSphere MQ
Playback - Datasets screen. Continue with step 3.
b. If you will be playing back a single script, continue with step 3.
3. To report on the playback, enter a name for the Reporting Database. Data from the
playback will be collected to this database and used in a future reporting job. This
field is required only if you selected the Generate Reporting Job field. Selecting
Generate Reporting Job provides reporting panels after the playback panels are
completed.
4. The playback error log is a report that describes any errors that occurred during
playback. If you leave this field blank, the report will go to SYSOUT=*. You can enter
a dataset name or an hfs path to specify an alternate location.
5. Press Enter to continue. The member list screen will appear (Figure 4-5).
Figure 4-5. WebSphere MQ Playback - Script Member List Screen
MEMBER LIST -- USER2312.MQ.SCRIPT ------------------------- ROW 00001 OF 00002
COMMAND ===>
SCROLL ===> PAGE
END
CANcel
End and process selection
End without processing
Line Cmds:
Name
LOG00000
SCR00000
**End**
S Select member
Prompt
Size
23
1508
B Browse member
Created
2007/07/27
2007/07/27
Changed
2007/07/27 16:10:00
2007/07/27 16:10:00
ID
USER2312
USER2312
6. Enter the END command to process your selection. The WebSphere MQ Playback Setup screen appears (Figure 4-6).
4-4
Figure 4-6. WebSphere MQ Playback - Setup Screen
------------------- WebSphere MQ Playback - Setup
Command ===>
--------- Row 1 to 2 of 2
Scroll ===> PAGE
Enter script, and modify desired options using /.
Type OK and press ENTER when ready.
Note: Use multiple MQGroups to test parallel connections to your application.
Scripts under each MQGroup will run sequentially.
Environment Options(apply to all MQGroups except when overridden)
MQGroup and script line commands are: (D)elete,(R)epeat,(A)dd,(/)Options
S MQGroup
** *******
1
2
S Script
** ********
SCR00000
SCR00001
7. Enter the name of the script you want to play back. You must know the script name
and enter it in the Script field, and it must be a script within the dataset that you
named on the Websphere MQ Playback - Datasets screen.
8. If you do not need to change any options, type OK on the Command line and
continue with the next step.
Notes:
1. To explain the relationship between an MQGroup and a Script, an MQGroup
represents a single connection to your application. When there are multiple
MQGroups in a playback, they run in parallel to each other, unless the
MQGroup start time is modified in the environment options. Within an
MQGroup, there are one or more scripts that run sequentially in the order
they appear.
2. You can change Environment, MQGroup, and Script options. See “Changing
Playback Options” on page 4-5 for complete information. Then continue
with the next step.
3. Lines commands can be applied to either the MQGroup or the Script. The
Add, Repeat, and Delete line commands will add, repeat, or delete an
MQGroup. When applied to a script, they will add, repeat, or delete a script
from that MQGroup. When deleting, keep in mind that at least one script
and MQGroup are required for a playback.
Generating a Playback from a Script Log
The Generate command allows you to create a playback from a log dataset that was
created in a script create job. The script dataset and names will be extracted from the log
allowing a playback to be instantly created for a particular log.
1. On the WebSphere MQ Playback - Selection screen, type G (generate) on the
command line and press Enter. The WebSphere MQ Playback - Log File screen appears
(Figure 4-7).
4-5
Figure 4-7. WebSphere MQ Playback - Log File Screen
---------------------- WebSphere MQ Playback - Log File --------------------Command ===>
Enter log file member to generate playback:
Log Dataset:
Project . . .
Group . . . .
Type . . . .
Member . . .
Dataset Name. . . .
Press ENTER to continue,
END to cancel setup.
2. Specify the log file you wish to use for playback. If you did not enter a member name
when you specified the log dataset, a list of members will appear allowing you to
select the desired member.
3. Type S next to the desired member and press Enter. The WebSphere MQ Playback Datasets screen appears. If your dataset name does not conform to ISPF naming
standards, the name including the member name must be entered in the Other
Partitioned Dataset Name field.
The remainder of the steps are the same as those you performed in “Creating a New
Interactive Playback”. Continue with step 2 on page 4-2.
Changing Playback Options
Environment Options
Environment options are applied to the entire playback with the exception of certain
parameters that can be overridden on the MQGROUP or SCRIPT level. The current
settings for the options are displayed next to each option category.
1. You can access the Environment Options screen (Figure 4-8), by typing a slash next
to the Environment Options field on the WebSphere MQ Playback - Setup screen
Figure 4-8. Environment Options Screen
----------------------------- Environment Options ----------------------------Command ===>
Select the type of options to view/modify using
/ .
Processing Options:
Rexx Enabled, Play transactions online
Internal Hiperstation REXX variables OFF
Timing Options:
Play at Full Speed,Groups start simultaneously,
Wait 15 seconds for I/O to complete
Websphere MQ Options:
Use Scripted QMGR
Use Scripted PUT queue
Enter END command to return to the previous panel
4-6
This screen allows you to view or modify processing, timing, and WebSphere MQ
options.
2. Type a slash (/) next to the Processing Options field and press Enter. The
Environment Processing Options screen appears (Figure 4-9).
Figure 4-9. Environment Processing Options Screen
------------------------ Environment Processing Options ----------------------Command ===>
Review current option settings and modify if required:
Enable REXX to be used in MQ scripts? ==> /
Use internal Rexx Stream Variables?
==>
(populated dynamically during playback)
Rexx Log Dataset name
Live I/O during playback
==> /
When MessageSets are created for reporting, relate messages by:
Correlation Id ==> /
Message ID
==>
Press ENTER
to continue, END
to exit
The options on this panel correspond to keywords that are placed in control cards for
the playback JCL.
– Enable REXX enables REXX to be used in scripts. The keyword is REXXON.
– Internal REXX stream variables enables the use of predefined REXX variables
during playback. The variables return information about the playback and
incorporate them into REXX logic that you add to your scripts to control the way
the scripts play back. The keyword is SET REXX STREAM VARIABLES.
– Enter the REXX Log Dataset name.
– Live I/O permits Hiperstation to play back scripts without performing any I/O
allowing you to generate reports for analyzing script content. The keyword is
OFFLINE.
– When Message Sets are created for reporting, relate messages by:
• Correlation ID: Creates request/reply message sets. This is the default.
• Message ID: Select this option when you want to track a particular message
ID throughout your application into a message set.
After making your changes, enter END to return to the previous screen.
3. Type a slash (/) next to the Timing Options field and press Enter. The Environment
Timing Options screen appears (Figure 4-10).
4-7
Figure 4-10. Environment Timing Options Screen
-------------------------- Environment Timing Options ------------------------Command ===>
Use start times to control dispatching of each MQGROUP?
(start times will be displayed when option selected)
==>
NUmber of seconds to wait for I/O to complete before timing out ==>
Select an
1 1 Play
2 Play
3 Play
15
option for playback think time:
at full speed
at think time recorded on script
at user specified think time
If you have selected options 2 or 3, you may alter the rate of the playback
by altering the Think Time (For option 3 only) or the percentage.
User Think Time (HH:MM:SS) . .
Percentage . . . . . . . . . . 100
Press ENTER
to continue, END
to exit
4. Use start times controls the playback initiation time for each MQGroup statement
supplied in the job. If USESTIME is specified, Hiperstation for WebSphere MQ
initiates playback of each MQGroup relative to the start time values supplied in the
MQGroup statement. When this option is selected, Start Time for each MQGroup is
displayed on the main setup panel. Enter a slash (/) to select this option.
5. Enter a Number of seconds to wait for I/O completion before timing out.
6. Select an option for playback think time:
– 1. Play back at full speed (no think time).
– 2. Play at think time recorded in the script.
– 3. Play at user-specified think time.
7. If you selected option 2 or 3, you can change the User Think Time and/or
Percentage if desired. User think time sets the amount of time to wait after receiving
a server message before sending the next client message. Seconds is the only required
value. Percentage is the percentage of think time to use for playback. With Option 2,
it is the think time recorded in the script. With Option 3, it is the user-specified
think time.
8. Press Enter to continue and return to the Environment Options screen.
9. Type a slash (/) next to the WebSphere MQ Options field and press Enter. The
Environment Websphere MQ Options screen appears (Figure 4-11).
4-8
Figure 4-11. WebSphere MQ Options Screen
----------------------- Environment WebSphere MQ Options ---------------------Command ===>
Enter QMGR/Queue Names in the fields you would like to override:
If you would like to connect to a Queue Manager that is not in your script,
enter new default Queue Manager Name
==>
Send all MQPUTs executed during playback to following queue:
Send all MQGETs executed during playback to following queue:
For all MQPUTs, set the REPLY TO QUEUE field to :
For all MQPUTs, set the REPLY TO QMGR field to ==>
Press ENTER to continue, END to exit
If you do not specify values for any of these fields, Playback uses the attributes from
the script. However, if your testing calls for playing back the script using different
queues or queue managers, you can specify those choices here.
Note:
For the following fields, the queue can be either a 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.
10. To connect to a Queue Manager that is not in your script, enter a new Queue
Manager Name to override the attributes in the script.
11. In the MQPUT field, specify the default output queue for your playback.
12. In the MQGET field, specify the default input queue for your playback.
13. Specify the REPLY TO QUEUE and REPLY TO QMGR fields for all MQPUTs to specify
where reply messages will go.
MQ Group Options
1. Type a slash (/) next to the desired MQGroup and press Enter. The MQGROUP
Options screen appears (Figure 4-12).
Figure 4-12. MQGROUP Options Screen
----------------------------- MQGROUP
Command ===>
1
Options -----------------------------
Select the type of options to view/modify using / . To copy options to
all MQGroups in playback, type save all from any MQGroup options panel.
Processing Options:
Repeat(1),Count(1),
Play as recorded
Timing Options:
No start delay
Use Scripted QMGR
4-9
This screen allows you to view or modify processing, timing, and WebSphere MQ
options for the selected MQGroup.
2. Type a slash (/) next to the Processing Options field and press Enter. The MQGroup
Processing Options screen appears (Figure 4-13).
Figure 4-13. MQGROUP Processing Options Screen
------------------------ MQGroup
Command ===>
1
Processing Options -----------------------
Number of Repeats
==>
1
Number of instances of this MQGroup ==>
1
Reverse Direction of Transactions on:
Connection(s)
(* for all,or list)
Only on Queue Name
Defaults for reversed transactions:
Send all PUTS to
Send all GETS to
Skip execution of :
Connection(s)
Jobname(s)
Press ENTER to continue, END
(list)
(list)
to exit
the playback JCL.
3. Enter the number of times to repeat playback of scripts in the MQGroup and the
number of instances of this MQGroup.
4. Reverse Direction of Transactions causes WebSphere MQ playback to act as though
it is receiving the data generated from the application. This is useful when a script is
created based on queue activity requested by a server, such as a CICS region, and you
want to test the server application using that script. When an MQGet is encountered
in the script, an MQput is executed, and when an MQPUT is encountered, an MQGET
is executed. Make your selection.
– Connections — Specify an * to reverse all transactions in the script, or list the
connections to reverse (for example, 1,2,5).
– Only on Queue Name — Specify a specific queue to reverse transactions.
– Default Queue Names — For reversed transactions, use these queues as respective
defaults.
5. Specify any connections or jobnames for which you want to skip execution.
6. Press Enter to continue and return to the MQGroup Options screen.
7. Type a slash (/) next to the Timing Options field and press Enter. The MQGroup
Timing Options screen appears (Figure 4-14).
4-10
Figure 4-14. MQGROUP Timing Options Screen
-------------------------- MQGroup
Command ===>
1
Timing Options -------------------------
Number of seconds to delay start of this MQGroup ==>
Press ENTER
to continue, END
0
to exit
8. Enter the number of seconds that you want playback to wait between the start of an
MQGROUP and the commencement of playback. Use STARTDLY to stagger the start
of playback using multiple MQGROUP statements.
9. Type a slash (/) next to the WebSphere MQ Options field and press Enter. The
MQGroup WebSphere MQ Options screen appears (Figure 4-15).
Figure 4-15. MQGROUP WebSphere MQ Options Screen
----------------------- MQGroup
Command ===>
1 WebSphere MQ Options ----------------------
==>
to exit
If you do not specify values for any of these fields, Playback uses the attributes from
the script. However, if your testing calls for playing back the script using different
queues or queue managers, you can specify those choices here.
Note:
For the following fields, the queue can be either a 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.
10. To connect to a Queue Manager that is not in your script, enter a new Queue
Manager Name to override the attributes in the script.
11. In the MQPUT field, specify the default output queue for your playback.
12. In the MQGET field, specify the default input queue for your playback.
13. Specify the REPLY TO QUEUE and REPLY TO QMGR fields for all MQPUTs to specify
where reply messages will go.
4-11
Script Options
1. Type a slash (/) next to the desired Script and press Enter. The Script Options screen
appears (Figure 4-16).
Figure 4-16. Script Options Screen
--------------------Script
Command ===>
SCR00000
Group
1
Options --------------------
Select the type of options to view/modify using / . To copy options to
all scripts in playback, type save all from any Script options panel.
Processing Options:
Repeat(1), Play as recorded
Use Scripted QMGR
On this screen, you can choose to modify Processing and WebSphere MQ options for
the selected script.
2. Type a slash (/) next to the Processing Options field and press Enter. The Script
Processing Options screen appears (Figure 4-17).
Figure 4-17. Script Processing Options Screen
---------------------- Script SCR00000 Processing Options --------------------Command ===>
Number of Repeats
==>
1
Reverse Direction of Transactions on:
Connection(s)
(* for all,or list)
Only on Queue Name
Defaults for reversed transactions:
Send all PUTS to
Send all GETS to
to exit
the playback JCL.
3. Enter the number of times to repeat playback of scripts in the MQGroup and the
number of instances of this MQGroup.
4. Reverse Direction of Transactions causes WebSphere MQ playback to act as though
it is receiving the data generated from the application. This is useful when a script is
created based on queue activity requested by a server, such as a CICS region, and you
want to test the server application using that script. When an MQGet is encountered
in the script, an MQput is executed, and when an MQPUT is encountered, an MQGET
is executed. Make your selection.
– Connections — Specify an * to reverse all transactions in the script, or list the
connections to reverse (for example, 1,2,5).
4-12
– Only on Queue Name — Specify a specific queue to reverse transactions.
– Default for reversed transactions, specify queues as respective defaults for PUTS
and GETS.
5. Press Enter to continue and return to the Script Options screen for the selected
MQGroup.
6. Type a slash (/) next to the WebSphere MQ Options field and press Enter. The Script
WebSphere MQ Options screen appears (Figure 4-18).
Figure 4-18. Script WebSphere MQ Options Screen
--------------------- Script SCR00000 WebSphere MQ Options -------------------Command ===>
==>
to exit
7. Specify where you want MQPUTs and MQGETs that are executed during playback to
be sent.
8. Set the REPLY TO QUEUE and REPLY TO QMGR fields.
9. Press Enter to continue and return to the Script Options screen for the selected
MQGroup.
10. Enter END to return to the Websphere MQ Playback - Setup screen.
11. Type OK on the command line and press Enter. The Websphere MQ Playback Submit screen appears.
12. Continue with the next section, “Submitting Your Playback for Execution” to submit
your playback.
Submitting Your Playback for Execution
After creating your playback script, the WebSphere MQ Playback - Submit screen appears
(Figure 4-19).
4-13
Figure 4-19. WebSphere MQ Playback - Submit Screen
------------------ WebSphere MQ Playback- Submit
Command ===>
-----------------------------
Select a processing option, or type SAVE on the command line to save
playback JCL to a dataset.
Select an option:
1. Submit batch job
2. Edit batch job
3. Save playback
X. Exit
===> //XXXXXXXX JOB ('OVPBAS8.0.0DEV',5M-0000),'HIPERSTN',
===> //
CLASS=Q,MSGCLASS=R,NOTIFY=&SYSUID
===> //*
===> //*
On this screen, you can submit, edit, or save a batch job, save your playback, and exit
playback submission.
1. If you want to save your playback JCL to a dataset, type SAVE on the command line.
The WebSphere MQ Playback - Save JCL File screen appears.
Figure 4-20. WebSphere MQ Playback - Save JCL File Screen
Hiperstation --------- WebSphere MQ Playback - Save JCL File
Command ===>
-----------------
Enter the name of the dataset where JCL will be saved, then press ENTER
to continue.
Playback JCL dataset:
Project . . .
Group . . . .
Type . . . .
Member . . .
Data Set Name . . .
Save JCL Options: (Enter "/" to select)
Replace existing members
This will save all of the parameters you have selected in the previous screens to your
Hiperstation for WebSphere MQ profile.
2. Enter a JCL dataset name. If your name does not conform to ISPF naming standards,
enter the name in the Other Data Set Name field. The JCL file must be a partitioned
dataset (PDS) or sequential file with variable blocked (VB) or fixed blocked (FB)
record format. The record length must be at least 72.
3. Press Enter to save your JCL file and return to the WebSphere MQ Playback - Submit
screen. If your dataset does not already exist, an Allocate JCL File screen will appear.
Press Enter to allocate the dataset.
4. Select an option:
– Option X exits the playback submit screen without submitting the playback.
– Option 1 submits a batch job that creates your scripts.
– Option 2 puts you in an ISPF edit session for the JCL that can be submitted to
create your scripts. To create scripts, you must enter the “SUBMIT” primary
command from within the edit session. After finishing your edits, enter the END
command to return to the playback submit screen.
4-14
Note:
If you select option 1 or 2, you need to enter job card information into the
Job statement information for batch job.
– Option 3 allows you to save your Playback. The WebSphere MQ Playback - Save
screen appears (Figure 4-21).
Figure 4-21. WebSphere MQ Playback - Save Screen
------------------------ WebSphere MQ Playback - Save ----------------------Command ===>
Playback Name . PLAYBACK
Description . . PLAYBACK TEST
Save Playback Dataset:
Dataset Name. . 'USER2312.MQ.PLAYBACK'
Press ENTER to save,
END to exit panel.
Enter a name and optional description for the Playback and a playback dataset name.
Then press Enter to save your Playback and END to return to the WebSphere MQ
Playback - Submit screen.
5. Press Enter to execute the option you selected on the WebSphere MQ Playback Submit screen. A message appears stating that your job was submitted.
Selecting a Previously Saved Playback to Review
1. On the WebSphere MQ Playback - Selection screen, type S (select) next to the
playback in the list you want to use and press Enter. The WebSphere MQ Playback Datasets screen appears.
This will load a previously created playback. You can make changes and resave it
using the same or another name.
2. Continue pressing Enter to view the next screen.
3. When finished, you can run your playback or press END to return to the Hiperstation
for WebSphere MQ main menu.
Deleting a Playback
1. On the WebSphere MQ Playback - Selection screen, type D (delete) next to the
playback you want to delete from the list and press Enter. The Delete Confirmation
screen appears
2. Accept the default Y and press enter to delete your playback. Change the default to N
to keep the playback.
4-15
Generating Playback Reports
1. From the Hiperstation for WebSphere MQ - Main Menu, select option 4 MQ
Playback Reporting (Figure 4-22).
----------------Option ===>
-----------------
1
2
3
4
5
6
Monitor MQ Requests
Create MQ Scripts
Playback MQ Scripts
MQ Archive Requests
The WebSphere MQ Reporting - Selection screen appears (Figure 4-23).
Figure 4-23. WebSphere MQ Reporting - Selection Screen
-------------------- WebSphere MQ Reporting - Selection
Command ===>
----- Row 1 to 2 of 2
Enter a database name , or select a database from the playback list below.
Dataset Name. . . . 'USER2312.ASTERSK.SCRDS'
Line commands...:
S)elect
S
-
Name
Database Name
-------- -----------------------------------------------------SCRIPT
'USER2312.REPORT.DATABASE'
XXXXXXX
'USER2312.ASTERSK.SCRDS'
******************************* Bottom of data ********************************
2. On this screen, select the desired report from the list, or type a dataset name within
single quotes in the Dataset Name field. The WebSphere MQ Reporting screen
appears (Figure 4-24).
Figure 4-24. WebSphere MQ Reporting Screen
---------------------------- WebSphere MQ Reporting --------------------------Command ===>
Select the type of report you wish to generate using
/ .
Basic Reports:
Fixed format reports include HTML Exception,
Script Timing and Response Time Summary
Custom Reports:
Select member below that contains reporting process
Project . . .
Group . . . .
Type . . . .
Member . . .
Dataset Name. . . .
Type END command to return to the previous panel, ENTER to
continue
3. Select whether you want to generate basic or custom reports and press Enter.
4-16
– Basic reports include the response time summary, exception, and script timing
reports.
– Custom Reports are reports that your site has created that contain REPORT
statements to be used in the report job.
4. Continue with the next section, “WebSphere MQ - Basic Reports”, or “WebSphere
MQ - Custom Reports” on page 4-17.
WebSphere MQ - Basic Reports
1. You will have accessed this screen by typing a slash (/) next to the Basic Reports field
on the WebSphere MQ Reporting screen (Figure 4-24) and pressing Enter. The
WebSphere MQ - Basic Reports screen appears (Figure 4-25).
Figure 4-25. WebSphere MQ - Basic Reports Screen
------------------------- WebSphere MQ - Basic Reports -----------------------Command ===>
HTML Exception Report (hfs path):
Optional Parameters:
Number of mismatches to display before stopping ==>
Masking DSN
Compare to baseline database ==>
Baseline DSN
Script Timing Summary (hfs path, DSN, or SYSOUT class):
Response Time Summary (hfs path, DSN, or SYSOUT class):
On this screen, you can specify the locations of the basic reports that you want to
generate. If you specify a location for a type of report, that type of report will be
generated. You can generate multiple report types in the same reporting job. The
types of reports available include:
– HTML Exception Report: A standard exception report that compares actual
response messages to expected response messages from a single data collection.
You must specify an hfs path. (Example: u/compware/user/excp.htm.)
• If desired, specify the number of mismatches to display before ending report
generation.
• You can use data masking to prevent comparison of specific data. Store your
masking statements in a sequential dataset or PDS member.
• To perform a baseline comparison, type a slash (/) in the Compare to
baseline database field and enter the name of the baseline dataset you wish
to compare.
– Script Timing Summary: A standard report that reports the time it took for each
script to play back. It also provides additional timing statistics for the play back
job. (Example: u/compware/user/scrp.htm.)
– Response Time Summary: A standard report that reports the amount of time it
took each group of related messages to occur. For example, this includes the time
that elapsed from the first byte of the request to the last byte of the response.
(Example: u/compware/user/resp.htm.)
4-17
WebSphere MQ - Custom Reports
Custom reports allow you to use a member from a dataset that contains REPORT
statements that will be used in the report job.
1. On the WebSphere MQ Reporting screen (Figure 4-24 on page 4-15), type a slash (/)
next to the Custom Reports field, enter a dataset name and member and press Enter.
The Custom Report Parameters screen appears (Figure 4-26).
Figure 4-26. Custom Report Parameters Screen
--------------------------- Custom Report Parameters -------------------------Command ===>
Report Layout:
Table(columns)
Form(rows)
==> /
==>
Type:
Text
Html
CSV
==> /
==>
==>
Number of lines to print in a field before truncating data ==>
Maximum Number of Lines to print on a page(30-9999)
==>
Break(only applicable to form reports)
EJECT
begin each record on a new page
NEXT
continue reporting on next line
continue
2. Select the desired Report Layout. Table is the default.
– Select Table to produce a row/column-oriented report. Figure 4-27 shows a Table
report layout.
Figure 4-27. Table Report Layout
Hiperstation for WebSphere MQ - MQGroup Report
Date: 06/26/07 14:23
Page:
1
--------------------------------------------------------------------------------------MQGroupNumber
MQGroupReturnCode
MQGroupStartTime
MQGroupDuration
--------------------------------------------------------------------------------------1
0
2007/06/26_10:55:54.685787
50.415205
2
0
2007/06/26_10:55:54.69347
50.407522
3
0
2007/06/26_10:55:57.877735
47.223257
******************************************* BOTTOM OF DATA ****************************
– Select Form to produce a line-based report. Figure 4-28 shows a Form report
layout.
4-18
Figure 4-28. Form Report Layout
Date: 06/26/07 14:24
Page:
1
--------------------------------------------------------------------------------------MQGroupNumber
1
--------------------------------------------------------------------------------------MQGroupReturnCode
0
--------------------------------------------------------------------------------------MQGroupStartTime
2007/06/26_10:55:54.685787
--------------------------------------------------------------------------------------MQGroupDuration
50.415205
--------------------------------------------------------------------------------------Hiperstation for WebSphere MQ - MQGroup Report
Date: 06/26/07 14:24
Page:
2
--------------------------------------------------------------------------------------MQGroupNumber
2
0
2007/06/26_10:55:54.69347
50.407522
Date: 06/26/07 14:24
Page:
3
--------------------------------------------------------------------------------------MQGroupNumber
3
0
2007/06/26_10:55:57.877735
47.223257
---------------------------------------------------------------------------------------
3. Select the type of report you want to produce. Choices include: Text (default), HTML,
and CSV.
4. Enter a number of lines to print in a field before truncating data. This applies only to
Text and CSV reports and allows you to truncate the printing of large fields that may
contain up to two gigabytes of data.
5. Enter the maximum number of lines to print on a page. Enter between 30 and 9999.
This applies only to Text reports. The default is 60.
6. If you are using form reports in a Text or HTML format, select EJECT to begin each
record on a new page or NEXT to continue the report on the next line. EJECT is the
default.
7. Press Enter to continue. The Custom Report Locations screen appears (Figure 4-29).
Figure 4-29. Custom Report Locations Screen
--------------------------- Custom Report Locations --------------------------Command ===>
Enter a location for the table(s) you are reporting on, if different than
SYSOUT=*. The tables used by each report correspond to the INTO parameter.
Playback
MQGroup
MQScript
MQOpenQueue
MQMessage
MQMessageSet
continue
4-19
8. If the tables you are reporting on are not located in SYSOUT=*, then specify the table
locations.
Note: Use unique report locations. If you specify the same dataset location for more
than one report, the last report will be the only one shown because the
previous ones will be overwritten.
9. Press Enter to continue. The WebSphere MQ Playback - Submit screen appears (Figure
4-19 on page 4-13).
Note:
You submit your playback report for execution in the same way you
submitted your playback for execution. See “Submitting Your Playback for
Execution” on page 4-12 for information on submitting and saving your
playback report.
4-20
5-1
Chapter 5.
Unattended Playback
Chap 5
Unattended Playback Overview
Use unattended playback to:
• Play back scripts — execute the MQ API commands found in the script.
• Analyze scripts — process the script without executing the MQ API commands for the
purpose of reporting information on the script’s contents.
Execute unattended playback via a batch job controlled by the following input
statements:
• A CONTROL statement that provides general processing information for the job.
• One or more MQGROUP statements to define processing information for groups of
scripts. All groups are processed simultaneously.
• One or more SCRIPT statements to define processing information for each script.
Scripts within a group are processed sequentially.
• One or more COLLECT statements to define the information to collect for reporting.
Generate reports during unattended playback by including REPORT statements in the job
or save the collected information and generate reports later. See Chapter 6, “Reporting”
for more information.
Although you can create and manage unattended playback and reporting assets, input
statements and JCL, any way you like, Hiperstation for WebSphere MQ is capable of
doing most of the work for you. While creating scripts, have Hiperstation for
WebSphere MQ generate a log file containing MQGROUP and SCRIPT statements based
on the script create options you select. The log also includes JCL SET statements that call
specified members containing playback and reporting assets (CONTROL, COLLECT, and
REPORT statements). Use the log to execute an unattended playback job, reporting job,
or both. This functionality requires a playback control library and a report control
library. Establish these libraries to manage your playback and reporting assets.
Unattended playback automatically generates a SYSOUT playback log preceded by a error
summary for troubleshooting playback issues. Generate an interactive HTML Playback
Error Summary report by adding the appropriate DD statement to the log file used to
execute the unattended playback job.
Following is a basic overview for setting up and running an unattended playback job.
1. Verify that the assets in the system-level playback and reporting control libraries suit
your needs. If necessary, build additional assets and store them in either the
system-level or your personal libraries. See “Creating and Managing Playback Control
Assets” on page 5-2 and “Creating and Managing Reporting Control Assets” on page
6-2.
2. When creating scripts, select the Log Entries option on the Create Script - Create
Options (2 of 2) panel (Figure 3-12 on page 3-17), to generate a log file.
3. Review and edit the log file as necessary. See “Preparing the Log File for Unattended
Playback” on page 5-16.
5-2
– Verify and if necessary edit the values of the SET statements at the beginning of
the log file.
– Supply a DD statement for each REPORT statement in the REPORT member that
is going to be written to a dataset or HTML file.
– Add the HTMLLOG DD statement to generate an interactive HTML Playback
Error Summary report (optional).
– Review the MQGROUP and SCRIPT statements to ensure they meet your needs.
4. Submit the Job. See “Submitting the Job” on page 5-21.
Creating and Managing Playback Control Assets
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), Hiperstation for WebSphere MQ plays back the script offline using think
option 3.
Hiperstation 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,
Hiperstation 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. Hiperstation 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.
See “CONTROL Statement” on page 5-3 to learn about CONTROL statement
parameters.
• A member for each set of collection criteria. Hiperstation for WebSphere MQ provides
a member called COLLECT that collects all information available.
The log files generated by Hiperstation 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 Chapter 8, “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. Hiperstation 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. Hiperstation for WebSphere MQ
provides a member called MQRCTT that generates a text based report in table format,
which supports the Default Script Analysis report (Figure 5-4 on page 5-21).
See Chapter 6, “Reporting” to learn more about reporting assets.
Unattended Playback
5-3
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 Hiperstation for WebSphere MQ. See to Chapter 8, “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.
CONTROL
MQGROUP
SCRIPT
SCRIPT
MQGROUP
SCRIPT
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 systemlevel or your personal playback control library. The system-level playback control library
5-4
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 Hiperstation 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
Unattended Playback
5-5
parameter inside the PLAY_TO or PLAY_AS parameter on the MQGROUP and/or
SCRIPT statements.
OFFLINE
Tells Hiperstation 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, Hiperstation 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
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)” on page 8-17 and “Overriding Queues (FROM_QUEUE/TO_QUEUE)” on
page 8-19 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
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 Figure 3-11 on page 3-15, 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.
5-6
– 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.
Note:
Specifying the first letter of the REXXON parameter value is sufficient. For
example, REXXON(P) is the same as REXXON(PARTIAL).
RLOG(*|destination)
To write your REXX say statements to a dataset 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 datasets 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 dataset
name. For example, RLOG(myrolog.rpl??) generates datasets containing REXX log
information that are named MYRLOG.RPL01.
If the RLOG specification is a single character, Hiperstation for WebSphere MQ
assumes it to be a SYSOUT class. RLOG data can be stored in a PDSE or in a dataset
member. To override a default RLOG dataset allocation, add an //RLOGDD statement
to your JCL as shown below.
//RLOGDD DD DUMMY,SPACE=(TRK,(15,15,15)),DSNTYPE=LIBRARY,
//
DCB=(LRECL=121,BLKSIZE=12100,RECFM=FB)
SET_REXX_STREAM_VARIABLES(NO|YES)
Enables the use of the Hiperstation 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 “Hiperstation for WebSphere MQ REXX Variables” on page 3-44. 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 Hiperstation 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. Hiperstation for WebSphere MQ retries the connections up to the number of
attempts set in the CONNECTION_ATTEMPTS parameter (TCP/IP only). Hiperstation
for WebSphere MQ retries any other I/O twice. Once all attempts are made to
complete the I/O, if still unsuccessful, Hiperstation 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.
Unattended Playback
5-7
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)” on page 8-14 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 Hiperstation for WebSphere MQ information. If
the TRACE specification is a single character, Hiperstation for WebSphere MQ
assumes it to be a SYSOUT class.
A dataset specification can contain wildcard characters. A single asterisk (*) tells
Hiperstation 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 Hiperstation
for WebSphere MQ to each message.
One or more question marks (?) tells Hiperstation 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.
TRACE(abc.def)
• no wild cards are allowed in this dataset
• produces ABC.DEF
TRACE(ABC.DEF(XYZ))
• no wild cards allowed in the dataset or member
• produces ABC.DEF(XYZ)
TRACE(abc??.def*) for ReplayID=1
• both ?? and * are wild cards
• produces ABC01.DEF0001.
USESTIME
When specified, Hiperstation 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.
MQGROUP STIME (‘2006/07/21=10:10:10.000000’)
MQGROUP STIME (‘2006/07/21=10:15:10.000000’)
See “Synchronizing Group Playback (USESTIME)” on page 8-11 and “Controlling
Playback Timing (USESTIME and THOPT)” on page 8-14 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” on page 8-4 and
5-8
“Playing Back Scripts Simultaneously (Multiple Groups)” on page 8-6 for comprehensive
MQGROUP examples.
Unattended Playback
5-9
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)” on page 8-9 for a detailed example.
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, Hiperstation 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
Hiperstation 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 Hiperstation
for WebSphere MQ to play the script in the direction recorded in the script, as if
Hiperstation for WebSphere MQ was the application generating the data in the script.
When encountering an MQ_GET, Hiperstation for WebSphere MQ performs an
MQGET. When encountering an MQ_PUT, Hiperstation for WebSphere MQ PUTs that
scripted message to the PUT_TO_QUEUE if specified. Additionally, when
encountering an MQ_GET, Hiperstation 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))
play the script to an application. Using the PLAY_TO statement reverses the direction
of script play causing Hiperstation 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,
Hiperstation 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(*))”
on page 8-24 for further examples.
For the CONNECTION_ID specified when encountering an MQ_GET in the script,
Hiperstation for WebSphere MQ PUTs that scripted message, making it available to
the application. If specified, Hiperstation for WebSphere MQ PUTs that message to
the PUT_TO_QUEUE. Additionally, when encountering an MQ_PUT in the script,
Hiperstation 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
5-10
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)” on page 8-17 and “Overriding Queues
(FROM_QUEUE/TO_QUEUE)” on page 8-19 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.
The default output queue for the WebSphere MQ playback. This can be either a
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, Hiperstation 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.
The queue manager to use for WebSphere MQ playback. See the “Reversing Playback
(PLAY_TO)” on page 8-17 scenario, which includes a queue manager override
example.
REPEAT(1|number_of_iterations)
Tells Hiperstation for WebSphere MQ to repeat playback the specified number of
times.
The default reply_to_ queue is used by the playback when a reply_to_ queue is found
request/reply messages. See Figure 3-11 on page 3-15, 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 Hiperstation 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:
Unattended Playback
5-11
YYYY/MM/DD_HH:MM:SS.TTTTTT
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)” on page 8-14 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 Hiperstation for WebSphere MQ information. If
the TRACE specification is a single character, Hiperstation for WebSphere MQ
assumes it to be a SYSOUT class.
A dataset specification can contain wildcard characters. A single asterisk (*) tells
Hiperstation 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 Hiperstation
for WebSphere MQ to each message.
One or more question marks (?) tells Hiperstation 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.
TRACE(abc.def)
• no wild cards allowed in this dataset
• produces ABC.DEF
TRACE(ABC.DEF(XYZ))
• no wild cards allowed in the dataset or member
• produces ABC.DEF(XYZ)
TRACE(abc??.def*) for ReplayID=1
• 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
5-12
log file based on the script create options you select. Modify SCRIPT statements in the log
file.
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, Hiperstation 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)
played on a CONNECTION_ID. This CONNECTION_ID represents a connection
play the script to an application. Using the PLAY_AS statement requests Hiperstation
for WebSphere MQ to play the script in the direction recorded in the script, as if
Hiperstation for WebSphere MQ was the application generating the data in the script.
When encountering an MQ_GET, Hiperstation for WebSphere MQ performs an
MQGET. When encountering an MQ_PUT, Hiperstation for WebSphere MQ PUTs that
scripted message to the PUT_TO_QUEUE if specified. Additionally, when
encountering an MQ_GET, Hiperstation 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.
Unattended Playback
5-13
PLAY_TO(CONNECTION_ID(x)ON(queue_name)
CONNECTION_ID. To use WebSphere MQ applications, you must tell Hiperstation
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 Hiperstation 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, Hiperstation
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,
Hiperstation for WebSphere MQ PUTs that scripted message, making it available to
the application. If specified, Hiperstation for WebSphere MQ PUTs that message to
the PUT_TO_QUEUE. Additionally, when encountering an MQ_PUT in the script,
Hiperstation 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.
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, Hiperstation 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.
The default queue manager for WebSphere MQ playback.
REPEAT(1|number_of_iterations)
Tells Hiperstation 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.
The default reply_to_ queue is used by the playback when a reply_to_ queue is found
request/reply messages. See Figure 3-11 on page 3-15, under “Where should details be
stored?”.
5-14
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.
Unattended Playback
5-15
Note: If you are load or stress testing your application and not concerned with expected
versus actual value comparison, omit COLLECT statements to optimize playback
performance.
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.
5-16
See Appendix A, “Data Collection and Reporting Tables” to determine which tables
and fields to collect or to locate short field names.
Note:
Depending on use, not every field is available. For example, message header
fields cannot be sent by an application during a particular transmission, and
therefore would not be available for reporting.
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
Appendix A, “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:
COLLECT FIELDS (*) FROM (MQGROUP) WHERE (MQGroupNumber = 2)
Preparing the Log File for Unattended Playback
When you create scripts, select the Log Entries option on the Create Script - Create
Options (2 of 2) panel (Figure 3-12 on page 3-17), to generate the log file used to run an
unattended playback job. The log file contains a series of SET statements that call
playback and reporting control assets. Most of the SET statement values default to the
system-level playback and report control library and member names. Override them with
your personal library information if necessary. Additionally, the values default to
produce a script analysis job. Run a script analysis prior to the actual playback to ensure
the script contains the appropriate activity for the testing you need to perform. Compare
the contents of two different scripts, by running a script analysis on each and saving the
collected data. Then generate a comparison report. See Chapter 6, “Reporting” for more
information on report generation.
To prepare the log for an unattended playback job:
1. Verify and, if necessary, edit the values of the SET statements at the beginning of the
log file. Refer to the SET statement definitions following the sample log illustration
2. Between ANALYZE EXEC PROC=MQPLAY1 and LOGCOPY.INDD DD * insert a DD
statement for each REPORT statement in the REPORT member that is going to be
written to a dataset or HTML file. Do not add DD statements for reports written to
SYSOUT. The MQPLAY1 procedure provides a DD statement for SYSOUT.
Note:
Refer to the “flower box” showing a sample DD statement defining an HFS
path and a sample statement defining a dataset.
To generate an interactive HTML Playback Error Summary Report, add
PROCESS.HTMLLOG DD with the appropriate PATHOPTS, PATH, and PATHMODE
definitions.
3. Review the MQGROUP and SCRIPT statements to ensure they meet your needs.
4. When finished preparing the log, submit the job. See “Submitting the Job” on page
5-21.
Unattended Playback
Figure 5-1. Sample Log File
//jobcard
//*
/*JOBPARM SYSAFF=TEST
//UPROCS JCLLIB ORDER=('COMPWARE.SQVPPROC')
//*
//**********************************************************************
//* EXEC PROC TO PROCESS LOG/SORT/REPORT
*
//**********************************************************************
//*
//
SET ACTION=ANALYZE
ANALYZE/PLAYBACK/other
//*
//
SET CNTLDS= COMPWARE.CONTROL
//
SET REPTDS= COMPWARE.REPORT
//*
//
SET SCRIPT= COMPWARE.SCRIPT
//
SET UNSORTED=&&UNSORTED
//
SET SORTED=&&SORTED
//*
//
SET COLLMEM=COLLECT
//
SET REPTCNTL=MQRCTT
//
SET REPTMEM=MQRCOMP
//*
//*
//ANALYZE EXEC PROC=MQPLAY1
//*
//**********************************************************************
//*
*
//*
TO ADD ADDITIONAL REPORT OUTPUT DATASETS, USE THE FOLLOWING
*
//*
HFS OR MVS DATASET MODEL CHANGING THE ddname TO THE NAME
*
//*
SPECIFIED ON THE REPORT INTO() STATEMENT
*
//*
*
//* //REPORT.ddname
DD PATHMODE=(SIRWXU,SIRGRP,SIROTH),
*
//* //
PATHOPTS=(ORDWR,OCREAT),
*
//* //
PATH='/hfs/path/reptname.htm'
*
//*
*
//*
or
*
//*
*
//* //REPORT.ddname
DD DISP=SHR,DSN=sysout.dataset.name
*
//*
*
//**********************************************************************
//*
//LOGCOPY.INDD DD *
************************************************************************
*
*
* HIPERSTATION FOR WEBSPHERE MQ LOG STARTED ON 2006/07/10 AT 12:12:01 *
*
*
* DESC: TEST
*
* GROUP: (1) One script for everything
*
*
*
* FILTER: 1
ACTION: INCLUDE
*
* QUEUE MANAGER EQ TEST
*
EQ Q1
*
* OBJECT/QUEUE
* EVENT
EQ PUT
*
* FILTER: 2
ACTION: INCLUDE
*
*
* OBJECT/QUEUE
EQ Q2
*
* EVENT
EQ GET
*
*
*
* RECORDING ALL DATA FROM GETS, ALL DATA FROM PUTS
*
* DETAIL DATA IS TRANSLATED FROM ASCII TO EBCDIC
*
* SAMPLE DATA IS TRANSLATED FROM ASCII TO EBCDIC
*
* DEFAULT MQAPI SCRIPT TAG PARAMETERS ARE INCLUDED
*
*
*
* REPOSITORY NAME: COMPWARE.REPOS
*
* LOG . . . . . : COMPWARE.LOG(LOG004)
*
* SCRIPT . . . . : COMPWARE.SCRIPT
*
*
*
************************************************************************
* SCRIPT NUMBER(1)
*
MQGROUP ID(1)STIME('2006/06/26_10:55:59.885251')
SCRIPT(SCR004)
******************************** Bottom of Data ********************************
5-17
5-18
MQ Log STEPLIB Overrides
This function allows you to add extra STEPLIB datasets to the supplied JCL and
procedures contained in the MQ log dataset for replaying MQ scripts. This is useful for
defining a specific level of WebSphere MQ for use with a particular script relay.
The additional STEPLIB datasets are defined in the ETRMGPAR member of the
Hiperstation for WebSphere MQ panel library (COMPWARE.SQQFPENU), as shown in
Figure 5-2.
Figure 5-2. Sample ETRMGPAR PNLSRC Member
)BODY EXPAND(\\)
%GLOBAL RECORDING PARAMETER SETTINGS
)INIT
&XTRMGRDS = AT.COMMON.OUTPUT.GRREQ
&REXXEXEC = COMPWARE.SQQFEXEC
&QAHSLOAD = COMPWARE.SQQFLOAD
&QAHSPLIB = COMPWARE.SQQFSAMP
&QAHSPLYC = COMPWARE.CONTROL
&QAHSREPC = COMPWARE.REPORT
&GLBLCSI = COMPWARE.GLOBAL.CSI
&TZONE
= ZONET
&TEMPUNIT = SYSDA
&TEMPVOLM = ''
&TEMPSPAC = 'CYLS'
&TEMPPRIM = 7
&TEMPSCND = 3
&TEMPMCLS = ''
&TEMPSCLS = ''
&TEMPDCLS = ''
IF (&ZSYSID = 'MACHINE1')
&TEMPSTP1 = 'SYS2.COMPWARE.SQQFLOAD'
ELSE
&TEMPSTP1 = 'COMPWARE.STEPLIB'
&TEMPSTP2 = ''
)END
Up to two extra STEPLIB datasets can be defined by assigning their fully qualified names
to variables TEMPSTP1 and/or TEMPSTP2 as shown. The example in Figure 5-2 also shows
how to set TEMPSTP1/2 differently depending on the LPAR used to execute the script
replay.
Once defined, the STEPLIB datasets are added to the JCL generated in the MQ log as part
of the MQ script create process. A sample MQ log, including generated JCL and the
overriding STEPLIB definition, is shown in Figure 5-3. The generation of replay JCL in an
MQ log is controlled by the script create parameter, MQSCLJCL.
Unattended Playback
5-19
Figure 5-3. Sample MQ Log
//USERID JOB ('ACCOUNT',NTRH),'PROGRAMMERNAME', --(MASS0118)----------//
CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
/*JOBPARM S=CW01
//*
//*
//UPROCS JCLLIB ORDER=('SYS2.COMPWARE.SQQFSAMP')
//*
//**********************************************************************
*
//**********************************************************************
//*
//
SET ACTION=ANALYZE
//*
//
SET CNTLDS=SYS2.COMPWARE.MQ.CONTROL
//
SET REPTDS=SYS2.COMPWARE.MQ.REPORT
//*
//
SET SCRIPT=USERID.WEBMQ.SCRIPT
//
//
SET SORTED=&&SORTED
//*
//
SET COLLMEM=COLLECT
//
SET REPTCNTL=MQRCTT
//
SET REPTMEM=MQRANLZ
//*
//*
//ANALYZE EXEC PROC=MQPLAY1
//PROCESS.STEPLIB DD DISP=SHR,DSN=&LOAD
//
DD DISP=SHR,
//
DSN=SYS2.CPWR.COMPWARE.SQQFLOAD
//*
//**********************************************************************
//*
*
//*
*
//*
*
//*
*
//*
*
//* //REPORT.ddname DD PATHMODE=(SIRWXU,SIRGRP,SIROTH),
*
//* //
*
//* //
*
//*
*
//*
or
*
//*
*
//* //REPORT.ddname
*
//*
*
//**********************************************************************
//*
//LOGCOPY.INDD DD *
************************************************************************
*
*
* HIPERSTATION WEBSPHERE MQ LOG STARTED ON 2006/02/17 AT 11:03:35
*
*
*
*
* DESC:
*
*
*
* FILTER: 001
ACTION: INCLUDE
*
* QUEUE MANAGER EQ *
*
*
*
*
* TIME STAMPS ARE SUPPRESSED IN SCRIPTS
*
*
*
*
* REPOSITORY NAME: USERID.WEBMQ.SUBTEST4
*
* REPOSITORY NUMS: 1:9
*
* LOG . . . . . : USERID.WEBMQ.LOG($SUBD000)
*
* SCRIPT . . . . : USERID.WEBMQ.SCRIPT
*
*
*
************************************************************************
*
* SCRIPT NUMBER(1)
*
MQGROUPID(1)STIME('2004/08/30_12:20:44.398671')
SCRIPT(SUBD0000)
The MQ log references the MQPLAY1 PROC to perform script relay. The MQPLAY1 PROC
is suppled in the Hiperstation for WebSphere MQ sample library
5-20
(COMPWARE.SQQFSAMP) member MQPLAY1. Within the MQPLAY1 PROC, the PROCESS
STEP executes the script replay, so it is the PROCESS.STEPLIB DD that is overridden.
Note:
Both the PROCESS.STEPLIB in the MQPLAY1 PROC and the override specify an
&LOAD dataset, which is resolved into the Hiperstation for WebSphere MQ load
library. The Hiperstation for WebSphere MQ load library must be in the script
replay STEPLIB for the replay to proceed.
SET Statements
SET ACTION
This statement defines which playback CONTROL member to use for the job. By
default, it calls the ANALYZE member stored in the system-level playback control
library. The ANALYZE member contains a CONTROL statement bearing the OFFLINE
keyword, which processes the script without executing the MQ API command. Use
this member to analyze script contents. Override the default with:
– PLAYBACK to call the CONTROL member that processes the script and executes
the MQ API commands in the script. PLAYBACK is also stored in the system-level
playback control library.
– the name of any CONTROL member stored in the system-level or your personal
playback control library.
SET CNTLDS
This statement identifies the playback control library owning the assets you are using
for this job. By default, it points to the system-level playback control library. This
statement must point to the library in which the CONTROL member specified on the
SET ACTION statement resides.
SET REPTDS
This statement identifies the report control library owning the assets you are using
for this job. By default, it points to the system-level report control library. This
statement must point to the library in which the REPORT and report CONTROL
members specified on the SET REPTCNTL and SET REPTMEM statements reside.
SET SCRIPT
This statement identifies the library in which the scripts are stored. By default, it
points to the library you specified on the WebSphere MQ Create Script - Output
screen (Figure 3-16 on page 3-23) during script creation. All scripts played back or
analyzed must reside in this library.
SET UNSORTED
This statement identifies where to store the data collected during the unattended
playback job. It defaults to a temporary dataset. The data written to this location has
not been processed for reporting. There is no reason to override the temporary
dataset although you can, if desired.
SET SORTED
This statement identifies where to store the data collected and processed for
reporting. It defaults to a temporary dataset. Override this value with a permanent
dataset to save the information for generating reports later.
SET COLLMEM
This statement identifies the collection member to use for the job. By default, it calls
a member named COLLECT, from the system-level playback control library, that
collects all fields from all tables. Override it with:
– any COLLECT member stored in the library specified on the SET CNTLDS
statement.
– NONE if you do not need to collect information for reporting.
Unattended Playback
5-21
SET REPTCNTL
This statement identifies the report CONTROL member to use for the job. By default,
it calls MQRCTT from the system-level report control library. MQRCTT produces a
text-based report in table format, that supports the default Script Analysis Report.
Override it with:
– any report CONTROL member stored in the library specified on the SET REPTDS
statement.
– NONE if you do not need a reporting CONTROL member. If the specified REPORT
member provides all necessary control information, a report CONTROL member
is unnecessary.
SET REPTMEM
This statement identifies the REPORT member to use for the job. By default, it calls
MQRANLZ from the system-level report control library, which produces a default
Script Analysis Report (Figure 5-4).
Figure 5-4. Script Analysis Report
HIPERSTATION FOR WEBSPHERE MQ - MQQueue Report
Date: 06/04/07 10:52
Page: 1
------------------------------------------------------------------------------------------------------MQGroupNumber
MQScriptNumber
MQOpenQueueID
MQOpenQueueName
QMNA
MQMessageCountQueue
------------------------------------------------------------------------------------------------------1
3
81
PDAPROD.CICSREG2 M520
1
1
3
86
1
1
3
87
1
1
3
98
1
1
3
103
1
1
3
104
1
1
3
116
1
HIPERSTATION FOR WEBSPHERE MQ - MQMessage Report
Date: 06/04/07 10:52
Page: 1
------------------------------------------------------------------------------------------------------QMAQ
MQMessageOutbound
MQMessageInbound
MQME
------------------------------------------------------------------------------------------------------CSQ1:PDAPROD.CICSREG1.C USR2312 AMERICANFASTNERS
CSQ1:PDAPROD.CICSREG1.C
0000000000000000000000000 000000000000000000000000
0AMERICANFASTNERS
0AMERICANFASTNERS
CSQ1:PDAPROD.CICSREG1.C USR2312 AMERICANFASTNERS
CSQ1:PDAPROD.CICSREG1.C USR2312 BOLTSNNUTS+
0000000000000000000000000 000000000000000000000000
0BOLTSNNUTS+
0BOLTSNNUTS+
Submitting the Job
Once the job is prepared, submit it in one of the following ways:
• Submit the job from the ISPF Edit session to execute it immediately. Type SUB on the
• 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
Hiperstation for WebSphere MQ reports an MVS return code for each step of a playback
job. The return code is a numeric value that indicates whether the job step completed
successfully and to what degree. See “Playback Return Code Descriptions” on page 5-22
for a complete list of MQ playback return codes.
5-22
Note: For more definitive playback results, you can add REXX logic to a script to return
a specific value based on criteria you supply. This is called a ‘custom’ return code.
Refer to the Hiperstation Scripting Reference to learn how to define custom return
codes.
The location of your return codes is dependent on your system configuration. On some
systems, with the correct job statement parameter, return codes appear in the user’s TSO
session. On others, they are written to a job log. If you need help locating your return
codes, see your system administrator.
Hiperstation for WebSphere MQ also writes the following informational messages to the
SYSPRINT upon job completion.
TCPSRPL-0051I
TCPPBMN-0007I
Play complete for Replay=1 - Return Code=xxxx.
Maximum return code=xxxx
Message TCPSRPL-0051I reports the return code from the indicated playback session
(Replay). Hiperstation for WebSphere MQ produces one of these messages for each
playback session in the job step. For example, the following playback statements result in
six playback sessions (Table 5-1) and therefore, six TCPSRPL-0051I messages:
MQGROUP COUNT(2) REPEAT(3)
SCRIPT(TEST)
Table 5-1. Playback Sessions for a MQGROUP Statement with COUNT(2) REPEAT(3)
Repeat
Count 1
Count 2
1
Replay=1
Replay=2
2
Replay=3
Replay=4
3
Replay=5
Replay=6
Message TCPPBMN-0007I reports the maximum return code from all of the playback
sessions in the job step. This is the value that Hiperstation for WebSphere MQ returns as
the job step completion code.
Note:
The job step completion code can be tested with the COND parameter on a JCL
EXEC or JOB statement.
If the MQGROUP statement contains multiple scripts, Hiperstation for WebSphere MQ
returns the value set by the last script processed. Incidentally, playback terminates
MQGROUP processing if it encounters a non-zero return code. For example, Hiperstation
for WebSphere MQ reports the return code from the LOGOFF script in the following
MQGROUP, unless LOGON or TEST produce a non-zero return code.
MQGROUP
SCRIPT(LOGON)
SCRIPT(TEST)
SCRIPT(LOGOFF)
Playback Return Code Descriptions
Hiperstation for WebSphere MQ 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.
Unattended Playback
Note:
5-23
It also writes a Playback Error Summary report to the location specified on the
ERRORLOG DD in the playback JCL. See “Troubleshooting with the Playback
Error Summary” for detailed information.
If you receive a non-zero return code, review the return code description provided in
Table 5-2. Then review the warning and error messages to determine the cause of the
problem. Refer to Hiperstation Messages and Codes for help with error resolution.
Table 5-2. Hiperstation for WebSphere MQ Internal Return Codes
Code
Description
0
All scripts ran successfully without errors.
4
Playback ended due to one of the following:
8
•
An invalid script record was encountered. Review the playback errors to determine which
record caused the issue, then edit the script record.
•
An invalid CONNECTION_ID was encountered. Edit the script to repair the incorrect connection ID.
•
A REXX initialization error was encountered. Refer to your REXX documentation for help
with initialization errors.
Playback ended due to one of the following:
•
A file allocation error occurred. Review the allocation parameters in the playback job. If
they are correct, contact your systems administrator.
•
A file could not be opened. Make sure you have authority to access all of the files specified
in the job and that the files are not in use.
•
A file could not be read. Maker sure you have authority to read all of the files specified in
the job.
•
A file could not be written. Make sure you have authority to write to all of the files specified in the job.
•
A script file was not found. Make sure the member names specified on the SCRIPT statements are accurate and exist and that the DSN provided on the SYSLIB DD parameter is
accurate.
•
Hiperstation for WebSphere MQ was unable to access or read the internal cache.
This could happen for a variety of reasons. For example, if the memory was corrupted. Contact your system administrator. Note: Removing the CACHON parameter from the CONTROL statement may resolve the error, but it will not correct any system issues.
12
•
Hiperstation for WebSphere MQ was unable to write to the internal cache. This
could happen for a variety of reasons. For example, the cache is full. Contact your system
administrator. Note: Reducing the size of the job may resolve the issue, but it will not correct any system issues.
•
An invalid control card was encountered. Correct the job SYSIN.
Playback is terminated due to a system failure. For example, if you are not licensed to use Hiperstation for WebSphere MQ , or no OMVS segment is available. Contact your system administrator.
100
Playback is terminated because the playback job does not include an ERRORLOG DD statement.
Insert an ERRORLOG DD statement before the SYSOUT DD in the playback JCL.
Note: You can add REXX logic to a script to return a specific value based on criteria you
supply. For example, add logic to evaluate application message content and
return a specific value if the content is incorrect. Refer to the Hiperstation
Scripting Reference to learn how to define custom return codes.
5-24
Troubleshooting with the Playback Error Summary
Hiperstation for WebSphere MQ’s unattended 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, positioned ahead of the Playback Log
SYSOUT DD, in the unattended playback JCL. MQPLAY1, the procedure called by the log
file, supplies this DD for you.
Note:
Unattended playback requires the ERRORLOG DD statement for successful
playback. If it is not included in the job, playback halts and the job returns an
error code of 100.
Generate an interactive HTML version of the report by including an HTMLLOG DD
statement that specifies an HFS path in the playback JCL. That is, in the log file used to
run the unattended playback job, between ANALYZE EXEC PROC=MQPLAY1 and
LOGCOPY.INDD DD *, insert PROCESS.HTMLLOG DD with the appropriate PATHOPTS,
PATH, and PATHMODE definitions. See Figure 5-1 on page 5-17.
View the report with a supported web browser.
Figure 5-5. Playback Error Summary Report (HTML Version)
In this version of the report, 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 corresponding messages 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.
Note: Please note HFS paths are case sensitive. Be aware of the position of the Caps Lock
key when you edit the log file used to run the unattended playback job.
Unattended Playback
Additionally, optimum screen resolution for viewing this report is 800 x 600
pixels or better.
5-25
5-26
6-1
Chapter 6.
Reporting
Chap 6
With Hiperstation for WebSphere MQ you can:
• Build custom reports that contain information you specify, presented as you define.
• Generate basic, predefined reports.
Both custom and basic report generation require the same steps. However, the assets
necessary to generate basic reports are much easier to build. In fact, Hiperstation for
WebSphere MQ provides sample reporting assets for each basic report. This chapter
teaches you how to perform all of the tasks necessary to generate either type of report.
Reporting Overview
Report generation requires collecting data from an unattended playback, sorting the
collected data, and submitting a report generation job. Collecting and sorting data occurs
during unattended playback providing you use the log file to execute the job. You can
also generate reports during the unattended playback job or save the collected and sorted
data to generate reports later. Run the unattended playback job once, collect, sort, and
save all possible data, then generate as many different reports as you like. You can even
generate reports that compare data collected from different unattended playback jobs.
A reporting job is controlled by the following input statements:
• CONTROL statements (optional), which provides general processing information for
a group of reports.
• REPORT statements, which define the information to report and potentially the
layout of the report.
Use the log file produced during script creation to execute an unattended playback job,
reporting job, or both. The log file executes a procedure that generates the reports. The
procedure calls specified members containing the reporting input statements. Build
REPORT and reporting CONTROL statements (reporting assets) and store them in
members of the system-level or your personal reporting control library. Plug the member
names into the log file and submit the job.
Note:
Using the log, only for reporting, requires a sorted data collection from an
unattended playback job.
To set up and run a reporting job using the log file generated during script creation:
1. Save sorted data from an unattended playback job by specifying a dataset name on
the SET SORTED statement that appears at the beginning of the log file. See
“Preparing the Log File for Unattended Playback” on page 5-16.
2. Verify that the assets in the system-level reporting control library are suitable. If
necessary, build additional assets and store them in either the system-level or your
personal library. See “Creating and Managing Reporting Control Assets” on page 6-2.
3. Review and edit the log file as necessary. See “Preparing the Log File for Reporting”
on page 6-14.
– Edit the values of the SET statements at the beginning of the log file.
6-2
– Supply a DD statement for each REPORT statement in the REPORT member that
is to be written to a dataset or HFS file.
– If you are running a baseline report, a report that compares two databases,
supply a DD statement for the baseline database.
– If you are masking information for an HTML Exception Report, supply a DD
statement for each masking statement dataset to be used during the reporting
job.
– Replace MQPLAY1 with MQREPT1 on the EXEC statement.
4. Submit the Job. See “Submitting the Job” on page 6-16.
Creating and Managing Reporting Control Assets
Hiperstation for WebSphere MQ ships with JCL that your installer uses to establish a
system-level report control library along with some members containing basic REPORT
and CONTROL statements. When generating the log file used to run an unattended
playback or reporting job, Hiperstation 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 report control library in
the same fashion as the system-level library.
• One member for each report or set of reports you would like to generate in a given
job. Hiperstation for WebSphere MQ provides a variety of basic REPORT members.
The log file defaults REPORT member MQRANLZ, which produces a Script Analysis
Report, is discussed in Chapter 5, “Unattended Playback”. See Appendix B,
“Hiperstation for WebSphere MQ Samples Index” for a complete list and description
of all samples.
• One member for each report CONTROL statement. Report CONTROL statements
define general report processing information. They are optional. The log file defaults
a member called MQRCTT that generates a text-based report in table format to
support the default Script Analysis Report (Figure 5-4 on page 5-21).
Create your own assets and store them in either the system-level or your personal
reporting control library. Give each member a name indicative of its purpose.
Reporting CONTROL statements apply to both basic and custom reports. Basic REPORT
statements require parameters specific to the basic report you are generating, while
custom REPORT statements offer a variety of parameters that apply to all custom reports.
This section provides a syntax diagram and parameter descriptions for constructing your
own:
• CONTROL statements
• REPORT statements for Basic Reports
• REPORT statements for Custom Reports
CONTROL Statement
Reporting CONTROL statements are optional. They provide processing information for a
group of REPORT statements. For example, if you are going to run several reports of the
same type, set the report type on the CONTROL statement, so you do not have to specify
it on each REPORT statement.
Most of the parameters available on CONTROL statements are also available on REPORT
statements. If a parameter is not defined on a REPORT statement, Hiperstation for
WebSphere MQ uses the parameter value defined on the CONTROL statement. If it is
defined on both, the REPORT statement takes precedence. For example, if CONTROL
specifies table and REPORT specifies form, form is used instead of table.
Reporting
6-3
Determine where to store the CONTROL statements based on your reporting needs.
Storing one CONTROL statement per member in the system-level or your personal
reporting control library is the easiest way to maintain and reuse CONTROL statements.
However, if you use the log file produced during script creation to run the reporting job,
storing the CONTROL statements separately limits the job to a single CONTROL
statement. Hiperstation for WebSphere MQ assembles the statements from specified
CONTROL and REPORT members in the appropriate order. For example, if your REPORT
member contains two REPORT statements, Hiperstation for WebSphere MQ assembles the
input statements as follows:
CONTROL
REPORT
REPORT
To run three reports with one set of processing options and two with another set, you
can:
• Create two REPORT members, for example, A and B, each containing the applicable
REPORT statements, and two CONTROL members, for example, Table and Form, each
containing a single CONTROL statement, then run two reporting jobs.
Job1 Processes:
Job2 Processes:
CONTROL (from member Table)
REPORT (from member A)
CONTROL (from member Form)
REPORT (from member B)
REPORT (from member B)
Although this may be more work initially, the CONTROL and REPORT members are
independent assets that are easily reusable.
• Create one REPORT member containing both CONTROL statements, each followed
by the applicable REPORT statements, and run a single reporting job.
Job1
CONTROL
REPORT
REPORT
REPORT
CONTROL
REPORT
REPORT
This may be less work initially, however, you will not be able to use the CONTROL
statements and REPORT member as independent assets for future reporting jobs.
• Create one REPORT member containing REPORT statements that provide all of the
necessary processing parameters and run a single job. Note: The CONTROL statement
provides additional processing options that are not available on the REPORT
statements. This method works only if you do not require any of those options.
If you specify a CONTROL member and a REPORT member containing CONTROL
statements, Hiperstation for WebSphere MQ uses the statements in the REPORT member.
Note: If two or more consecutive CONTROL statements precede the REPORT statements,
Hiperstation for WebSphere MQ uses the last statement listed.
6-4
The following syntax diagram shows all of the parameters available on the CONTROL
statement. All of the parameters are optional. LAYOUT and TYPE are also available on
REPORT statements.
DATABASE
Follow the DATABASE parameter with the DD name for the collected, sorted data to
use for report generation. DATABASE is the default value. The MQREPT1 procedure,
called by the log file, supplies a DD statement that defines the SET SORTED dataset as
“DATABASE”. Thus, the default should suffice, providing you did not alter the DD
statement in the procedure.
Note:
If you are running reports that compare two data collections, specify the
additional databases with REPORT statement parameters. See “HTML
Exception REPORT Statement” on page 6-6 or “REPORT Statement for
Custom Reports” on page 6-9.
LAYOUT
Follow LAYOUT with:
– TABLE to produce a row, column oriented report (Figure 6-1 on page 6-4). If you
do not specify a layout, TABLE is used.
Note: TEXT reports with a table layout will print a maximum of 6 fields. HTML
reports with a table layout will print a maximum of 32 fields.
– FORM to produce a line based report (Figure 6-2 on page 6-5).
Figure 6-1. Sample MQGROUP Text Report in Table Layout
Date: 06/26/07 14:23
Page:
1
--------------------------------------------------------------------------------------MQGroupNumber
MQGroupReturnCode
MQGroupStartTime
MQGroupDuration
--------------------------------------------------------------------------------------1
0
2007/06/26_10:55:54.685787
50.415205
2
0
2007/06/26_10:55:54.69347
50.407522
3
0
2007/06/26_10:55:57.877735
47.223257
******************************************* BOTTOM OF DATA ****************************
Reporting
6-5
Figure 6-2. Sample MQGROUP Text Report in Form Layout
Date: 06/26/07 14:24
Page:
1
--------------------------------------------------------------------------------------MQGroupNumber
1
0
2007/06/26_10:55:54.685787
50.415205
Date: 06/26/07 14:24
Page:
2
--------------------------------------------------------------------------------------MQGroupNumber
2
0
2007/06/26_10:55:54.69347
50.407522
Date: 06/26/07 14:24
Page:
3
--------------------------------------------------------------------------------------MQGroupNumber
3
0
2007/06/26_10:55:57.877735
47.223257
---------------------------------------------------------------------------------------
TYPE
Follow TYPE with either TEXT, HTML, or CSV (comma separated value). Generate
custom reports in any of these formats. Basic reports, however, do not support CSV
format. Some basic reports support only HTML while others support TEXT and
HTML. Refer to the REPORT statement for the desired basic report.
If you do not specify a type, TEXT is used.
Note:
For TEXT and CSV reports, make sure the LRECL of the dataset you allocate
for the report is equal to or larger than the longest message reported.
Hiperstation for WebSphere MQ truncates or wraps messages exceeding the
dataset’s LRECL.
BREAK
BREAK applies only to TEXT and HTML reports with a FORM layout. For:
– TEXT reports, follow the parameter with EJECT to begin each record on a new
page, or NEXT to continue reporting on the next line.
– HTML, follow the parameter with EJECT to begin each record in a new HTML
table or NEXT to continue reporting on the next line of the same HTML table.
Note:
HTML FORM reports are displayed in HTML tables.
If you do not specify breaking conditions, EJECT is used.
MAXLINES
MAXLINES applies only to TEXT reports. Follow MAXLINES with the maximum
number of lines to print on each page. The value must be between 30 and 9999. If
you do not specify MAXLINES, 60 is used.
6-6
FIELDDEPTH
FIELDDEPTH applies only to TEXT and CSV reports. Use it to truncate the printing of
large fields, some of which may contain up to 2 gigabytes of data. Follow
FIELDDEPTH with the number of lines of message data to print. For example,
FIELDDEPTH(1) results in one line of data per message.
REPORT Statements for Basic Reports
Hiperstation for WebSphere MQ offers the following basic reports:
• HTML Exception Report: Compares inbound (MQ_GET) messages and reports the
differences.
– A standard exception report compares “actual” inbound messages to “expected”
inbound messages from a single data collection.
– A baseline exception report compares “actual” inbound messages from two data
collections. The baseline “actuals” are used as “expected” values for comparison.
• Response Time Summary: Reports the amount of time it took each group of related
messages to occur. For example, the amount of time it took to receive the MQ_GET
from the time the correlating MQ_PUT was sent.
• Script Time Summary: Reports the amount of time it took for each script to play
back and provides additional timing statistics for the playback job.
HTML Exception REPORT Statement
The following syntax diagram shows all of the parameters available on the REPORT
statement for the HTML Exception Report. See “HTML Exception Report” on page 6-17
for a report sample and detailed information including field definitions. Also, refer to
your system-level reporting control library, members: MQRREXCP (standard report
statement sample), MQRREXCB (baseline report statement sample), MQRREXCM (mask
report statement sample).
COMPARE
This parameter is required to generate an HTML Exception Report.
BASELINE
This is an optional parameter. Use it to identify the DD name of the baseline database
to use for comparison. Be sure to insert a corresponding DD statement into the log
file used to generate the report. If you do not specify a baseline, then the report
compares the “actual” MQ_GET messages to the “expected” MQ_GET messages from
a single data collection.
Note: If you use the log file to generate the report, specify a primary database on the
SET SORTED statement. The MQREPT1 procedure, called by the log file,
provides a DD statement defining the SET SORTED value as DATABASE.
Either accept the default DATABASE parameter value on the CONTROL
statement or do not include a CONTROL statement to have Hiperstation for
WebSphere MQ define the primary database DD statement for you.
Reporting
6-7
MASK
This is an optional parameter to identify the DD name of the sequential dataset or
PDS member containing masking statements. Use masking statements to prevent
specified information from being compared. See “Masking Statements” on page 6-7.
Be sure to insert a corresponding DD statement into the log file used to run the
reporting job.
STOPON
This is an optional parameter. Use it to automatically end report generation once the
specified number of mismatches has occurred. For example, if you specify
STOPON(5), Hiperstation for WebSphere MQ reports no more information after the
fifth mismatch. Valid values are 1 to 9999.
TITLE
This is an optional parameter. Use it to specify a title that will appear at the top of
the report and in the title bar of the browser window. If you do not specify a title, the
report will be titled “Hiperstation for WebSphere MQ - Exception Report”.
INTO
This required parameter specifies the DD name of the HFS file that is to contain the
HTML report. Be sure to insert a corresponding DD statement into the log file used to
run the reporting job.
Masking Statements
Use data masking to prevent comparison of specified MQ message data. For example,
mask date and time fields to prevent generating mismatches for data you expect to be
different. Data masks are statements that specify qualification criteria and stipulate the
positions to mask if the criteria is met. Each statement consists of a WHEN and a MASK
clause.
Store all statements you wish to use for a given report in a sequential dataset or PDS
member. Specify a DD name on the MASK parameter of the REPORT statement. In the log
file used to run the reporting job, insert a corresponding DD statement for each mask
dataset that will be used for the reporting job.
If a given file contains multiple statements, Hiperstation for WebSphere MQ applies the
masking specification from the first true statement. The statement must be true for both
the “actual” and “expected” messages in order for the mask to apply.
Note:
In a baseline report, Hiperstation for WebSphere MQ uses the “actuals” from
the baseline as the “expected” values for the comparison.
Only one masking statement is applied to a given set of “actual” and “expected”
messages. Once a statement is applied, Hiperstation for WebSphere MQ processes the
next “actual” and “expected” message in the collected data.
The syntax of a masking statement is as follows:
WHEN(POSITION1, RO, VALUE) MASK(POSITION2:LENGTH2, ...)
POSITION1
Specify the starting position of the data to evaluate for masking qualification.
RO
Specify the relational operator (RO) to use for qualifying data for masking. You can
use either the RO code or symbol. Valid operators for:
6-8
– Character, Hexadecimal, or Packed Decimal data are:
Conditional RO Codes
RO Symbol
Description RO
EQ
=
Equal To
NE
\=
Not Equal
LT
<
Less Than
GT
>
Greater Than
LE
<=
GE
>=
Greater than or equal to
– Binary data are:
BIT RO Codes
RO Symbol
Bit RO
EQ
=
Specified bits are all ones
NE
\=
Specified bits are all zeros
NO
not applicable
Specified bits are not all ones
NZ
not applicable
Specified bits are not all zeros
MX
not applicable
Specified bits are mixed ones and zeros
VALUE
Specify the data value that completes the comparison argument. If the argument is
true, Hiperstation for WebSphere MQ masks the data specified by the MASK clause.
Place the value in single quotations and precede it with one of the following data
type indicators:
– C for Character, for example, C'Smith'
Character mask values are case-sensitive. For example, messages containing
Smith match the mask value above, while message containing SMITH do not.
– X for Hexadecimal, for example, X'0CDF'
Hexadecimal masking values must consist of an even number of hexadecimal
digits (0-9, A-F).
– P for Packed Decimal, for example, P'0001'
Packed decimal masking values must consist of decimal digits and can be
preceded by an optional sign (+-). Additionally, they must be less than 32 bytes.
– M for Binary Masks, for example, M'11000000'
Binary mask value must consist of eight binary digits that identify the bits,
within the specified byte (POSITION1 in WHEN clause), to consider for masking.
In the example above, Hiperstation for WebSphere MQ will examine the first two
bits of the specified byte.
POSITION2:LENGTH2
Specify the starting position and length of the data to mask. Specify multiple
positions and lengths by inserting a comma between each POSITION:LENGTH
parameter. For example, the following masking statement masks columns 4 through
11, 45 and 46 when columns 5 and 6 contain 03.
WHEN(5, EQ, C'03') MASK(4:8, 45:2)
Set length to 0 (zero) to mask the remainder of the message.
Response Time and Script Timing REPORT Statements
The REPORT statements for the Response Time and Script Timing Reports are virtually
the same except for the BASIC REPORT KEYWORD. See “Script Timing Summary” on page
6-20 and “Response Time Summary” on page 6-21 for a sample of each report and
Reporting
6-9
detailed information including field definitions. Also, refer to your system-level
reporting control library, members: MQRRRESP (response time report statement sample)
and MQRRSCRT (script time report statement sample).
BASIC REPORT KEYWORD
Follow REPORT with RESPONSETIME to generate a Response Time Summary or
SCRIPTTIME to generate a Script Timing Summary.
TYPE
This is an optional parameter. Use it to specify the format (TEXT or HTML) of the
report file. If you do not specify a type, Hiperstation for WebSphere MQ uses the type
specified on the CONTROL statement providing it is either HTML or TEXT. If CSV is
specified on the CONTROL or REPORT statement, you will receive an error. If you do
not specify a type on the CONTROL or REPORT statement, or you are not using a
CONTROL statement, TEXT is used.
TITLE
This is an optional parameter. Use it to specify a title to appear at the top of the
report and in the title bar of the browser window if you are generating an HTML
report. If you do not specify a title, the report is called “Hiperstation for
WebSphere MQ - Response Time Summary” or “Hiperstation for WebSphere MQ Script Timing Summary” depending on the BASIC REPORT KEYWORD.
INTO
This required parameter specifies the DD name for the dataset or HFS file that is to
contain the report. Be sure to insert a corresponding DD statement into the log file
used to run the reporting job. If your destination is SYSOUT, do not add a DD
statement. The reporting procedure called by the log file supplies a DD statement for
SYSOUT.
Note:
If you generate a TEXT version of the report, make sure the logical record
length (LRECL) of the reporting dataset is minimally 133.
REPORT Statement for Custom Reports
Just as there are six collection and reporting tables, there are six types of custom reports:
• PLAYBACK reports
• MQGROUP reports
• MQSCRIPT reports
• MQOPENQUEUE reports
• MQMESSAGESET reports
• MQMESSAGE reports
Report any combination of the fields from a given collection and reporting table,
providing you collected and saved the fields during unattended playback. For example,
report all fields from the PLAYBACK table to produce a Playback Summary. See Appendix
A, “Data Collection and Reporting Tables” for a list of the fields available for each type of
report.
Although you cannot include fields from multiple tables on a single report, you can
generate multiple reports from the same data collection in the same reporting run. For
instance, you cannot include an MQGROUP field on a PLAYBACK report, but you can
6-10
generate a PLAYBACK report and an MQGROUP report from the same data collection at
the same time. Create a REPORT statement for each report, save them in the same
reporting member, and use the log file to run the reporting job.
Build custom comparison reports by including the same reporting fields from multiple
unattended playback data collections. Qualify comparison fields with the name of the
applicable data collection. For example, to compare the number of message sets played
back in jobs PLAY1, PLAY2, and PLAY3 create a report member containing the following
statement and store it in your reporting control library:
REPORT FIELDS (MQMESSAGESETCOUNT,PLAY1.MQMESSAGESETCOUNT,PLAY2.MQMESSAGESETCOUNT)FROM(MQMESSAGESET) INTO(SYSOUT)
Use this reporting member during the third playback job or in a reporting job that uses
the third data collection (That is, SET SORTED = PLAY3).
The following syntax diagram shows all fields available on the custom REPORT
statement.
Note: TEXT reports in table layout print a maximum of six fields. HTML reports in table
layout print a maximum of 32 fields. Consider breaking large reports into several
Reporting
smaller reports to support printing or viewing them with standard paper or
terminal size.
6-11
6-12
LAYOUT
Whether the report will be in table (row, column) or form (one line per record)
format. Figure 6-1 and Figure 6-2 on page 6-5 show the same report in both table and
form layout.
TYPE
Format of the report, either TEXT, HTML, or CSV. TEXT reports are written in
EBCDIC and the LINK function is not valid. HTML reports support the LINK
function, which tells Hiperstation for WebSphere MQ to write that field’s value to a
separate file. A reference to that separate file appears in the HTML report as a link.
TITLE
This is an optional parameter. Use it to specify a title for the report. If you do not
specify a title, then the report is titled “Hiperstation for WebSphere MQ - Table
Report”, where table is the collection and reporting table specified on the FROM
clause.
FIELDS
See Appendix A, “Data Collection and Reporting Tables” to select the fields you wish
to report. In order to report a field, you must have collected it during unattended
playback. Even if you collected all possible fields, every field is not always available
for reporting. For example, message header fields cannot be sent by an application
during a particular transmission, and therefore would not be available to put in a
report.
Reporting
6-13
Use long or short field names to specify the fields to include in the report. The field
labels in the report appear as specified on the statement. That is, if the statement
includes short field names, the report will contain short field names. Additionally,
the fields appear in the report in the same order as specified on the REPORT
statement.
To report on every available field for a given table, use an asterisk (*) on the FIELDS
parameter - FIELDS (*).
Built-in function fields (AVG, MIN, MAX, LINK, and so on) are not automatically
included by using FIELDS (*). These fields must be explicitly requested in the format
FIELDS (*,AVG(xxxx)).
Any field names not fully qualified with a database name use the database name
supplied on the FROM keyword. If no database name is available on the FROM
keyword, the value supplied, or defaulted, by CONTROL DATABASE is used.
FROM
Specifies what kind of report to produce. The table name specified in the FROM
keyword is used to resolve field names specified by FIELDS(*) and validate the field
names specified in the FIELDS keyword. The optional database qualifier can be used
as explained under the FIELDS description.
WHERE
Use the WHERE clause to provide criteria for reporting only the data you need. For
example, to report all fields from the MQGROUP table for the second of five groups
in the reporting job, construct the REPORT statement as follows:
REPORT FIELDS (*) FROM (MQGROUP) WHERE (MQGroupNumber = 2)
SUBSTR
Produces a substring of the first argument. The second argument is the starting
position of the substring, and can have a minimum value of one (1). The third
argument is optional and is the length of the substring. If it is absent, the remainder
of the string is the new substring. The behavior of the SUBSTR function matches the
behavior of the REXX SUBSTR function.
The SUBSTR function is valid only on character fields. Other usage causes an error at
statement parsing time and ends the reporting jobstep.
SUBSTRX
The SUBSTRX keyword works the same way as the SUBSTR keyword, but displays the
value of the argument in hexadecimal characters.
DIFFERENCE
(DIFF) produces a number indicating the first byte position in a string that is
different from another string. The two arguments are the byte strings to be
compared. The strings can contain any values, including nonprintable characters.
Two strings that are identical result in a value of zero (0). The SUBSTR and
DIFFERENCE functions can be nested as “DIFFERENCE(SUBSTR(...))”.
LINK
Indicates that a field’s value should be shown as an HTML link in a report rather than
being shown directly in the report. The SUBSTR and LINK functions can be nested as
“LINK(SUBSTR(...))”.
Note:
Use of LINK in the WHERE clause is invalid. It is valid only as described.
6-14
Preparing the Log File for Reporting
When you create scripts, select the Log Entries option on the Create Script - Create
Options (2 of 2) panel (Figure 3-12 on page 3-17), to generate the log file used to run an
unattended playback job, a reporting job, or both. The log file contains a series of SET
statements that call reporting control assets. Most of the SET statement values default to
the system-level playback and report control library and member names. Override them
with your personal library information if necessary.
This section explains how to prepare the log for a reporting only job. See Chapter 5,
“Unattended Playback”, to learn how to generate reports during unattended playback.
To prepare the log for a reporting job:
1. Edit the values of the SET statements at the beginning of the log file. Refer to the SET
statement definitions following the sample log illustration (Figure 6-3 on page 6-15).
2. On the ANALYZE EXEC PROC= statement, replace MQPLAY1 with MQREPT1, the
reporting procedure.
3. Between ANALYZE EXEC PROC=MQREPT1 and LOGCOPY.INDD DD * insert a DD
statement for each:
– REPORT statement in the REPORT member that is to be written to a dataset for
HFS file. Do not add DD statements for reports written to SYSOUT. The MQREPT1
procedure provides a DD statement for SYSOUT.
– baseline database that is to be used for comparison reports.
– masking statement dataset that is to be used for an HTML Exception Report.
Note:
Refer to the “flower box” showing a sample DD statement defining an HFS
path and a sample statement defining a dataset.
4. When finished preparing the log, submit the job. See “Submitting the Job” on page
6-16.
Reporting
Figure 6-3. Sample Log File Prepared for Reporting Job
//jobcard
//*
/*JOBPARM SYSAFF=TEST
//UPROCS JCLLIB ORDER=('COMPWARE.SQVPPROC')
//*
//**********************************************************************
*
//**********************************************************************
//*
//
SET ACTION=NONE
//*
//
SET CNTLDS= COMPWARE.CONTROL
//
SET REPTDS= COMPWARE.REPORT
//*
//
SET SCRIPT= COMPWARE.SCRIPT
//
//
SET SORTED= USER253 .JAN04.AP.PLAY3
//*
//
SET COLLMEM=NONE
//
SET REPTCNTL=MQRCTT
//
SET REPTMEM=MQRCOMP
//*
//*
//ANALYZE EXEC PROC=MQREPT1
//*
//**********************************************************************
//*
*
//*
*
//*
*
//*
*
//*
*
//* //REPORT.ddname
DD PATHMODE=(SIRWXU,SIRGRP,SIROTH),
*
//* //
*
//* //
*
//*
*
//*
or
*
//*
*
//* //REPORT.ddname
*
//*
*
//**********************************************************************
//*
//LOGCOPY.INDD DD *
************************************************************************
*
*
* HIPERSTATION FOR WEBSPHERE MQ LOG STARTED ON 2006/07/10 AT 12:12:01 *
*
*
* DESC: TEST
*
*
*
*
* FILTER: 1
ACTION: INCLUDE
*
*
* OBJECT/QUEUE
EQ Q1
*
* EVENT
EQ PUT
*
* FILTER: 2
ACTION: INCLUDE
*
*
* OBJECT/QUEUE
EQ Q2
*
* EVENT
EQ GET
*
*
*
*
* DETAIL DATA IS TRANSLATED FROM ASCII TO EBCDIC
*
* SAMPLE DATA IS TRANSLATED FROM ASCII TO EBCDIC
*
*
*
*
* REPOSITORY NAME: COMPWARE.REPOS
*
* LOG . . . . . : COMPWARE.LOG(LOG004)
*
* SCRIPT . . . . : COMPWARE.SCRIPT
*
*
*
************************************************************************
* SCRIPT NUMBER(1)
*
MQGROUP ID(1)STIME('2006/06/26_10:55:59.885251')
SCRIPT(SCR004)
******************************* Bottom of Data *******************************
6-15
6-16
SET Statements
This section defines the SET statements that apply to reporting. All other statements
apply to unattended playback only. Since Hiperstation for WebSphere MQ ignores the
unattended playback SET statements during reporting, there is no need to modify their
values. See Chapter 5, “Unattended Playback” to learn about the statements that apply to
unattended playback only.
SET REPTDS
This statement identifies the report control library containing the assets you are
using for this job. By default, it points to the system-level report control library. This
statement must point to the library in which the REPORT and report CONTROL
members specified on the SET REPTCNTL and SET REPTMEM statements reside.
SET SORTED
This statement identifies the database to use for reporting. Complete this statement
with the name of the dataset that was collected and sorted during an unattended
playback job. The MQREPT1 procedure assigns DD name DATABASE to the dataset
you plug in here.
Note:
“DATABASE” is the default DD name on the DATABASE parameter of the
reporting CONTROL statement.
SET REPTCNTL
This statement identifies the report CONTROL member to use for the job. By default,
it calls MQRCTT from the system-level report control library. MQRCTT produces a
text-based report in table format that supports the default Script Analysis Report.
Override it with:
– Any report CONTROL member stored in the library specified on the SET REPTDS
statement.
– NONE if you do not need a reporting CONTROL member. If the specified REPORT
member provides all necessary control information, a report CONTROL member
is unnecessary.
SET REPTMEM
This statement identifies the REPORT member to use for the job. By default, it calls
MQRANLZ from the system-level report control library, which produces a default
Script Analysis Report (Figure 5-4 on page 5-21). Plug in the name of the desired
reporting member from the library specified on SET REPTDS.
Submitting the Job
To submit the reporting job, open the log file in an ISPF Edit session, type SUBMIT on the
Note:
You must be in Edit mode to submit the job.
Reading and Navigating Basic Reports
This section provides report samples and detailed information for each of the basic
reports.
Reporting
6-17
HTML Exception Report
A standard HTML Exception Report compares the MQ_GET messages that occurred
during playback (“actual”) to the MQ_GET messages recorded in the script (“expected”).
A baseline HTML Exception Report compares “actual” MQ_GET messages from two
unattended playback data collections. The “actuals” from the baseline database are used
as “expected” values for comparison.
Note: In an ANALYZE job (offline playback) the MQ_GET messages in the script are the
“actuals”. In an online playback job, the MQ_GET messages that resulted from
the playback are the “actuals”.
An HTML Exception Report presents a summary of mismatches at the top of report
followed by the “actual” and “expected” messages with highlighted differences. The
messages in the summary are hyperlinked to the messages in the detail. Depending on
the content of the script or the structure of the application you are testing, the report
may also include the MQ_PUT message related to the reported MQ_GET messages.
Note:
The report requires collecting several fields from several reporting and collection
tables. Use the default COLLECT member to collect all fields from all tables
ensuring the necessary data is available for this or any other report. Refer to
Chapter 5, “Unattended Playback”.
View the report with a supported Web browser. Scroll up and down to view the entire
report or click a message number in the summary to see the mismatch detail for that
message.
Figure 6-4 shows a mismatch summary and Figure 6-5 shows the corresponding
mismatch detail.
Figure 6-4. HTML Exception Report Mismatch Summary (Top of Report)
Field Definitions
The title specified on the REPORT statement or the default report title, Hiperstation for
WebSphere MQ - Exception Report, displays across the top of the window and in the title
bar. In a baseline report, the following fields come from the database entered on the SET
SORTED statement in the log file.
Run Date
The date and time that the unattended playback job was executed.
SYSID
The LPAR in which the playback job was executed.
Jobname
The playback job name.
Jobnumber
The playback job number.
6-18
Group Number
The number of the group in which the message was played back. Groups are
numbered sequentially.
Script Number
The number of the script containing the reported message. Scripts are numbered
sequentially within the group.
Script Name
The name of the script containing the reported message.
MessageSet Number
The connection number of the MessageSet (a group of related messages) containing
the reported message. MessageSets are numbered sequentially within a script.
Message Number
The reported message’s number. Messages are numbered sequentially within a
Message Set.
MQ Queue Manager and Queue
The MQ Queue Manager and Queue name associated with the reported message.
Figure 6-5. HTML Exception Report Mismatch Detail
Field Definitions
Each group of “expected” and “actual” messages is preceded by the associated Group
Number, Script Number, Script Name, Message Set Number, and Message Number. These
are the same fields presented in the summary at the top of the report. See “Field
Definitions” on page 6-17. Additionally, all of the fields displayed under the “expected”
message also display under the “actual” message. Although the values they present may
be different, the field definitions are the same.
Reporting
6-19
Expected MQGET Message
The “expected” MQ_GET message. In a standard exception report, this comes from
the script. In a baseline report, this comes from the baseline data collection. If the
baseline was generated from an:
– Online playback, this is the MQ_GET message that resulted from the playback.
– ANALYZE playback (offline playback), this is the MQ_GET message from the
script.
Mismatches are highlighted. Masked information displays in green text.
Message Type
The reported message’s type, for example, REQUEST, REPLY, DATAGRAM, or REPORT.
This comes from the MQ message descriptor (MQMD).
Note:
Message type is represented as an integer value in the MQMD. The HTML
Exception Report translates the value into text. Refer to IBM’s WebSphere
MQ documentation to learn more about message types.
Message Persistence
The reported message’s “persistence” setting. This comes from the MQMD.
Note:
Message persistence is represented as an integer values in the MQMD. The
HTML Exception Report translates the value into text. Refer to IBM’s
WebSphere MQ documentation to learn more about message persistence.
ReplyToQueueManger
The name of the Queue Manager to receive the reported message’s reply. This comes
from the MQMD. If the message is not supposed to reply, the MQMD does not
contain a ReplyToQueue, and this field displays the name of the queue manager that
the application was connected to during capture or playback.
ReplyToQueue
The name of the Queue to receive the reported message’s reply. This comes from the
MQMD. Not all messages reply. This field is blank if the message’s MQMD does not
possess this information.
MQ Message ID
The message ID from the reported message’s MQMD.
Correlation ID
The correlation ID from the reported message’s MQMD.
Actual MQGET Message
The “actual” MQ_GET message. In a standard exception report, this is the MQ_GET
message that resulted from the playback. In a baseline report, this comes from the
baseline data collection. If the baseline was generated from an:
– Online playback, this is the MQ_GET message that resulted from the playback.
– ANALYZE playback (offline playback), this is the MQ_GET message from the
script.
Mismatches are highlighted. Masked information displays in green text.
Message Start Time
The date and time the reported message was received.
Actual MQPUT Message
The MQPUT message related to the preceding MQGET message. This section appears
only if there is a correlating MQPUT message.
6-20
Note:
Figure 6-5 on page 6-18 does not show an “Actual MQPUT Message” because
the reported message type is a DATAGRAM, which does not expect a reply.
Script Timing Summary
A Script Timing Summary Report shows the amount of time it took for each script to play
back and provides additional timing statistics for the playback job.
Generate an HTML or TEXT version of the report. View the HTML version with a
supported web browser.
Figure 6-6 shows an HTML Script Timing Summary. Field definitions follow the
illustration.
Figure 6-6. HTML Script Timing Summary Report
Field Definitions
The title you specified on the REPORT statement or the default report title, Hiperstation
for WebSphere MQ - Script Timing Summary Report, displays across the top of the report.
In an HTML version, the report title also appears in the title bar of the browser window.
Run Date
The date and time that the playback job was executed. This field appears only on the
HTML version of the report.
Note:
The TEXT version of the report includes the date and time the report was
generated.
SYSID
The LPAR in which the playback job was executed. This field appears only on the
Jobname
The playback job name. This field appears only on the HTML version of the report.
Jobnumber
The playback job number. This field appears only on the HTML version of the report.
MQGroup Number
The number of the group in which the reported script was played back. Groups are
Script Name
The name of the script.
Reporting
6-21
Number
The number of the script being reported. Scripts are numbered sequentially within
the group.
Start Time
The date and time the given script began playing back.
Finish Time
The date and time playback completed for the given script.
Duration
The amount of time it took for the given script to play back.
MQGroup Total
A row of statistics for each MQGroup played back.
Number
The total number of scripts within the group.
Minimum Duration
The shortest playback duration in the group.
Maximum Duration
The longest playback duration in the group.
Average Duration
The average of all playback durations in the group.
Report Total
A row of statistics for the entire playback job.
Number
The total number of scripts played back.
Minimum Duration
The shortest playback duration in the job.
Maximum Duration
The longest playback duration in the job.
Average Duration
The average of all playback durations in the job.
Response Time Summary
A Response Time Summary Report shows the amount of time it took each group of
related messages to occur. For example, the amount of time it took to receive the
MQ_GET from the time the correlating MQ_PUT was sent.
Generate an HTML or TEXT version of the report. View the HTML version with a
supported Web browser.
Figure 6-7 shows an HTML Response Time Summary. Field definitions follow the
illustration.
6-22
Figure 6-7. HTML Response Time Summary Report
Field Definitions
The title you specified on the REPORT statement or the default report title, Hiperstation
for WebSphere MQ - Response Time Summary Report, displays across the top of the
report. In an HTML version, the report title also appears in the title bar of the browser
window.
Run Date
The date and time that the playback job was executed. This field appears only on the
Note:
The TEXT version of the report includes the date and time the report was
generated.
SYSID
The LPAR in which the playback job was executed. This field appears only on the
Jobname
The playback job name. This field appears only on the HTML version of the report.
Jobnumber
The playback job number. This field appears only on the HTML version of the report.
MQGroup Number
The number of the group in which the reported script was played back. Groups are
Script Name
The name of the script.
Number
The number of the message being reported. Messages are numbered sequentially
within the connection.
ID
The ID Hiperstation for WebSphere MQ assigns the message set, group of related
messages, during playback.
Start Time
The date and time the given message set began playing back.
Reporting
Finish Time
The date and time playback of the message set is completed.
Duration
The amount of time it took for the given message set to play back.
Total
A row of statistics for the given script.
Number
The total number of message sets within the script.
Minimum Duration
The shortest response duration within the script.
Maximum Duration
The longest response duration within the script.
Average Duration
The average of all response durations for the given script.
MQGroup Total
A row of statistics for each MQGroup played back.
Number
The total number of message sets within the group.
Minimum Duration
The shortest response duration in the group.
Maximum Duration
The longest response duration in the group.
Average Duration
The average of all response durations in the group.
Report Total
A row of statistics for the entire playback job.
Number
The total number of message sets played back.
Minimum Duration
The shortest response duration in the job.
Maximum Duration
The longest response duration in the job.
Average Duration
The average of all response durations in the job.
6-23
6-24
Reading Custom Reports (Field Definitions)
The following table lists custom reporting fields and provides definitions. See the IBM
WebSphere MQ manuals for additional information.
Table 6-1. Report Field Names and Descriptions
Field Name
Definition
ExpMQMessageAccountingToken (EXMQAT)
Expected value - from this field in the MQMessageDescriptor (MQMD).
ExpMQMessageApplIdentifyData (EXMQAI)
ExpMQMessageApplOriginData (EXMQAO)
ExpMQMessageBackoutCount (EXMQBC)
ExpMQMessageCharSetID (EXMQCS)
ExpMQMessageCorrelationID (EXMQCI)
ExpMQMessageEncoding (EXMQEN)
ExpMQMessageExpiry (EXMQEX)
ExpMQMessageFeedback (EXMQFD)
ExpMQMessageFormat (EXMQFM)
ExpMQMessageMsgID (EXMQMI)
ExpMQMessagePersistence (EXMQPS)
ExpMQMessagePriority (EXMQPR)
ExpMQMessagePutApplName (EXMQPN)
ExpMQMessagePutApplType (EXMQPA)
ExpMQMessagePutDate (EXMQPD)
ExpMQMessagePutTime (EXMQPT)
ExpMQMessageReplyToQueue (EXMQRQ)
ExpMQMessageReplyToQueueMgr (EXMQRM)
ExpMQMessageReport (EXMQRO)
ExpMQMessageType (EXMQTY)
ExpMQMessageUserIdentifier (EXMQUI)
ExpMQMessageVersion (EXMQMV)
Expected value - from this field in the MQMessageDescriptor (MQMD). S
MQGroupDuration (MQDR)
Amount of time it took for a particular MQGroup to play back.
MQGroupFinishTime (MQFT)
The time that a particular MQGroup completed playback.
MQGroupID (MQID)
Value specified by the ID parameter of the MQGroup statement.
MQGroupNumber (MQNU)
Order in which the MQGroup statement appears within the control cards.
MQGroupReturnCode (MQRC)
Playback return code for a particular MQGroup.
MQGroupStartTime (MQST)
The time that a particular MQGroup began playback.
MQGroupStatementCount (MQCN)
Number of MQGroup statements in the playback.
MQMessageAccountingToken (MQAT)
Actual value - from this field in the MQMessageDescriptor (MQMD).
MQMessageApplIdentifyData (MQAI)
MQMessageApplOriginData (MQAO)
MQMessageBackoutCount (MQBC)
Reporting
6-25
Field Name
Definition
MQMessageCharSetID (MQCS)
MQMessageCorrelationID (MQCI)
MQMessageCountMessageSet (MQMC)
Number of MQMessage entries related to a particular MQMessageSet.
MQMessageCountQueue (MQCQ)
Number of MQMessage entries related to a particular MQOpenQueue.
MQMessageEncoding (MQEN)
MQMessageExpectedInbound (MQME)
Data from the GET of the queue during the recording.
MQMessageExpiry (MQEX)
MQMessageFeedback (MQFD)
MQMessageFormat (MQFM)
MQMessageID (MMID)
ID associated with the MQMessage.
MQMessageInbound (MQMB)
Data from the GET of the queue.
MQMessageMsgID (MQMI)
MQMessageNumber (MMNU)
Order in which the WebSphere MQ request appears within the script.
MQMessageOutbound (MQMO)
Data PUT to the queue.
MQMessagePersistence (MQPS)
MQMessagePriority (MQPR)
MQMessagePutApplName (MQPN)
MQMessagePutApplType (MQPA)
MQMessagePutDate (MQPD)
MQMessagePutTime (MQPT)
MQMessageQueueManagerAndQueue (QMAQ) Field composed of the queue manager name and the queue name,
separated by a colon.
MQMessageReplyToQueue (MQRQ)
MQMessageReplyToQueueMgr (MQRM)
MQMessageReport (MQRO)
MQMessageSetCount (MSSC)
Number of MQMessageSets found for a specific MQScript.
MQMessageSetDuration (MSSD)
Amount of time it took for a particular MQMessageSet to play back.
MQMessageSetFinishTime (MSTF)
The time that a particular MQMessageSet completed playback.
MQMessageSetID (MMSI)
ID associated with the MQMessageSet.
MQMessageSetNumber (MSSN)
Order in which the message set appears within the script.
MQMessageSetStartTime (MSTS)
The time that a particular MQMessageSet began playback.
MQMessageType (MQTY)
MQMessageUserIdentifier (MQUI)
MQMessageVersion (MQMV)
MQOpenQueueAttempted (MQOA)
Number of attempts at opening this message queue.
MQOpenQueueCount (MQOC)
Number of WebSphere MQ queues opened for a specific MQScript.
MQOpenQueueDuration (OQDR)
Amount of time it took for a particular MQScript to play back.
MQOpenQueueFailed (MQOF)
Number of failed attempts at opening this message queue.
MQOpenQueueFinishTime (CLQT)
The time that a particular MQOpenQueue completed playback.
6-26
Field Name
Definition
MQOpenQueueID (OQID)
ID associated with the <MQ_OPEN> tag.
MQOpenQueueManagerName (QMNA)
WebSphere MQ queue manager name in use.
MQOpenQueueMessageRate (MQMR)
Average rate that messages are processed for a particular MQOpenQueue.
MQOpenQueueName (QNAM)
WebSphere MQ queue name in use.
MQOpenQueueNumber (OQNU)
Order in which the <MQ_OPEN> tag appears within the script.
MQOpenQueueStartTime (OPQT)
The time that a particular MQOpenQueue began playback.
MQOpenQueueStatus (MQOP)
Indicates how the queue was closed (either by Hiperstation for
WebSphere MQ or WebSphere MQ). 3 indicates there was not a close in
the script; 1 indicates there was a close in the script.
MQScriptDuration (MQSD)
Amount of time it took for a particular MQScript to play back.
MQScriptFinishTime (MSCF)
The time that a particular MQScript completed playback.
MQScriptName (MSCN)
Name of the script being played back.
MQScriptNumber (MQSN)
Order in which the MQScript statements appear within the MQGroup
statement.
MQScriptReturnCode (MSRC)
Playback return code for a particular MQ script.
MQScriptStartTime (MSCS)
The time that a particular MQScript began playback.
MQScriptStatementCount (MQSC)
Number of MQScript statements for a specific MQGroup.
7-1
Chapter 7.
Archive Functions
Chap 7
Introducing the Archive Function
Hiperstation is a zSeries automated testing solution that enables systems and applications
programmers and quality assurance personnel to streamline the testing process and
improve the quality of their applications. In addition to automated testing, Hiperstation
can address other business issues as well, specifically, security monitoring.
Using Hiperstation as a Security Monitoring Tool
Today's mainframe application organizations use two standard facilities for managing
security. First, security systems prevent unauthorized users from logging on and then
controlling access privileges of authorized users. Second, monitoring facilities, such as
System Management Facilities (SMF), log a variety of activities performed by the user,
including opening datasets and logging off. Most organizations have programs that postprocess their SMF records to produce audit reports.
Hiperstation can provide what these facilities lack, which is an in-depth record of the
detail on each screen the user accessed on their terminal. Hiperstation's Auditing Archive
Recording feature allows you to record all users of a given application that you want to
monitor, select users across all of the applications that they use, and for VTAM,
document each keystroke and screen that the user sees. Hiperstation can be likened to an
electronic security camera installed directly behind the user. The user is not aware that
the recording is taking place unless the security team chooses to disclose this
information.
Hiperstation is the watchdog for users who are able to gain access to the mainframe and
are able to navigate throughout the system. Rather than relying only on security
violations and SMF records, the Hiperstation script is a true picture of what the user saw
and did.
Implementing Hiperstation as a Security Monitoring Tool
Implementing Hiperstation for WebSphere MQ as a security-monitoring tool requires
analysis and agreement between management and the system implementation team. You
need to decide:
• Whether to monitor all mainframe users or just a selected group of users
• Whether to record groups or users in separate recordings or all together in one.
• Whether to record continuously
• Who will be responsible for administering the recording
• Where to store the recorded data and scripts in secured files
• Who will be accountable for the web reports
• How long to store the recorded data
• How to analyze the web reports
7-2
After you decide what to do about these issues, an implementation plan can be
developed. Although the details will vary slightly, the general task list includes the
following items:
• Set up and start Global Recording. Compuware recommends that you integrate the
Global Recording Started Task into the IPL process. This allows data capture to begin
immediately with any IPL.
• Implement your Archive Audit Request scheme (for example, how many requests
record which users, terminals or applications). Use the Name and Description fields
to help convey the probable contents of each Archive Audit Request to the users.
• Train your Search users to use the tool effectively (for example, restricting date/time
of searches to save processing time and DASD space consumption).
• Ensure that users who plan to execute the Search Tool against the Archive Audit
Requests understand the Archive Audit Request schemes.
• Ensure RACF controls are in place to provide proper access protection to the Archive
Audit Repositories.
• Encourage Search users to build a repository of shared search criteria wherever
possible.
• Set goals for report management (for example, cleanup and final disposition of Web
Reports) by the Search users.
Summary
Hiperstation can provide an organization with a comprehensive audit trail of online user
activity. Unlike other auditing processes that require looking at security logs and SMF
records, Hiperstation provides a complete audit trail of what the user executed on their
terminal with the application in question. The Archive Search Web Report capability
gives the auditor the ability to step through each screen the user viewed. The auditor will
see all traffic for that user from logon to logoff.
The benefit of using Hiperstation for security monitoring can be summed up in two
words: maximum accountability. By combining the analysis potential of Hiperstation
scripts with existing security tools, the security auditor is able to analyze and quantify
the impact of all security breaches.
Figure 7-1. Hiperstation Archive Recording Setup Screen
Hiperstation ------------Command ===>
3270 - Archive Criteria
------------------------
Press ENTER to continue, or PF1 for help, or CANCEL to exit.
Name . . . . . . . . CICSPROD
Description. . . . . Capture All Data for Region CICSPROD
Repository Registry Dataset. . . ‘CICSPROD.ALLDATA’
Terminal . . . . . . . . .
Application. . . . . . . .
Userid . . . . . . . . . .
OR
Global Record Manager List
. . *
Use an asterisk for wildcarding
. . CICSPROD the Terminal, Application or Userid
. . *
fields.
. .
MM / DD / YYYY
Start Date . . . 00 / 00 / 0000
End Date . . . . 00 / 00 / 0000
Second filter GRM List . .
HH : MM : SS
Start Time . . . 00 : 00 : 00
End Time . . . . 00 : 00 : 00
(Optional)
(Optional)
Figure 7-1 shows the Archive Criteria setup screen. In this example, we are capturing all
of the activity for our CICSPROD region, regardless of terminal ID or user ID. Notice that
Archive Functions
7-3
there is no specified start or end date or time. Therefore, our recording will continue
24x7 as long as the Global Recording Started Task is running.
We have specified a meaningful NAME and DESCRIPTION for the request. We have also
specified a Repository Registry Dataset of CICSPROD.ALLDATA. This name will be used to
generate the Registry Dataset (VSAM file containing date/time indexes to the created
repository segments). The Repository Registry Dataset name will also be used to generate
the dataset names of the repository segments by adding a sequence number to it (for
example, #0000001, #0000002, etc.).
Searches can be performed automatically against any repository segment that has filled
up and switched, or has been switched manually, with an e-mail notification being sent
to the owner of the request.
Note:
E-mail notification is set up using Hiperstation profiles. See the Hiperstation
Installation Guide for details.
Using the Archive Function
For complete details on how to use the Archive Function, see the Hiperstation Auditor User
Guide.
7-4
8-1
Chapter 8.
Testing Scenarios
Chap 8
This chapter provides comprehensive testing scenarios to teach you how to use
Hiperstation for WebSphere MQ.
These scenarios are based on testing a Customer Order and Credit Inquiry application that is
detailed on page 8-1. These are progressive examples. That is, concepts presented in the
earlier scenarios are used in subsequent scenarios and the testing strategies become more
advanced with each scenario.
To help you conceptualize these scenarios, this release supplies the following samples
generated from the example application:
• Repositories containing activity captured with Global Recording. Find these
repositories in your system-level repositories datasets.
• Scripts generated from those repositories. Some of the scripts have been modified to
support the given testing scenario. Locate the script files in the script library
(SQQFSCRP).
• Logs files generated during script creation. Some of the log files have been modified
to support the given testing scenario. Find the log files in your system-level playback
control library.
• External Files generated from playing back modified scripts. These files are used as
input for other testing scenarios. Find these files in the Hiperstation samples library
(SQQFSAMP).
• A script analysis control member, discussed in Chapter 5, “Unattended Playback”.
Find the ANALYZE member in your system-level playback control library.
• Report control and report members, discussed in Chapter 6, “Reporting”. Find these
assets in your system-level report control library.
Each scenario provides a list of supporting sample files. See Appendix B, “Hiperstation for
WebSphere MQ Samples Index” for a list of all sample files ordered alphabetically.
Use the samples, along with the appropriate instructional chapters, to replicate the tasks
involved in each scenario. For example, using a sample capture repository in Chapter 3,
“Scripts and Subset Repositories”, create scripts with the filtering specifications from a
given scenario. Verify your work by comparing the scripts you create to the sample
scripts, as described in “Analyzing and Comparing Scripts” on page 8-52.
Understanding the Example Application’s Data Flow
The scenarios presented in this chapter are based on an example customer order and
credit inquiry application that is comprised of three programs:
• PDA016 Customer Order Inquiry program
• PDA017 Customer Order Inquiry Processing program
• PDA018 Credit Inquiry program
The application communicates with a remote application that returns information
necessary for PDA018 processing.
8-2
In order to understand these testing scenarios, you must understand the application’s
data flow. Refer to Figure 8-1 on page 8-3 as you read through the following processing
description. The circled numbers on the illustration correspond to the following steps.
1. Processing begins with a customer order and credit inquiry request. PDA016
(Customer Order Inquiry Program) receives the request and issues:
– An MQ_PUT to the MQ Customer Order Inquiry Queue that triggers PDA017
(Customer Order Inquiry Processing Program).
– An MQ_GET with a wait interval to the MQ Customer Order Inquiry Response
Queue to be satisfied when PDA017 completes processing.
– An MQ_GET with a wait interval to the MQ Credit Inquiry Response Queue to be
satisfied when PDA018 completes processing.
2. PDA017 responds to the triggering MQ_PUT from PDA016 and issues an MQ_GET to
MQ Customer Order Inquiry Queue.
3. PDA017 locates the customer’s order information and issues:
– An MQ_PUT to the MQ Customer Order Inquiry Response Queue that answers
the MQ_GET from PDA016.
– An MQ_PUT to the MQ Credit Inquiry Queue that triggers PDA018 (Credit
Inquiry Program).
PDA017 processing is complete.
4. PDA018 responds to the triggering MQ_PUT from PDA017 and issues an MQ_GET to
the MQ Credit Inquiry Queue.
5. PDA018 begins processing by issuing:
– An MQ_PUT to the remote Credit Bureau Inquiry Queue that will drive remote
processing.
– Three MQ_GETs to Credit Bureau Inquiry Response Queue with wait intervals.
6. After the MQ_GETs are satisfied with responses or expire, PDA018 determines credit
authorization and issues an MQ_PUT to MQ Credit Inquiry Response Queue, which
answers the MQ_GET from PDA016.
Testing Scenarios
Figure 8-1. Flowchart for the Sample Customer Order And Credit Inquiry Application
8-3
8-4
Playing Back Multiple Scripts Serially
This scenario demonstrates playing back the same script serially, multiple times, to
ensure the application behaves consistently.
It begins by capturing activity from the entire customer order and credit inquiry
application (Figure 8-1 on page 8-3); then generating a script containing only the activity
produced by the PDA016 Customer Order Inquiry Program (Figure 8-2). The script drives
the rest of the application during playback. PDA017 Customer Order Inquiry Program
and PDA018 Credit Inquiry Program should respond to a given request the same way
each time the script is played back. For example, if the script contained a single
transaction requesting Bill Smith’s order and credit authorization, PDA017 and PDA018
should return Bill Smith’s order information and the same credit authorization each time
you play back the script.
Figure 8-2. Activity Captured in Sample Script SCRMS000
This scenario also requires editing the script and the SCRIPT statements in the log file
before submitting the unattended playback job.
The rest of this section details each of these steps, except for capture. Use the filtering
information provided in this discussion to generate scripts from sample repository
REPOS1. Then 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.
Supporting Sample Files
The sample files supporting this scenario include:
Testing Scenarios
8-5
• Repository: REPOS1
• Log: LOGMS000
• Script:
SCRMS000 (original script),
SCRMS001 (contains all but the MQ_DISCONNECTS from the original script),
SCRMS002 (contains all MQ_DISCONNECTs associated with the activity in the
original script)
Filters
REPOS1 contains activity for the entire customer order and credit inquiry program
(Figure 8-1 on page 8-3). Apply the following three filters during script creation to
generate a script containing only PDA016’s activity. Refer to Figure 8-2 on page 8-4 to see
the application flow of PDA016 and the names of the queues it uses.
Filter 1
Field Name
Queue manager
EQ *
Object/Queue name EQ PDAPROD.H01AC013.CUSTOMER.QUEUE.ALIAS
Event
EQ PUT
Filter 2
Field Name
Queue manager
EQ *
Object/Queue name EQ PDAPROD.H01AC013.CUSTOMER.RESPONSE.QUEUE.ALIAS
Event
EQ GET
Filter 3
Field Name
Queue manager
EQ *
Object/Queue name EQ PDAPROD.H01AC013.CREDIT.AUTH.RESP.QUEUE.
Event
Note:
EQ GET
Enter this filtering information on the Header Filter Detail screen (Figure 3-5 on
page 3-7) in the Create MQ Script facility. Also, be sure to select the Log Entries
field on the WebSphere MQ Create Scripts - Create Options screen (2 of 2) to
generate a LOG file that you can compare to the sample LOG file.
Script and Log Editing Requirements
Serial playback of multiple scripts or the same script multiple times is achieved by
placing the appropriate SCRIPT statements under the same MQGROUP statement.
Hiperstation for WebSphere MQ processes all activity on a connection ID until an
MQ_DISCONNECT is encountered. After the disconnect is processed, that connection ID
cannot be used again during playback of the given MQGROUP. The Connection IDs
within a script are numbered sequentially. Therefore, two scripts will contain minimally
one connection ID that is the same. If you plan to serially play back the same script, the
same connection IDs are processed for each replay. To avoid failed connections during
replay, remove the MQ_DISCONNECTS from all scripts within the group and save them
8-6
in a separate PDS member. Play this member back as the last script in the group to
process the MQ_DISCONNECTs.
Refer to the following samples to see how this is done.
• SCRMS000 contains all of the activity for PDA016.
• SCRMS001 has had the MQ_DISCONNECTs edited out.
• SCRMS002 contains the removed MQ_DISCONNECTs.
After you have edited the disconnects out of the scripts, open the LOG file you generated
while creating your scripts. Scroll to the bottom to locate the script statements. The
SCRIPT statement in your LOG file should look something like this, except the script
name (SCRMS000) will reflect the name you provided.
* SCRIPT NUMBER(1)
MQGROUPID(1)STIME('2006/06/26_10:55:54.685787')
SCRIPT(SCRMS000)
1. Change the script name to point to the script without the MQ_DISCONNECTs.
2. Either add the REPEAT parameter to the SCRIPT statement or copy the SCRIPT
statement as many times as desired to play it back. See “SCRIPT Statement” on page
5-11.
3. At the end, add a SCRIPT statement to play back the file containing the
MQ_DISCONNECTS.
Sample LOG file LOGMS000 reflects these edits:
* SCRIPT NUMBER(1)
MQGROUPID(1)STIME('2006/06/26_10:55:54.685787')
SCRIPT(SCRMS001)
SCRIPT(SCRMS001)
SCRIPT(SCRMS001)
SCRIPT(SCRMS002)
Playing Back Scripts Simultaneously (Multiple Groups)
This scenario demonstrates playing back one or more scripts simultaneously to ensure
the integrity of the MQ activity propagated by the application. For example, the sample
application can be accessed by several phone operators at the same time. Use this type of
testing to ensure the application will perform efficiently if accessed by multiple users.
This scenario begins by capturing activity from the entire customer order and credit
inquiry application (Figure 8-1 on page 8-3) and then generating three scripts:
• One containing the MQ_PUTs issued by PDA016
• One containing the MQ_GETs issued by PDA016 to retrieve customer order
information from PDA017
• One containing the MQ_GETs issued by PDA016 to retrieve credit authorization from
PDA018
Testing Scenarios
8-7
Figure 8-3. Activity Captured in Sample Scripts SCRMG001, SCRMG002, SCRMG003
The scripts then drive the rest of the application during playback. PDA017 Customer
Order Inquiry Program and PDA018 Credit Inquiry Program should respond to each
request in approximately the same amount of time. During playback, generate a Script
Timing Summary (page 6-20) and Response Time Summary (page 6-21) to review the
application’s performance.
This scenario requires manually combining the LOG files from each script creation before
submitting the unattended playback job.
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. Generate a baseline HTML Exception
Report to ensure that the script you created contains the same activity as the sample
script.
• Log:
LOGMG001
LOGMG002
LOGMG003
LOGMG000
The first three logs were generated during script creation. The last was created
manually. It is combination of the first three logs.
8-8
• Script:
SCRMG001 (contains the MQ_PUT issued by PDA016)
SCRMG002 (contains the MQ_GET issued by PDA016 to retrieve customer order
information from PDA017)
SCRMG003 (contains the MQ_GET issued by PDA016 to retrieve credit authorization
from PDA018)
Filters
(Figure 8-1 on page 8-3). Run through script creation three times to generate three scripts
and three logs. Apply the following filters to isolate the desired activity. See Figure 8-3 on
page 8-7 to see the application flow of PDA016 and the names of the queues it uses.
To create a script containing the MQ_PUT issued by PDA016, apply the following filters:
Field Name
Queue manager
EQ *
Event
EQ PUT
To create a script containing the MQ_PUT issued by PDA016 to retrieve customer order
information from PDA017, apply the following filters:
Field Name
Queue manager
EQ *
Event
EQ GET
To create a script containing the MQ_PUT issued by PDA016 to retrieve credit
authorization information from PDA018, apply the following filters:
Field Name
Queue manager
EQ *
Object/Queue name EQ PDAPROD.H01AC013.CREDIT.AUTH.RESP.QUEUE.
Event
Note:
EQ GET
generate a LOG file that you can compare to the sample LOG files.
Log Editing Requirements
Simultaneous playback of multiple scripts or the same script multiple times is achieved
by placing the appropriate SCRIPT statements under separate MQGROUP statements. The
log file generated during script creation always places the SCRIPT statements in a single
group. Use a standard file editing tool to create a copy of the first log file. Give it a
unique name. Then copy the MQGROUP and SCRIPT statements from the second log
files and paste them into the new log file. Additionally, each MQGROUP statement will
have an ID of 1. Give each group a unique ID for reporting purposes. See the following
samples to see how this is done.
• LOGMG001 contains the MQGROUP and SCRIPT statements for SCRMG001.
Testing Scenarios
8-9
• LOGMG000 contains the MQGROUP and SCRIPT statements from the previous three
logs.
Repeating Simultaneous Playback (Count and Repeat)
This scenario demonstrates playing back a group of one or more scripts simultaneously,
then repeating the simultaneous playback.
inquiry application (Figure 8-1 on page 8-3), then generating a script containing only
some of the activity produced by the PDA018 Credit Inquiry Program. For each customer
credit inquiry, PDA018 issues an MQ_PUT to the remote inquiry queue and three
MQ_GETs with wait intervals to the response queue.
Figure 8-4. Activity Captured in Sample Script SCRCR001
8-10
The script then drives remote processing.
During playback, generate a:
• Script Timing Summary (page 6-20) and Response Time Summary (page 6-21) to
review the remote processing performance.
• HTML Exception Report (page 6-17) to compare recorded remote processing
responses to the responses received during playback. You can also generate a custom
comparison report in TEXT or CSV format.
This scenario requires adding the appropriate parameters to the MQGROUP statement in
the LOG file before submitting the unattended playback job.
REPOS1. If you wish to compare the scripts you generate to the sample scripts, run an
script.
• Log: LOGCR000
• Script: SCRCR001
Filters
(Figure 8-1 on page 8-3). Apply the following filters during script creation to generate a
script containing PDA018’s credit inquiry and response retrieval activity. See Figure 8-4
on page 8-9 to view the application flow of PDA018 and the names of the queues it uses.
Filter 1
Field Name
Queue manager
EQ *
Object/Queue name EQ PDAPROD.QREMOTE.CW01.TO.CW09.CREDIT.AUTH
Event
EQ PUT
Filter 2
Field Name
Queue manager
EQ *
Object/Queue name EQ PDAPROD.QLOCAL.CW09.TO.CW01.CREDIT.AUTH
Event
Note:
EQ GET
Testing Scenarios
8-11
To achieve repeated, simultaneous group playback, add COUNT and REPEAT parameters
to the MQGROUP statement in the log file before submitting the playback job.
• COUNT(x) plays X instances of the MQGROUP. All instances simultaneously begin
playback.
• REPEAT(y) repeats the playback y times.
Refer to sample log LOGCR000 for an example of the statement syntax.
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” on page 8-4 to find out how and why you need to do this.
Synchronizing Group Playback (USESTIME)
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 (Figure 8-1 on page 8-3), 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.
8-12
Figure 8-5. Activity Captured in Sample Script SCRTS001
During playback, generate a:
• Script Timing Summary (page 6-20) and Response Time Summary (page 6-21) to
review the remote processing performance.
• HTML Exception Report (page 6-17) 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” on page 8-52.
Testing Scenarios
8-13
• Log: LOGTS000
• Script: SCRTS001
Filters
Filter 1
Field Name
Queue manager
EQ *
Event
EQ PUT
Filter 2
Field Name
Queue manager
EQ *
Event
Note:
EQ GET
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).
Note:
Playback CONTROL statements added to the log file are concatenated to the
CONTROL statement in the playback control member specified on the SET
ACTION statement.
Multiple Scripts Serially” on page 8-4 to find out why you need to do this and how.
8-14
Controlling Playback Timing (USESTIME and THOPT)
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.
Hiperstation for WebSphere MQ uses the difference between <TIME> tags to determine
the amount of time to wait before playing the next transaction.
Note:
Due to processing capacity available during playback and/or system throttling of
batch playback, the playback duration may be longer than the recording
duration.
This scenario entails capturing activity from the entire customer order and credit inquiry
application (Figure 8-1 on page 8-3), 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.
Testing Scenarios
8-15
Figure 8-6. Activity Captured in Sample Script SCRTD001
During playback, generate:
• A Script Timing Summary (page 6-20) and Response Time Summary (page 6-21) to
review the remote processing performance and ensure application resources are
available when subsequent groups play back.
• An HTML Exception Report (page 6-17) 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.
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” on page 8-52.
8-16
• Log: LOGTD000
• Script: SCRTD001
Filters
script containing the credit inquiry of PDA018 and response retrieval activity. Refer to
Figure 8-6 on page 8-15 to see the application flow of PDA018 and the names of the
queues it uses.
Filter 1
Field Name
Queue manager
EQ *
Event
EQ PUT
Filter 2
Field Name
Queue manager
EQ *
Event
Note:
EQ GET
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).
Note:
Playback CONTROL statements added to the log file are concatenated to the
CONTROL statement in the playback control member specified on the SET
ACTION statement.
Testing Scenarios
8-17
Multiple Scripts Serially” on page 8-4 to find out how and why you need to do this.
Reversing Playback (PLAY_TO)
This scenario demonstrates using the PLAY_TO parameter to reverse playback. That is,
Hiperstation 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.
Figure 8-7. 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
8-18
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.
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
script. See “Analyzing and Comparing Scripts” on page 8-52.
• 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
Field Name
Queue manager
EQ O530
Object/Queue name EQ PDAPROD*
Testing Scenarios
Field Name
Event
EQ GET
Note:
8-19
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.
Note:
In batch processing, Hiperstation for WebSphere MQ gives a unique
connection ID to each MQ_CONNECT that occurred during the job. In
foreground processing, such as CICS applications, each transaction bears a
unique connection ID. Specify one or more connection IDs on the
CONNECTION_ID(x) parameter.
Refer to sample LOGPT000 to see these edits.
Overriding Queues (FROM_QUEUE/TO_QUEUE)
This scenario demonstrates using the following MQGROUP statement parameters:
• QUEUE_MANAGER to play back a script in a test environment.
• PLAY_TO with GET_FROM_QUEUE and PUT_TO_QUEUE to reverse playback and
direct application requests and responses to the queues in a test environment. That
is, Hiperstation for WebSphere MQ plays MQ_GETs as MQ_PUTs and vice versa.
Reversing playback, in the scenario, populates the initial inquiry queue with requests
that were retrieved by the subject application during recording. It also empties the
response queue at the end of processing and allows you to compare the application’s
recorded responses to the responses resulting from playback.
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.
8-20
Figure 8-8. Activity Captured in Sample Script SCRTQ001
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 perform the test without involving the remote location, capture the Credit
Bureau Processing Program’s activity, build a script containing the GETs and PUTs, and
play back the script in reverse. Hiperstation for WebSphere MQ plays:
• The GETs as PUTs, which put the recorded requests into the inquiry queue, thus
driving application activity. As soon as requests exist in the inquiry queue, the
application automatically GETs the requests and begins processing.
• The PUTs as GETs, which empty the response queue at the end of processing.
Generate a report, such as the HTML Exception Report, that compares the reversed
PUTs to the PUTs resulting from playback to ensure the application responded as
expected.
Testing Scenarios
8-21
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.
• Log: LOGTQ000
• Script: SCRTQ001
Filters
REPOS3 contains Credit Bureau Processing Program activity from the production
environment that uses queue manager O530. It also contains activity from the CHIN and
remote queue transmission activity that MQ performed. To generate a script containing
only the MQ_GETs and MQ_PUTs that the application issued, apply the following filters
during script creation.
Filter 1
Field Name
Queue manager
EQ O530
Event
EQ GET
Filter 2
Field Name
Queue manager
EQ O530
Event
Note:
EQ PUT
Add the following parameters to the MQGROUP statement in the log file used to run the
unattended playback job:
• QUEUE_MANAGER(M530)
to play back the script on the test system (M530) instead of the production system
(O530).
8-22
• PLAY_TO(CONNECTION_ID(2) on (PDAPRO.QLOCAL.CW01.TO.CW09.CREDIT.AUTH) GET_FROM_QUEUE(TEST.Q1))
to reverse the playback of CONNECTION_ID(2) activity that occurred on the
production inquiry queue against the test inquiry queue. In other words, populate
TEST.Q1 with the requests that were retrieved by the application from the production
inquiry queue during recording.
• PLAY_TO(CONNECTION_ID(2) on(PDAPRO.QREMOTE.CW09.TO.CW01.CREDIT.AUTH) PUT_TO_QUEUE (TEST.Q2))
to reverse the playback of CONNECTION_ID(2) activity that occurred on the
production response queue against the test response queue. In other words, empty
TEST.Q2 by playing the recorded PUTs as GETs, thus getting the responses that were
PUT there by the application during playback.
Note:
In batch processing, Hiperstation for WebSphere MQ gives a unique
connection ID to each MQ_CONNECT that occurred during the job. In
foreground processing, such as CICS applications, each transaction bears a
unique connection ID. Specify one or more connection IDs on the
CONNECTION_ID(x) parameter.
Refer to sample LOGTQ000 to see these edits.
Omitting Specified Activity (SKIP(CONNECTION_ID))
This scenario demonstrates using the SKIP(CONNECTION_ID) parameter on the
MQGROUP statement to prevent specified activity from playing back.
Customer order and credit inquiry application processing begins when PDA016 issues a
PUT to the Customer Order Inquiry Queue, a GET to the Customer Order Inquiry
Response Queue, and a GET to the Credit Inquiry Response Queue (Figure 8-9 on page
8-23). This activity drives the rest of the application. Play back PDA016 activity to test
PDA017 and PDA018. To accomplish this, capture activity from the application and
either filter out PDA017 and PDA018 activity during script creation or generate an
unfiltered script and use the SKIP(CONNECTION_ID) parameter to prevent PDA017 and
PDA018 activity from playing back. Generate an:
• Event Summary during script creation to review the events in the script and select
the appropriate connections to omit. You may also need to review the message
contents in the script to select the appropriate connections.
• Exception report during playback to compare the recorded responses from PDA017
and PDA018 to the responses resulting from playback.
The customer order and credit inquiry application runs in a CICS environment.
Hiperstation for WebSphere MQ gives each MQ transaction in a foreground processing
environment a unique connection ID. For instance, a script containing one complete
customer order and credit authorization inquiry would contain:
• CONNECTION_ID(1) consisting of an MQ_OPEN, the MQ_PUT and two MQ_GETs
that PDA016 issued, an MQ_CLOSE, and an MQ_DISCONNECT.
• CONNECTION_ID(2) consisting of an MQ_OPEN, the MQ_GET and two MQ_PUTs
that PDA017 issued, an MQ_CLOSE, and an MQ_DISCONNECT.
• CONNECTION_ID(3) consisting of an MQ_OPEN, the MQ_GETs and MQ_PUTs that
PDA018 issued, an MQ_CLOSE, and an MQ_DISCONNECT.
Note:
For applications using batch processing, Hiperstation for WebSphere MQ gives a
unique connection ID to each MQ_CONNECT that occurred during the job.
The rest of this section lists the sample files supporting this scenario and describes log
file edits necessary to prevent PDA017 and PDA018 activity from playing back.
Testing Scenarios
8-23
Figure 8-9. Activity from REPOS1 to Play Back
This scenario details skipping connections during playback of a CICS application script.
However, there are also samples that reflect using this parameter to skip connections
while playing back a batch processing application script.
• Repository: REPOS1 (CICS Application Capture Repository)
REPOS4 (Batch Application Capture Repository)
• Log: LOGSC000 (CICS Application Log)
LOGSC001 (Batch Application Log)
• Script: SCRSC000 (CICS Application Script)
SCRSC001 (Batch Application Script)
8-24
To prevent PDA017 and PDA018 activity from playing back, add the following parameter
to the MQGROUP statement in the log file used to run the unattended playback job:
SKIP(CONNECTION_ID(2, 3, 5, 6, 8, 9, 11, 12, 14, 15, 17, 18, 20, 21))
See sample LOGSC000 to see the syntax of the entire MQGROUP statement.
Playing Back with PLAY_TO(CONNECTION_ID(*))
This scenario demonstrates playing multiple groups in reverse by using the
PLAY_TO(CONNECTION(*)) parameter on the MQGROUP statements. Each group
contains a single script with the same MQ activity. However, the activity in one script
was initiated by the Web service and the other by PDA016 Customer Order Inquiry
Program.
Testing the entire customer order and credit inquiry application (Figure 8-23 on page
8-44) requires playing back the initial inquiry request (PUT to Customer Order Inquiry
Queue) and the final response retrievals (GET from Customer Order Inquiry Response
Queue and GET from Credit Inquiry Response Queue). The Web service transmits this
activity through a CHIN. However, the capture does not contain CHIN activity because it
was limited to a single job name. As such, the activity needed to perform the test was not
captured for the Web service inquiry. You can still perform the test by generating scripts
that contain the:
• MQ_GET issued by PDA017
• MQ_PUT issued by PDA017 to the Customer Order Inquiry Response Queue
• MQ_PUT issued by PDA018 to the Credit Inquiry Response Queue
Note:
Refer to the black boxes in Figure 8-23 on page 8-44.
Then using PLAY_TO(CONNECTION_ID(*)) to play the:
• MQ_GET as an MQ_PUT, which populates the Customer Order Inquiry Queue with
the requests that were originally retrieved from the queue during capture. Once the
requests are in the queue, PDA017 will automatically GET the requests and begin
processing.
• MQ_PUTs as MQ_GETs, which empties the two response queues at the end of
processing and allows you to generate an exception report to compare recorded
application responses to the responses resulting from playback.
Testing Scenarios
8-25
Figure 8-10. Activity Replicated by PLAY_TO(CONNECTION_ID(*))
This scenario requires generating two scripts with the appropriate filtering and
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 requirements to
generate the scripts, and details the log edits required to play back the groups
simultaneously in reverse.
8-26
• Log: LOGMG004
LOGMG005
LOGMG006 (Manually compiled from LOGMG004 and LOGMG005)
• Script: SCRMG004 (Web service initiated activity)
SCRMG005 (PDA016 initiated activity)
Filters
REPOS2 contains activity from the entire customer order and credit inquiry application
initiated by both the Web service and PDA016. Use this repository to generate two
scripts: one containing the activity generated by the Web service and the other
containing the activity generated by PDA016. Each script should contain the:
• MQ_GETs issued by PDA017
• MQ_PUTs issued by PDA017 to the Order Inquiry Response Queue
• MQ_PUTs issued by PDA018 to the Credit Inquiry Response Queue
Note:
To generate a script that contains the activity initiated by the Web service, apply the
following three filters:
• Filter 1 writes the MQ_GETs issued by PDA017 to the Customer Order Inquiry Queue
into the script.
Field Name
Queue manager
EQ *
UserIdentifier
EQ ASPNET
• Filter 2 writes the MQ_PUTs issued by PDA017 to the Order Inquiry Response Queue
into the script.
Field Name
Queue manager
EQ *
UserIdentifier
EQ ASPNET
Testing Scenarios
8-27
• Filter 3 writes the MQ_PUTs issued by PDA018 to the Credit Inquiry Response Queue
into the script.
Field Name
Queue manager
EQ *
Object/Queue name EQ PDAPROD.H01AC013.CREDIT.AUTH.RESP.QUEUE
UserIdentifier
Note:
EQ ASPNET
The capture was limited to a single job name, which excludes the CHIN activity.
Because the Web service PUTs the requests on the Customer Order Inquiry Queue
and GETs the responses from the Order Inquiry Response Queue and the Credit
Inquiry Response Queue via a CHIN, these events do not exist in the repository.
Therefore, filtering by event is not necessary.
To generate a script that contains the activity initiated by PDA016, apply the following
three filters:
• Filter 1 writes the MQ_GETs issued by PDA017 to the Customer Order Inquiry Queue
into the script.
Field Name
Queue manager
EQ *
Event
EQ GET
UserIdentifier
EQ USER015
• Filter 2 writes the MQ_PUTs issued by PDA017 to the Order Inquiry Response Queue
into the script.
Field Name
Queue manager
EQ *
Event
EQ PUT
UserIdentifier
EQ USER015
• Filter 3 writes the MQ_PUTs issued by PDA018 to the Credit Inquiry Response Queue
into the script.
Field Name
Queue manager
EQ *
Object/Queue name EQ PDAPROD.H01AC013.CREDIT.AUTH.RESP.QUEUE
Event
EQ PUT
UserIdentifier
EQ USER015
Using a standard file editing tool, manually merge the two log files generated during
script creation into a single file. To do this, copy the first log file and save it with a
unique name. Copy the MQGROUP and SCRIPT statements from the other log file and
paste them into the new log file. Then add the PLAY_TO(CONNECTION(*)) parameter to
each MQGROUP statement.
8-28
Refer to the following samples to see how this is done.
• LOGMG006 contains the MQGROUP and SCRIPT statements from the previous two
logs.
Replacing Script Data with a Static Value
The scenario demonstrates adding REXX logic to the script to replace the customer name
with a static value in every other credit inquiry. This test verifies that the remote
application can successfully process a credit inquiry for a new customer.
inquiry application (Figure 8-1 on page 8-3), then generating a script that isolates the
credit inquiry activity — that is, the MQ_PUTs that PDA018 issues to the remote inquiry
queue and the MQ_GETs that it issues to the Credit Bureau Inquiry Response Queue.
Figure 8-11 on page 8-29 shows this activity.
Testing Scenarios
8-29
Figure 8-11. Credit Inquiry Activity Captured in Filtered Script FDDSD000
The script then drives remote processing. The REXX logic added to the script replaces the
customer name recorded in the script with a static value in every other inquiry.
During playback, generate an HTML Exception Report (page 6-17) to verify data
replacement. Every other inquiry should produce a mismatch.
This scenario requires adding REXX logic to the script and modifying the playback
CONTROL statement in either the LOG file or the CONTROL member.
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.
8-30
• Log: LOGSD000
• Script: FDDSD000
Filters
on page 8-29 to view PDA018’s application flow and the names of the queues it uses.
Filter 1
Field Name
Queue manager
EQ *
Event
EQ PUT
Filter 2
Field Name
Queue manager
EQ *
Event
Note:
EQ GET
generate a LOG file to compare to the sample LOG file.
This section show you how to:
• Modify the script to replace the customer name in every other inquiry with a static
value.
• Modify the log file to enable the use of REXX during playback.
Script Edits
This section details the script modifications necessary to replace the recorded customer
name with a static value in every other inquiry.
Note:
The sample script, FDDSD000, contains comment boxes that were manually
added to the script to explain each modification.
At the end of the script, insert a REXX procedure to replace the recorded customer name
with the static value. Figure 8-12 shows the REXX logic added to the end of the script,
along with the “flower box” that describes the logic.
• Include the EXPOSE parameter on the PROCEDURE statement to make the REXX
variables available to the REXX procedure and to script processing.
• Use the Hiperstation REPLACE verb, discussed on page 3-40, to execute the data
replacement. The REPLACE verb has two parameters:
Testing Scenarios
8-31
– offset indicates the starting position, relative to zero, for data replacement. The
first byte of the customer name field is an attribute byte that must be preserved.
Set the offset to 1 to begin replacing data at the second byte.
– data is the replacement data. This example assigns the static value 'ABC
CORPORATION' to the CUSTNAME variable. Whether you assign a variable or
specify the value directly on the REPLACE verb, be sure the length of the
replacement value matches the length of the data you need to replace. Notice the
additional spaces between the end of ABC CORPORATION and the closing
quotation mark — they ensure replacement of all 32 characters in the customer
name field.
• Include logic to select every other inquiry for data replacement. In this example,
when CHG_CUST executes, the value of I is increased by 1. When I =2, the data is
replaced and I is set to back zero.
• Complete the procedure with a REXX RETURN statement.
Before the REXX procedure, add a REXX EXIT statement to terminate playback.
Normally, playback terminates when all activity in the script has been executed. Since
this example calls for adding REXX to the end of the script, the EXIT statement is
necessary to indicate the end of the activity.
Figure 8-12. Data Replacement Logic at End of Sample Script FDDSD000
EXIT 0
* ************************************************************************
*
* THE REXX EXIT STATEMENT ABOVE MUST BE ADDED BEFORE THIS FUNCTION
*
* THE FUNCTION BELOW WILL USE STATIC DATA REPLACEMENT TO ALTER THE
* CONTENT. THE QAH REPLACE COMMAND WILL PREPARE MESSAGE ALTERATIONS
* TO BE USED BY THE NEXT CONTENT ENCOUNTERED
*
* REXX VARIABLE "I" IS USED TO CONTROL DATA REPLACEMENT. EVERY
* OTHER MQ PUT WILL HAVE CONTENT DATA REPLACED.
*
* THE QAH STATEMENT REPLACE(OFFSET,VARNAME) IS USED TO REPLACE DATA
* LOCATED IN THE NEXT CONTENT ENCOUNTERED. "OFFSET" IS RELATIVE
* TO ZERO.
*
* THE FUNCTION USES THE EXPOSE OPTION ON THE PROCEDURE STATEMENT
* TO MAKE REXX VARIABLES AVAILABLE TO THE FUNCTION AND THE MAINLINE
* SCRIPT.
*
************************************************************************
CHG_CUST: PROCEDURE EXPOSE CUSTNAME I
I = I + 1
IF I = 2 THEN DO
CUSTNAME = 'ABC CORPORATION
'
I = 0
<REPLACE FIELD(1,CUSTNAME)>
END
RETURN 0
Next, add logic to set the initial value of I. Insert the variable initialization in the
beginning of the script, before the MQ activity. See bold text in Figure 8-13.
8-32
Figure 8-13. Variable Initialization in Sample Script FDDSD000 (Top)
************************************************************************
*
* THIS SCRIPT HAS BEEN MODIFIED TO PERFORM STATIC DATA REPLACEMENT OF
* MQ PUT MESSAGE CONTENT. BEFORE THE CONTENT OF EACH MQ PUT,
* A FUNCTION CALL HAS BEEN ADDED. THIS FUNCTION, LOCATED AT THE END
* OF THIS SCRIPT, WILL MODIFY THE CUSTOMER NAME OF EACH MQ PUT
* MESSAGE USING THE QAH REPLACE COMMAND. THE REPLACE ALTERS THE
*
* REXX VARIABLE "I" IS USED TO CONTROL DATA REPLACEMENT. EVERY
* OTHER MQ PUT WILL HAVE CONTENT DATA REPLACED.
*
* ADDITIONAL FLOWER BOXES ARE LOCATED IN THIS SCRIPT TO ASSIST IN
* IDENTIFYING THE CHANGES MADE TO FACILITATE STATIC DATA REPLACEMENT
* THE FOLLOWING SCRIPT CODE ADDITIONS WILL:
*
* 1) INITIALIZE THE REXX VARIABLE "I" WHICH IS USED TO CONTROL
*
WHEN DATA REPLACEMENT IS TO BE PERFORMED. OTHER METHODS OF
*
CONTROL MAY BE USED TO CONTROL DATA REPLACEMENT
*
************************************************************************
I = 0
*
* SCRIPT STARTED ON 2006/07/10 AT 12:12:01
* DESC: MULTIPLE GROUP
*
<VERSION>07.01.00
<DETAIL COMBINED='*'>
*
* MQ_CONNECT
*
*
* WARNING: MISSING DATA,SYNTHESIZED MQ_CONNECT TAG
<TIME>2006/06/26_10:55:57.885251
<MQ_CONNECT,
CONNECTION_ID = 3,
COMPCODE = 0,
REASON = 0,
QMGR_NAME = 'M520',
Then insert a call to the CHG_CUST procedure before the <CONTENT> tag in each
MQ_PUT. See the bold text in Figure 8-14.
Testing Scenarios
8-33
Figure 8-14. Procedure Call in Sample Script FDDSD000
*
* MQ_PUT *
*
<TIME>2006/06/26_10:55:57.885251
<MQ_PUT,
CONNECTION_ID = 3,
OBJECT_ID = 16,
COMPCODE = 0,
REASON
= 0,
MQMD_VERSION = 1,
MQMD_REPORT = (NONE),
MQMD_MSGTYPE = DATAGRAM,
MQMD_EXPIRY = '00001388'X,
MQMD_FEEDBACK = NONE,
MQMD_ENCODING = '00000311'X,
MQMD_CODEDCHARSETID = 0,
MQMD_FORMAT = 'MQSTR',
MQMD_PRIORITY = 'FFFFFFFF'X,
MQMD_PERSISTENCE = NOT_PERSISTENT,
MQMD_MSGID = 'C3E2D840D4F5F2F04040404040404040B99FE304AF5483C1'X,
MQMD_CORRELID = NONE,
MQMD_BACKOUTCOUNT = '',
MQMD_REPLYTOQ = '',
MQMD_REPLYTOQMGR = 'M520',
MQMD_USERIDENTIFIER = 'MCONID',
MQMD_ACCOUNTINGTOKEN = '1A11E4E2C3E6E7D5F0F14BC8F0F1C1C3F0F1F39FE307BA81E2000
MQMD_APPLIDENTITYDATA = '',
MQMD_PUTAPPLNAME = 'H01AC013PD18',
MQMD_APPLORIGINDATA = '',
MQPMO_VERSION = 1,
MQPMO_OPTIONS = (FAIL_IF_QUIESCING,DEFAULT_CONTEXT,NO_SYNCPOINT),
MQPMO_RESOLVEDQNAME = 'PDAPROD.QLOCAL.CW01.TO.CW09.CREDIT.AUTH',
MQPMO_RESOLVEDQMGRNAME = 'O530',
CRNTLEN = 300,
TRUELEN = 300>3
************************************************************************
*
* THE REXX STATEMENT BELOW WILL CALL THE FUNCTION CHG_CUST.
* THE FUNCTION WILL PREPARE A REPLACE STATEMENT THAT ALTERS
* THE CONTENT FOR THIS MQ_PUT.
*
* THE FUNCTION CALL FOR CHG_CUST IS ADDED TO THE SCRIPT BEFORE EACH
* CONTENT FOR ALL MQ_PUTS.
*
************************************************************************
X = CHG_CUST() /* IN EACH MQ PUT BEFORE THE CONTENT */
*
<CONTENT>.þ..000000010AMERICANFASTNERS
Log Edits
To enable REXX interpretation during playback, add the REXXON parameter to the
playback control information. Either:
• Add a CONTROL statement with this parameter directly to the log file used to run
the playback job. Insert it above the MQGROUP statement.
• Add it to the control member specified on the log file’s SET ACTION statement.
Replacing Script Data Dynamically
The scenario demonstrates adding REXX logic to the script to replace recorded customer
names with names from an external file. This test verifies that the remote application
successfully processes credit inquiries for new customers.
8-34
Figure 8-15 shows this activity.
Figure 8-15. Credit Inquiry Activity Captured in Filtered Script FDDDD000
customer names recorded in the script with names from an external file.
Testing Scenarios
8-35
• Log: LOGDD000
• Script: FDDDD000
• External file containing replacement data: FDDFILE1
Note:
Sample script FDDDD002 shows a slightly more advanced variation of dynamic
data replacement. Once you read and understand this example, review sample
script FDDDD002. It contains a single customer order and credit inquiry request
(MQ_PUT issued by PDA016) and REXX logic to replay the script with each
customer record from an external file. That is, it contains ADDRESS and EXECIO
statements to read in the external file and the MQ_PUT is wrapped in a REXX DO
instruction that replays the MQ_PUT with each record contained in the external
file. It also contains comment boxes that explain each script modification.
Filters
Filter 1
Field Name
Queue manager
EQ *
Event
EQ PUT
Filter 2
Field Name
Queue manager
EQ *
Event
Note:
EQ GET
This section shows you how to:
• Modify the script to replace the recorded customer names with names read from an
external file.
• Modify the log file to enable the use of REXX during playback.
Script Edits
names with names from an external file (FDDFILE1).
8-36
Note:
The sample script, FDDDD000, contains comment boxes that were manually
At the beginning of the script:
• Insert Hiperstation REXX command HSCMDS to allocate the input file. Refer to the
Hiperstation Scripting Reference for more information on the HSCMDS command.
• Insert an EXECIO statement to read the file into a REXX stem variable. In this case,
INREC.n where n is the record number. Include the FINIS parameter to close file after
all records have been read.
• Initialize a count variable.
Figure 8-16 shows this logic in bold text.
Figure 8-16. Sample Script FDDDD000 with Logic to Read in External Information
************************************************************************
*
* THIS SCRIPT HAS BEEN MODIFIED TO PERFORM DYNAMIC DATA REPLACEMENT OF
* OF THIS SCRIPT, WILL MODIFY THE CUSTOMER NAME OF EACH MQ PUT
* MESSAGE USING THE QAH REPLACE COMMAND. THE REPLACE ALTERS THE
* CONTENTS OF THE NEXT ENCOUNTERED CONTENT TAG.
*
*
*
* 1) ALLOCATE A FILE USING THE QAH REXX COMMAND HSCMDS
* 2) READ IN THE FILE INTO A REXX STEM VARIABLE. EACH RECORD
*
IS READ INTO THE STEM.X WHERE INREC IS THE STEM
*
AND X IS 1 - NUMBER OF RECORDS
* 3) CLOSE IS PERFORMED BY SPECIFYING THE FINIS PARM ON THE EXECIO
*
*
THE DATA TO BE USED BY THE REPLACE STATEMENT. I IS THE INDEX
*
FOR THE REXX STEM VARIABLE INREC
*
* REVIEW THE DATASET NAME LOCATED IN THE ADDRESS COMMAND BELOW.
* CHANGE COMPWARE.SQQFSAMP TO THE NAME OF YOUR INSTALLATION
* SAMPLE DATASET.
*************************************************************************
ADDRESS HSCMDS "ALLOC FILE (INDATA),
DA(COMPWARE.SQQFSAMP(FDDFILE1)), SHR REUS"
"EXECIO * DISKR INDATA (FINIS STEM INREC."
I = 0
*
*
*
<VERSION>07.01.00
*
* MQ_CONNECT
*
*
* WARNING: MISSING DATA,SYNTHESIZED MQ_CONNECT TAG
<TIME>2006/06/26_10:55:57.885251
<MQ_CONNECT,
CONNECTION_ID = 3,
COMPCODE = 0,
REASON = 0,
QMGR_NAME = 'M520',
SYSTEM_NAME = 'CW01',
with a customer name from the external file. Figure 8-17 shows the REXX logic added to
the end of the script, along with the “flower box” that describes the logic.
Testing Scenarios
8-37
• Increment the count variable. Use this to select the appropriate customer name as
described in the next bullet.
• Each record in the external file contains the customer name and program name. The
customer name occupies the first 20 characters of each record. Use the REXX
substring instruction to pass only the customer name from the record represented by
the selected INREC variable to the CUSTNAME variable.
Notice, "INREC." is followed by the count variable. Each time the procedure executes,
the value of I increases by one. The customer name from INREC.1 replaces the
recorded customer name on the first inquiry calling the procedure, and the name
from INREC.2 replaces the name on the second inquiry calling the procedure, and so
on.
replacement. Since the customer name field begins with an attribute byte that must
be preserved, set the offset to 1 to replace data beginning with the second byte.
Provide the data to use for replacement. In this case, the CUSTNAME variable is the
replacement data.
Figure 8-17. Data Replacement Logic at End of Sample Script FDDDD000
EXIT 0
************************************************************************
*
*
* THE FUNCTION BELOW WILL USE DATA READ INTO INREC EARLIER TO ALTER THE
* CONTENT. THE QAH REPLACE COMMAND WILL PREPARE MESSAGE ALTERATIONS
* TO BE USED BY THE NEXT CONTENT ENCOUNTERED
*
* THE REXX VARIABLE "I" IS USED TO CONTROL THE DATA TO BE USED BY
* THE REPLACE STATEMENT. I IS THE INDEX FOR THE REXX STEM VARIABLE
* INREC
*
* THE REXX STATEMENT SUBSTR(VARNAME,START,LEN) IS USED TO EXTRACT
* DATA FROM THE STEM VARIABLE INREC CREATED DURING THE READING OF
* THE EXTERNAL FILE FOUND AT THE START OF THIS SCRIPT.
* "START" IS RELATIVE TO 1.
*
* THE QAH STATEMENT REPLACE(OFFSET,VARNAME) IS USED TO REPLACE DATA
* LOCATED IN THE NEXT CONTENT ENCOUNTERED. "OFFSET" IS RELATIVE
* TO ZERO.
*
* SCRIPT.
*
************************************************************************
CHG_CUST: PROCEDURE EXPOSE INREC. I CUSTNAME
I = I + 1
CUSTNAME = SUBSTR(INREC.I,1,20)
RETURN 0
Finally, insert a call to the CHG_CUST procedure before the <CONTENT> tag in each
8-38
Figure 8-18. Procedure Call in Sample Script FDDDD000
*
* MQ_PUT *
*
<TIME>2006/06/26_10:55:57.885251
<MQ_PUT,
CONNECTION_ID = 3,
OBJECT_ID = 16,
COMPCODE = 0,
REASON
= 0,
MQMD_VERSION = 1,
MQMD_REPLYTOQ = '',
MQPMO_VERSION = 1,
CRNTLEN = 300,
TRUELEN = 300>3
************************************************************************
*
* THE REXX STATEMENT BELOW WILL CALL THE FUNCTION CHG_CUST.
* THE FUNCTION WILL PREPARE A REPLACE STATEMENT THAT ALTERS
* THE CONTENT FOR THIS MQ_PUT.
*
* THE FUNCTION CALL FOR CHG_CUST IS ADDED TO THE SCRIPT BEFORE EACH
*
************************************************************************
X = CHG_CUST() /* IN EACH MQ PUT BEFORE THE CONTENT */
*
.
Log Edits
playback control information. Either:
• Add the parameter to the CONTROL statement in the control member specified on
the log file’s SET ACTION statement.
Expanding Data During Playback
This scenario demonstrates expanding MQ message content during playback. The
customer order and credit inquiry application provides 32 bytes for the customer name.
Before modifying the application to accept a longer customer name, verify that the
remote application can handle the additional bytes in the credit inquiry. To accomplish
this, capture all of the activity from the entire customer order and credit inquiry
Testing Scenarios
8-39
application (Figure 8-1 on page 8-3). Generate a script that isolates the credit inquiry
activity — that is, the MQ_PUTs that PDA018 issues to the remote inquiry queue and the
MQ_GETs that it issues to the Credit Bureau Inquiry Response Queue. Figure 8-19 shows
this activity. Create two copies of the script.
• In the first copy, add REXX logic to write the “actual” PUT and GET message content
to an external file during playback.
• In the second copy, add REXX logic that uses the “actual” PUT messages from the
external file to replace the customer name with the expanded customer name.
Figure 8-19. Credit Inquiry Activity Captured in Filtered Script FDDDD001
8-40
• Log:
LOGDD001 — Log file used to play back script FDDDD001
LOGED000 — Log file used to play back script FDDED000
• Script:
FDDDD001 — Script to capture “actual” GET and PUT message content
FDDED000 — Script to play back with expanded customer names
Filters
Filter 1
Field Name
Queue manager
EQ *
Event
EQ PUT
Filter 2
Field Name
Queue manager
EQ *
Event
Note:
EQ GET
This section show how to modify the scripts and log files to achieve MQ message
expansion.
Script Edits
This section details the modifications made to each copy of the script.
• “FDDDD001” on page 8-41, describes the REXX modifications necessary to write the
“actual” GET and PUT message content to an external file.
• “FDDED000” on page 8-43, describes the REXX modifications necessary to replace
the customer name with the expanded customer name.
Note:
Both sample scripts contain manually added comment boxes that explain each
modification.
Testing Scenarios
8-41
FDDDD001
• Insert Hiperstation REXX command HSCMDS to allocate the output file. Refer to the
Figure 8-20. Sample Script FDDDD001 with Logic to Allocate an External File
************************************************************************
*
* THIS SCRIPT HAS BEEN MODIFIED TO PERFORM DATA COLLECTION OF
* MQ GET MESSAGE CONTENT. AFTER THE CONTENT OF EACH MQ GET AND PUT,
* OF THIS SCRIPT, WILL CREATE A FILE RECORD AND WRITE THE RECORD
* TO AN EXTERNAL FILE. THIS FILE MAY BE USED AS INPUT TO OTHER
* MQ PLAYBACK RUNS, 3270 VALIDATION RUNS, OR USED TO DRIVE OTHER
* APPLICATIONS.
*
*
*
THE DATA TO BE COLLECTED AND WRITTEN TO AN EXTERNAL FILE.
*
I IS THE INDEX FOR THE REXX STEM VARIABLE OUTREC
*
*
* CHANGE COMPWARE.FDDDD001.REXX.OUTPUT TO AN APPROPRIATE
* DATASET NAME.
*
************************************************************************
ADDRESS HSCMDS "ALLOC FILE (OUTDATA),
DA(COMPWARE.FDDDD001.REXX.OUTPUT), OLD REUS" /* <=== REVIEW */
I = 0
*
*
*
At the end of the script, insert two REXX procedures: one that collects GET data and one
that collects PUT data.
• Increment the count variable. Use this value to supply an index on the REXX stem
variable described in the next bullet.
• Use the Hiperstation REXX variable ACTUAL_MSG to return the content of the
GETs/PUTs executed during playback. Concatenate the “actual” message content to a
message type identifier and pass it to a REXX stem variable.
Notice, "OUTREC." is followed by the count variable. Each time either of the
procedures execute, the value of I increases by one. This ensures a unique stem index
for each message, in addition to ensuring that the records are ordered
chronologically. The content of the initial PUT is written to OUTREC.1 and the
content of the resulting GETs is written to OUTREC.2, OUTREC.3, and OUTREC.4.
• Terminate each procedure with a RETURN statement.
8-42
Figure 8-21. Sample Script FDDDD001 with Data Collection Logic
*
* THE FUNCTION BELOW WILL USE COLLECT DATA INTO THE STEM VARIABLE
* OUTDATA. AT THE END OF THE SCRIPT, THE STEM VARIABLE WILL BE
* USED TO WRITE THE COLLECTED STEM DATA TO AN EXTERNAL FILE
*
* THE REXX VARIABLE "I" IS USED TO CONTROL THE COLLECTION OF DATA
* INTO THE STEM VARIABLE.
* INREC
*
* THE REXX STATEMENT "OUTREC.I = 'XXX ' || ACTUAL_MSG" WILL PLACE THE
* TYPE OF MSG, GET OR PUT, FOLLOWED BY THE MESSAGE CONTENT.
*
* SCRIPT.
*
* COLL_PUTS IS THE SAME AS COLL_GET WITH THE EXCEPTION OF THE TYPE
* IDENTIFIER.
*
************************************************************************
COLL_GETS: PROCEDURE EXPOSE OUTREC. I ACTUAL_MSG
I = I + 1
OUTREC.I = 'GET ' || ACTUAL_MSG
RETURN 0
*
*
COLL_PUTS: PROCEDURE EXPOSE OUTREC. I ACTUAL_MSG
I = I + 1
OUTREC.I = 'PUT ' || ACTUAL_MSG
RETURN 0
******************************** Bottom of Data ********************************
Before the REXX data collection procedures, after the last MQ_DISCONNECT:
• Insert an EXECIO statement that writes the OUTREC stem variable values to the
dataset defined on the OUTDATA DD. Include the FINIS parameter to close file after
all records have been written. Refer to the Hiperstation Scripting Reference for more
information on the EXECIO command.
• Insert a REXX EXIT statement to terminate playback. Normally, playback terminates
when all activity in the script has been executed. Since this example calls for adding
REXX to the end of the script, the EXIT statement is necessary to indicate the end of
the activity.
Testing Scenarios
8-43
Figure 8-22. Sample Script FDDDD001 with EXECIO and EXIT Statements
*
* MQ_DISCONNECT *
*
<TIME>2006/06/26_10:56:45.102880
<MQ_DISCONNECT,
CONNECTION_ID = 21,
COMPCODE = 0,
REASON
= 0>85
*
*
************************************************************************
*
* THE REXX STATEMENT BELOW WILL WRITE THE STEM OUTREC TO THE
* OUTDATA DD.
*
************************************************************************
"EXECIO * DISKW OUTDATA (FINIS STEM OUTREC."
EXIT 0
************************************************************************
*
* THE REXX EXECIO STATEMENT ABOVE WRITES THE STEM VARIABLE OUTREC
* TO THE DATASET IDENTIFIED BY OUTDATA
*
*
Respectively insert one of the following function calls after the <CONTENT> of each
MQ_GET and MQ_PUT:
X = COLL_GETS()
X = COLL_PUTS()
Play back the script to create the external file that the FDDDED000 script uses. In the log
file or the control member specified on the log file’s SET ACTION statement, add the
playback control parameters to enable interpretation of REXX and the use of the
Hiperstation REXX STREAM variables during playback. See “Log Edits” on page 8-46.
FDDED000
• Insert Hiperstation REXX command HSCMDS to allocate the input file. Specify the
output dataset created during playback of the data collection script (FDDDD001).
Refer to the Hiperstation Scripting Reference for more information on the HSCMDS
command.
INREC.n where n is the record number. Include the FINIS parameter to close file after
all records have been read.
8-44
Figure 8-23. Sample Script FDDED000 with Logic to Read in External Information
********************************* Top of Data **********************************
************************************************************************
*
* THIS SCRIPT HAS BEEN MODIFIED TO PERFORM EXPANSION OF USER DATA FOR
* OF THIS SCRIPT, WILL EXPAND THE CUSTOMER NAME OF EACH MQ PUT
* MESSAGE BEFORE USING THE QAH REPLACE COMMAND. THE REPLACE ALTERS
* THE CONTENTS OF THE NEXT ENCOUNTERED CONTENT TAG.
*
*
*
*
*
*
*
*
*
*
*
* CHANGE COMPWARE.FDDDD001.REXX.OUTPUT TO THE DATASET NAME
* CREATED IN SCRIPT FDDDD001 (LOGDD001).
*
************************************************************************
DA(COMPWARE.FDDDD001.REXX.OUTPUT), SHR REUS" /* <=== REVIEW */
I = 0
*
At the end of the script, insert a REXX procedure to select the PUT messages from the
external file, expand the length of the customer name value, and build the appropriate
REPLACE verb. Figure 8-24 shows the REXX logic added to the end of the script, along
with the “flower box” that describes the logic.
• Increment the count variable. Use this to select the appropriate GET/PUT record as
described in the next two bullets.
• Use a substring instruction to pass the first three bytes the selected INREC to the
TYPE variable. This returns the message type that was added to the beginning of the
the “actual” GET/PUT content when the external file was written.
• Insert a DO WHILE loop to select the PUT messages from the external file. If INREC.I
is a GET, then increment the value of I to select the next record. Insert the TYPE
variable declaration into the loop to return the message type of the next record. If
INREC.I is a PUT, END the loop.
• Each record in the external file contains the message type (GET/PUT) that was
assigned during data collection, followed by a space, and then the 300 byte inquiry.
The first byte of the inquiry is the attribute byte, the next 32 bytes are the customer
name, and the rest of the bytes are reserved for additional customer information. Use
the REXX substring instruction to parse the record. Pass the attribute byte, the
customer name bytes, and the rest of the bytes to separate variables.
• Concatenate ten spaces to the CUSTNAME variable and pass it to a new variable.
replacement. Provide the offset to indicate where in the message to insert the data
and provide the data to use for replacement. Use the LENGTH parameter to ensure
that the total length of the inquiry is 310 bytes.
Testing Scenarios
8-45
Figure 8-24. Data Replacement Logic at End of Sample Script FDDED000
*
* SCRIPT.
*
************************************************************************
*
*
CHNG_PUTS: PROCEDURE EXPOSE INREC. I FIRST EXPCUST REST
I = I + 1
TYPE
= SUBSTR(INREC.I,1,3)
DO WHILE TYPE = 'GET'
I = I + 1
TYPE
END
FIRST
CUSTNAME = SUBSTR(INREC.I,6,32)
REST
*
EXPCUST = CUSTNAME||'
'
*
<REPLACE FIELD(0,FIRST) FIELD(1,EXPCUST) FIELD(43,REST) LENGTH=310>
RETURN 0
Finally, insert a call to the CHG_PUTS() procedure before the <CONTENT> tag in each
8-46
Figure 8-25. Procedure Call in Sample Script FDDED001
*
* MQ_PUT *
*
<TIME>2006/06/26_10:55:57.885251
<MQ_PUT,
CONNECTION_ID = 3,
OBJECT_ID = 16,
COMPCODE = 0,
REASON
= 0,
MQMD_VERSION = 1,
MQMD_REPLYTOQ = '',
MQPMO_VERSION = 1,
CRNTLEN = 300,
TRUELEN = 300>3
************************************************************************
*
* THE REXX STATEMENT BELOW WILL CALL THE FUNCTION CHNG_PUTS
* THE FUNCTION WILL EXPAND THE MQ MESSAGE DATA BEFORE USING THE
* REPLACE STATEMENT TO MODIFY THE MQ MESSAGE.
*
* THE FUNCTION CALL FOR CHNG_PUTS IS ADDED TO THE SCRIPT BEFORE EACH
*
************************************************************************
X = CHNG_PUTS()
/* BEFORE EACH MQ PUT
*/ *
Log Edits
Both scripts require the addition of the REXXON parameter to the playback control
information to enable the interpretation of REXX during playback.
To use the ACTUAL_MSG variable in the data collection script (FDDDD001), add the
SET_REXX_STREAM_VARIABLES(YES) parameter to the playback control information.
Either:
• Add a CONTROL statement with one or both of these parameters directly to the log
file used to run the playback job. Insert it above the MQGROUP statement.
Testing Scenarios
8-47
Replacing Data During Repeated Concurrent Playback
The scenario demonstrates adding REXX logic to the script to replace recorded customer
names with names from an external file on each iteration of a repeated, concurrent
playback. This example plays three instances of the same script concurrently, then
repeats the playback three times, replacing data on each iteration. This test verifies that
the remote application can handle three concurrent users requesting order and credit
information for 90 different customers.
Figure 8-15 shows this activity.
Figure 8-26. Credit Inquiry Activity Captured in Filtered Script FDDPD000
customer names recorded in the script with names from an external file.
8-48
•
•
•
•
Repository: REPOS1
Log: LOGPD000
Script: FDDPD000
External file containing replacement data: FDDFILE2
Filters
Filter 1
Field Name
Queue manager
EQ *
Event
EQ PUT
Filter 2
Field Name
Queue manager
EQ *
Event
Note:
EQ GET
This section show how to:
• Modify the script to replace the recorded customer names with names read from an
external file.
• Modify the log file to enable the use of REXX and Hiperstation REXX variables
during playback.
Testing Scenarios
8-49
Script Edits
names with names from an external file (FDDFILE2).
Note:
The sample script, FDDPD000, contains comment boxes that were manually
• Insert Hiperstation REXX command HSCMDS to allocate the input file. Refer to the
INREC.IX where IX is the record number. Include the FINIS parameter to close file
after all records have been read.
• Initialize a data replacement count variable.
Figure 8-27. Sample Script FDDPD000 with Logic to Read in External Information
*
*
*
*
*
*
*
*
*
*
* CHANGE COMPWARE.SQQFSAMP TO THE NAME OF YOUR INSTALLATION
* SAMPLE DATASET.
*
************************************************************************
DA(COMPWARE.SQQFSAMP(FDDFILE2)), SHR REUS" /* <=== REVIEW */
I = 0
*
*
*
<VERSION>07.01.00
*
* MQ_CONNECT
*
*
with a customer name from the external file. Figure 8-28 shows the REXX logic added to
the end of the script in bold text.
• Insert record selection logic based on the current iteration of playback. The external
file contains 90 records. In this example, the script plays back three times
concurrently (COUNT(3)). The concurrent playback repeats three times (REPEAT(3)).
To ensure the content of each PUT is replaced with a different record:
8-50
– Use the first 30 records for the first COUNT, the next 30 records for the second
COUNT, and the last 30 for the last COUNT.
– From each set of 30 records, use the first 10 records for the first REPEAT, the next
10 records for the second REPEAT, and last 10 records for the last REPEAT.
Note:
The number of records to use for each combination of count and repeat
must be equal to or greater the number of data replacements you need to
perform.
The following tables shows the records used for each iteration of playback.
Iteration
Count 1 (1-30)
Count 2 (31-60)
Count 3 (61-90)
REPEAT 1
1-10
31-40
61-70
REPEAT 2
11-20
41-50
71-80
REPEAT 3
21-30
51-60
81-90
To achieve this, use the:
– Hiperstation REXX variable MQGROUP_COUNT_NBR, which returns the current
COUNT value, and the modulo function (//) to return the remainder from the
variable divided by the total number of COUNTS. Pass this value to a variable.
This example passes it to GROUP.
– Hiperstation REXX variable MQGROUP _REPEAT_NBR, which returns the current
REPEAT value, and the modulo function to return the remainder from the
variable divided by the total number of REPEATS. Pass this value to a variable.
The example passes it to REPEAT.
In this example, the modulo function always returns 0, 1, or 2. Since you need to
select a record from the first, second, or third set of records for each COUNT and
REPEAT, use an IF statement to change the variable value to 3 when it is zero.
Using the GROUP, REPEAT, and I variables, construct an equation that returns the
record number to use for the data replacement.
Decrement each variable by one to make them relative to zero. Then multiply them
by the number of records applicable to the variable. That is:
– Each COUNT uses a set 30 records, so multiply (GROUP -1) by 30
– Each REPEAT uses a set of 10 records, so multiply (REPEAT-1) by 10.
Add these sub-equations to determine which set of 10 records to use. Add 1 to make
the total relative to 1. Add I, which increments every time the procedure is called, to
select the appropriate record within the set of 10.
Watch how this works for the first data replacement in the second count of the third
repeat.
I=0 (as initialized)
GROUP= the remainder of 2/3
= 2
REPEAT= the remainder of 3/3
= 0
IF REPEAT=0 THEN REPEAT=3
IX= (2-1)*30 + (3-1)*10 + 1 + 0
IX =51, which represents the record number. As shown in the table, COUNT2,
REPEAT 3 uses records 51-60.
• After the record number is calculated, increment the value of I to make the procedure
select the next record the next time the function is called.
Testing Scenarios
8-51
• FDDFILE2 contains comma separated values (CSV). Each record in the file is
comprised of the customer name, program name, and numeric string. Since this
example calls for replacing the customer name during playback, use a parse
statement to return only the customer name. Include the INREC variable to select the
appropriate record.
Notice, "INREC." is followed by the IX variable, which is the previously calculated
record number.
• The application allows a 32 character customer name. To ensure all characters in the
recorded customer name are overwritten, concatenate 32 spaces to the data in the
CUSTNAME variable, then use a substring instruction to parse out the first 32
characters.
replacement. Since the customer name field begins with an attribute byte that must
be preserved, set the offset to 1 to replace data beginning with the second byte.
Provide the data to use for replacement. In this case, the CUSTNAME variable is the
replacement data.
Figure 8-28. Data Replacement Logic at End of Sample Script FDDPD000
*
* SCRIPT.
*
************************************************************************
CHG_CUST: PROCEDURE EXPOSE INREC. CUSTNAME PROGNAME,
MQGROUP_COUNT_NBR MQGROUP_REPEAT_NBR I
/*********************************************************************
/*
/* THE FOLLOWING STATEMENT USES THE MODULO STATEMENT '//' TO CREATE
/* THE MODULO OR REMAINDER AFTER DIVIDING MQGROUP_COUNT_NBR BY 3.
/* THE RESULT WILL BE 0, 1, OR 2. THIS IS ALSO TRUE FOR THE
/* STATEMENT
REPEAT = MQGROUP_REPEAT_NBR // 3
/*
/*********************************************************************
GROUP = MQGROUP_COUNT_NBR // 3
IF GROUP=0 THEN GROUP=3
REPEAT = MQGROUP_REPEAT_NBR // 3
IF REPEAT=0 THEN REPEAT=3
IX=(GROUP-1)*30 + (REPEAT - 1) * 10 + 1 + I
I = I + 1
PARSE VAR INREC.IX CUSTNAME ','
CUSTNAME = CUSTNAME || '
'
CUSTNAME = SUBSTR(CUSTNAME,1,32)
RETURN 0
******************************** Bottom of Data ********************************
After the last MQ_DISCONNECT in the script, before the REXX procedure, add a REXX
EXIT statement to terminate playback. Normally, playback terminates when all activity
in the script has been executed. Since this example calls for adding REXX to the end of
the script, the EXIT statement is necessary to indicate the end of the activity.
Finally, insert the following function call before the <CONTENT> tag within each
MQ_PUT.
X= CHG_CUST()
8-52
Log Edits
playback control information.
To use the Hiperstation REXX variables MQGROUP_COUNT_NBR and
MQGROUP_REPEAT_NBR, add the SET_REXX_STREAM_VARIABLES(YES) parameter to
the playback control information.
Either:
Analyzing and Comparing Scripts
There are many ways to use script analysis. With regard to these scenarios, use it to
compare the sample scripts to the scripts you generate and edit to ensure you filtered the
repository and edited the scripts correctly. The main focus of this exercise is to familiarize
you with script analysis, the HTML Exception Report, and the concept of building a
baseline.
To compare the scripts you created to the sample scripts:
1. Locate the sample report member, MQRREXCB, for the HTML Exception Report.
Complete the statement by providing a ddname on the BASELINE parameter and an
HFS path on the INTO parameter. Save the edited report member in your personal
report control library. See “HTML Exception REPORT Statement” on page 6-6.
2. Use the edited LOG file to run an ANALYZE job on the scripts specified by the log
file. Override the temporary dataset on the SET SORTED statement with a permanent
dataset to save the data collected from the analyze job. This will be the baseline
database. See Chapter 5, “Unattended Playback” for help with this and the next step.
3. Use the sample log to run an analyze job on the sample scripts and generate the
exception report simultaneously. Complete SET REPTDS with your personal report
control library, SET SORTED with a unique dataset name, and SET REPTMEM with
the HTML Exception report member. Add a DD statement for the baseline database
specified on the report statement’s BASELINE parameter and the HFS path specified
on the statement’s INTO parameter.
4. Once both analysis jobs have completed, review the report to see if any differences
exist between the two scripts from your log file and the two sample scripts from the
sample log file.
9-1
Chapter 9.
Hiperstation for WebSphere MQ Profile Defaults
Chap 9
WebSphere MQ Profile Defaults
1. Select option 4 WebSphere MQ from the Hiperstation for WebSphere MQ Profile
screen.
Note:
For easier display, the initial Profile screens have been combined. Figure 9-1
shows the profile selection screen. The WebSphere MQ screens in this section
have been combined into logical groups. Figure 9-2 shows the Record
Settings, Figure 9-3 on page 9-3 shows the Script Create Settings, Figure 9-4
on page 9-5 shows the Output Dataset Settings and Figure 9-5 on page 9-6
shows the Script Create Execution Options. On your actual screen, press
FORWARD (PF8) or BACKWARD (PF7) to view all of the fields.
Figure 9-1. Hiperstation for WebSphere MQ Profile Screen
Hiperstation
OPTION ===>
-------------- Hiperstation Profile ---------------------------More:
+
Primary commands: menu-number, ALL, CANCEL
Line commands: S or / to select options.
Active Profile:
Dataset
Member
Description
===> 'USER2312.HIPER.PROFILE'
===> HIPER
===> changed description
_ 1 Domain Traveler
_ 2 APPC
_ 3 3270/LU0
_ 4 WebSphere MQ
_ 5 TCP/IP
_ 6 Auditing 3270
_ 7 Auditing MQ
_ 8 Auditing TCP/IP
_ 9 Playback MQ
_ 10 Playback TCP
_ 11 ATV Manager
Recording and Playback defaults
Global Record and Script Create
Auditing defaults for 3270
Auditing defaults for WebSphere
Auditing defaults for TCP/IP
MQ Playback parameter defaults
TCP Playback parameter defaults
Test Vehicle defaults
settings
settings
settings
settings
MQ
Should changes made elsewhere to Profile values be saved?
Profile Autosave
===> Y
(Y = YES, N = NO OR A = ASK)
Should changes made elsewhere to dataset names be saved?
DSN Autosave
===> Y
(Y = YES, N = NO)
Email address: _______________________________________________________________
Codepage: ISO8859-1
Job statement information for batch jobs:
===> //XXXXXXXA JOB ('ACCOUNT',5M-0000),'HIPERSTN',
===> //
===> //*
> //*
The WebSphere MQ Record/Script Create Defaults screen appears.
9-2
Figure 9-2. WebSphere MQ Record/Script Create Defaults - Record Settings
Hiperstation ---- Websphere MQ Record/Script Create Defaults ----- Top of data
Profile: HIPER
Profile Dataset: USER2312.HIPER.PROFILE
OPTION ===> ________________________________________________
More:
+
--------------------------------Record Settings-------------------------------_ Create Recording Filters (/ for Filter Create panel)
Repository Dataset:
Dataset Name
First Number
Last Number
===> _______________________________________________
===> ________ (if wildcard in dataset)
Reuse Repository Options: (Enter "/" to select)
_ Delete existing data
_ Append to existing data
_ Overwrite existing data when all segments are full
Amount of Data to Record:
Message Data from GETs ===> _____ (ALL or number of bytes)
Message Data from PUTs ===> _____ (ALL or number of bytes)
2. Enter a slash (/) on the Create Recording Filters field to access the WebSphere MQ
Data Collect screen where you can change data collection criteria.
3. Specify your Repository Dataset options.
– Dataset Name is required and specifies where captured data will be stored on
DASD. You can enter a fully qualified dataset name up to 44 characters to
allocate a fixed repository. You can also enter a dataset name with a wildcard of
“*” or “?” to allocate a repository set. This set is defined by a range of numbers
entered in the First Number and Last Number fields. Entering an “*” in the
dataset name expands the qualifier to eight characters and fills with zeros (for
example, xyz* would result in XYZ00001). Entering one or more “?”s in the
dataset name replaces those character positions with numbers (for example,
XYZ??ABC would result in XYZ01ABC).
– First Number and Last Number define the range of datasets for your repository
set. You can enter any range from 0 to 9999999. When one dataset fills up, it is
closed and data continues to be written to the next dataset in sequence. These
fields are required if you enter a wildcard in the Repository Dataset name field.
4. Reuse Repository Options specifies the way your capture request will process the
repository.
– Delete existing data allows capture to start writing data to the beginning of the
repository or the first segment of a repository set. Any data that exists will be
overwritten. This selection is mutually exclusive with Append to existing data.
– Append to existing data allows capture to add data to the repository (or the last
segment of a repository set) that was capturing data. Any data that exists will be
preserved. This is mutually exclusive with Delete existing data.
– Overwrite existing data when all segments are full continues writing captured
data to the first segment of a repository set when the last segment is full. This
option is valid only when using a repository set. This option is only valid when using
a repository set.
5. Amount of Data to Record can record any WebSphere MQ data that passes through
this MVS system and matches your filtering criteria. To record all of that data, enter
ALL in both the Message Data from GETs and Message Data from PUTs fields.
Otherwise, any non-zero numeric value will limit the amount of data recorded from a
single message to that number of bytes.
9-3
Figure 9-3. WebSphere MQ Record/Script Create Defaults - Script Create Settings
Hiperstation ---- Websphere MQ Record/Script Create Defaults -----------------Profile: HIPER
Profile Dataset: 'USER2312.HIPER.PROFILE'
OPTION ===> ________________________________________________
More:
+
----------------------------Script Create Settings---------------------------_ Create Header Filters
(/ for Header Filter Create panel)
Repository Dataset:
Dataset Name
First Number
Last Number
===> _______________________________________________
Amount of Data to Use:
Data from GETs
Data from PUTs
===> _____
===> _____
(ALL/number)
(ALL/number)
Grouping:
Create a New Script for Each:
_ 1. One script for everything
2. New combination of (one or more)
_ Queue manager
_ Connection
_ Object (queue)
_ Jobname
_ Event
Script Content:
Where Should Details be Stored:
(Enter number to select)
_ 1. Merged into the script
2. Separate from the script, input and output together
3. Separate from the script, input and output split
Script Options:
(Enter "/" to select)
_ Suppress Time Stamps in Script
_ Translate Detail Data from ASCII to EBCDIC
_ Translate Sample Data from ASCII to EBCDIC
_ Include Default MQAPI Script Tag parameters
What Should be Created:
_ Create Log entries
_ Create Script entries
_ Create Detail entries
_ Create Event summary entries in CSV format
_ Create Event summary entries in HTML format
_ Create Subset repository
6. Enter a slash (/) to select Create Header Filters and display the WebSphere MQ Header Filter Create screen. See the Hiperstation for WebSphere MQ User Guide or
online help for more information about that screen.
7. Specify your Repository Dataset options.
– Dataset name is required and specifies where captured data will be stored on
DASD. You can enter a fully qualified dataset name up to 44 characters to
allocate a fixed repository. You can also enter a dataset name with a wildcard of
“*” or “?” to allocate a repository set. This set is defined by a range of numbers
entered in the First and Last number fields. Entering an “*” in the dataset name
expands the qualifier to eight characters and fills with zeros (for example, xyz*
would result in XYZ00001). Entering one or more “?”s in the dataset name
replaces those character positions with numbers (for example, XYZ??ABC would
result in XYZ01ABC).
– First Number and Last Number define the range of datasets for your repository
set. You can enter any range from 0 to 9999999. When one dataset fills up, it is
closed and data continues to be written to the next dataset in sequence. These
fields are required if you entered a wildcard in the Repository Dataset name field.
8. Amount of Data to Use can record any WebSphere MQ data that passes through this
MVS system and matches your filtering criteria. To record all of that data, enter ALL
in the Data from GETS and Data from PUTS fields. Otherwise, any non-zero
numeric value will limit the amount of data recorded from a single message to that
number of bytes.
9-4
9. The Grouping fields allow you to reproduce, at playback time, the timing and
sequence of all of the WebSphere MQ data, as seen at capture time, or create scripts
that contain just the subset of WebSphere MQ connections that you need.
1. Select option 1 to create one script for everything.
2. Select option 2 to group your script information by combining one or more
of the choices. Your script choices include collecting the following types of
information: Queue manager, Connection, Object (queue), Jobname, and
Event.
10. The Script Content fields let you choose where to store your script contents, specify
script options, and specify what should be created. Four types of information can be
produced: a log, a script, details, and an event summary.
11. Where should details be stored? Enter a number to select. The choices include:
1. Merged into the script places the details into the same PDSE member as the
script. WebSphere MQ verbs contained in the script will be merged with the
data sent by the verbs. This allows viewing of all data in a single location —
one PDSE member.
2. Separate from script, input and output together places the detail data into
a PDSE member that is separate from the script PDSE member. This keeps the
script member uncluttered with (possibly) non-printable data. In addition, a
file formatting tool can display the detail data since it is now separate from
the WebSphere MQ verbs.
3. Separate from script, input and output split places the detail data into two
PDSE members, both of which are separate from the script member. One
member contains the PUT data and the other member contains the GET data.
12. Enter a slash (/) to select your Script Options. These options include:
– Suppress Time Stamps in Script omits time stamps making the script easier to
browse. Select only if you have no plans to play back the scripts. Time stamps
appear with every WebSphere MQ verb in a script and are used during playback
to keep scripts synchronized. If you are using scripts as debugging tools rather
than for playback, you might want to suppress time stamps to make the scripts
more readable.
– Translate Detail Data from ASCII to EBCDIC converts the content of ASCII
messages to EBCDIC making it easier to display and edit detail data in ISPF. This
option has no effect on messages already in EBCDIC. Hiperstation for
WebSphere MQ adds the TRANSLATE=A2E keyword to the script tag to indicate
that translation has occurred for a particular message. During playback, these
messages are converted back to ASCII.
– Translate Sample Data from ASCII to EBCDIC includes a single line, or sample,
of the detail data in the script for reference purposes when you store script and
detail data separately. This option converts ASCII sample data, based on the
CodedCharSetId field of the MQMD, to EBCDIC. Select this option if you plan to
view your scripts in ISPF.
– Include Default MQAPI Script Tag parameters writes your application's entire
MQ API parameter set into the script. Normally, Hiperstation for WebSphere MQ
saves space in the script by omitting parameters with default settings. Use this
option to ensure all parameters are set appropriately.
13. What Should be Created? Enter a slash (/) to select one or more of the following:
– Create Log entries — A single WebSphere MQ Log is produced for a recording
request that you create. The log contains a list of every script that has been
recorded at your request. Each entry in the log consists of an MQGROUP
statement and a SCRIPT statement. The SCRIPT statement specifies the PDSE
member containing the WebSphere MQ message data. The log, possibly requiring
modifications, is typically used as the SYSIN dataset for your WebSphere MQ
playback job.
9-5
– Create Script entries — A new script is produced for each combination of Queue
manager, connection, object, jobname, and/or event as specified previously on
the Grouping screen. The name of the member is entered into the WebSphere
MQ log on the SCRIPT statement. This allows the log to locate the script
members during playback. A script contains all the WebSphere MQ verbs
(MQ_CONNECT, MQ_OPEN, MQ_PUT, etc.) issued by the specified WebSphere
MQ objects and its partners.
– Create Detail entries — Details refers to data sent to or from WebSphere MQ
objects. It can be human readable or it can consist only of binary data. See step
11 on page 9-4 to specify where to store the details:.
– Create Event summary entries in CSV format — The Event Summary is a report
which contains one record for each PUT or GET. Key information on the Event
Summary is the date, time, and the WebSphere MQ object associated with the
data.
– Create Event summary entries in HTML format — The Event Summary is a
report which contains one record for each PUT or GET. Key information on the
Event Summary is the date, time, and the WebSphere MQ object associated with
the data.
– Create Subset repository — Enter a slash (/) to create a subset repository.
Figure 9-4. WebSphere MQ Record/Script Create Defaults - Output Datasets
Hiperstation ---- Websphere MQ Record/Script Create Defaults -----------------Profile: HIPER
OPTION ===> ________________________________________________
More:
- +
Output Datasets:
Conversation Log:
Dataset Name
===> ______________________________________________
Member Prefix
===> ______
(1 - 6 character prefix)
Member Suffix
===> _______ (2 - 7 numeric suffix)
Replace
===> _
(Enter "/" to replace)
Script Output Dataset:
Dataset Name
===>
Member Prefix
===>
Member Suffix
===>
Replace
===>
______________________________________________
______
_______ (2 - 7 numeric suffix)
_
Combined Detail:
Dataset Name
Member Prefix
Member Suffix
DDname
===>
===>
===>
===>
______________________________________________
______
________
Outbound detail:
Dataset Name
Member Prefix
Member Suffix
DDname
Replace
===>
===>
===>
===>
===>
______________________________________________
______
________
_
Inbound detail:
Dataset Name
Member Prefix
Member Suffix
DDname
===>
===>
===>
===>
______________________________________________
______
________
Event Summary:
Dataset Name
Member Prefix
Member Suffix
Replace
===>
===>
===>
===>
______________________________________________
______
_
14. Several Output Datasets will be created. You can add or change the dataset name,
member prefix, member suffix, or DDname, if desired.
9-6
– Dataset Name: Supply a dataset name (without a member name) for each row.
The dataset names can be fully qualified (enclosed in single quotes) or partially
qualified (not in quotes). Partially qualified dataset names will be prefixed with
your TSO prefix (normally your userid) at processing time. All datasets must be
partitioned datasets extended (PDSE). A regular PDS is not supported. For an
HTML event summary, supply the HFS path of where the report is to be written
(not in quotes).
– Member Prefix: Supply a member name prefix (one to six characters) for each
row marked with an *. This prefix is used (in combination with the suffix) to
create complete member names to be stored in your datasets. You should select
member name prefixes that make it easy for you to identify the type of data
stored in each member. You can supply any prefix that is valid as the start of a
PDSE member name. For an HTML event summary, the prefix is used with the
suffix to create an .htm file and sub-directory.
– Member Suffix: Supply a member name suffix (one to seven numerals) for each
row marked with an *. This suffix is used (in combination with the prefix) to
create complete member names to be stored in your datasets. As Hiperstation for
WebSphere MQ creates new members for each new script, the suffix number is
incremented to produce a unique member names.
– DDname: Supply a data definition name (DDname) for each row marked with an
* that is also for detail data. The DDname can be from one to eight characters in
length. The DDname you supply is written into the script member along with the
WebSphere MQ verbs. The DDname enables to find your detail data when you
play back the script. You must place the same DDname in the Job Control
Language (JCL) used to play back your Hiperstation for WebSphere MQ scripts.
– Replace: If you want Hiperstation to overwrite existing data in your datasets,
select the appropriate “Replace ...” options. Otherwise, Hiperstation will create
new members in your datasets.
Figure 9-5. WebSphere MQ Record/Script Create Defaults - Script Create Exec. Options
Hiperstation ---- Websphere MQ Record/Script Create Defaults ----- End of data
Profile: HIPER
OPTION ===> ________________________________________________
Script
Select
_ 1.
2.
3.
Create Execution Options:
Processing Option: (Enter number to select)
Submit batch job
Edit batch job
Process in foreground
15. Script Create Execution Options specifies whether you want background (batch) or
foreground processing to be your default. Select 1 to perform background processing.
Select 2 to edit a batch job. Select 3 to process in the foreground. Sample JCL is
provided for a batch job, which you can change if desired.
1.
Auditing WebSphere MQ Profile Defaults
This section defines the auditing defaults for WebSphere MQ.
1. Select option 7 Auditing MQ from the “Hiperstation for WebSphere MQ Profile
Screen”.
Note:
shows the profile selection screen. On your actual screen, press FORWARD
(PF8) or BACKWARD (PF7) to view all of the fields.
9-7
Hiperstation
OPTION ===>
+
Active Profile:
Dataset
Member
Description
===> HIPER
_ 1 Domain Traveler
_ 2 APPC
_ 3 3270/LU0
_ 4 WebSphere MQ
_ 5 TCP/IP
_ 6 Auditing 3270
_ 7 Auditing MQ
_ 8 Auditing TCP/IP
_ 9 Playback MQ
_ 10 Playback TCP
_ 11 ATV Manager
settings
settings
settings
settings
MQ
Profile Autosave
===> Y
DSN Autosave
===> Y
(Y = YES, N = NO)
Email address: _______________________________________________________________
Codepage: ISO8859-1
===> //
===> //*
> //*
The “Auditing Defaults for WebSphere MQ Screen” appears (Figure 9-7).
Figure 9-7. Auditing Defaults for WebSphere MQ Screen
Hiperstation
------- Auditing Defaults for WebSphere MQ --------------------Profile: HIPER
OPTION ===> _________________________________________________
_ Create Recording Filters (/ for Filter Create panel)
Datasets:
Registry DSN
Description
Replace Existing
Repositories?
===> _____________________________________________
===> __________________________________________
===> _
1 = Yes, 2 = Terminate
Archive Request Criteria:
_ Exclude SYSTEM traffic ('/')
Recording Date and Time
HH : MM : SS
Start Time
===> 00 : 00 : 00
End Time
===> 00 : 00 : 00
(Optional)
Start Date
End Date
MM / DD / YYYY
00 / 00 / 0000
00 / 00 / 0000
2. Enter a slash (/) to select Create Recording Filters and display the “WebSphere MQ
Data Collect - Filtering Screen”. This screen specifies the Queue Managers, Queue
Names, and Jobnames to capture. It also provides the ability to filter events by
completion and reason codes. See the Hiperstation for WebSphere MQ User Guide or the
online help for information about creating filters.
3. Specify your Datasets information.
9-8
– Registry DSN specifies the name of the dataset that contains the index to this
archive recording request. You can enter a fully qualified dataset name up to 35
characters in length to allocate the repository registry. Repositories created by
this archive record request will be based on the repository registry dataset name
(for example, a repository registry dataset of A.B.C would result in repositories
being created from A.B.C.#0000001 to A.B.C.#9999999).
– Description is an optional field that describes the archive record request. This
description will be provided to the user when the user specifies an archive record
request in the Create Search Reports function.
– Replace Existing Repositories? specifies what should occur when archive record
attempts to switch to a new repository segment and a dataset already exists that
matches that repository segment dataset name. Select 1 or 2.
1 (Yes) deletes the existing dataset and creates a new dataset with the same name
that is allocated and with the same options as the initial repository dataset
segment. Specify this option if it is imperative that the archive record request
remain active.
2 (Terminate) terminates the archive record request. The archive record request
will not start if any datasets exist that match the repository dataset specification.
4. Archive Request Criteria specifies whether to exclude SYSTEM queue traffic
(excluding the SYSTEM.DEFAULT queues). This traffic can be associated with your
WebSphere MQ sessions, and it is recommended to filter it out to avoid obscuring
your application flow. Enter a slash (/) to filter out SYSTEM queue traffic.
5. The Recording Start and End Date and Time fields are optional. For a user profile,
leaving the date and time blank is most useful. When a user specifies a time-frame for
the request, it becomes active at the designated start time. If no time-frame is
specified, it becomes active immediately. Capture begins when all of the criteria for
an active request are met. If you enter a Start Time you must enter a Start Date. If you
enter an End Time you must enter an End Date. Times are entered in a 24-hour clock.
The range of acceptable year values is 2000 to 2040, and the end date and time must
be later than the start date and time.
Playback WebSphere MQ Profile Defaults
This section defines the playback WebSphere MQ profile defaults.
1. Select option 9 Playback MQ from the Hiperstation for WebSphere MQ Profile
screen.
Note:
shows the profile selection screen. The Playback MQ screens in this section
have been combined. Figure 9-9 shows all of the Playback MQ profile
settings. On your actual screen, press FORWARD (PF8) or BACKWARD (PF7)
to view all of the fields.
9-9
Hiperstation
OPTION ===>
+
Active Profile:
Dataset
Member
Description
===> HIPER
_ 1 Domain Traveler
_ 2 APPC
_ 3 3270/LU0
_ 4 WebSphere MQ
_ 5 TCP/IP
_ 6 Auditing 3270
_ 7 Auditing MQ
_ 8 Auditing TCP/IP
_ 9 Playback MQ
_ 10 Playback TCP
_ 11 ATV Manager
settings
settings
settings
settings
MQ
Profile Autosave
===> Y
DSN Autosave
===> Y
(Y = YES, N = NO)
Email address: _______________________________________________________________
Codepage: ISO8859-1
===> //
===> //*
> //*
The “MQ Interactive Playback Defaults Screen” appears (Figure 9-9).
9-10
Figure 9-9. MQ Interactive Playback Defaults Screen
Hiperstation --------- MQ Interactive Playback Defaults ----------------------Profile: HIPER
Profile Dataset: 'userid.HIPER.PROFILE'
OPTION ===> _______________________________________________
More:
+
Playback Information
_ Live
(/ for live I/O, blank for off-line)
_ Use REXX
_ Set REXX Stream Variables
Stop On
===> ____ (End compare report generation after the specified number of mismatches have been reached.)
Standard Wait Time
===> ___
Think Time Option
_ 1. Play at full speed
2. Think time recorded on script
3. User-specified think time
(HH:MM:SS)
===> ________
Percent
===> ___
Reporting Options:
Field Depth
===> __
Max Lines per Page ===> ____
Break
===> _
(Maximum lines to print in field)
(1-9999, 0 for all)
(E)ject, (N)ext
Datasets:
Conversation log:
Dataset Name
===> _______________________________________________
Script Dataset:
Dataset Name
===> _______________________________________________
Database:
Dataset Name
===> _______________________________________________
REXX log:
Dataset Name
===> _______________________________________________
Error log:
Dataset Name
===> _______________________________________________
2. Specify your WebSphere MQ Playback Information.
– In the Live field, enter a slash (/) for interactive playback or leave blank for
unattended playback.
– Use REXX sets REXXON or REXXOFF on the Hiperstation for WebSphere MQ
CONTROL statement. This allows you to use REXX clauses outside of script tags
to perform tasks such as replacing recorded application data during playback. For
Hiperstation for VTAM you can use REXX conditional logic to replace recorded
inputs with variable names to dynamically replace input data with unique values
during playback. Enter a slash (/) to set REXXON or leave blank to set REXXOFF.
– Set REXX Stream Variables is specified in the Hiperstation for Mainframe
Servers and the Hiperstation for WebSphere MQ CONTROL statements. This
parameter enables the use of the Hiperstation for Mainframe Servers 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. Since this is not necessary for replay,
the default value for this parameter is usually set to NO. A slash (/) sets the value
to YES, leave blank to set to NO.
– In the Stop On field, enter a number to end the compare report generation after
the specified number of mismatches have been reached.
3. Specify a Standard Wait Time or enter the number of the Think Time Option you
want to select.
– Standard Wait Time is the Think Time for each transaction.
– Select one of the following Think Time Options:
9-11
1. Play at full speed. Transactions are played back as fast as the system can
execute them.
2. Think time recorded on script. Think time is simulated using the time
recorded on the script.
3. User-specified think time. Enter the think time in the desired number of
minutes and seconds. Or you can enter a percent. One hundred percent
specifies the original think time. Fifty percent specifies one-half the original
think time. Seconds is the only required value.
4. Select the desired Reporting Options.
– Field Depth specifies the number of lines to print in a field before truncating
data. This applies only to Text and CSV reports and allows you to truncate the
printing of large fields that may contain up to two gigabytes of data.
– Max lines per Page specifies the maximum number of lines to print on a page.
Enter a number between 30 and 9999 or zero (0) for all. This applies only to Text
reports. The default is 60.
– Break specifies whether to begin each record on a new page or continue the
report on the next line. This is valid if you are using form reports in a Text or
HTML format. Select EJECT to begin each record on a new page or NEXT to
continue the report on the next line. EJECT is the default.
5. Name your Datasets.
– Conversation Log Dataset Name — The dataset name where you want the
conversation log to reside on DASD.
– Script Dataset Name — The location of the scripts you will play back. This is a
required field and must refer to an existing dataset.
– Database Dataset Name — To report on the playback, enter a name for the
reporting database. Data from the playback is collected to this database and used
in a future reporting job. This field is only required if “Generate Reporting Job” is
selected.
– REXX Log Dataset Name — Specifies that the output generated by REXX
statements in a script is directed to a SYSOUT or DASD dataset, rather than to
SYSPRINT. If the specified value is a single character, the REXX log is allocated to
a SYSOUT class. The SYSOUT goes to the class specified by the single character. If
the value is more than one character, the REXX Log is allocated to a permanent
file with the name dataset.Pnnnn, where nnnn is the port number assigned to the
terminal. Wild cards (* or ?) can be used to identify where the port number
(nnnn) is inserted. A member can also be supplied. By default, REXX output is
directed to the SYSPRINT dataset.
– Error Log Dataset Name — The playback error log is a report that describes any
errors that occurred during playback. If this field is left blank, the report will go
to SYSOUT=*. Enter a dataset name or an hfs path to specify an alternate
location.
9-12
A-1
Appendix A.
Data Collection and Reporting Tables
App A
This appendix provides information to help you define the parameters of your COLLECT
and REPORT statements. See “COLLECT Statement” on page 5-14 and “REPORT
Statement for Custom Reports” on page 6-9.
Most report tables are broken into two sections:
• Report fields: Collect any or all of these fields during playback. Then build custom
reports containing the fields you need. For example,
– COLLECT FIELDS(*) FROM(PLAYBACK)
collects all report fields from the PLAYBACK table.
– REPORT FIELDS(OWNA, JBNA, PLNA) FROM(PLAYBACK)
reports the OwnerName, JobName, and PlaybackName fields from the PLAYBACK
table.
• Statistic fields: These fields report the minimum and maximum values, averages,
and sums of specified report fields. You do not collect statistic fields, you collect the
field on which the statistic is based. For example, collect MQScriptStatementCount
from the MQGROUP table to report the SUM of MQScriptStatementCount on a
PLAYBACK report.
While sorting the collected data, Hiperstation for WebSphere MQ calculates statistics
for that data. Report the statistic by specifying any or all of the statistics fields on
your REPORT statements.
Additionally, statistics are relative to the table from which they are reported. For
example:
– REPORT FIELDS(MAX(MQScriptReturnCode)) FROM(PLAYBACK)
reports the highest script return code that occurred during the playback.
– REPORT FIELDS(MAX(MQScriptReturnCode)) FROM(MQGROUP)
reports the highest script return code from each group played back.
The tables include the long and short name for each report field. Use either on the
FIELDS declarations of your COLLECT and REPORT statements.
PLAYBACK Table
The PLAYBACK table includes both report and statistic fields.
PLAYBACK Report Fields
COLLECT any or all of the following fields and REPORT them on customized PLAYBACK
reports.
Long Field Names
Short Field Names
OwnerName
OWNA
JobName
JBNA
JobNumber
JBNU
A-2
Long Field Names
Short Field Names
SystemName
SYNA
PlaybackName
PLNA
PlaybackNumber
PLNU
PlaybackReturnCode
PLRC
PlaybackStartTime
PLST
PlaybackFinishTime
PLFT
PlaybackDuration
PLDR
MQGroupStatementCount
MQCN
Note: Hiperstation for WebSphere MQ and Hiperstation for Mainframe Servers share the
same PLAYBACK report fields table. As such, a report containing all of the
PLAYBACK fields includes the MQGroupStatementCount field.
PLAYBACK Statistic Fields
REPORT any of the following statistics on customized PLAYBACK reports.
Note:
Use the Collect from Table column to determine the parameters for the
collection statement required to report the given statistic. For example, to report
MAXIMUM MQGroupReturnCode from the PLAYBACK table, collect the
MQGroupReturnCode field from the MQGROUP table. Collect all fields from all
tables to simplify collection and ensure a complete reporting database.
Statistics
For Field (long names)
Field Short Names Collect from Table
MIN or MAX
MQGroupReturnCode
MQRC
MQGROUP
MIN or MAX
MQScriptReturnCode
MSRC
MQSCRIPT
AVG, MIN, MAX, or SUM MQGroupDuration
MQDR
MQGROUP
AVG, MIN, MAX, or SUM MQScriptDuration
MQSD
MQSCRIPT
AVG, MIN, MAX, or SUM MQOpenQueueDuration
OQDR
MQOPENQUEUE
AVG, MIN, MAX, or SUM MQMessageSetDuration
MSSD
MQMESSAGESET
SUM
MQScriptStatementCount
MQSC
MQGROUP
SUM
MQOpenQueueCount
MQOC
MQSCRIPT
SUM
MQMessageSetCount
MSSC
MQSCRIPT
SUM
MQMessageCountQueue
MQCQ
MQOPENQUEUE
SUM
MQMessageCountMessageSet
MQMC
MQMESSAGESET
AVG, MIN, MAX, or SUM MQOpenQueueAttempted
MQOA
MQOPENQUEUE
AVG, MIN, MAX, or SUM MQOpenQueueFailed
MQOF
MQOPENQUEUE
MIN or MAX
MQOP
MQOPENQUEUE
AVG, MIN, MAX, or SUM MQOpenQueueMessageRate
MQMR
MQOPENQUEUE
MIN or MAX
MQMessageVersion
MQMV
MQMESSAGE
MIN or MAX
ExpMQMessageVersion
EXMQMV
MQMESSAGE
MQOpenQueueStatus
MQGROUP Table
The MQGROUP table includes both report and statistic fields.
A-3
MQGROUP Report Fields
COLLECT any or all of the following fields and REPORT them on customized MQGROUP
reports.
Long Field Names
Short Field Names
MQGroupNumber
MQNU
MQGroupID
MQID
MQGroupReturnCode
MQRC
MQGroupStartTime
MQST
MQGroupFinishTime
MQFT
MQGroupDuration
MQDR
MQScriptStatementCount
MQSC
MQGROUP Statistic Fields
REPORT any of the following statistics on customized MQGROUP reports.
Note:
MAXIMUM MQScriptReturnCode from the MQGROUP table, collect the
MQScriptReturnCode field from the MQSCRIPT table. Collect all fields from all
tables to simplify collection and to ensure a complete reporting database.
Statistics
MIN or MAX
MQScriptReturnCode
MSRC
MQSCRIPT
AVG, MIN, MAX, or SUM
MQScriptDuration
MQSD
MQSCRIPT
MQOpenQueueDuration
OQDR
MQOPENQUEUE
MQMessageSetDuration
MSSD
MQMESSAGESET
SUM
MQOpenQueueCount
MQOC
MQSCRIPT
SUM
MQMessageSetCount
MSSC
MQSCRIPT
SUM
MQMessageCountQueue
MQCQ
MQOPENQUEUE
SUM
MQMessageCountMessageSet MQMC
MQMESSAGESET
MQOpenQueueAttempted
MQOA
MQOPENQUEUE
MQOpenQueueFailed
MQOF
MQOPENQUEUE
MIN or MAX
MQOpenQueueStatus
MQOP
MQOPENQUEUE
MQOpenQueueMessageRate
MQMR
MQOPENQUEUE
MIN or MAX
MQMessageVersion
MQMV
MQMESSAGE
MIN or MAX o
ExpMQMessageVersion
EXMQMV
MQMESSAGE
MQSCRIPT Table
The MQSCRIPT table includes both report and statistic fields.
A-4
MQSCRIPT Report Fields
COLLECT any or all of the following fields and REPORT them on customized MQSCRIPT
reports.
Long Field Names
Short Field Names
MQScriptNumber
MQSN
MQScriptName
MSCN
MQGroupNumber
MQNU
MQScriptReturnCode
MSRC
MQScriptStartTime
MSCS
MQScriptFinishTime
MSCF
MQScriptDuration
MQSD
MQOpenQueueCount
MQOC
MQMessageSetCount
MSSC
MQSCRIPT Statistic Fields
REPORT any of the following statistics on customized MQSCRIPT reports.
Note:
MAXIMUM MQMessageSetDuration from the MQSCRIPT table, collect the
MQMessageSetDuration field from the MQMESSAGESET table. Collect all fields
from all tables to simplify collection and to ensure a complete reporting
database.
Statistics
For Fields (long names)
AVG, MIN, MAX, or SUM MQOpenQueueDuration
OQDR
MQOPENQUEUE
AVG, MIN, MAX, or SUM MQMessageSetDuration
MSSD
MQMESSAGESET
SUM
MQMessageCountQueue
MQCQ
MQOPENQUEUE
Sum
MQMC
MQMESSAGESET
AVG, MIN, MAX, or SUM MQOpenQueueAttempted
MQOA
MQOPENQUEUE
AVG, MIN, MAX, or SUM MQOpenQueueFailed
MQOF
MQOPENQUEUE
MIN or MAX
MQOpenQueueStatus
MQOP
MQOPENQUEUE
MQMR
MQOPENQUEUE
MIN or MAX
MQMessageVersion
MQMV
MQMESSAGE
MIN or MAX
ExpMQMessageVersion
EXMQMV
MQMESSAGE
MQMESSAGESET Table
During playback, Hiperstation for WebSphere MQ groups related MQ messages into
message sets for reporting purposes. Grouping is based on MQMD header information.
Hiperstation for WebSphere MQ groups messages with matching correlation IDs. If the
message(s) do not have correlation IDs, it groups them by Message IDs.
Note:
A-5
In addition to matching Correlation and/or Message IDs, the queue on a reply
message must match the queue or the ReplyToQueue on the related request
message to be grouped with that message.
Hiperstation for WebSphere MQ creates a Message Set for each:
• Request message and all of its related messages
• Non-request message that is not related to any other message—these message sets
contain only a single message
Finally, Hiperstation for WebSphere MQ treats datagrams as reply messages unless they
contain a ReplyToQueue. Then they are treated as request messages.
Use the MQMESSAGESET table to collect and report information about message sets. It
includes both report and statistics fields.
MQMESSAGESET Report Fields
COLLECT any or all of the following fields and REPORT them on customized
MQMESSAGESET reports.
Long Field Names
Short Field Names
MQMessageSetNumber
MSSN
MQMessageSetID
MMSI
MQScriptNumber
MQSN
MQGroupNumber
MQNU
MQMessageSetStartTime
MSTS
MQMessageSetFinishTime
MSTF
MQMessageSetDuration
MSSD
MQMC
MQMESSAGESET Statistic Fields
REPORT any of the following statistics on customized MQMESSAGESET reports.
Note:
MAXIMUM MQMessageVersion from the MQMESSAGESET table, collect the
MQMessageVersion field from the MQMESSAGE table. Collect all fields from all
tables to simplify collection and to ensure a complete reporting database.
Statistics
MIN or MAX
MQMessageVersion
MQMV
MQMESSAGE
MIN or MAX
EXPMQMessageVersion
EXMQMV
MQMESSAGE
MQOPENQUEUE Table
The MQOPENQUEUE table includes only report fields. There are no statistics fields.
A-6
MQOPENQUEUE Report Fields
MQOPENQUEUE reports.
Long Field Names
Short Field Names
MQOpenQueueNumber
OQNU
MQOpenQueueID
OQID
MQScriptNumber
MQSN
MQGroupNumber
MQNU
MQOpenQueueName
QNAM
MQOpenQueueManagerName
QMNA
MQOpenQueueStartTime
MSCS
MQScriptFinishTime
MSCF
MQOpenQueueDuration
OQDR
MQMessageCountQueue
MQCQ
MQOpenQueueAttempted
MQOA
MQOpenQueueFailed
MQOF
MQOpenQueueStatus
MQOP
MQMR
MQMESSAGE Table
The MQMESSAGE table includes only report fields. There are no statistics fields.
MQMESSAGE Report Fields
MQMESSAGE reports.
Note: All fields from MQMessageVersion through the end of the table collect and report
information from the MQMD header.
Long Field Names
Short Field Names
MQMessageNumber
MMNU
MQMessageID
MMID
MQMessageSetNumber
MSSN
MQOpenQueueNumber
OQNU
MQScriptNumber
MQSN
MQGroupNumber
MQNU
MQMessageVersion
MQMV
MQMessageReport
MQRO
MQMessageType
MQTY
MQMessageExpiry
MQEX
MQMessageFeedback
MQFD
Long Field Names
Short Field Names
MQMessageVersion
MQMV
MQMessageEncoding
MQEN
MQMessageCharSetID
MQCS
MQMessageFormat
MQFM
MQMessagePriority
MQPR
MQMessagePersistence
MQPS
MQMessageMsgID
MQMI
MQMessageCorrelationID
MQCI
MQMessageBackoutCount
MQBC
MQMessageReplyToQueue
MQRQ
MQMessageReplyToQueueMgr
MQRM
MQMessageUserIdentifier
MQUI
MQMessageAccountingToken
MQAT
MQMessageApplIdentifyData
MQAI
MQMessagePutApplType
MQPA
MQMessagePutApplName
MQPN
MQMessagePutDate
MQPD
MQMessagePutTime
MQPT
MQMessageApplOriginData
MQAO
ExpMQMessageVersion
EXMQMV
ExpMQMessageReport
EXMQRO
ExpMQMessageType
EXMQTY
ExpMQMessageExpiry
EXMQEX
ExpMQMessageFeedback
EXMQFD
ExpMQMessageEncoding
EXMQEN
ExpMQMessageCharSetID
EXMQCS
ExpMQMessageFormat
EXMQFM
ExpMQMessagePriority
EXMQPR
ExpMQMessagePersistence
EXMQPS
ExpMQMessageMsgID
EXMQMI
ExpMQMessageCorrelationID
EXMQCI
ExpMQMessageBackoutCount
EXMQBC
ExpMQMessageReplyToQueue
EXMQRQ
ExpMQMessageReplyToQueueMgr
EXMQRM
ExpMQMessageUserIdentifier
EXMQUI
ExpMQMessageAccountingToken
EXMQAT
ExpMQMessageApplIdentifyData
EXMQAI
ExpMQMessagePutApplType
EXMQPA
ExpMQMessagePutApplName
EXMQPN
ExpMQMessagePutDate
EXMQPD
A-7
A-8
Long Field Names
Short Field Names
ExpMQMessagePutTime
EXMQPT
ExpMQMessageApplOriginData
EXMQAO
MQMessageOutbound
MQMessageInbound
1
2
MQMessageExpectedInbound
MQMO
MQMB
MQME
MQMessageQueueManagerAndQueue QMAQ
1. Outbound indicates an MQ_PUT
2. Inbound indicates an MQ_GET
B-1
Appendix B.
Hiperstation for WebSphere MQ Samples Index
Appendix A.
App B
Playback Control Library
Basic Playback Control Assets
The following samples are basic playback control assets that you can use to run
unattended playback jobs. Copy them into your own asset libraries and modify them to
meet your needs.
Sample Name
Description
ANALYZE
CONTROL Card for Script Analysis Job
COLLECT
Playback CONTROL Card to Collect All Report Data
NONE
Playback and Report CONTROL Card To Skip Action
PLAYBACK
Playback CONTROL Card to Produce A Full Playback
Sample Log Files
The following log file samples correspond to the example testing scenarios discussed in
Chapter 8, “Testing Scenarios”.
Sample Name
Description
LOGCR000
WebSphere MQ Log for a Playback Using Count and Repeat
LOGDD000
WebSphere MQ Log for a Data Driven Playback w/Data Replacement
LOGDD001
WebSphere MQ Log for a Data Driven Playback Capturing Data
LOGDD002
WebSphere MQ Log for a Data Driven Playback Data Pump
LOGED000
WebSphere MQ Log for a Data Driven Playback Expanding Queue Data
LOGMG000
WebSphere MQ Log for a Playback Using Multiple Groups
LOGMG001
WebSphere MQ Log Used By LOGMG000
LOGMG002
LOGMG003
LOGMG004
LOGMG005
LOGMG006
WebSphere MQ Log for a Playback Using Multiple Groups w/PLAY_TO
LOGMS000
WebSphere MQ Log for a Playback Using Multiple Scripts
LOGPD000
WebSphere MQ Log for a Data Driven Playback w/REPEAT and COUNT
LOGPT000
WebSphere MQ Log for a Playback Using PLAY_TO
LOGSC000
WebSphere MQ Log for a Playback Using SKIP Connection
LOGSC001
WebSphere MQ Log for a Playback Using SKIP Connection and PLAY_TO
LOGSD000
WebSphere MQ Log for a Data Driven Playback Using Static Data
B-2
Sample Name
Description
LOGTD000
WebSphere MQ Log for Controlling Playback Duration Scenario
LOGTQ000
WebSphere MQ Log for a Playback Using TO_QUEUE
LOGTS000
WebSphere MQ Log for Controlling the Playback Synchronization Scenario
Reporting Control Library
JCL to Create Web Reports
The following JCL samples produce specific web reports.
Note:
A data collection from an unattended playback job is required to use these
samples.
Samples
Description
MQRJCL3
JCL for Response Time Reports Using JCL Procedure
MQRJCL4
JCL for Script Time Reports Using JCL Procedure
MQRJCL5
JCL for Exception Reports Using JCL Procedure
MQRJCL6
JCL for Exception w/Baseline Reports Using JCL Procedure
MQRJCL7
JCL for Exception w/Masking Reports Using JCL Procedure
REPORT and Reporting CONTROL Statements
The following sample members contain REPORT and reporting CONTROL statements.
Samples
Description
MQRANLZ
Report Cards to Produce Default Analysis Report
MQRCFH
Report Control Cards to Produce LAYOUT(FORM) HTML Reports
MQRCFT
Report Control Cards to Produce LAYOUT(FORM) TEXT Reports
MQRCOMP
Report Cards to Produce Analysis and Comparison Reports
MQRCTH
Report Control Cards to Produce LAYOUT(TABLE) HTML Reports
MQRCTT
Report Control Cards to Produce LAYOUT(TABLE) TEXT Reports
MQRDUR
Report Cards to Produce Playback Duration Reports
MQRREXCB
Report Cards to Produce Playback Exception w/Baseline Reports
MQRREXCM
Report Cards to Produce Playback Exception w/Masking Reports
MQRREXCP
Report Cards to Produce Playback Exception Reports
MQRRGR
Report Cards to Produce Playback MQGROUP Analysis Reports
MQRRMG
Report Cards to Produce Playback MQMESSAGESET Reports
MQRRMS
Report Cards to Produce Playback MQGROUP Analysis Reports
MQRROQ
Report Cards to Produce Playback MQOPENQUEUE Analysis Reports
MQRRPL
Report Cards to Produce PLAYBACK Analysis Reports
MQRRRESP
Report Cards to Produce Playback Response Time Reports
MQRRSC
Report Cards to Produce Playback MQSCRIPT Analysis Reports
MQRRSCRT
Report Cards to Produce Playback Script Time Reports
Hiperstation for WebSphere MQ Samples Index
B-3
Script Library
The library contains sample script files that correspond to the example testing scenarios
Samples
Description
FDDDD000
Script Used by the Data Driven Sample Log Member LOGDD000
FDDDD001
FDDDD002
FDDED000
Script Used by the Data Driven Sample Log Member LOGED000
FDDPD000
Script Used by the Data Driven Sample Log Member LOGPD000
FDDSD000
Script Used by the Data Driven Sample Log Member LOGSD000
SCRCR001
Script Used by the Playback Sample Log Member LOGCR000
SCRMG001
Script Used by the Playback Sample Log Member LOGMG000
SCRMG002
SCRMG003
SCRMQ004
SCRMQ005
SCRMS000
Script Used to Create the Sample Scripts SCRMS001, SCRMS002
SCRMS001
Script Used by the Playback Sample Log Member LOGMS000
SCRMS002
Script Used by the Playback Sample Log Member LOGMS000
SCRPT001
Script Used by the Playback Sample Log Member LOGPT000
SCRSC000
Script Used by the Playback Sample Log Member LOGSC000
SCRSC001
Script Used by the Playback Sample Log Member LOGSC001
SCRTD001
Script Used by the Playback Sample Log Member LOGTD000
SCRTQ000
Script Used by the Playback Sample Log Member LOGTQ000
SCRTS001
Script Used by the Playback Sample Log Member LOGTS000
Repository Datasets
The following repository dataset sample files correspond to the example testing scenarios
Sample
Description
REPOS1
Sample MQ Repository Used to Create Sample Log and Script Members
REPOS2
REPOS3
REPOS4
B-4
Samples Library (SQQFSAMP)
Playback and Reporting JCL and JCL SYSIN
Use the following JCL samples to establish system-level libraries or to execute a playback
or reporting job using the log file produced by script create or the MQRUN1 sample.
Samples
Description
MQPBCOPY
JCL to Create Playback and Report Control and JCL Library
MQPBCTL
Member List Used to Create Playback Control and JCL Library
MQPBRPT
Member List Used to Create Report Control and JCL Library
MQPLAY1
JCL Procedure to Run MQ Playback from a Log or MQRUN1
MQREPT1
JCL Procedure to Run MQ Reports from a Log or MQRUN1
MQRUN1
JCL to Run MQPLAY1 or MQREPT1 JCL Procedures
Global Recording Batch Interface JCL and XML
Use the following JCL samples to add or manage Global Recording requests with batch
jobs. See “Using the Global Recording Batch Interface” on page 2-9, for more
information.
Samples
Description
DCIJCL
Sample JCL to add or manage Global Recording requests
DCIADDMQ
Sample of commonly used Global Recording request creation XML parameters
DCIADXMQ
Sample of all available Global Recording request creation XML parameters
C-1
Appendix C.
Customer Support Diagnostics
Appendix A.
App C
The Customer Support Diagnostic Report produces a list of PTFs that have been applied
to your installation. Customer Support may ask you to generate the report to aid in
diagnosing an issue.
Note:
Generating this report requires READ access to the SMP/E datasets. Consult with
your Security Administrator if you do not have the proper authority.
To generate the Customer Support Diagnostic:
1. On the Hiperstation Product Menu, type PTFS on the Option Line and press Enter.
The “Hiperstation - Diagnostics Screen” appears (Figure C-1).
Figure C-1. Hiperstation - Diagnostics Screen
---------------------- Hiperstation - Diagnostics ------------------Command ===>
Specify the install and output datasets, then press ENTER to continue.
Input datasets to use:
Global CSI dataset . . 'COMPWARE.QQF800.GLOBAL.CSI'
Target Zone . . . . . . QQF800
Output datasets to use:
PTF output list . . . . 'JSMITH.PTFS.REPORT'
===> //USER05 JOB ('ACCOUNT',99),'J.SMITH',REGION=0M,
===> //
NOTIFY=&SYSUID,CLASS=A,MSGCLASS=R,USER=JSMITH
===> //*
===> //*
The Global CSI dataset is the SMP/E Global CSI dataset. The Target Zone is the
SMP/E Target Zone. These fields default to the dataset name and target zone
established by your installer. The PTF output list is the sequential dataset to contain
the report.
2. Complete the PTF output list field, insert a job card, and press Enter. Hiperstation
submits the job.
3. Once the job has completed, view the report with ISPF. Figure C-2 shows a sample
report.
C-2
Figure C-2. Customer Support Diagnostic Report
********************************* Top of Data **********************************
+---------------------------------------------------------------+
|
Hiperstation PTF list 05/10/07 15:32:08
|
|
Loadlib: SYS2.HIPER.SQQFLOAD
|
+---------------------------------------------------------------+
QF43181 QF44415 QF45463 QF46350 QF47331 QF47364 QF47687 QF47857
QF50457 QF50731
******************************** Bottom of Data ********************************
D-1
Appendix D.
Script Create Parameters
App D
Table D-1 describes the Script Create parameters found in the JCL generated during the
script create process. Each parameter corresponds to a field or an option on the Script
Create screens or to an operational parameter defined by the installer.
Table D-1. Script Create Parameters
Name
Description
FILTERS._ACTION.n
Action for filter n (INCL/EXCL)
FILTERS._APPL_ID_DATA.n
ApplIdentityData for filter n
FILTERS._APPL_ID_DATA_OP.n
Relational operator for ApplIdentityData for filter n
FILTERS._APPL_ORIGIN_DATA.n
ApplOriginData for filter n
FILTERS._APPL_ORIGIN_DATA_OP.n
Relational operator for ApplOriginData for filter n
FILTERS._COMP.n
Completion code for filter n
FILTERS._COMP_OP.n
Relational operator for Completion code for filter n
FILTERS._CONTENT.0.n
Number of <CONTENT> filters for filter n
FILTERS._CONTENT.x.n
<CONTENT> filter value for message filter x within filter n
FILTERS._CONTENT_LEN.x.n
Length of filter value for message filter x within filter n
FILTERS._CONTENT_OP.x.n
Relational operator for message filter x within filter n
FILTERS._CONTENT_POS.x.n
Offset into <CONTENT> data of message filter x within filter n
FILTERS._CONTENT_TYP.x.n
Data type value of message filter x within filter n
FILTERS._EVENT.n
Event type for filter n
FILTERS._EVENT_OP.n
Relational operator for Event type for filter n
FILTERS._JOBNAME.n
Jobname for filter n
FILTERS._JOBNAME_OP.n
Relational operator for Jobname for filter n
FILTERS._PUT_APPL_NAME.n
PutApplName for filter n
FILTERS._PUT_APPL_NAME_OP.n
Relational operator for PutApplName for filter n
FILTERS._PUT_APPL_TYPE.n
PutApplType for filter n
FILTERS._PUT_APPL_TYPE_OP.n
Relational operator for PutApplType for filter n
FILTERS._PUT_DATE.n
PutDate for filter n
FILTERS._PUT_DATE_OP.n
Relational operator for PutDate for filter n
FILTERS._PUT_TIME.n
PutTime for filter n
FILTERS._PUT_TIME_OP.n
Relational operator for PutTime for filter n
FILTERS._QMGR.n
Queue manager for filter
FILTERS._QMGR_OP.n
Relational operator for queue manager for filter n
FILTERS._QUEUE_OBJECT_NAME.n
Queue (object) name for filter n
FILTERS._QUEUE_OBJECT_NAME_OP.n Relational operator for Queue (object) name for filter n
FILTERS._REASON.n
Reason code for filter n
D-2
Name
Description
FILTERS._REASON_OP.n
Relational operator for Reason code for filter n
FILTERS._USERID.n
UserIdentifier for filter n
FILTERS._USERID_OP.n
Relational operator for UserIdentifier for filter n
FILTERS.0
Number of filters
MQCRDCLS
Data class for the temporary dataset required to create the HTML
Event Summary
MQCRMCLS
Management class for the temporary dataset required to create
the HTML Event Summary
MQCRPRIM
Primary space value for the temporary dataset required to create
the HTML Event Summary
MQCRSCLS
Storage class for the temporary dataset required to create the
HTML Event Summary
MQCRSCND
Secondary space value for the temporary dataset required to
create the HTML Event Summary
MQCRSPAC
Space units for the temporary dataset required to create the
HTML Event Summary
MQCRSUB
Create Subset Repository
MQCRSUM
Record event summary
MQCRSUMH
Create HTML Event Summary flag
MQCRUNIT
DASD Unit name to contain the temporary dataset required to
MQCRVOLM
Volume name to contain the temporary dataset required to
MQSCCNTA
Where should details be stored (1/2/3)
MQSCDBCS
DBCS flag
MQSCDESC
Script description
MQSCDMT
Include default MQAPI parameters flag
MQSCEDA
Filtering: End Date (Day)
MQSCEHR
Filtering: End Time (Hour)
MQSCEMI
Filtering: End Time (Minute)
MQSCEMO
Filtering: End Date (Month)
MQSCESD
Output: Event Summary Dataset
MQSCESE
Filtering: End Time (Second)
MQSCESP
Output: Event Summary Prefix
MQSCESQ
Output: Event Summary Required (do not modify)
MQSCESS
Output: Event Summary Suffix
MQSCEYR
Filtering: End Date (Year)
MQSCGRP1
Grouping: New script for Queue Manager
MQSCGRP2
Grouping: New script for Connection
MQSCGRP3
Grouping: New script for Object (Queue)
MQSCGRP4
Grouping: New script for Jobname
MQSCGRP5
Grouping: New script for Event
D-3
Name
Description
MQSCJC1
JCL job header line 1
MQSCJC2
MQSCJC3
MQSCJC4
MQSCJCL
Generate playback JCL in script create log flag. The default
behavior of this parameter is set by the installer.
MQSCSMSG
Maximum message size, in kilobytes, that can be processed (32K
is the default)
Note: This parameter does not correspond to a field or
operational parameter. Add the parameter to the Script Create
JCL prior to submitting the job. See “Select a Processing Option”
on page 3-24 to find out how to access the JCL for edit.
MQSCOBD
Output: Combined Detail Dataset
MQSCOBN
Output: Combined Detail DDname
MQSCOBP
Output: Combined Detail Prefix
MQSCOBQ
Output: Combined Detail Required (do not modify)
MQSCOBS
Output: Combined Detail Suffix
MQSCOCD
Output: GET Detail Dataset
MQSCOCN
Output: GET Detail DDname
MQSCOCP
Output: GET Detail Prefix
MQSCOCQ
Output: GET Detail Required (do not modify)
MQSCOCS
Output: GET Detail Suffix
MQSCOLD
Output: Log Dataset
MQSCOLP
Output: Log Prefix
MQSCOLQ
Output: Log Required (do not modify)
MQSCOLS
Output: Log Suffix
MQSCOPD
Output: Script Dataset
MQSCOPP
Output: Script Prefix
MQSCOPQ
Output: Script Required (do not modify)
MQSCOPS
Output: Script Suffix
MQSCOSD
Output: PUT Detail Dataset
MQSCOSN
Output: PUT Detail DDname
MQSCOSP
Output: PUT Detail Prefix
MQSCOSQ
Output: PUT Detail Required (do not modify)
MQSCOSS
Output: PUT Detail Suffix
MQSCPLIB
Library containing playback and reporting procedures, typically
Hiperstation samples library. This value is written into the script
create log to run unattended playback and reporting jobs.
MQSCPLYC
Library containing playback control members. This value is
written into the script create log to run unattended playback and
reporting jobs.
MQSCQTD
Translate detail from ASCII to EBCDIC
D-4
Name
Description
MQSCQTM
Suppress timestamps in script
MQSCQTS
Translate sample data from ASCII to EBCDIC
MQSCRBLK
Output Subset Repository: Allocation block size
MQSCRD
Record Detail entries
MQSCREPC
Library containing reporting control members. This value is
written into the script create log to run unattended playback and
reporting jobs.
MQSCRL
Record Log Entries
MQSCRPRM
Output Subset Repository: Primary space allocation
MQSCRS
Record Script Entries
MQSCRSDC
Output Subset Repository: Allocation SMS Data class
MQSCRSEC
Output Subset Repository: Secondary space allocation
MQSCRSMC
Output Subset Repository: Allocation SMS Management class
MQSCRSPC
Output Subset Repository: Allocation space units
MQSCRSSC
Output Subset Repository: Allocation SMS Storage class
MQSCRUNT
Output Subset Repository: Allocation unit
MQSCRVOL
Output Subset Repository: Allocation volume serial number
MQSCSCNT
Grouping: Option (1/2)
MQSCSDA
Filtering: Start Date (Day)
MQSCSDD1
Name of Hiperstation SQQFEXEC library
MQSCSDD2
Name of Hiperstation SQQFLOAD library
MQSCSHR
Filtering: Start Time (Hour)
MQSCSI1
Input Repository: First Number
MQSCSI2
Input Repository: Last Number
MQSCSICL
Message Data from GETs
MQSCSIDN
Input Repository: Dataset Name
MQSCSISL
Message Data from PUTs
MQSCSMI
Filtering: Start Time (Minute)
MQSCSMO
Filtering: Start Date (Month)
MQSCSO1
Output Subset Repository: First segment number
MQSCSO2
Output Subset Repository: Last segment number
MQSCSODN
Output Subset Repository: Dataset Specification
MQSCSQER
Error event notification flag
MQSCSQNR
Normal event notification flag
MQSCSSE
Filtering: Start Time (Second)
MQSCSTP1
Log STEPLIB override 1
MQSCSTP2
Log STEPLIB override 2
MQSCSUB
Submit option (1/2/3)
MQSCSUM
Replace existing event summary members
D-5
Name
Description
MQSCSUPR
Force messages uppercase flag
MQSCSYR
Filtering: Start Date (Year)
MQSCWD
Replace existing detail members
MQSCWL
Replace Existing Log members
MQSCWS
Replace existing script members
MQSUSER
User ID of submitter (used only in PDSE statistics)
TEMPEVNT
Name of the temporary dataset that is internally allocated for the
creation of an HTML Event Summary. Do not modify the
parameter.
D-6
G-1
Glossary
This glossary gives a brief description of
Hiperstation for WebSphere MQ terms, and other
related terms referred to in this document.
abend. ABnormal END of task. The termination
of a job, prior to normal completion, due to an
unresolved error condition.
APPC. Advanced Program-to-Program Communications. A protocol in a distributed environment
that allows programs to talk to each other and
interconnected systems to communicate and share
the processing of programs.
APPC conversation. The activity that occurs
between ALLOCATE and DEALLOCATE.
archive/search function. A Hiperstation option
that allows you to create archive record requests. A
request is started and repositories are generated
based on filter criteria. The registry dataset contains entries that indicate the date and time ranges
of each generated repository segment so that the
Archive/Search function can locate specific datasets by date and time.
batch. Processing in which jobs are submitted
and processed in the background. The jobs run
unattended and are executed sequentially. Each
job must be processed to completion before the
following job can begin execution. Batch is the
converse of an interactive or online task.
capture repository. A repository where recorded
activity is written to a sequential dataset or series
of datasets. Testing scripts are then generated from
the capture repository. Capture repositories contain recorded activity in a compressed format. See
also repository dataset.
capture segment summary report. A report that
indicates when recording began and ended for
each segment of one or more specified capture
repositories. You can use it to help you identify
the information contained in each segment. For
example, generate this report to script activity that
was captured on Monday morning from 8:00 am
to 12:00 pm if you are unsure which repository
segment contains the information. You can import
the report into a spreadsheet or database for easy
manipulation.
CHIN. Channel Initiator. A WebSphere MQ channel initiator.
CICS. Customer Information Control System. An
IBM-licensed program that enables transactions
entered at remote terminals to be processed concurrently by user-written application programs. It
includes facilities for building, using, and maintaining databases.
command. Request from a terminal to execute an
operation or program.
COMMAND field. Field in which you enter commands to execute an operation or program.
customer support diagnostics report. A report
that produces a list of PTFs that have been applied
to your installation. Customer Support may ask
you to generate the report to aid in diagnosing an
issue.
CSV. Comma Separated Value. A report format
that is available for custom Playback reports. Some
basic reports support only HTML while others support TEXT and HTML.
DASD. Direct Access Storage Device. Any peripheral device that is directly addressable, such as a
disk or drum.
dataset. Refers to files stored on an IBM mainframe computer. Datasets can be organized in various ways, such as logical record and block
structures.
DB2. DATABASE 2. IBM’s database management
system that provides a relational model of data.
DB2 runs as a subsystem of MVS and on other
platforms.
DBCS. Double Byte Character Set. Used primarily
to display Japanese Kanji characters during 3270
testing.
dump. Hexadecimal representation of storage
that may contain data useful for diagnosing an
error.
Enterprise Common Components (ECC). The
shared components of mainframe Compuware
products, that provide Compuware License Management System.
exception. (1) An abnormal situation that may
occur during a program’s execution that may
cause a deviation from the normal execution
sequence, and for which facilities exist in the programming language to define, recognize, ignore,
or handle it. (2) An abnormal condition such as an
G-2
I/O error encountered in processing a dataset or
file.
file. Set of related records that are organized and
treated as a unit.
GDG. Generation Data Group.
global record manager. A Hiperstation for VTAM
function that builds lists of applications, terminals, and user IDs to include or exclude from
recording. Global Record Manager Lists provide
greater flexibility in defining Global Recording
requests.
global recording. An option that captures the
activity of one or more users. This option writes
the activity to a repository that generates testing
scripts. It records LU0 and3270 traffic to generate
stress tests or to archive activity for audit purposes. It also captures LU6.2, TCP/IP and MQ data.
You can record while groups of users perform their
daily routines and choose the exact terminals,
applications, and time frames to record. You can
choose to include or exclude certain messages
from recording based on a predefined list of messages. Message filtering provides a script that contains a subset of the messages from the 3270
session. You can also create and reuse lists of user
IDs, logical unit (LU) names, or applications that
can be included or excluded from a session.
MQ script. Formatted human-readable data generated from a capture repository. You can generate
scripts from selected sessions or from entire capture repositories.
MVS. Multiple Virtual Storage. The primary operating system used on large IBM mainframe computers. It is packaged as the operating system
component of OS/390 and z/OS. It was packaged
separately as MVS/XA (eXtended Architecture),
MVS/ESA (Enterprise Systems Architecture), and
OS/MVS. Through its evolution, the core operating system has remained fundamentally the same.
Most programs written for MVS can run on z/OS
without modification.
offset. A relative location or position within a
data area.
operating system. Software that controls the
execution of jobs. It may provide resource allocation and scheduling.
operation exception. An operation exception
occurs when the CPU attempts to execute an
instruction with an invalid operation code. The
operation code may be unassigned, or the instruction with that operation code may not be installed
on the CPU.
OS. Operating System.
GMT. Greenwich Mean Time.
PIU. Path Information Units.
IMS. Information Management System. IBM’s
hierarchical database information management
system and transaction processor capable of managing complex databases and networks.
PDS. Partitioned Dataset.
JCL. Job control language. A job or task control
language that describes how a job or task will be
executed. All non-operating system tasks (batch or
online) use JCL to execute in MVS/JES2.
line command. Command that is typed directly
on the line to be processed.
masking. A function that prevents comparison of
specified MQ message data. Data masks are statements that specify qualification criteria and stipulate the positions to mask if the criteria is met.
Masking date and time fields will prevent generating mismatches for data that you expect to be different.
message sets. A set of messages grouped during
playback for reporting purposes. Grouping is based
on MQMD header information. Hiperstation for
WebSphere MQ groups messages with matching
correlation IDs. If the messages do not have correlation IDs, it groups them by Message IDs.
PDSE. Partitioned Dataset Extended.
PF keys. Program Function keys. ISPF uses PF keys
for many commonly used functions such as
<End>, <Repeat Find>, and <Scroll>. For example,
pressing the PF3 key in ISPF usually sends the
<End> command to the application. Most terminals have 24 PF keys.
PF key mapping. A method for assigning functions to your PF keys. If your terminal has 24 PF
keys, you can assign some of them to the domain
destination. ISPF uses the rest of the keys. Generally, PF1 through PF12 are mapped to PF1 through
PF12 for the domain destination, and PF13
through PF24 are seen directly by ISPF. This map
correspondence is established on the Session
Options screen.
PLU. Primary Logical Unit. The logical unit that
is being accessed by the SLU. See SLU.
primary command. Command that provides a
general function and is entered in the COMMAND
field.
G-3
playback. A function to play back scripts and
execute the commands found in the script.
repository dataset. The name of the dataset to
use for storing captured information. For active
requests, this is the dataset in which data is currently being written. See also capture repository.
request parameters skeleton. A complete set of
Global Recording parameters with default values.
You can generate a skeleton to save time when creating a new request, see all of the available parameters, and reference the syntax of a particular tag
REXX log. A log that records the text of REXX
SAY statements. These statements can be used to
track script progress.
script language tokens. Consist of variable
names, arithmetic operators, constants, and other
language constructs.
SLU. Secondary Logical Unit. The logical unit
that initiated the session. See PLU.
STIME. Start time. The start date and time of a
connection, recorded activity in a script, or when
the first transaction in a group began. STIME is
used on the MQGROUP statement. STIME is used
in conjunction with USESTIME.
storage. A functional unit into which data can be
placed and from which it can be retrieved.
structure data types. Groups of parameters or
fields that contain information relevant to a specific MQ object or function. Each of the structure
data type fields requires a specific type of value,
for example, some require character strings, while
others require numeric values.
subset repository. A repository that contains
only the desired activity. An entire repository is
processed during script creation, and the larger the
repository, the longer it takes to create scripts.
Subset repositories are created to minimize script
creation time and storage overhead.
subtask. Task initiated and terminated by a
higher order task.
TCP/IP. Transmission Control Protocol/Internet
Protocol. Communication protocols on which the
Internet and most commercial networks run.
think time. The amount of time between each
recorded user action.
THOPT. Think option. A playback parameter that
forces the group to play back at approximately the
same speed as it was recorded. THOPT in APPC is
used on the ALLOCATE/ACCEPT statements.
THOPT in TCP/IP is used on the CONTROL statement and/or the MQGROUP statement. THOPT for
Abend-AID for WebSphere MQ is used on the
CONTROL statement.
trace. Record of the execution of a computer program; it exhibits the sequences in which the
instructions were executed.
transaction. A unit of processing, which consists
of one or more application programs, begun by a
single request (usually from a terminal).
trigger monitor. A long running background job,
task, or process that waits on and processes any
MQ Trigger Messages from a MQ Trigger Initiation
Queue. MQ Trigger Messages are generated by messages arriving on a MQ Trigger Queue. The purpose of the Trigger Monitor is to initiate job, task,
or command processing based on the indication of
the corresponding trigger message.
trigger queue. A WebSphere MQ queue enabled
for triggering and defined with indications of a
initiation queue and trigger message definitions
that will ultimately be processed by an MQ Trigger
Monitor for the purpose of starting a job, task, or
command.
unattended playback. A function that allows
you to play back scripts to test WebSphere MQ
applications. Provided that you collect the appropriate playback information, you can generate
reports that compare the activity resulting from
playback (actual) to the activity recorded in the
script (expected).
USESTIME. Use Start Time. A playback CONTROL
statement parameter that allows you to stagger
group playback to accommodate application timing requirements. The USESTIME parameter forces
playback of the groups relative to each group’s
STIME. Apply the USESTIME parameter and modify the STIME to stagger playback. USESTIME is on
the CONTROL STATEMENT for APPC and on the
CONTROL and/or SOCKET statement for TCP/IP.
VSAM. Virtual Storage Access Method. An access
method for direct or sequential processing of fixed
and variable length records on direct access
devices.
VTAM. Virtual Telecommunications Access
Method. Set of programs that control communication between terminals and application programs.
WebSphere MQ. An IBM network communication technology that is part of a suite of WebSphere products. It provides the ability for
independent programs on a distributed system to
communicate with each other. Formerly called
MQSeries.
G-4
XML. Extensible Markup Language. A language
that is capable of describing many different kinds
of data. The XML file can contain the data as well
as the data description or structure. Its purpose is
to share data across different systems.
z/OS. IBM enterprise mainframe suite of product
components, one of which is the MVS operating
system. It is used to build and deploy Internet and
Java-enabled applications, providing a comprehensive and diverse application execution environment.
I-1
Index
A
accessibility, xviii
font and font size, xix
keyboard shortcuts, xx
windows accessibility features, xix
ACTUAL_COMPCODE REXX variable, 3-44
ACTUAL_CORRELID REXX variable, 3-45
ACTUAL_LENGTH REXX variable, 3-45
ACTUAL_MSG REXX variable, 3-45, 8-46
ACTUAL_MSGID REXX variable, 3-45
ACTUAL_REASON REXX variable, 3-45
administrator access
Monitor MQ Requests, 2-9
Adobe Reader, xiii
allocate datasets
logs, scripts, details, event summaries, 3-24
repositories, for, 3-22
amount of data to use, 2-6
analyze scripts, 8-52
ASCII
translate detail data to EBCDIC, 3-16, 9-4
translate sample data to EBCDIC, 3-16, 9-4
B
baseline reporting, 8-52
Baseline Comparison Report, 8-18
basic reports, 6-2, 6-6
navigate, 6-16
BookManager
documentation output, xiv
known issues, xv
browse a script, 3-26
BRULE macro, 3-42
BRULES macro, 3-42
C
capture file
parameter tags, 2-16
See repository datasets
Capture Segment Summary, 3-1–3-2
channel initiator, G-1
CHIN, 2-2
character filters, 3-10
CHIN, 2-2
COLLECT statement, 5-14
completion code, 3-21
return actual and expected, 3-44
connection attributes
GET_FROM, 5-3
PUT_TO, 5-3
QUEUE_MANAGER, 5-3
REPLY_TO_QUEUE, 5-3
connection sequence links, 3-19
<CONTENT> tag, 3-30–3-31
DDname, 3-23
message mapping, 3-47
See message content data and detail data
translate from ASCII to EBCDIC, 3-16
troubleshoot message mapping, 3-50
control playback timing, 8-14
CONTROL statement, 5-3, 6-1–6-2
syntax, 6-4
correlation ID
return actual and expected, 3-45
COUNT, 8-9, 8-50
CSV
Event Summary, 3-24
format, 3-17
reports, 6-5
custom reports, 6-2, 6-9
field definitions, 6-24
customer support, xxi
Customer Support Diagnostic Report, G-1
diagnostic report, C-1
D
data collection tables, A-1
data replacement during playback, 8-28
data to keep tags, 2-17
DCIADDMQ member, 2-12
DCIADXMQ member, 2-12
DCIJCL
check status of requests, 2-20
create a Global Recording request, 2-10
generate a parameters skeleton, 2-23
manage Global Recording requests, 2-21
retrieve parameters from a request, 2-22
DCIPROC, 2-20–2-22
DD statements
ERRORLOG, 5-24
HTMLLOG, 5-24
Default Script Analysis report, 5-2
detail data
generate, 3-17
map MQ messages into File-AID, 3-47
translate from ASCII to EBCDIC, 3-16, 9-4
troubleshoot message mapping, 3-50
detail datasets
LRECL, 3-24
detail entries, 9-5
<DETAIL> tag, 3-32
unresolved script tag, 3-17
documentation
master index, xiii
dynamic data replacement during playback, 8-33
E
EBCDIC
translate detail data from ACSII, 3-16, 9-4
I-2
translate sample data from ACSII, 3-16, 9-4
environment options, 4-5
Error Summary Report, 5-24
ETRMGPAR member, 5-18
Event Summary, 3-18
generate, 3-17
LRECL, 3-24
event summary entries, 9-5
events
group for script/subset repository creation, 3-14
EXECIO statement, 8-43
EXIT statement, 8-45
EXPECTED_COMPCODE REXX variable, 3-44
EXPECTED_CORRELID REXX variable, 3-45
EXPECTED_LENGTH REXX variable, 3-45
EXPECTED_MSG REXX variable, 3-45
EXPECTED_MSGID REXX variable, 3-45
EXPECTED_REASON REXX variable, 3-45
EXPOSE parameter, 8-49
F
FEEDBACK DD, 2-10
request keys, 2-20
VIEW, 2-22–2-23
File-AID
message mapping, 3-47
filter criteria, 3-4, 3-11, 3-25
header filter detail, 3-7
header filter relational operators, 3-8
header filters, 3-5
import filters, 3-12
message data filter relational operators, 3-10
message data filters, 3-9, 3-11
first number
WebSphere MQ, 9-2–9-3
font and font size, accessibility, xix
foreground
script/subset repository creation processing options, 3-24
FrontLine, xiv
support Web site, xxi
G
general request parameter tags, 2-15
GET_FROM attribute, 5-3
GET_FROM_QUEUE, 8-19
GET_QUEUE_NAME REXX variable, 3-46
global CSI dataset, C-1
Global Recording
add a request, 2-1, 2-7
administrator access, 2-9
batch JCL samples, B-4
batch XML samples, B-4
cancel a request, 2-7
disable a request, 2-7
force a request, 2-7
merge capture repositories, 2-24
repositories, 2-5
request commands, 2-21
restart a request, 2-7
stop a request, 2-7
update a request, 2-7
view a request, 2-7
view session activity, 2-7
Global Recording batch interface, 2-9
check request status, 2-19
create a request, 2-9
delete a request, 2-21
disable a request, 2-21
KEYS, 2-19
manage existing requests, 2-20
parameter syntax, 2-11
request parameters, 2-12
restart an inactive request, 2-21
retrieve parameters from an existing request, 2-22
stop recording, 2-21
switch repository segments, 2-21
troubleshoot failed jobs, 2-23
update a request, 2-21–2-22
VIEW, 2-22
Global Recording requests, 2-1
GMT (Greenwich Mean Time), 3-3
group events for script creation, 3-14
H
relational operators, 3-8
header filters, 3-5
help, requesting, xxi
hexadecimal filters, 3-10
Hiperstation for WebSphere MQ
overview, 1-1
HSCMDS, 8-43
HTML documentation files, xiv
HTML format, 3-17
HTML reports
HTML Event Summary, 3-19
HTML Exception Report, 6-2, 6-6, 6-14, 6-17, 8-4,
8-7, 8-10, 8-12, 8-15, 8-20, 8-26, 8-29, 8-39, 8-52
HTML Exception Report Mismatch Detail, 6-18
HTML Exception Report Mismatch Summary, 6-17
HTML Playback Error Summary, 5-1–5-2, 5-16
HTML Response Time Summary, 6-22
HTML Script Timing Summary, 6-20
I
IBM
BookManager documentation output, xiv
IEBGENER utility, 2-12
Softcopy Reader, xiv
IEBGENER utility, 2-12
import filters/options, 3-12
index, master, xiii
initiation queues, 2-2
interactive playback, 4-1
J
JCL
playback samples, B-4
report samples, B-4
save repository creation filters/options, 3-25
I-3
last number
WebSphere MQ, 9-2–9-3
LOCPOS macro, 3-42
log datasets
LRECL, 3-24
log entries, 9-4
log file
unattended playback job SET statements, 5-20
log file for unattended playback job, 5-16, 6-14
SET statements, 6-16
LRECL
detail datasets, 3-24
Event Summary, 3-24
log datasets, 3-24
script datasets, 3-24
MQ_CLOSE, 2-8, 3-5, 3-21, 3-32
MQ_COMMIT, 2-8, 3-20, 3-33
MQ_CONNECT, 2-8, 3-4, 3-20, 3-33
MQ_DISCONNECT, 2-8, 3-5, 3-21, 3-34
MQ_ENDTHREAD, 2-8
MQ_GET, 3-20, 3-34
return actual and expected messages, 3-45
MQ_INQUIRE, 3-20, 3-34
MQ_OPEN, 2-8, 3-5, 3-20, 3-35
MQ_PUT, 3-20, 3-36
return expected and actual messages, 3-45
MQ_PUT1, 2-8, 3-20, 3-36
MQ_SET, 3-5, 3-20, 3-37
MQAPI, 3-27
include in scripts, 3-16, 9-4
MQGMO, 3-27, 3-29
MQGROUP statement, 5-7, 5-22
multiple groups, 8-6
MQGROUP table, A-2
MQGROUP_COUNT_NBR REXX variable, 3-46, 8-52
MQGROUP_REPEAT_NBR REXX variable, 3-46, 8-52
MQMD, 3-28
MQMESSAGE table, A-6
MQMESSAGESET report, A-5
MQMESSAGESET table, A-4
MQOPENQUEUE table, A-5
MQPMO, 3-29
MQS capture filter tags, 2-18
MQSCRIPT table, A-3
multiple script playback, 8-4
M
N
macros
data replacement offset and length determination,
3-41
MAPD
assign a PF key, 3-47
command prefix invocation character, 3-48
help panels, 3-50
map entire data file, 3-49
map individual message, 3-48
troubleshoot, 3-50
mask data filters, 3-10
mask filters, 3-11
merge all details into script, 3-16
merge repositories, 2-24
message content data, 3-17
message data filters, 3-9
character, 3-11
hexadecimal, 3-11
mask, 3-11
packed decimal, 3-11
relational operators, for, 3-10
text, 3-11
zoned decimal, 3-11
message data mapping, 3-47, 3-50
message ID, return expected and actual, 3-45
message length
return expected and actual, 3-45
Monitor MQ Requests, 2-2, 2-6
administrator access, 2-9
MQ group options, 4-8
MQ log, 5-18
MQ_BACKOUT, 2-8, 3-20, 3-32
notation conventions
screens and commands, xvi
SYSIN, B-4
SYSPLEX samples, 2-24
unattended playback, for, 3-17
K
keyboard shortcuts, accessibility, xx
KEYS command, 2-19
L
O
OBJECT_ID REXX variable, 3-46
Offset and Length Determination Macros, 3-41
omit specified activity from playback, 8-22
options
change playback, 4-5
environment, 4-5
output datasets for script/subset repository creation,
3-23
override queues during playback, 8-19
overview
create scripts, 1-1
play back scripts, 1-2
record activity, 1-1
reporting, 1-2
P
packed decimal filters, 3-10–3-11
parameters
generate Global Recording request skeleton, 2-23
Global Recording request syntax, 2-11
retrieve parameters from Global Recording requests, 2-22
PLAY_TO, 8-17, 8-19
I-4
CONNECTION_ID, 8-24
playback, 5-1
attribute precedence, 5-3
control assets, 5-2, 6-2
control library, 5-2, B-1
data replacement, 8-28
expand data during, 8-38
generate reports, 5-1
input statements, 5-2
JCL samples, B-4
log file, 5-16, 6-14
MQPLAY1 procedure, 5-16, 6-14
overview, 5-1
reports, 6-9
return codes, 5-21
REXX variables, 3-44
table, A-1
Playback Error Summary, 5-23–5-24
ERRORLOG DD, 5-24
HTML, 5-24
HTMLLOG DD, 5-24
playback statements, 5-3
COLLECT, 5-14
CONTROL, 5-3
MQGROUP, 5-7
SCRIPT, 5-11
Playback Summary, 6-9
playback, interactive, 4-1
basic reports, 4-16
change options, 4-5
create new, 4-2
custom reports, 4-17
delete, 4-14
environment options, 4-5
error log, 4-3
generate from script log, 4-4
MQ group options, 4-8
reporting database, 4-3
script options, 4-11
select previously saved, 4-14
submit, 4-12
prefix
output datasets, for, 3-23
PRGLOG DD, 2-23
PROCEDURE statement, 8-49
process
edit batch job for script/subset repository creation,
3-25
in foreground, 3-25
submit batch job for script/subset repository creation, 3-25
protocol parameter tag
MQS, 2-14
PTFS, C-1
PUT_QUEUE_NAME REXX variable, 3-46
PUT_TO attribute, 5-3
PUT_TO_QUEUE, 8-19
Q
QUEUE_MANAGER
attribute, 5-3
queues, initiation, 2-2
R
reason codes, 3-21
return expected and actual, 3-45
recording activity
add a request, 2-7, 2-10
cancel a request, 2-7
create a recording request, 2-1, 2-9
disable a recording request, 2-7
force a recording request, 2-7
monitor a request, 2-1
restart a recording request, 2-7
stop a recording request, 2-7
update a recording request, 2-7
view a recording request, 2-7
view session activity, 2-7
recording option parameter tags, 2-17
recording requests, 2-1
relational operators, 3-10
header filters detail, for, 3-8
message data filters, for, 3-10
REPEAT, 8-9, 8-50
repeat simultaneous script playback, 8-9
<REPLACE> tag, 3-40
Offset and Length Determination Macros, 3-41
REPLAY_ID REXX variable, 3-46
REPLY_TO_QUEUE attribute, 5-3
report control library, 5-2, B-2
REPORT statement, 5-1, 5-16, 6-1
syntax, 6-6
report tables, A-1
reporting, APPC
report generation parameters, 3-3
Reports
Baseline Comparison Report, 8-18
Capture Segment Summary, 3-1
Default Script Analysis report, 5-2
Error Summary Report, 5-24
Exception Report, 6-7
HTML Event Summary, 3-19
HTML Exception Report, 6-2, 6-6, 6-14, 6-17, 8-4,
8-7, 8-10, 8-12, 8-15, 8-20, 8-26, 8-29, 8-39, 8-52
HTML Exception Report Mismatch Detail, 6-18
HTML Exception Report Mismatch Summary, 6-17
HTML Playback Error Summary, 5-1–5-2, 5-16
HTML Response Time Summary, 6-22
HTML Script Timing Summary, 6-20
Playback Error Summary, 5-23–5-24
Playback Summary, 6-9
Response Time Summary, 6-6, 6-8–6-9, 6-21, 8-7,
8-10, 8-12, 8-15
Sample MQGROUP Text Report (Form Layout), 6-5
Sample MQGROUP Text Report (Table Layout), 6-4
Script Analysis, 5-21, 6-2, 6-16, 8-52
Script Timing Summary, 6-6, 6-8–6-9, 6-20, 8-7,
8-10, 8-12, 8-15
Table Report, 6-12
Time Sequence Event Summary, 3-19
reports
basic, 4-16, 6-2, 6-6
Capture Segment Summary, 3-2
control assets, 6-2
CONTROL statement, 6-2
CSV reports, 6-5
custom, 4-17, 6-2, 6-9
Customer Support Diagnostic Report, C-1
I-5
generate playback reports, 4-15
JCL samples, B-4
MQMESSAGESET, A-5
navigate, 6-16
overview, 6-1
PLAYBACK, 6-9
reports, custom
field definitions, 6-24
MQGROUP, 6-9
MQMESSAGE, 6-9
MQMESSAGESET, 6-9
MQOPENQUEUE, 6-9
MQSCRIPT, 6-9
PLAYBACK, 6-9
repositories
delete datasets, 2-7, 2-21
merge capture repositories, 2-24
segmented, 2-5
specify dataset for subset repository, 3-21
specify for script/subset repository creation, 3-13
switch dataset segments, 2-7, 2-22
request key, 2-19
Response Time Summary, 6-6, 6-8, 6-21, 8-7, 8-10,
8-12, 8-15
return codes, TCP/IP playback, 5-21
RETURN statement, 8-45
reuse repository options, 2-6, 9-2
reverse playback, 8-17
REXX variables, 3-44
ACTUAL_COMPCODE, 3-44
ACTUAL_CORRELID, 3-45
ACTUAL_LENGTH, 3-45
ACTUAL_MSG, 3-45
ACTUAL_MSGID, 3-45
ACTUAL_REASON, 3-45
EXPECTED_COMPCODE, 3-44
EXPECTED_CORRELID, 3-45
EXPECTED_LENGTH, 3-45
EXPECTED_MSG, 3-45
EXPECTED_MSGID, 3-45
EXPECTED_REASON, 3-45
GET_QUEUE_NAME, 3-46
MQGROUP_COUNT_NBR, 3-46, 8-52
MQGROUP_REPEAT_NBR, 3-46, 8-52
OBJECT_ID, 3-46
PUT_QUEUE_NAME, 3-46
REPLAY_ID, 3-46
SCRIPT_REPEAT_NBR, 3-47
REXXON, 8-33, 8-38, 8-52
RO
conditional codes, 3-10
relational operators filter criteria, 3-8
symbol, 3-10
S
sample
index, B-1
log files, B-1
SQQFSAMP library, B-4
SYSPLEX, 2-24
sample datasets and libraries
sample external files for test scenarios, 8-1
sample log files, 8-1
sample playback control members, 8-1
sample reporting control members, 8-1
sample repository datasets, 8-1
sample scripts, 8-1
Sample MQGROUP Text Report (Form Layout), 6-5
Sample MQGROUP Text Report (Table Layout), 6-4
samples, APPC
MCSREPT, 3-3
save filter/option JCL, 3-25
scheduled capture parameter tags, 2-15
script
analysis, 8-52
browse, 3-26
dataset messages, 3-50
edit, 3-38
entries, 9-5
library, B-3
options, 4-11
processing options, 3-16
SCRIPT statement, 5-11
separate details, 3-16
syntax rules, 3-39
Script Analysis Report, 5-21, 6-2, 6-16, 8-52
script create
execution options
WebSphere MQ, 9-6
include MQAPI parameters, 9-4
Script Create parameters, D-1
script datasets
LRECL, 3-24
script log
generate playback, 4-4
script tags
<CONTENT>, 3-30–3-31
<DETAIL>, 3-32
<MQ_BACKOUT...>, 3-32
<MQ_CLOSE...>, 3-32
<MQ_COMMIT...>, 3-33
<MQ_CONNECT...>, 3-33
<MQ_DISCONNECT...>, 3-34
<MQ_GET...>, 3-34
<MQ_INQUIRE...>, 3-34
<MQ_OPEN...>, 3-35
<MQ_PUT...>, 3-36
<MQ_PUT1...>, 3-36
<MQ_SET...>, 3-37
<REPLACE>, 3-40
<TIME>, 3-37
<VERSION>, 3-37
Script Timing Summary, 6-6, 6-8–6-9, 6-20, 8-7, 8-10,
8-12, 8-15
SCRIPT_REPEAT_NBR REXX variable, 3-47
scripts, create, 3-1, 3-17
access Create MQ Scripts option, 3-4
allocate datasets for log, script, detail, event summary, 3-24
filter criteria, 3-4
generate Event Summary, 3-18
group events, 3-14
header filters, 3-5
import filters/options, 3-12
include MQAPI parameters, 3-16
log entries, 3-17
minimize script size, 3-14
output datasets, specify, 3-23
output options, 3-15
overview, 3-1
I-6
source repositories, wildcards for selecting, 3-14
store detail data, 3-15
scripts, WebSphere MQ
suppress time stamps, 9-4
security, 2-7
security monitoring, 7-1
audit trail, 7-2
serial playback, 8-4
SET statements
in log file, 5-20, 6-16
SET ACTION, 5-20
SET CNTLDS, 5-20
SET COLLMEM, 5-20
SET REPTCNTL, 5-21
SET REPTDS, 5-20
SET REPTMEM, 5-21
SET SCRIPT, 5-20
SET SORTED, 5-20
SET UNSORTED, 5-20
SET_REXX_STREAM_VARIABLES, 8-46, 8-52
simultaneous script playback, 8-6
skeleton, Global Recording request parameters, 2-23
SKIP
CONNECTION_ID, 8-22
SMP/E
global CSI dataset, C-1
target zone, C-1
SQQFSAMP, 2-12, 2-20–2-21
samples library, B-4
SQQFSCRP, 8-1
statements
COLLECT, 5-14
CONTROL, 5-3
MQGROUP, 5-7
SCRIPT, 5-11
STEPLIB, 5-18
structure data type, 3-27
submit a job, 5-21
subset repositories, create, 3-17
access Create MQ Scripts option, 3-4
allocate repository dataset, 3-22
filter criteria, 3-4
generate Event Summary, 3-18
group events, 3-14
header filters, 3-5
import filter/option JCL, 3-12
MQAPI parameters, 3-16, 9-4
output datasets, specify, 3-23
output options, 3-15
overview, 3-1
source repositories, wildcards for selecting, 3-14
specify dataset for subset repository, 3-21
store detail data, 3-15
subset repository, 9-5
switch repository segments, 2-21
synchronize group playback, 8-11
syntax
conventions, xvii
diagrams, xvii
syntax rules, 3-39
SYSIN
unattended playback, for, 3-17
SYSIN DD, 2-10, 2-22
SYSPLEX, 2-24
job input parameters, 2-25
SYSTEM queues, 2-2
system queues, 1-1
SYSTSIN DD, 2-10, 2-20
T
Table Report, 6-12
tables
MQGROUP, A-2
MQMESSAGE, A-6
MQMESSAGESET, A-4
MQOPENQUEUE, A-5
MQSCRIPT, A-3
PLAYBACK, A-1
TCPIP playback return codes, 5-22
TEMPSTP1, 5-18
TEMPSTP2, 5-18
test scenarios, 8-1
expand data during playback, 8-38
omit specified activity from playback, 8-22
override queues, 8-19
play back multiple groups with PLAY_TO, 8-24
play back multiple scripts serially, 8-4
play multiple scripts simultaneously, 8-6
repeat simultaneous playback, 8-9
replace data dynamically, 8-33
replace data with static values, 8-28
test scripts
build, 3-1
text filters, 3-10
THOPT, 8-14
Time Sequence Event Summary, 3-19
time stamps, suppress, 3-16
<TIME> tag, 3-37
timing options, 4-6
transmission queues, 1-1, 2-2
trigger queues, 1-1
triggers, 2-2
troubleshoot
Global Recording batch jobs, 2-23
U
unattended playback, 5-1
attribute precedence, 5-3
batch, 5-1
COLLECT statement, 5-14
control assets, 5-2, 6-2
CONTROL statement, 5-3
DDname for detail data, 3-23
expand data during, 8-38
input statements, 5-2
JCL, 3-17
log file, 5-16, 6-14
MQGROUP statement, 5-7
MQPLAY1 procedure, 5-16, 6-14
I-7
omit specified activity, 8-22
override queues, 8-19
overview, 5-1
play back scripts serially, 8-4
play back scripts simultaneously, 8-6
PLAY_TO, 8-24
Playback Error Summary, 5-24
repeat simultaneous playback, 8-9
replace data dynamically, 8-33
replace data with static values, 8-28
Script Analysis Report, 5-21
SCRIPT statement, 5-11
statements, 5-3
SYSIN, 3-17
unsynchronized playback, 3-49
update a Global Recording request, 2-22
UPROCS, 2-20, 2-22
USESTIME, 8-11, 8-14
V
<VERSION> tag, 3-37
view
session information, 2-8
VIEW function, 2-22–2-23
W
Web report JCL, B-2
WebSphere MQ
basic playback reports, 4-16
custom playback reports, 4-17
wildcards
segment repositories, 2-5
select source repositories, 3-14
X
XML parameters, 2-11
Z
zoned decimal filters, 3-10–3-11

Hiperstation for WebSphere MQ User Guide

Transcription

Similar documents

E - DEVLET

Hiperstation for WebSphere MQ

Auto Mouse Click by MurGee.com - MurGee Auto Mouse Click Video

Drum Set Notation in Logic

the TMPGEnc KARMA.. Manual

product lineup 2015-2016

notes (eng) - film press plus

Here - RCeL

Service Virtualization - Northwestern University Information