TCP/IP Scripts and Subset Repositories (MF User)

  Creating scripts and subset repositories

Capture repositories contain recorded activity in a compressed format. Scripts contain formatted, human-readable data generated from a capture repository. Play back scripts to test TCP/IP applications or browse them to review TCP/IP data flows.

After you have recorded activity (see TCP/IP Global Recording), use the Create TCP/IP Scripts option to:

• Build testing scripts from the capture repository.
• Generate subset repositories containing specified activity.
• Generate a Connection Log that lists the all of the scripts created. Use the Connection Log as the SYSIN for an unattended playback job.

Performance Test for Mainframe Servers 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, you can save time and spare system resources by identifying the repository segments of interest. Script only the segments you need, as opposed to the entire capture repository. As discussed in Generating a 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.

  Create TCP/IP scripts and establish filtering criteria

The capture repository may contain more activity than is required to perform a given test. You can supply filtering criteria to create only the scripts or subset repositories containing the activity you need. Activity that matches any of the filters is written into the scripts or subset repositories.

You can filter by one or more of the following criteria: Time Frame, Client IP Address, Client Port, Server IP Address. and Server Port.

Additional protocol-specific filtering options are also available:

• Db2 Connect Filters
• IMS Connect Filters
• CTG Filters
• ECI Filters

Performance Test for Mainframe Servers requires at least one filter to create scripts or subset repositories. Each line in the lower portion of the screen represents a separate filter for creating scripts or subset repositories.

  Filtering line commands

The TCP/IP Create Scripts - Filtering screen as well as the Db2, IMS, CTG, and ECI filter screens all use the following line commands to view additional filter details and to add or remove filters:

• (S)elect displays a protocol-specific filtering screen when additional filtering is available.
• (R)epeat repeats the selected filter.
• (D)elete deletes the selected filter as long as it is not currently in use by an active Global Recording request.
• (I)nsert inserts a blank filter after the selected filter.
• (A)ddress displays the TCP/IP Create Scripts - Filtering IP Addresses screen. This allows you to specify whether you want to use IPv6 or IPv4 as your IP address format.

From the following Performance Test for Mainframe Servers Main Menu, type 7 on the Option line to select Create TCP/IP Scripts and press Enter.

Performance Test  for Mainframe Servers Main Menu

The following TCP/IP Create Scripts - Filtering screen is displayed.

 TCP/IP Create Scripts - Filtering screen

This screen is the starting point for creating Performance Test TCP/IP scripts. The scripts that you create with these panels can then be used for performing playbacks or simply for browsing TCP/IP data flows (for example, to help with application debugging).

Before creating scripts, you must have a repository that contains the raw TCP/IP data captured with the Performance Test Global Recording component. A repository is an MVS sequential data set that was named on a Global Recording request to contain captured TCP/IP data.

Use this Filtering panel to limit the data used to create scripts. You can also name the protocols associated with particular TCP port numbers. This is important if your system uses nonstandard port numbers for the HTTP or HTTPS servers.

Performance Test can play back HTTP, HTTPS, Db2, IMS, ECI and CTG scripts, but you can capture (for browsing, not for playback) any TCP data streams, regardless of application protocol. Currently, UDP data streams cannot be captured or played back.

1. Supply start and end times and dates to generate scripts that contain only data from a specific period. Note that the start and end times form a single range, not multiple ranges across several dates. For example, START TIME = 08:00:00, END TIME = 10:00:00, START DATE = 5/20/2010, END DATE = 5/21/2010 is a total of 26 hours, not 2 hours.
   Valid date ranges are from January 1, 1900 through December 31, 2041. Performance Test for Mainframe Servers populates these fields with the last specified values. Leave all values zeros if you do not want to filter activity based on time and date.

   Important

   The Ftr column contains an arbitrary value assigned as a unique ID for each filter. This field cannot be modified.

2. Supply IP addresses and port numbers to limit scripts to the specified values. The wildcard character, an asterisk (*), can be supplied to indicate that any value is a match. In addition, any or all of the four segments of an IP address can be wild-carded. In a field or an IP address segment, a wildcard must appear by itself, not mixed with other values.
3. Valid line commands are ‘D’elete, ‘I’nsert, ‘R’epeat, ‘S’elect and ‘A’ddress. Selecting a row moves to a protocol-specific CONTENT filtering panel (not available for HTTP, HTTPS, or TCP). Addressing a row formats the Client and Server IP addresses into structured fields, depending on format (IPv6, IPv4 or mixed) for easy modification. Use one of the line commands to perform an action on the designated filter. See Filtering Line Commands for more information.
4. Enter a Protocol Name to apply to the activity that matches the given filter. Valid values are HTTP, HTTPS, TCP, ECI, CTG, DB2C, and IMSC. Performance Test for Mainframe Servers uses the protocol names assigned to the activity in the scripts to initiate the appropriate message handlers during playback.
5. Enter the Client IP Address associated with the activity you wish to include in the scripts or subset repositories. Enter an asterisk (*) wildcard for any IP address segment to include all possible values for the given segment. A wildcard character can be used on any or all segments. You can enter an IPv6 or IPv4 address.
6. Specify the Client Port. Enter an asterisk (*) wildcard to indicate all ports. If you enter an asterisk, all activity on all ports for the specified IP address is labeled with the protocol specified in the Protocol Name field.
7. Specify the Server IP Address. Enter an asterisk (*) wildcard for any IP address segment to include all possible values for the given segment. A wildcard character can be used on any or all segments. You can enter an IPv6 or IPv4 address.
8. Specify the Server Port. Enter an asterisk (*) wildcard to indicate all ports. If you enter an asterisk, all activity on all ports for the specified IP address is labeled with the protocol specified in the Protocol Name field.
9. Type OK on the command line and press Enter to validate the information you have entered and move to the next Create Scripts panel. Use Exit to return to the previous panel.

The screen that is displayed next depends on what you select on this panel. If you typed OK, see Define Activity Grouping to continue. If you selected one of the protocols (other than HTTP, HTTPS, or TCP, which do not accept filters), you will navigate to the filter screen for that protocol. A description of these filters follows. If you used the ‘A’ddress line command, you will proceed to the TCP/IP Create Scripts - Filtering IP Addresses screen.

  Db2 Connect Filters

1. On the TCP/IP Create Scripts - Filtering screen, select a Db2 Connect filter from the list of filters. The TCP/IP Create Scripts - DB2 Connect Filters screen is displayed.
   

    TCP/IP Create Scripts - DB2 Connect Filters screen

     ----------------- TCP/IP Create Scripts - DB2 Connect Filters  Row 1 to 8 of 8
      Command ===>                                                  Scroll ===> CSR
   
      Make changes to the DB2 Connect filtering criteria below or select a filter to
      edit the expanded fields. Use END when complete.
   
         Client IP Address: *.*.*.*             Client Port: *
         Server IP Address: *.*.*.*             Server Port: 80
   
      Line commands are: (S)elect, (R)epeat, (D)elete, or (I)nsert
   
                                                                        SQL    SQL
      S Ftr Act  SQL Statement              RDB Name           UserId   Code   State
      ***** **** ************************** ****************** ******** ****** *****
        001
        002
        003
        004
        005
        006
        007
        008
      ******************************* Bottom of data ********************************

   Important

   The Ftr column contains an arbitrary value assigned as a unique ID for each filter. This field cannot be modified.

   You can use one of the line commands, (S)elect, (R)epeat, (D)elete, or (I)nsert, to perform an action on the designated filter. See Filtering Line Commands for more information.

2. Specify the filter action (Act) to be performed. Valid values are INCL (include) or EXCL (exclude). Data from the repository must match at least one Include filter and none of the Exclude filters to be included in the output.
3. Enter an SQL statement to be monitored (alphanumeric). Enter an asterisk (*) wildcard to specify all SQL statements.
4. Enter an RDB Name (alphanumeric Relational Database Name). Enter an asterisk (*) wildcard to specify all databases.
5. Enter the UserId to filter connections on. Enter an asterisk (*) wildcard to indicate all user IDs.
6. Enter a five-digit SQL code. Valid values include numbers from -30106 to 30100.
7. Enter a five-digit, alphanumeric SQL state, xxyyy, where xx represents the class code and yyy the subclass code.

8. Issue the S (select) line command to view detail data for the desired filter. The TCP/IP Create Scripts - DB2 Connect Filter Detail screen is displayed.
   The SQL Statement, RDB Name, UserId, SQLcode, and SQLstate fields are prefilled from the previous screen but can be changed.

    TCP/IP Create Scripts - DB2 Connect Filter Detail screen

      -------------- TCP/IP Create Scripts - DB2 Connect Filter Detail -------------
      Command ===>
   
      Review and/or Edit this filter. Use END when complete.
   
      Filter number   001 of 008
      Filter action   INCLUDE     (Include or Exclude)
   
      Field Name     RO Filtering Criteria
      ************** ** *************************************************************
      SQL Statement
      SQL Answer Set
      RDB Name
      UserId
      SQLcode
      SQLstate
9. Enter an SQL Answer Set and its relational operator. This alphanumeric field specifies data returned in response to an SQL statement. Enter an asterisk (*) wildcard to indicate all responses.

 The relational operators (RO) for each field with filtering criteria are prefilled from the previous screen but can be changed. This column specifies how the filtering criteria are compared to the actual content data. Valid values can be entered as either alphabetic- or character-based codes as shown below.

   Alphabetic    Character

Description                Code          Code

  IMS Connect Filters

1. On the TCP/IP Create Scripts - Filtering screen, select an IMS Connect filter. The TCP/IP Create Scripts - IMS Connect Filters screen is displayed.
   

   TCP/IP Create Scripts - IMS Connect Filters screen

    ----------------- TCP/IP Create Scripts - IMS Connect Filters - Row 1 to 8 of 8
      Command ===>                                                  Scroll ===> CSR
   
      Make changes to the IMS Connect filtering criteria below or select a filter to
      edit the expanded fields. Use END when complete.
   
         Client IP Address: *.*.*.*             Client Port: *
         Server IP Address: *.*.*.*             Server Port: 80
   
      Line commands are: (S)elect, (R)epeat, (D)elete, or (I)nsert
   
      S Ftr Act  Transcode Datastore User Id  Client Id Client USERDATA
      ***** **** ********* ********* ******** ********* *****************************
        001
        002
        003
        004
        005
        006
        007
        008
      ******************************* Bottom of data ********************************

   Important

   The Ftr column contains an arbitrary value assigned as a unique ID for each filter. This field cannot be modified.

   You can use one of the line commands, (S)elect, (R)epeat, (D)elete, or (I)nsert, to perform an action on the designated filter. See Filtering Line Commands for more information.

2. Specify the filter action (Act) to be performed. Valid values are INCL (include) or EXCL (exclude). Data from the repository must match at least one Include filter and none of the Exclude filters to be included in the output.
3. Specify the alphanumeric Transcode to filter connections by IMS transaction code (the target application program). Enter an asterisk (*) wildcard to indicate all transaction codes.
4. Enter an alphanumeric Datastore to filter connections by IMS datastore (as defined in the IMS Connect configuration file on the server). Enter an asterisk (*) wildcard to indicate all datastores.
5. Enter an alphanumeric User ID to filter connections based on the RACF userID associated with them. Enter an asterisk (*) wildcard to indicate all user IDs.
6. Enter an alphanumeric Client ID to filter connections based on the unique client identifier associated with them. Enter an asterisk (*) wildcard to indicate all client IDs.
7. Enter alphanumeric Client USERDATA to filter client data not found in IMS Connect headers. Enter an asterisk (*) wildcard to indicate all client data.
8. Enter the S (select) line command. The TCP/IP Create Scripts - IMS Connect Filter Detail screen is displayed.

9. The Transcode, Datastore, User Id, Client Id, and Client USERDATA fields and their relational operators are prefilled from the previous screen but can be changed.
   

   TCP/IP Create Scripts - IMS Connect Filter Detail screen

      -------------- TCP/IP Create Scripts - IMS Connect Filter Detail -------------
      Command ===>
   
      Review and/or Edit this filter. Use END when complete.
   
      Filter number   001 of 008
      Filter action   INCLUDE     (Include or Exclude)
   
      Field Name       RO Filtering Criteria
      **************** ** ***********************************************************
      Transcode
      Datastore
      User Id
      Client Id
      Client USERDATA
      Server USERDATA
10. Enter alphanumeric Server USERDATA to filter server data not found in IMS Connect headers. Enter an asterisk (*) wildcard to indicate all server data.

The relational operator (RO) column specifies how the filtering criteria are compared to the actual content data. Valid values can be entered as either alphabetic- or character-based codes as shown on IMS Connect Filters.

CTG Filters

1. On the TCP/IP Create Scripts - Filtering screen, select a CTG filter. The following TCP/IP Create Scripts - CTG Filters screen is displayed.
   TCP/IP Create Scripts - CTG Filters
   

      --------------------- TCP/IP Create Scripts - CTG Filters ---- Row 1 to 8 of 8
      Command ===>                                                  Scroll ===> CSR
   
      Make changes to the CTG filtering criteria below or select a filter to edit
      the expanded fields. Use END when complete.
   
         Client IP Address: *.*.*.*             Client Port: *
         Server IP Address: *.*.*.*             Server Port: 80
   
      Line commands are: (S)elect, (R)epeat, (D)elete, or (I)nsert
   
      S Ftr Act  Program  Applid   Client COMMAREA
      ***** **** ******** ******** **************************************************
        001
        002
        003
        004
        005
        006
        007
        008
      ******************************* Bottom of data ********************************

   Important

   The Ftr column contains an arbitrary value assigned as a unique ID for each filter. This field cannot be modified.

2. Use one of the line commands, (S)elect, (R)epeat, (D)elete, or (I)nsert, to perform an action on the designated filter. See Filtering Line Commands for more information.
3. Specify the Filter Action (Act) to be performed. Valid values are INCL (include) or EXCL (exclude). Data from the repository must match at least one Include filter and none of the Exclude filters to be included in the output.
4. Enter an alphanumeric Program Name to filter connections by program name. Enter an asterisk (*) wildcard to indicate all program names.
5. Enter an alphanumeric Applid to filter connections by VTAM application ID. Enter an asterisk (*) wildcard to indicate all connections.
6. Enter an alphanumeric Client COMMAREA to filter the user data portion passed by the client to the CICS application.

7. Enter the S (select) line command. The following TCP/IP Create Scripts - CTG Connect Filter Detail screen is displayed.
   

   TCP/IP Create Scripts - CTG Filter Detail

      ------------------ TCP/IP Create Scripts - CTG Filter Detail -----------------
      Command ===>
   
      Review and/or Edit this filter. Use END when complete.
   
      Filter number   001 of 008
      Filter action   INCLUDE     (Include or Exclude)
   
      Field Name       RO Filtering Criteria
      **************** ** ***********************************************************
      Program
      Applid
      Client COMMAREA
8. The Program Name, Applid, and Client COMMAREA fields are prefilled from the previous screen.

The relational operator (RO) column specifies how the filtering criteria are compared to the actual content data. Valid values can be entered as either alphabetic- or character-based codes as shown on IMS Connect Filters.

  ECI Filters

1. On the TCP/IP Create Scripts - Filtering screen, select an ECI filter. The TCP/IP Create Scripts - ECI Filters screen is displayed.
    TCP/IP Create Scripts - ECI Filters
   

      --------------------- TCP/IP Create Scripts - ECI Filters ---- Row 1 to 8 of 8
      Command ===>                                                  Scroll ===> CSR
   
      Make changes to the ECI filtering criteria below or select a filter to edit
      the expanded fields. Use END when complete.
   
         Client IP Address: *.*.*.*             Client Port: *
         Server IP Address: *.*.*.*             Server Port: 80
   
      Line commands are: (S)elect, (R)epeat, (D)elete, or (I)nsert
   
      S Ftr Act  Program  Userid   Client COMMAREA
      ***** **** ******** ******** **************************************************
        001
        002
        003
        004
        005
        006
        007
        008
      ******************************* Bottom of data ********************************

   Important

   The Ftr column contains an arbitrary value assigned as a unique ID for each filter. This field cannot be modified.

2. Use one of the line commands, (S)elect, (R)epeat, (D)elete, or (I)nsert, to perform an action on the designated filter. See Filtering Line Commands for more information.
3. Enter the filter action (Act) to be performed. Valid values are INCL (include) or EXCL (exclude). Data from the repository must match at least one Include filter and none of the Exclude filters to be included in the output.
4. Enter an alphanumeric Program Name to filter connections by program ID being invoked by CICS. Enter an asterisk (*) wildcard to indicate all program names.
5. Enter an alphanumeric Userid to filter connections by the user ID associated with them. Enter an asterisk (*) wildcard to indicate all user IDs.
6. Enter an alphanumeric Client COMMAREA to filter the user data portion of COMMAREA being passed into CICS.
7. Enter the S (select) line command. The following TCP/IP Create Scripts - ECI Connect Filter Detail screen is displayed.

The Program Name, Userid, and Client COMMAREA fields are prefilled from the previous screen but can be changed.

 TCP/IP Create Scripts - ECI Filter Detail

The relational operator (RO) column specifies how the filtering criteria are compared to the actual content data. Valid values can be entered as either alphabetic- or character-based codes as shown on IMS Connect Filters.

  Filtering IP addresses

The TCP/IP Create Scripts - Filtering screen is a starting point for creating IP address and port filters for TCP/IP Script Create. With the introduction of IPv6 support, there are now three formats in which IP addresses can be expressed in Performance Test. The TCP/IP Create Scripts - Filtering IP Addresses screen provides an illustrative structure for entering these formats for users who are new to IPv6.

You can access the TCP/IP Create Scripts - Filtering IP Addresses screen by using the “A” line command for any of the filters on the TCP/IP Create Scripts - Filtering screen.

IP address values in the selected filter list entry are expanded into the Client or Server IP address fields on this screen, as appropriate. The format chosen is determined by the format of the entered IP addresses. IP addresses on this screen are validated for correctness when you press Enter. Addresses where all segments are zeroed out are ignored.

When you exit the TCP/IP Create Scripts - Filtering IP Addresses screen, the IP address segments are recombined into a single text string and used to update the Client and Server fields of the originally selected filter list entry. Which exit format is selected is determined by the validity of the IP addresses. If all formats contain valid IP addresses the precedence order is IPv6, followed by IPv4, and then mixed IPv6 and IPv4. Client IP addresses are evaluated first, then the corresponding Server IP address selected format is validated.

 IPv6 IP address filters

The first format on the screen is IPv6. An IPv6 IP address is 16 bytes long and, in textual form, consists of eight two-byte segments. Each two-byte segment is defined as a four-digit hexadecimal XXXX (0..9,A..F) value and segments are separated by colons. Therefore, as shown in TCP/IP Create Scripts - Filtering IP Addresses screen, an IPv6 IP address contains seven colons.

Given that many of these segments could have a zero value, IPv6 defines a shorthand representation to prevent the repetitive entering of :0. Use double colon (::), to represent one or more consecutive zero segments. Thus, an Ipv6 address of FE80:0:0:0:0:0:0:A0A could be written as FE80::A0A. The double colon notation can be entered in the IP address free-form area on the previous panel. Such a double colon IP address is expanded into its full form on the TCP/IP Create Scripts - Filtering IP Addresses screen. ::XXXX and XXXX:: are supported for 0:0:0:0:0:0:0:XXXX and XXXX:0:0:0:0:0:0:0 respectively.

Other valid IPv6 IP address formats include:

The IP address filter (::10.10.27.200) captures IPv6 compatible addresses. Since this format is valid but depricated, it is allowed with a pop-up warning. It only captures IPv6 address 0000:0000:0000:0000:0000:0000:0A0A:1BCA. It will not capture a mapped IPv4 address.

The IP address filter (FE80::C0C:10.10.200.0) is valid and will only capture FE80:0000:0000:0000:0000:C0C:A0A:CA00.

The IP address filter (FE80::C0C:675) specifies that nodes 1, 7, and 8 must be as specified. Nodes 206 are zeros.

The IP address filter (::1) specifies all zeros ending with an eighth node of 1.

 IPv4 IP address filters

The second format on the screen is IPv4. IPv4 IP addresses are four bytes long and are usually expressed as four decimal numbers in the form “ddd.ddd.ddd.ddd” where “ddd” is a decimal number in the range 0-255. An example might look like: 10.10.27.200, which will only capture native IPv4 address 10.10.27.200 or 0000:0000:0000:0000:0000:FFFF:0A0A:1BCA.

Other valid IPv4 IP address formats include:

The IP address filter (10.*.27.*) is similar to the previous example except that the second and fourth nodes can be anything.This example will only capture native IPv5 address 10.nn.27.nn or 0000:0000:0000:0000:0000:FFFF:0Ann:1Bnn where nn can be anything.

The IP address filter (::FFFF:10.*.27.*) or (0:0:0:0:0:FFFF:10.*.27.*) captures native IPv4 addresses or mapped IPv4 addresses only.

 Mixed IPv6 and IPv4 address filters

The third format on the screen is a mixed IPv6 and IPv4 notation, designed for mapping existing IPv4 addresses into the IPv6 environment. As an IPv6 address, mixed IP addresses are 16 bytes long. They are defined as six two-byte IPv6 segments plus a four-byte IPv4 address (i.e., XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:ddd.ddd.ddd.ddd). Note that an extra colon is added to the end of the IPv6 portion to connect the IPv6 and IPv4 components together.

It is likely that many users will want to format groups of TCP/IP sessions. This can be achieved by using the wildcard asterisk (*) character. Any IP address segment, IPv6 or IPv4, can be replaced with a wildcard.

To wildcard the entire address, there are three possibilities: a single asterisk (*) entered in the filter list entry on the previous panel, a full IPv4 wildcarded address (*.*.*.*), and a full IPv6 wildcarded address (*:*:*:*:*:*:*:*), which will also capture IPv4 addresses. A single asterisk (*) is expanded to a full IPv6 wildcarded address on the TCP/IP Create Scripts - Filtering IP Addresses screen. Except when using a single asterisk (*) or valid IPv6 shorthand notations (FE80::FA49), all filter nodes must be specified.

No line commands are available on the TCP/IP Create Scripts - Filtering IP Addresses screen. Press Enter to validate input. Use EXIT to return to the previous screen.

 Warning message

A warning, specified as a “W” will appear if you omit the FFFF and enter an IP address in the format:

::10.10.0.32

Type an S over the W to select that IP address and you will navigate to the TCP/IP Collect Data Filters screen where you will get a message stating “Deprecated IPV4 mapped IPV6 will capture only IPV6 address. On this screen, you can modify your IP address if desired.

 Invalid IP address filter examples

Following are examples of invalid IP address filters:

The IP address filter (10.**.58) is not valid for either IPv6 or IPv4.

The IP address filter (::C0C::A0A) is invalid because you cannot use more than one set of colons (::) in a single IP address filter.

The IP address filter (*:A0A:*:B00:*) is invalid because not enough nodes are specified.

 TCP/IP Create Scripts - Filtering IP Addresses screen

  Define activity grouping

To define activity grouping, you will need to generate one of the following:

• One script containing filtered activity ordered as it was captured.
• Separate scripts containing filtered activity grouped by connection.
• Separate scripts containing filtered activity grouped by client IP address, client port, server IP address, server port, and/or protocol. 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:

• To replicate an issue that a specific user encountered, and each user has a unique IP address, group by client IP address to create a separate script containing each user’s activity.
• To test a specific application within the system, group by server IP address and port to create a separate script containing each application’s activity.
• To test Secure Socket connections, group by protocol to isolate HTTPS activity.
• To test the application’s responses to user action, group by connection to create a separate script for each transfer of information from client to server.
• To test client activity, group by connection to create a separate script containing each client’s activity.

Although you can use activity 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 log to use as the SYSIN for a playback job. The log contains one SOCKETS and one SCRIPT statement for each script created. All SOCKETS play back simultaneously. Be mindful of transaction interdependence. For example, while recording, you request a record and 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 or may not be an issue.

1. On the TCP/IP Create Scripts - Filtering screen, specify the desired filter criteria and enter OK on the command line. The TCP/IP Create Scripts - Grouping screen is displayed.

   Important

   Selections on this screen do not impact subset repositories.

    TCP/IP Create Scripts - Grouping screen

      &---------------------- TCP/IP Create Scripts - Grouping ----------------------
      Command ===>
   
      Choose how to group data among scripts, then press Enter to continue.
   
      Create a new script for each:
        1  1. One script for everything
           2. Connection
           3. New combination of (one or more)
                 Client IP address
                 Client port
                 Server IP address
                 Server port
                 Protocol
   
      Select item 1 if you want to play back all TCP/IP activity in the exact
      sequence that it was originally created.
   
      Synthesized Connection Special Processing:
   
       Reverse Synthesized Connections:
   
       Server Port DSN:
2. On the line next to option 1, enter the number of the desired grouping selection. Choices include:
   • (One script for everything) — Puts all activity in one script in the exact order that it was recorded (optimum for playback).
   • (Connection) — Creates a separate script for each connection captured. Connection is the desired setting if testing client activity (for example, PLAY(SERVER)).
   • (New combination of one or more) — Creates separate scripts for each unique combination of selected grouping criteria. Type a slash (/) next to the desired grouping criteria. Combinations include:
     • Client IP address
     • Client port
     • Server IP address
     • Server port
     • Protocol.
3. (Reverse Synthesized Connections:) This optional selection applies to Synthesized Connections only. To create a TCP/IP Connection in a Script when one was not recorded, Script Create uses a heuristic algorithm to determine the Client and Server Assignments from the existing data. If the determination made by Script Create is incorrect, select this field to reverse the determination made using the algorithm.
4. (Server Port DSN:) Specify a fully qualified data set name, without quotes, in the Server Port DSN field if you wish to supply a list of Ports that will always be considered the Server side by Script Create in a Client-Server pair. This option applies to Synthesized Connections only and is optional. This option takes precedence over Reverse Synthesized Connections option, but they are not mutually exclusive.
5. Press Enter to continue.

  Specify the source repository

After you select a grouping option from the previous section, the following TCP/IP Create Scripts - Input screen is displayed.

 TCP/IP Create Scripts - Input screen

1. Specify the capture repository or repository segments to use for generating the scripts or subset repositories.
   You can save time and system resources by scripting the repository segments of interest as opposed to the entire repository. To identify the information contained in each segment of the repository, generate a Capture Segment Summary. It indicates when recording began and ended for each repository segment.

2. Enter the repository Dataset name to use for generating your scripts/subset repositories. To select a range of source repositories, use either of the following wildcard characters in the data set name designation and define a range with the First to last number fields:

   • Asterisk (*): Insert the asterisk in place of the data set name qualifier characters that should be substituted with incremental values during repository selection. This wildcard pads to eight characters. For example, enter USER.REP*.DATABASE with first=1 and last=3 to create scripts/subset repositories from source repositories:

   USER.REP00001.DATABASE
   USER.REP00002.DATABASE
   USER.REP00003.DATABASE

   • Question mark (?): Insert a question mark for each data set name 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

3. Specify the Amount of data to use to minimize the size of your scripts by truncating the client and/or server transmission data detail, that is, data tagged <CONTENT> in TCP/IP scripts. This option supports tasks such as debugging and stress testing.

   If you are manually inspecting scripts for debugging purposes and only need to see the first 200 bytes, truncate to 200. If you are stress testing and are only interested in the transaction speed, rather than data comparison, truncate client data to reduce the size of your scripts and demand on DASD storage. Enter ALL to include all transaction data or indicate the number of bytes, between 0-9999999, to include.If you intend to play back and compare actual with expected values, select ALL. If you truncate client data, your scripts may not play back properly. If you truncate server data, your scripts may play back, but comparing actual to expected values may not be possible.

4. Press Enter to continue.

  Define detail data storage and output requirements

After selecting a source repository or set of repositories from the previous section, the TCP/IP Create Scripts - Create Options screen is displayed. Use this screen to specify how to store transmission data, what to create, and whether the new items should replace existing items with the same names.

 TCP/IP Create Scripts - Create Options screen

1. On the line next to option 1, specify where details should be stored. Detail data is the information actually sent by TCP socket applications. This data is either written to one or more detail files, or is written within the script on <CONTENT> tags. In both cases, the data is prefixed with a twelve-byte header carrying information about the detail data.
   Detail data can be mapped into File-AID/MVS to view or edit in a formatted context. You can map all detail data at once if it is stored in an external file. If it is merged into the script, each message must be mapped independently. See Editing TCP/IP Detail Data with File-AID/MVS, for more information.
   Choices include:
   • Merged into the script — Merges the detail data into the script where it can be found on <CONTENT> tags.
   • Separate from the script, client and server together — Stores the script and detail data in separate PDSE members. The script contains links to the detail data and the activity reflects the data flow at the time of capture.
   • Separate from the script, client and server split — Stores the script, client activity, and server activity in separate PDSE members. The script contains links to the detail data, and the activity is separated by client and server. Therefore, all client activity is written into one member and the server activity into another.

2. Type a slash next to the items to be generated. To overwrite existing files for any of the selected items, type a slash next to the corresponding replace option.

   • Log — Generates a Connection Log that lists every script Performance Test for Mainframe Servers created. Each entry consists of a SOCKETS and SCRIPT statement. The log not only reports the results of script creation, but may also be used as the SYSIN for an Unattended Playback job. Depending on your testing requirements, you may need to modify it before playing back your scripts. For more playback information, see TCP/IP Unattended Playback.
   • Script — Generates scripts that consist of header information and data for one or more TCP connections. For more information on the contents of script tags, see Browsing and Editing Scripts.
   • Details — Generates detail data, which is the information actually sent by TCP socket applications. This data is either written to one or more detail files, or is written within the script on <CONTENT> tags, depending on your previous selections. In both cases, the data is prefixed with a twelve-byte header carrying information about the detail data.

   To generate scripts you intend to play back, be sure to select this option. Otherwise, the scripts will contain unresolved <DETAIL> tags, <DETAIL COMBINED ???>. Either regenerate the scripts, or generate the details and replace the question marks with the DD names associated with the Detail Datasets.

   • Subset Repository — Generate one or more subset repositories depending on your selections on the previous and remaining screens.
   • Replace existing log members — Replaces any log member that has the same name as the log being generated.
   • Replace existing script members — Replaces any script members that have the same name as the scripts being generated.
   • Replace existing detail members — Replaces any detail members that have the same name as the detail members being generated.
3. Press Enter to go to the next screen.

  Specify output data sets

If you selected Log, Script, or Details on the TCP/IP Create Scripts - Create Options screen, the TCP/IP Create Scripts - Output screen is displayed. Otherwise, the TCP/IP Create Scripts - Subset Output screen is displayed. Go to Specify Subset Repository Output Datasets to continue.

 TCP/IP Create Scripts - Output screen

1. Complete the fields that are marked with an asterisk (*):
   • Dataset Name — Supply 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, Performance Test for Mainframe Servers prefixes it with your TSO prefix, typically your user ID, at processing time.

   • Prefix — Enter a one- to six-character member name prefix for each row marked with an asterisk (*). Provide a prefix that makes it easy to identify the type of data stored in the members of the given data set. Performance Test for Mainframe Servers 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.

     Important

     Make sure the combined number of characters for prefix and suffix does not exceed eight.

   • Suffix — Enter a one- to seven-numeral member name suffix for each row marked with an asterisk (*). Performance Test for Mainframe Servers uses the prefix and suffix to create complete member names for the information stored in the given data set. If it creates more than one member for the data set, 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, Performance Test for Mainframe Servers generates members PRTEST01, PRTEST02, PRTEST03.

   • DDname — Enter a one- to eight-character DD name for detail data sets marked with an asterisk (*). Performance Test for Mainframe Servers creates a <DETAIL> tag in the script that points to the DD names you specify. It uses this information to locate the detail data during playback.

     Important

     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.

2. After filling in all of the desired data set names, press Enter to continue.
3. If you enter a data set name that does not exist, the Allocate Dataset screen is displayed. The fields on the allocation screen default 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 TCP message length.

     Important

     Messages longer than the detail data set LRECL will span multiple lines. If the data set contains messages that span multiple lines, the MAPD command, discussed on here, will not allow you to map the entire detail data set into File-AID/MVS for editing, only individual messages.

   • 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.
4. After filling in the fields, press Enter to allocate the data set or press End to exit the screen without allocating the data set.

  Select script options

After you specify Log, Script, or Detail Output data sets, the TCP/IP Create Scripts - Options screen is displayed. If you are generating a subset repository only, you will not see the Options screen. Go to Specify Subset Repository Output Datasets.

Use the TCP/IP Create Scripts - Options screen to select script formatting options.

  TCP/IP Create Scripts - Options screen

1. Enter a slash to select any or all of the following options:
   • Suppress time stamps in script — This option omits time stamps, making the script easier to browse for auditing purposes. However, Performance Test uses time stamps to synchronize playback when think option 2, THOPT(2), is specified on the playback CONTROL statement. Do not use this option if you intend to play back your scripts at the same pace as they were recorded.
   • Translate detail data from ASCII to EBCDIC — Converts detail data, normally written in ASCII, to EBCDIC. This makes it easier to display and edit detail data in ISPF. Performance Test adds the TRANSLATE=A2E keyword to the script tag to indicate that translation has occurred. During playback, Performance Test translates the data back to ASCII.
   • Translate sample data from ASCII to EBCDIC — When you store script and detail data separately, Performance Test includes a single line, or sample, of the detail data in the script for reference purposes. This option converts ASCII sample data to EBCDIC. Select this option if you plan to view your scripts in ISPF.
   • Split lines at linefeed characters (for readability) — Select Split lines at linefeed characters to show the detail data in a more readable format. Much of the data transferred between Web browsers and servers consists of readable lines that end with the ASCII linefeed character (x'0A'). Splitting detail data lines at each linefeed character can help you understand script contents. Playback is not affected by this option.
   • Suppress CONTENT data formatting (DB2C, IMSC, CTG, or ECI) — Select this option to indicate that key protocol fields (DB2C, IMSC, CTG, or ECI) should not be separated from the CONTENT data and formatted into a readable format within the script.
2. Enter up to 53 characters that describe the scripts or subset repositories you are creating. This description appears at the top of the Log and at the top of each script.
3. Press Enter to continue.

Specify subset repository output data sets

If you are creating a subset repository, the TCP/IP Create Scripts - Subset Output screen is displayed. Otherwise, the TCP/IP Create Scripts - Process screen is displayed. See Select a Processing Option.

Specify a single data set to contain the entire subset repository or a range of data sets to segment the repository. Performance Test writes the new repository data to the first specified data set. If the data set contains data, it adds the new data to the end of existing data until it completes repository creation or the data set is full. If there is more data to write, it continues writing to the next specified data set. Performance Test reports progress with messages indicating the opening and closing of data sets.

1. In the Dataset name field, enter the name of the sequential data set to contain the new subset repository. To create a segmented repository, use either of the following wildcards and specify a wildcard range with the First and last number fields:
   • Asterisk (*): Insert the asterisk in place of the data set name qualifier characters to substitute with incremental values during repository creation. This wildcard pads to eight characters. For example, enter USER.REP*.DATABASE with first=1 and last=3 to create the following subset repositories:
     USER.REP00001.DATABASE
     USER.REP00002.DATABASE
     USER.REP00003.DATABASE
   • Question mark (?): Insert a question mark for each data set name qualifier character to substitute with incremental values during repository creation. For example, enter USER. REP??.DATABASE with first=9 and last=11 to create the following subset repositories:
     USER.REP09.DATABASE
     USER.REP10.DATABASE
     USER.REP11.DATABASE
2. Press Enter to continue.
   If the first specified data set does not exist, the Allocate Dataset screen is displayed. It populates the Space units, Primary quantity, and Secondary quantity fields with allocation values from the originating (input) repository and Block size with the default value of 9004.
3. Make changes, if necessary, and press Enter to continue or press End to exit the screen without allocating the file.

  Select a processing option

After selecting all of your script/subset repository creation options, the TCP/IP Create Scripts - Process screen is displayed.

 TCP/IP Create Scripts - Process screen

Enter the desired processing option on the line next to the list and press Enter to begin processing. Press End to exit the screen without processing the job.

 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, Performance Test for Mainframe Servers returns to the TCP/IP Create Scripts - Process screen.

 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. To exit the edit session without submitting the job, type EXIT on the Command line and press Enter.

 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 are displayed on your TSO terminal.

 Exit

Use this option to exit this screen without submitting the job.

 Job statement information for batch job

Enter batch JOB card information into this area. If you use option 2, you can edit this information again before job submission.

  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.

  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 TCP/IP script tags. Each definition includes a syntax diagram that shows all of the parameters for the given script tag.

  <VERSION> tag

The <VERSION> tag identifies the version of the Performance Test for Mainframe Servers script creation program that created the script and 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:

  <DETAIL> tag

The <DETAIL> tag specifies the location of the detail data (the bytes that flow between clients and servers). For example, this could be an HTTP request and response. The <DETAIL> tag appears after the <VERSION> tag at the beginning of the script.

COMBINED

Specifies that client and server data are stored together in a single PDSE member, either within the script or in an external file. If the details are contained in the script, the value of this parameter is an asterisk (*). If they are 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 CLIENT nor SERVER appear on this tag and cannot be added.

CLIENT

Identifies where client data is located. The value is the DD name provided during script creation.

SERVER

Identifies where server data is located. The value is the DD name provided during script creation.

  <TIME> tag

The <TIME> tag specifies the date and time an event was seen during data capture, for the immediately following tag. The <TIME> tag is used during some types of playback to provide script synchronization and “timed release” of data flows. The <TIME> tag appears immediately before each <CONNECT>, <CLIENT>, and <SERVER> tag.

The time value is relative to the system the scripts were created on; it is not GMT (not Coordinated Universal Time, UTC). The content of this tag is a time stamp with the format: YYYY/MM/DD_HH:MM:SS.XXXXXX. For example:

  <CONNECT> tag

The <CONNECT> tag shows the start of a TCP connection. The keywords and values on the <CONNECT> tag indicate the identities of the two partners (the client and server) and the application protocol used by the connection. At playback time, the <CONNECT> tag starts a TCP connection between Performance Test for Mainframe Servers and a partner application.

ID

Identifies all of the data flows for a single TCP connection. The value of the ID attribute changes for each different TCP connection in a single script. The same ID value is present on all data flows for a single TCP connection. The value of ID is a decimal number, starting at 1 for the first connection in the script.

PROTOCOL

Lists the application protocol used by the TCP connection. This is the protocol that you assigned to the activity during script creation. Supported protocols include: HTTP, HTTPS, TCP, ECI, CTG, IMSC, and DB2C.

CLIENT_ADDRESS

The IP address of the partner that started the TCP connection (the partner that issued the TCP connection request). At playback time, Performance Test usually overrides this IP address with the IP address of the local machine (the OS/390 system) that the playback is running on. The value of CLIENT_ADDRESS can be specified in IPv6 or IPv4 format. See Filtering IP Addresses for more information on how to specify IPv6 or IPv4 addresses.

CLIENT_PORT

The port number of the partner that started the TCP connection (the partner that issued the TCP connection request). At playback time, Performance Test usually overrides this port number with a temporary port number, which is dynamically assigned by the local host machine that the playback is running on. The value of CLIENT_PORT is a decimal number from 0 through 65535.

SERVER_ADDRESS

The IP address of the partner that accepted the TCP connection (the partner that issued a LISTEN and ACCEPT). At playback time, Performance Test usually uses this IP address with no modification. The value of SERVER_ADDRESS can be specified in IPv6 or IPv4 format. See Filtering IP Addresses for more information on how to specify IPv6 or IPv4 addresses.

SERVER_PORT

The port number of the partner that accepted the TCP connection. At playback time, Performance Test usually uses this port number with no modification. The value of SERVER_PORT is a decimal number from 0 through 65535. Port number 80 is often used by the HTTP protocol (Web browsing) and port number 443 is often used by the HTTPS protocol (secure Web browsing).

STIME

Indicates the local date and time when the TCP connection started. The STIME value is relative to the system that the scripts were created on; it is not GMT (i.e., not Coordinated Universal Time, UTC). The value is a time stamp with the format: YYYY/MM/DD_HH:MM:SS.XXXXXX. For example:

TRANSLATE

Lists the character translation that was applied to the TCP data flows at script creation time for this connection. In this release, the only value allowed is A2E, which is short for ASCII-to-EBCDIC. A value of A2E indicates that all detail data for this connection, whether in the script or in an external file, has been translated from ASCII to EBCDIC.

This translation does not use a specific IBM or ISO character set and code page. Instead, Performance Test does a product-specific translation that changes a minimum number of characters when going from ASCII to EBCDIC. An attempt is made to translate only the typical “human readable” characters, (a-z, A-Z, 0-9, and punctuation), while leaving control characters in their original ASCII format. In this way, you can read the translated characters and still see the ASCII control codes that were transmitted (for example, carriage return (CR) and linefeed (LF)).

Here is the translation table used by Performance Test during script creation and script playback:

* SYNTHESIZED CONNECT TAGThe appearance of a synthesized <CONNECT> tag may lead to incorrect playback results since some of the data that originally flowed on the TCP connection may be missing from the script. Be careful when interpreting the playback results from a script that contains a synthesized <CONNECT> tag.

  <DISCONNECT> tag

The <DISCONNECT> tag specifies the end of a TCP connection. It immediately follows either a <CLIENT> tag or a <SERVER> tag, depending on which partner ended the connection.

 <CLIENT> tag

The <CLIENT> tag specifies that either data or a disconnect event flowed from the client to the server. The value after the <CLIENT> tag is a decimal number indicating how many events (CONNECT, CLIENT data, or SERVER data) have been seen so far in this script.

ID

Identifies all of the data flows for a single TCP connection. The value of the ID attribute changes for each different TCP connection in a single script. The same ID value will be present on all data flows for a single TCP connection. The value of ID is a decimal number, starting at 1 for the first connection in the script.

CRNTLEN

Indicates the number of bytes of detail data recorded for this client data flow event. This is the number of bytes actually written into the script or an external file, which may be different than the number of bytes sent by the client at capture time. The CRNTLEN value may be less than the TRUELEN value if data truncation was requested by the user either at data capture time or at script creation time.

TRUELEN

Indicates the number of bytes of detail data actually sent by the client, as seen during data capture. This may not be the same as the number of bytes actually written into the script or an external file. The TRUELEN value may be greater than the CRNTLEN value (see above) if data truncation was requested by the user either at data capture time or at script creation time.

 <SERVER> tag

The <SERVER> tag specifies that either data or a disconnect event flowed from the server to the client. The value after the <SERVER> tag is a decimal number indicating how many events (CONNECT, SERVER data, or CLIENT data) have been seen so far in this script.

ID

Identifies all of the data flows for a single TCP connection. The value of the ID attribute changes for each different TCP connection in a single script. The same ID value will be present on all data flows for a single TCP connection. The value of ID is a decimal number, starting at 1 for the first connection in the script.

CRNTLEN

Specifies the number of bytes of detail data recorded for this server data flow event. This is the number of bytes actually written into the script or an external file, which may be different than the number of bytes sent by the server at capture time. The CRNTLEN value may be less than the TRUELEN value if data truncation was requested by the user either at data capture time or at script creation time.

TRUELEN

Specifies the number of bytes of detail data actually sent by the server, as seen during data capture. This may not be the same as the number of bytes actually written into the script or an external file. The TRUELEN value may be greater than the CRNTLEN value (see above) if data truncation was requested by the user either at data capture time or at script creation time.

 <CTG> tag

<CTG> tags present information that may appear in a script for formatted CTG content.

APPLID

The VTAM application ID associated with the session.

PROGID

The CICS program associated with the session.

 <DB2> tag

<DB2> tags present information that may appear in a script for formatted Db2 Connect content.

SQLSTMT

The SQL statement in editable form.

USERID

The userID associated with the session.

PASS

The password for the session.

NPASS

The password for the session in an encrypted format.

RDBNAM

The server name for Db2 Connect (the name of the relational database).

SQLCODE

A non-editable field returned by the server.

SQLSTATE

A non-editable field returned by the server.

  <ECI> tag

<ECI> tags present information that may appear in a script for formatted ECI content.

USERID

The user ID associated with the session.

PASS

The password for the session.

NPASS

The password for the session in an encrypted format, which is ‘xx...xx’X where xx...xx indicates 2 to 16 hexadecimal characters.

PROGID

The CICS program associated with the session.

 <IMS> tag

<IMS> tags present information that may appear in a script for formatted IMS Connect content.

USERID

The userID associated with the session.

PASS

The password for the session.

NPASS

The password for the session in an encrypted format, which is ‘xx...xx’X where xx...xx indicates 2 to 16 hexadecimal characters.

CLIENT

The unique client identifier for the session.

DSTORE

The target IMS Datastore for the session.

TRANS

The transaction code (application program) the message belongs to.

  <CONTENT> tag for inline data

<CONTENT> tags present the data that flowed between the client and the server. One or more <CONTENT> tags appear immediately after a <CLIENT> or <SERVER> tag. If the length of the client or server data is greater than the logical record length (LRECL) of the script data set, 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 begins immediately after “7”.

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).

• 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'10' indicates TCP/IP data
  • X'08' indicates the beginning of the CONTENT chain
  • X'04' indicates the end of the CONTENT chain
  • X'02' indicates truncated data
  • X'01' indicates SERVER data.

For example, if the TCP/IP message is comprised of three <CONTENT> tags, this byte’s value on the:

• First tag is X'18', which indicates TCP/IP data and beginning of CONTENT chain.
• Second tag is X'10', which indicates TCP/IP data.
• Third tag is X'14', which indicates TCP/IP data and end of CONTENT chain.

If the <CONTENT> tag follows a <SERVER> tag, this byte’s values on each <CONTENT> tag is: X'19', X'11', and X'15'.

• The fourth byte indicates the protocol of the detail data.
  • X'01' indicates generic TCP/IP
  • X'03' indicates HTTP
  • X'04' indicates HTTPS
  • X'05' indicates Db2 Connect
  • X'06' indicates ECI
  • X'07' indicates CTG
  • X'08' indicates IMS Connect.
• 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.

  <CONTENT> tag for external data

Identifies the detail data records that are associated with the preceding <CLIENT> or <SERVER> tag. The <CONTENT> tag only includes 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 of detail data and is provided to support script browsing when the detail data is stored separately. The sample bytes are translated from ASCII to EBCDIC if you requested that option at script creation time.

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 provided in the <CONTENT> Tag for Inline Data.

 Edit a script

You may want to 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 and 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 TCP/IP 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 <CLIENT> and <SERVER> tag content.

Use ISPF Edit to edit your scripts. To perform dynamic data replacement during playback, insert the <REPLACE> tag. For example, the script contains a series of transactions performed against a specific account. If the account number resides in the same location in the TCP/IP data streams, you can replace that account number in all of the transactions by inserting one <REPLACE> tag in the appropriate location. You can replace data in a single client or server data stream or in a specified range of data streams.

You can add REXX logic to the script to:

• Create dynamic scripts that facilitate data-driven testing or create smart scripts that modify application flow based on message content.
• Define custom MVS job step return codes for more definitive playback results.

Performance Test for Mainframe Servers provides customized REXX variables that return playback information. You can incorporate these 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 describes the elements necessary for basic script editing and a short description of the Performance Test REXX variables:

• Script Syntax Rules
• <REPLACE> Tag
• Offset and Length Determination Macros
• Performance Test for Mainframe Servers REXX Variables

For more advanced scripting concepts or a better understanding of REXX applications, refer to the Performance Test Scripting-Reference guide. Additionally, consider reviewing APPC Data-Driven Testing Example Using REXX. Although it applies to APPC testing, it provides a comprehensive example that includes the use of Performance Test REXX variables and the <REPLACE> tag. The concepts and mechanics are the same regardless of the type of application you are testing.

  Script syntax rules

Editing a script requires an understanding of script tags and syntax rules. If you are unfamiliar with TCP/IP script tags, see Browse a Script.

TCP/IP Script Syntax Rules:

• A script tag must be enclosed in angle brackets ‘<>’ and the tag name must be adjacent to the opening angle bracket ‘<‘. For example:

• Script tag parameters follow the tag name inside the angle brackets. The format of a script tag parameter is parameter=value.

• A tag can have multiple parameters. Parameters on the same line must be separated by one or more spaces. For example:

Parameters can appear on separate lines for easy reading. Each line must end with a comma, which is the standard ISPF record continuation character. For example:

• 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 CLIENT_ADDRESS parameter value contains periods so it is enclosed in single quotation marks. IPv6 and IPv4 IP address formats are both valid CLIENT_ADDRESS values.

• The script tag’s value follows the tag’s closing bracket ‘>’. For example, 4 is this <CONNECT> tag’s value.

• The script tag’s entire value must be on the same line as the closing bracket ‘>’.
• Comment lines, used to provide details 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 connection information and a description of the next connection in the script

• REXX clauses added to the script must precede the activity the logic applies to. They can be inserted between scripts tags, but not within a tag or its value.

• A single REXX variable can be supplied as the value of a script tag parameter. For example:

However, REXX variables cannot be supplied within the script tag’s value. Therefore, they cannot be the value or within the value following the tag’s closing angle bracket ‘>’.

  <REPLACE> tag

The <REPLACE> tag replaces the information within the TCP/IP data streams during playback. Use the <REPLACE> tag to supply new data, such as account numbers, user names, etc. 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 Edit a Script.

The <REPLACE> tag can be applied to the CONTENT of a single <CLIENT> or <SERVER> tag or to a range of tags. If applied to a range, the <REPLACE> tag acts on the CONTENT of both <CLIENT> and <SERVER> tags within the range.

Insert the <REPLACE> tag before the <CLIENT> or <SERVER> tag or group of tags it applies to. 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 occurs 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.

Specify one or more FIELD attributes on a given <REPLACE> tag. For example:

TYPE

Indicates how to apply data replacement.

• TYPE=ONE applies data replacement to the next CLIENT or SERVER message. This is the default.
• TYPE=ALL applies data replacement to all subsequent CLIENT and SERVER messages. This is a global data replacement.
• TYPE=DELETE disables global data replacement established by a previous <REPLACE> tag with the TYPE=ALL parameter.

LENGTH

Sets the length for the entire message content to be used during playback, LENGTH=n, where n indicates the number of bytes. If part of a message is replaced and it changes the data length from the original, then the LENGTH parameter would be needed. This applies whether the length change shortens or lengthens the data.

  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 data set, the data stream is broken into multiple content records each beginning with the <CONTENT> tag and a 12-byte header.

To ease offset and length determination, Performance Test 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.

To use the offset and length determination macros:

1. Open the script or detail data set 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 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 near the bottom of the screen.

 LOCPOS results

The BRULE macro displays a byte ruler above the selected <CONTENT> record (BRULE Results). In the illustration, the offset of ‘m’ is 144, ‘s’ is 145, ‘-’ is 146, etc. Every fifth and tenth 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 ‘we’ in the word ‘powerpoint’. The offset value of ‘w’ is 149 and ‘e’ is 150.

 BRULE results

The BRULES macro displays a byte ruler above each record (line) of the selected <CONTENT> tag.

 BRULES Results

  Performance Test for Mainframe Servers REXX Variables

Add REXX logic to your TCP/IP scripts to control the way scripts play back. For example, dynamically replace script data with unique data from an external file on each iteration of playback. Incorporate the following Performance Test predefined REXX variables. They return playback information used to drive data-replacement logic. Refer to the Performance Test Scripting-Reference for more information.

Returns the content of the most recent message processed by Performance Test. This variable’s value is similar to the RequestBody or ResponseBody reporting fields, depending on whether the data came from the client or server.

TCPIP_EXPECTED

Returns the content of an inbound message that Performance Test expects to receive. This is the server content from your script. This variable is similar to the ExpResponseBody reporting field.

TCPIP_ACTUAL_LENGTH

Returns the length of the most recent message processed by Performance Test.

TCPIP_EXPECTED_LENGTH

Returns the length of an inbound message that Performance Test expects to receive.

CONNECTION_NBR

Returns the current ID of the connection that is playing back. This variable’s value may be the same across multiple sockets, as it is pulled from the script.

REPLAY_ID

Returns a sequential value for each instance of a SOCKETS replay. For example, a SOCKETS 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 */
   <CLIENT...
3. Set the count value in the SOCKETS statement to 1000:

SOCKETS 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.

SOCKETS_COUNT_NBR

Returns the COUNT value of the current SOCKETS replay. For example, if the SOCKETS statement specifies COUNT(3), the first instance returns COUNT = 1; the second, COUNT = 2; the third, COUNT = 3. This value is set when the SOCKETS replay begins.

Use this variable and SOCKETS_REPEAT_NBR to extend testing capability.

SOCKETS_REPEAT_NBR

Returns the REPEAT value of the given SOCKETS. This value is set when a socket begins execution. Use SOCKETS_COUNT_NBR and SOCKETS_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).

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 */
   <CLIENT...
3. Set the count and repeat values in the SOCKETS statement as follows:

SOCKETS COUNT(3),REPEAT(2)This generates six unique customer requests, each with a unique combination of product and account parameter values.

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.

ACTUAL_DB2_USERID

Returns the ID of the user associated with the Db2 transaction being played back. This value comes from the script and is sent to the server by playback.

ACTUAL_DB2_RDBNAM

Returns the name of the relational database associated with the Db2 transaction being played back. This value comes from the script and is sent to the server by playback.

ACTUAL_DB2_SQLSTMT

Returns the SQL Statement associated with the Db2 transaction being played back. This value comes from the script and is sent to the server by playback.

ACTUAL_DB2_SQLSTATE

Returns the value of the last SQL State returned by the application during playback. This is a live value that is received by playback from the server being tested.

ACTUAL_DB2_SQLCODE

Returns the value of the last SQL code returned by the application during playback. This is a live value that is received by playback from the server being tested.

ACTUAL_DB2_ANSWER_SET

Returns the server’s response to an SQL Query/Statement being played back. This is a live value that is received by playback from the server being tested.

EXPECTED_DB2_SQLSTATE

Returns the value of the last DB2 SQLSTATE from the most recent message processed by Performance Test. This is the server SQLSTATE from your script.

EXPECTED_DB2_SQLCODE

Returns the value of the last DB2 SQLCODE from the most recent message processed by Performance Test. This is the server SQLCODE from your script.

EXPECTED_DB2_ANSWER_SET

Returns the value of the response to an SQL Query/Statement from the most recent message processed by Performance Test. This is taken from the server content in your script.

ACTUAL_IMS_CLIENT

Returns the unique client identifier associated with the IMS transaction being played back. This value comes from the script and is sent to the server by playback.

ACTUAL_IMS_TRANS

Returns the IMS transaction code (target application) associated with the IMS transaction being played back. This value comes from the script and is sent to the server by playback.

ACTUAL_IMS_DSTORE

Returns the IMS Datastore associated with the IMS transaction being played back. This value comes from the script and is sent to the server by playback

ACTUAL_IMS_USERID

Returns the ID of the user associated with the IMS transaction being played back. This value comes from the script and is sent to the server by playback.

ACTUAL_CTG_APPLID

Returns the APPLID of the VTAM application being accessed by the CTG transaction being played back. This value comes from the script and is sent to the server by playback.

ACTUAL_CTG_PROGID

Returns the name of the program being accessed by the CTG transaction being played back. This value comes from the script and is sent to the server by playback.

ACTUAL_ECI_USERID

Returns the ID of the user associated with the ECI call being played back. This value comes from the script and is sent to the server by playback.

ACTUAL_ECI_PROGID

Returns the name of the program invoked in CICS by the ECI call being played back. This value comes from the script and is sent to the server by playback.

  Editing TCP/IP detail data with File-AID/MVS

Review and edit TCP/IP detail data (transmission or message data) with:

• ISPF Edit or View.
• File-AID/MVS version 08.00 (if you are licensed).

Invoke File-AID/MVS from an ISPF Edit or View session to review and edit TCP/IP message data in a formatted context. For example, if the message data contains a numeric string representing a customer ID and account number, identifying the account number portion of the string may be difficult in ISPF Edit and therefore editing may be 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 data set. This process is referred to as mapping message data into application data structures.

If TCP/IP message data is stored in the script, map one message at a time. If it is stored in a separate data set, map an individual message or all messages in the data set at once. Refer to step 1.

  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 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.

  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 data set in ISPF Edit or View. 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 you wish to map.

   Important

   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.

   Important

   The command prefix (!) is only required 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 used by your terminal. In the United States, the exclamation point is typically the correct character. See the note in the Assign a PF Key to MAPD 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 your File-AID/MVS documentation for help with the screens that appear. 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 you need to review or edit.

   Important

   MAPD creates a temporary data set, 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 data set. When you leave File-AID/MVS, it passes your changes back to ISPF and deletes the temporary data set. Upon exiting ISPF, MAPD updates the script/detail data set.

   If for some reason, the File-AID/MVS session is lost during edit, delete the temporary data set manually.

   Additionally, you can use the temporary data set as input to an XML generation job. After you submit the job, exit the File-AID screen that is displayed to ensure the temporary data set 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 return to ISPF or End to exit File-AID/MVS and transfer your changes to ISPF.

6. 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.

  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 data set in ISPF Edit or View.

   Important

   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 for the MAPD command, type exclamation point (!) MAPD on the Command line and press Enter.

   Important

   The command prefix (!) is only required 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 used by your terminal. In the United States, the exclamation point is typically the correct character. See the note in the Assign a PF Key to MAPD discussion for more information.

3. MAPD invokes File-AID/MVS. Refer to your File-AID/MVS documentation for help with the screens that appear. 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 you need to review or edit.

   Important

   MAPD creates a temporary data set, with a four-node naming convention (USERID.MAPDTEMP.DATE.TIME), to pass mapped messages to File-AID/MVS. File-AID/MVS writes changes to the temporary data set. When you leave File-AID/MVS, it passes your changes back to ISPF and deletes the temporary data set. Upon exiting ISPF, MAPD updates the script/detail data set.

   If for some reason, the File-AID/MVS session is lost during edit, delete the temporary data set manually.
   Additionally, you can use the temporary data set as input to an XML generation job. After you submit the job, exit the File-AID screen to ensure that the temporary data set 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 your changes to ISPF.

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

To access MAPD help panels, type MAPD space HELP or MAPD space question mark (?) on the Command line in the ISPF Edit or View session. Then press 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 messages 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 data set messages

'CURSOR NOT ON <CONTENT> - SEE USER’S GUIDE'

Explanation: The data set containing the message you are mapping is not a script data set.

User Response: Press Enter to clear the message and Cancel to exit the ISPF session. Locate the appropriate data set 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'S GUIDE'

Explanation: While editing a script data set, 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 occurred in the current ISPF session, use Cancel to exit the session without saving changes and retry.

'SCRIPT & DETAIL MUST BE COMBINED - SEE USER’S GUIDE'

Explanation: You are attempting to map from a script data set that is stored separately from the detail data set (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.

User Response: Press Cancel to exit the ISPF session. Locate the corresponding detail data set and map messages from there.

  Detail data set messages

'CURSOR NOT ON DETAIL RECORD - SEE USER’S GUIDE'

Explanation: You are either attempting to map from a data set that is not a detail data set 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 you inadvertently altered 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, regenerate the script and detail.

'LINE(S) DELETED - DETAIL OUT OF SYNC'

Explanation: While editing a detail data set in File-AID/MVS, you deleted a record, which will cause an unsynchronized playback.

User Response: Press Cancel to exit the ISPF session without saving changes to the detail data set.

'LINE(S) INSERTED - DETAIL OUT OF SYNC'

Explanation: While editing a detail data set in File-AID/MVS, you inserted a record, which will cause an unsynchronized playback.

User Response: Press Cancel to exit the ISPF session without saving changes to the detail data set.

'MESSAGE DATA SPANS MULTIPLE LINES - SEE USER'S GUIDE'

Explanation: When the script was created, if the length of the TCP/IP message data is longer that the detail data set’s logical record length (LRECL), the message will span 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 32K. 32K is the maximum record length supported by MAPD.

'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.

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; therefore, File-AID/MVS had no data to return.

System Action: No changes are made to the TCP/IP message data.

User Response: Press Enter to clear the message and return to ISPF.