Global Recording Requests and Scripts (VTAM)

Testing with Performance Test for VTAM involves capturing activity and generating testing scripts from the captured activity. Use Global Recording to perform both of these tasks. The Global Recording menu provides the following options:

• Monitor Requests — Create, manage, and monitor Global Recording requests. Record all of the 3270/LU0 traffic on the system or specify the terminals, applications, and user IDs to record. Set up the recording request to initiate script creation when the recording request ends, or suspend script creation and generate scripts later.
• Review Repository — View a list of the sessions captured in a given recording. Generate scripts from selected sessions or for entire capture repositories. Save the specified script creation criteria in the affiliated recording request, or discard it after script creation.
• Global Recording Manager — Build lists of applications, terminals, and user IDs to include or exclude from recording. Global Recording Manager lists provide greater flexibility in defining Global Recording requests.

Performance Test for VTAM also offers a batch interface to Global Recording. Use the batch interface with a job scheduler to automate recording initiation, termination, and script creation. For example, you can create a job that starts or stops recording, and a job that generates scripts and schedules them to run every day at the appropriate time.

You can use the interfaces together. For example:

• Schedule request management jobs to capture activity for the same time period each day. Then use the Review Repository option to select specific sessions for scripting.
• Use the online interface to create Global Recording Manager lists. Then, use the lists to govern automated recordings.

Performance Test for VTAM also provides a Capture Segment Summary report to help you identify the information stored in your capture repositories. It indicates when recording began and ended for each segment of the specified repositories. Use it to select the appropriate segments for script creation. Review the report with a file-browsing tool such as ISPF Browse or import it into a spreadsheet or database for easy manipulation.

Accessing Global Recording

Start Performance Test for VTAM and select option 4 Global Recording from the Performance Test for VTAM Main Menu.

Performance Test for VTAM - Main Menu

The Global Recording menu appears.

 Global Recording Menu

Creating a Global Recording request

Global Recording writes captured activity to a specified data set or range of data sets called a repository. Testing scripts are generated from the capture repository. If your installer enabled Autostart Script Creation, Global Recording initiates script creation at the end of recording. However, you can suspend script creation and initiate it later using the Review Repository option or the batch interface. For example, you may want to capture an entire day’s activity, then generate scripts in the evening when more system resources are available.

To capture activity and potentially generate scripts, 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.

To create a Global Recording request:

1. Select option 1 Monitor Requests by typing 1 on the Option line of the Global Recording menu and pressing Enter.

   • If there are no existing requests, the Global Recording - Add Requests screen appears.
     Global Recording - Add Requests screen 

        ----------------------  Global Recording - Add Requests  --- REQUEST SCHEDULED
        Command ===>
     
         Press ENTER to continue, or END to return.
     
         *****************************************************************************
         *                                                                           *
         *          No Global Recording Requests were found for your userid.         *
         *                                                                           *
         *****************************************************************************
     
         Type of request to add:
           1  1. 3270
              2. APPC

     • If a licensed version of Performance Test for Mainframe Servers is installed, the Type of request to add field with options 1. 3270 and 2. APPC appears on the screen. Type 1 to select the 3270 option and press Enter.
     • If the options are not displayed, press Enter to continue.

     Warning

     Important

     Refer to the  Performance Test for Mainframe Servers User Guide for information about option 2. APPC.

   • If Global Recording requests exist, the Global Recording - Monitor Requests screen appears showing a list of requests. Active requests are highlighted. On the first request listed, type 1 (to indicate Add 3270), and press Enter.
     Global Recording - Monitor Requests screen

        --------------------- Global Recording - Monitor Requests ------ REQUEST ADDED
        Command ===>                                                  Scroll ===> PAGE
     
        Line commands are: (C)ancel, (F)orce, (P)Stop, (R)estart,  (D)isable,
                           (S)elect, (U)pdate,(V)iew,  (1)Add 3270,(2)Add APPC, or
                           (9)Switch repositories
     
           LU   Side-A/  Side-B/            Repository
        S  Type Applid   Terminal Userid    Dataset                               Users
        -  ---- -------- -------- --------  ------------------------------------- ----
           3270 *        *        *         PMIJSS0.EXAMPLE.REPOS201                 0
        ******************************* BOTTOM OF DATA ********************************

     The 3270/LU0 Capture Criteria screen appears.
     3270/LU0 Capture Criteria screen

        --------------------  3270/LU0 - Capture Criteria  (View)  --------------------
        Command ===>
     
         Press ENTER to continue, or PF1 for help, or CANCEL to exit.
     
         Terminal . . . . . . . . . . . *        Use an asterisk for wildcarding
         Application  . . . . . . . . . *        the Terminal, Application or Userid
         Userid . . . . . . . . . . . . *        fields.
          OR
         Global Record Manager List . .          Second filter GRM List . .
     
                          HH : MM : SS                    MM / DD / YY
         Start Time . . .    :    :      Start Date . . .    /    /     (Optional)
         End Time . . . .    :    :      End Date . . . .    /    /     (Optional)
     
         Repository Dataset . . . 'PMIJSS0.EXAMPLE.REPOS2*'
         First and last number. . 0000001 0000005 (If wildcard in dataset)
     
         Recording options:  (Enter "/" to select)
              Suspend script creation         /  Normal event notification
           /  Re-use repositories             /  Error event notification
              FORCE request at 'End Time'        Record from LOGON only

2. Enter the logical unit name of the Terminal to record. Enter one of the following:

   • A specific terminal ID
   • An asterisk (*) to select all terminals
   • A terminal prefix followed by an asterisk to select a group of terminals. For example, H8606* selects all terminals beginning with H8606.

   This field is required unless you provide a value in the Userid field or an include or exclude list in the Global Record Manager List field. Leaving the field blank selects all terminals. This field holds eight characters.

3. Enter the ID of the Application to record. To select all applications, leave the field blank. To specify a group of similar applications, type the application name prefix with an asterisk (*). For example, CICS* selects all applications with names that begin with CICS. This field holds eight characters.

4. Enter the Userid of the user to record. Enter one of the following:

   • A specific user ID
   • An asterisk (*) to select all users
   • A user ID pattern to select a group of users based on the entered pattern:
     • Use wildcard “?” to specify exactly one of any character in that spot of the pattern.
     • Use wildcard “*” to specify that characters at that spot and after will always match.
     • Use any combination of alphanumeric characters and wildcards to create the pattern.
     • Only specify the “*” wildcard as the last character in the pattern.
     • Examples: AB* will match any user IDs starting with “AB”. A??B* will match any user IDs starting with “A” with fourth character “B”. A*B is not allowed; use “?” to specify any character within the pattern, for example A?B.

   This field is required unless you enter a value in the Terminal field or an Include or Exclude list in the Global Record Manager List field. Leaving the field blank selects all users. This field holds eight characters.

5. If you have not already entered the Terminal, Application, and/or Userid, enter the name of the Global Record Manager (GRM) list (and the Second Filter GRM List, if desired) to use for this request. Save time by creating Global Recording Manager lists that specify terminals, applications, and user IDs to include or exclude from capture.
   If you specify a list name, and an existing list starts with the same characters, the Global Record Manager * Include/Exclude List screen appears. It displays all lists beginning with the same characters. You need to:

   • Select one of the existing lists by typing an S next to it and pressing Enter.
     or
   • Use the A (add) line command to define the new list. Press End to return to request creation.

   If you specify a list that does not exist, the Global Record Manager * Add List screen appears. Fill in the fields and press End to return to request creation.
   See Defining Global Recording Manager Listsfor more information.
   This field accepts a value only if you did not enter information in the Terminal, Application, or Userid fields.
   If a Second Filter GRM List is specified, the Global Record Manager List must also be specified. The list can be either an Include or Exclude list. If the first and second lists are the same, it is logically equivalent to the one list. If they are different, the second filter will be applied to the result of the first filter.

6. Enter the start and end date and time. If you provide a start time, a start date is required. If you provide an end time, an end date is required. If you supply a start date, but accept all zeros for the start time, the request activates at midnight at the beginning of the start date.

   • To activate the request immediately, accept the default value of all zeros in both the Start Time and Start Date fields.
   • To activate or deactivate the request at a specific time, enter start and end times and dates:
     • Enter a two-digit hour based on a 24-hour clock. The cursor automatically moves to the MM field.
     • Enter either a two-digit minute, or press Tab to accept 00 and move to the SS field.
     • Enter either a two-digit second, or press Tab to accept 00 and move to the date fields.
     • Enter a two-digit month. The cursor automatically moves to the DD field.
     • Enter a two-digit day. The cursor automatically moves to the YY field.
     • Enter a two-digit year.
   • To keep the request active until you STOP, FORCE, or CANCEL it, accept the default value of all zeros for both the End Time and End Date fields.

   Warning

   Important

   If you select the FORCE request at ‘End Time’ option under Recording Options, an End Time is required.

7. In the Repository Dataset field, enter the name of the data set to use for storing captured information. To create a segmented repository, use the following wildcard characters in the data set name field and define a range with the First and last number fields:

   • Asterisk (*): Inserts an incremental value into the data set name qualifier in which the asterisk appears. This wildcard pads the incremental value with enough zeros to ensure an eight-character qualifier. For example, USER.#3270.REC* with first=1 and last=3 creates capture repositories:USER.#3270.REC00001USER.#3270.REC00002USER.#3270.REC00003

     USER.#3270.REC00001
     USER.#3270.REC00002
     USER.#3270.REC00003

   • Question mark (?): Inserts the incremental value into the data set name qualifier where the question marks appear. Enter at least one question mark for each digit of the greatest value in the range fields. For example, USER.#3270.REC?? with first=9 and last=11 creates capture repositories:USER.#3270.REC09USER.#3270.REC10USER.#3270.REC11

     USER.#3270.REC09
     USER.#3270.REC10
     USER.#3270.REC11

   Warning

   Important

   Begin each segment of the data set name with an alpha character (A-Z) or @#$ including segments with wildcard characters. Global Recording does not support multiple Global Recording requests using the same repository to store captured information. Make sure each Global Recording request uses a unique repository.

8. Enter a beginning and ending value in the First and Last number fields to define the range of numbers (if you specified wildcard characters in the Repository Dataset field).
   If you did not use wild card characters in the Repository Dataset field, leave these fields blank and go to the next step.
9. Type a slash to select the desired recording options:
   • Suspend script creation controls automatic script creation. Select this field to prevent script creation at the end of the recording request. If you leave this field blank you will be guided through the script creation criteria screens prior to your capture request being activated. This will also cause automatic script creation to execute when your capture request is stopped.
   • Normal event notification sends all recording request status and error messages to your TSO session. This option is selected by default. If you are recording a large number of sessions, consider disabling this option to reduce the number of messages you receive.
   • Re-use repositories applies to segmented repositories only. It causes Global Recording to continue capturing activity after the repository segments are full. After the last segment fills, it begins writing to the first segment again, replacing the oldest captured activity with the newest. If this option is not selected, recording terminates after the last segment is full.

   • Error event notification sends only the error messages associated with the request to your TSO session. This option is selected by default. If you are recording a large number of sessions, consider selecting this option and disabling Normal event notification to minimize the number of messages you receive.

     Warning

     Important

     Normal event notification sends all messages, including error messages, to your TSO session. If Normal event notification is selected, Global Recording ignores the Error event notification option. To prevent receiving messages altogether, clear both Normal event notification and Error event notification. However, even when these settings are cleared, certain messages are always issued by Global Recording: TCPAR101I, TCPAR102I, TCPAR104I, and TCPAR105I.

   • FORCE request at ‘End Time’, issues a FORCE command at the end time specified in the request. FORCE terminates recording of all sessions including in-flight sessions. Script creation begins immediately, unless the Suspend script creation option is selected. Be aware that you may lose buffered data, resulting in partially recorded sessions.
     If you do not select this option, Global Recording issues a STOP command at the request’s specified end time. It stops recording new sessions but continues to record any active sessions. After all in-flight sessions end, recording terminates and script creation begins unless the Suspend script creation option is selected. Although this ensures complete session captures, it may delay script creation.
   • Record from LOGON only begins recording upon logon if all other request criteria are met. This option is selected by default. If you specify a time frame for the request, recording begins only if the logon occurs during the specified time frame.
     If you do not select this option, recording begins as soon as the request criteria are met. All in-flight sessions are captured. You may need to edit the scripts to delete any partially recorded business transactions.
     Devices using non-3270 data streams, such as LU0, are typically acquired when powered up. If you select this option, capture will begin only if the terminals are cycled within the time frame of the recording request.
10. Press Enter to continue.
    If you specified an existing data set in the request, Global Recording displays the Capture Criteria - Output Options prompt.

11. Type 1 to overwrite the existing data (choose this option only if you do not need to retain any data that might exist in the specified data set) or type 2 to append the existing data and press Enter.

    Warning

    Important

    The data set is overwritten when Global Recording captures and processes activity that matches the request criteria. If no activity matches, the data set is not overwritten.

    If the data set you specified does not exist, the Allocate Dataset screen appears. Generally the default parameters are appropriate, but you can modify them as necessary. Press Enter to continue.

    If you selected Suspend script creation, request creation is complete. Depending on the request options, your terminal may display messages associated with your request.

12. Press Enter to clear any messages your terminal displays. (You may need to press Enter several times.) After you clear all of the messages, the Monitor Requests screen appears. See Monitoring and Managing Existing Requests.
    If you did not select Suspend script creation, the 3270/LU0 - Script Criteria screen appears.

Define script creation criteria

Script creation criteria allows you to generate:

• Scripts containing user inputs and the resulting output screens for validating application responses.
• Scripts containing only user inputs for stress testing or dubbing baseline scripts.
• Formatted scripts for easy reading.
• Unformatted scripts for testing LU0 applications.
• Filtered scripts containing specific activity for unit or regression testing.

The Script Create procedure (HSSCREAT) generates one script for each captured session.

1. Use the 3270/LU0 - Script Criteria screen to define script creation parameters. Access this screen using one of the following:

   • The Monitor Requests option while creating or updating a recording request.
   • The Review Repository option (here) while generating scripts.
   • The batch interface to create scripts (here).

    3270/LU0 - Script Criteria screen 

      -------------------------- 3270/LU0 - Script Criteria -------------------------
      Command ===>
   
       Press ENTER to continue, or PF1 for help, or enter CANCEL to exit.
   
       Script dataset . 'PMIJSS0.JMS.SCRIPTS'
       Description. . . EXAMPLE FOR DOCUMENTATION
       Member prefix. . EXAMP    (1 - 6 character prefix)
       Member suffix. . 0000002  (2 - 7 numeric suffix)
       Session log. . .          (1 - 8 character member name)
   
       Script create options:  (Enter "/" to select)
            Replace existing members
         /  Format the recording
            Record inputs only
         /  Record input in (row,column) format
            Edit message filters
            Use message filters

2. Enter the Script dataset (the data set containing the scripts). This field holds up to 44 characters.

   Warning

   Important

   The automatic Script Create PROC (HSSCREAT) must have authority to update your script data sets.

3. Enter a Description, if desired. The description will appear in the script header section. This field holds up to 55 characters.
4. Enter a one- to six-character Member prefix that, in conjunction with the member suffix, forms the member name for each script created by this request.
5. Enter a Member suffix (a numeric value up to seven digits) that, in conjunction with the member prefix, forms an eight-character member name for each script created by this request. Script Create increments this value each time it creates a new script.
   • If you enter a suffix that is too short, Script Create pads the suffix with zeros to the left. For example, if the prefix is OES and the suffix is 10, the first script member name is OES00010, and the next member is OES00011.
   • If you enter a suffix that is too long, Script Create truncates the digits on the left. For example, if you enter SCRIPT for the prefix and 1234 for the suffix, the first script member is SCRIPT34, and the next member is SCRIPT35.
6. Enter a one- to eight-character member name containing the Session log or leave the field blank if you do not need a session log. A session log contains an entry for each session (and each script) created by the request. Session logs contain the bulk of the input required for an Unattended Playback job. You can save time when preparing the job by starting with the session log. See Unattended-Playback-Dubbing-and-Comparison-for-3270-and-LU0-Scripts-VTAM to learn about playback statements you may need to add or modify.
7. Type a slash to select the desired Script create options:
   • Replace existing members overwrites existing members with the same names as those specified in the request.
   • Format the recording applies a human-readable format to the scripts. If this option is not selected, the scripts contain a series of hexadecimal data streams. If you are testing with LU0 applications, do not select this option. This option is selected by default.
   • Record inputs only creates scripts that contain only user input keystrokes. This option primarily supports stress testing, where recorded and actual output screen comparison is not required. You can also use it to create scripts for dubbing baseline scripts. For example, play back an inputs only script, with dubbing active, against the production version of the software to create a baseline script. Then play back the baseline script against the application you are testing to validate its responses. This option reduces your script size and the demand on system resources. If this option is not selected, the scripts contain both the user input keystrokes and the resulting output screen images.
   • Record inputs in (row,column) format creates scripts containing input tags in row,column format, as opposed to the standard relative input format. For example, in standard format the first input tag is:
     <I01> “data”
     In row,column format, the same input tag contains the position of the input field:
     <I(07,28)>”data”
     When the input tag provides coordinates, locating the corresponding entry field on the screen image within this script is easier. This option is useful if you intend to review the script for debugging or audit purposes.
   • Edit message filters causes the 3270/LU0 - Message Filters screen to appear. Use this screen to designate filters for including or excluding specific messages from your scripts.
   • Use message filters causes Script Create to use the message filters associated with the recording request. This option saves time when updating recording requests.
8. Press Enter to continue.
   • If you specified a script data set that does not exist, and you did not select Edit message filters, an allocation screen appears. Generally, the default values are appropriate; however, you can override any or all values. Press Enter to allocate the data set and continue.
   • If you selected Edit message filters, the 3270/LU0 - Message Filters screen appears before the allocation screen. See Message Filters for more information.
   • If you specified an existing data set, did not select the Edit message filters option, and accessed the Script Criteria screen through the:
     • Monitor Requests option, then request creation is complete. Depending on the request options, your terminal may display messages associated with your request. Press Enter to clear the messages. (You may need to press Enter several times.) After you clear all of the messages, the Global Recording Monitor Requests screen appears. See Monitoring and Managing Existing Requestsfor more information.
     • Review Repository option, then the Script Processing screen appears. The cursor starts in the Select processing option field. Enter 1 for background processing or 2 for foreground processing. The cursor automatically advances to the Job statement area of the screen. If you selected option 1, enter the job statement information and press Enter. Your terminal may display processing messages. Press Enter to clear the messages and return to the Review Repository screen.

If script creation fails

If Global Recording encounters an error, it may prevent the script from being created in the script data set. For example, the data set may be full or renamed since the request was added.

If you have event notification enabled for the request, you receive a message that script creation was not successful and a return code that indicates the reason for the failure.

Session log for Global Record

The session log is a member stored in your script data set containing a summary of every script created for a request. It is available for any 3270 or LU0 recording request (formatted or unformatted) when you create a script. This is a summary of all the scripts created for a script create request.

If you supply a member name in the session log member name field on the 3270/LU0 - Capture Criteria screen you get a session log. If you do not need a session log, leave the session log member name field blank. An example of a typical session log appears in the following figure.

 Session Log example

The session log is most useful as the basis for SYSIN input to a Performance Test unattended playback job. The GROUP statement lists the following:

• name of the application
• name of the terminal
• logmode name
• start time and finish time of the session
• FM and TS profiles used for the session
• PSERVIC (LU presentation services profile and usage) for the session.

To perform a successful playback using the session log, you typically need to change the TERMINAL value and, possibly, the APPLICATION value. The FTIME, FMPROF, TSPROF, and PSERVIC keywords are ignored during a playback and can either remain unchanged or be removed using a standard text editor as follows:

1. Exclude all lines containing TERMINAL, FMPROF, TSPROF, PSERVIC, or FTIME.
2. Delete all of the excluded lines.
3. Remove the continuation character from the STIME line.

 Message Filters

You can filter captured information to generate scripts containing only the activity you need.

A filter is a short REXX program that compares message content to a set of criteria. If the message meets the criteria, it matches the filter.

To use message filters:

1. Create filters using the Message Filtering option, or code them manually and store them in PDS members. Unattended-Message-Filters-VTAM explains both methods.
2. Use the 3270/LU0 - Message Filters screen to associate one or more filters with the request. You can access the Message Filters screen by selecting the Edit message filters option on the 3270/LU0 - Script Criteria screen.
3. On each filter entry, specify whether to include or exclude messages that match the filter. Each captured message is compared to all specified filters. The last matching filter takes precedence, so arrange the filters from the least to greatest priority.

4. Define a default action for messages that do not match any of the specified filters.
   Since the action is specified on the filter designation, rather than in the filter code, you can use the same filter to include specified activity in one request and exclude the same activity in another request.
   3270/LU0 - Message Filters screen

      -------------------------- 3270/LU0 - Message Filters --- MISSING REXX DATASET
      Command ===>                                                  Scroll ===> CSR
   
       Press END to save changes and return, or enter CANCEL to exit without
       saving changes.
   
       Message Filters:
         Default  . . . . INCLUDE  (Include or Exclude)
         Comments . . . . NO       (Yes, No, or Clear)
         REXX dataset . .
         Report dataset .
   
       Line commands are: (C)opy, (D)elete, (I)nsert, (M)ove or (R)epeat
   
              Type      Name      Parameters
       ****** **************************** Top of Data ******************************
       ==MSG> -Warning- The UNDO command is not available until you change
       ==MSG>           your edit profile using the command RECOVERY ON.
       000001 EXCLUDE
       ****** *************************** Bottom of Data ****************************

   Fill in the fields on this screen.

5. Default defines the action to take for messages that do not match any of the specified filters. Choose INCLUDE or EXCLUDE.

   Each captured message is compared to all of the specified filters. The action (include or exclude) defined by the type of the last matching filter is taken. For example, the first filter defined is an include filter and the second is an exclude filter. A message that matches both filters is excluded from the script because exclude was the last filter.

   If a message does not match any of the defined filters, the default action for that message is taken. For example, to create scripts containing only output screens that have PLAF on the first line, set the filter type to INCLUDE and set the default to EXCLUDE.

   IF (hs_exittype = 'OUTPUT') & (POS('PLAF',hs_output.1) > 0) THEN
      hs_match = 1
   ELSE
      hs_match = 0

   To include all messages except output screens with PLAF on the first line, use the same filter, but set the filter type to EXCLUDE and the default to INCLUDE.

6. Comments defines if and how excluded messages appear in the script. Enter:
   • YES to make the excluded messages comment lines. If you later wish to include a specific transaction that was initially excluded, remove the comment indicators.
   • NO to replace excluded messages with a single comment line that indicates the type of message, the name of the filter applied, and the date and time that filtering occurred.
     For example:
     * INPUT group excluded by PLAF 02/23/07 at 11:52:44
   • CLEAR to exclude the messages altogether.
7. Enter the REXX dataset — the data set containing the REXX filters. Do not include a member name. Script Create prefixes partially qualified data set names with your TSO prefix or user ID, depending on your TSO profile.
8. Enter the Report data set — the sequential data set or PDS member in which Script Create writes a summary report. Leave the field blank if you do not want a report. If the specified data set exists, Script Create overwrites any information it contains. If it does not exist, Script Create allocates it at report creation time.
   Script Create prefixes partially qualified data set names with your TSO prefix or user ID depending on your TSO profile.

9. Define a filter entry for each filter you want to apply to the given request. Complete the following fields for each filter.

   • Type — The action to take when a message matches the given filter. Enter I to include or E to exclude messages that match the filter. See step 5 for additional information about when to use INCLUDE or EXCLUDE.
   • Name — The member name containing the filter code.
   • Parameters — The value assigned to the hs_parm variable within the REXX filter code. This tag is required only if the REXX filter code includes hs_parm.

   Warning

   Important

   If the filter parses hs_parm, you can pass a string of values to the filter.

10. Press End to return to the 3270/LU0 Script Criteria screen.

Monitoring and managing existing requests

After you create a Global Recording request, the Monitor Requests option displays a screen that lists the existing requests. Active requests are highlighted. With only read access, the Monitor Requests screen is displayed in view-only mode with no available line commands.

Use this screen to:

• Stop recording
• Add, delete, or update a request
• Force a request
• Restart an inactive request
• Disable a request to prevent it from automatically restarting
• View the sessions being captured
• Switch the repository segment so that you can review captured activity without interrupting recording.

1. To access the Global Recording - Monitor Requests screen, type 1 on the Option line of the Global Recording menu and press Enter.
2. Position the cursor in the S column next to the desired request.

3. Type the appropriate line command and press Enter.
   Global Recording - Monitor Requests screen

      --------------------- Global Recording - Monitor 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,(V)iew,  (1)Add 3270,(2)Add APPC, or
                         (9)Switch repositories
   
         LU   Side-A/  Side-B/            Repository
      S  Type Applid   Terminal Userid    Dataset                               Users
      -  ---- -------- -------- --------  ------------------------------------- ----
         3270 *        *        *        *PMIJSS0.EXAMPLE.REPOS201                 0
      ******************************* BOTTOM OF DATA ********************************

Line commands

(C)ancel

Cancels and deletes the request and all buffered information. This may result in partially recorded business transactions. To avoid losing important data, first STOP the request. Wait for recording to terminate before issuing the CANCEL command.

Use ISPF file management tools to delete any repository or repository segments created by the request.

(F)orce

Terminates all sessions, which includes any in-flight session processing. However, the global capture buffers will be flushed to ensure that all activity captured prior to issuing the (F)orce command will be recorded appropriately.

If script criteria is specified within the request, script creation begins immediately.

(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 STOP is issued.

(R)estart

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.

(D)isable

Disables the request. All requests, except disabled requests, are restarted when the Global Recording started task is brought up. An asterisk (*) appears to the left of the repository data set indicating that the request is disabled.

STOP or FORCE the request and wait for the request to terminate prior to disabling it.

(S)elect

Displays the Active Sessions screen, which lists all 3270/LU0 sessions being recorded.

(U)pdate

Displays request information for update. Recording must be terminated and the request must be inactive. Issue STOP or FORCE to terminate recording and deactivate the request. After you finish editing, issue RESTART to reactivate the request.

(V)iew

Displays request information.

(1) Add 3270

Adds a new 3270 or LU0 Global Recording request. See Creating a Global Recording Request for more information.

(2) Add APPC

Adds a new APPC Global Recording request. This option is explained in the  Performance Test for Mainframe Servers User Guide.

(9) Switch Repositories

Closes the repository segment that is currently being written and opens the next segment. If you did not specify a wildcard character in the Repository Dataset field, this option is not available. This command will fail if the current repository has not yet been opened.

View active sessions

The Active Sessions screen shows a list of all sessions currently being recorded for a given request. If it is a capture by userid request, the list will also include sessions where the userid is currently unknown (for example, the user is not logged on).

1. To access this screen, type S (select) next to the appropriate request on the Monitor Requests screen and press Enter.
2. Press End to return to the Monitor Requests screen.

 Global Recording - Active Sessions screen

The information that appears on this screen includes:

• The Terminal ID of the terminal associated with the given session.
• The Application ID of the application associated with the given session.
• The Userid ID of the user being recorded.
• The time that the user logged on or the time the first transaction was recorded for the given session. It represents statistics for the VTAM session across all global recording requests.

• The last time Global Recording flushed and processed the captured information from the global capture buffers. This indicates the age of the counts displayed in the Trans and Lost fields. It represents statistics for the VTAM session across all global recording requests.

  Warning

  Important

  If this field indicates a significant lag, or sessions are being recorded that do not appear on this screen, contact your MVS Systems Programmer. The Performance Test Advanced-Configuration-Guide provides instructions for optimizing Global Recording performance.

• The Trans column shows the number of inbound and outbound VTAM data streams (transactions) that were recorded for the given session. It represents statistics for the VTAM session across all global recording requests.

• The Lost column shows the number of transactions (PIUs) lost. Slow processing or full buffers can result in lost messages. It represents statistics for the VTAM session across all global recording requests.

  Warning

  Important

  If this field reports lost messages, your MVS Systems Programmer may need to adjust the Global Recording buffers to optimize performance as described in the Performance Test Advanced Configuration Guide.

 Reviewing Repositories and creating scripts

You can use the Review Repository option to review the sessions captured in a given repository and to generate scripts. You can create scripts from selected sessions or from all sessions in the repository.

To use the Review Repository option:

1. On the Option line of the Global Recording Menu, type 2 for Review Repository and press Enter. The Review Repository - Dataset List screen appears.

2. Type the name of the repository data set from which you want to review or create scripts in the corresponding field if the desired repository data set does not appear in the data set list or if you want to apply temporary script creation criteria. Otherwise, select it from the list. If you enter the repository name in this field, as opposed to selecting it from the list, the script criteria you provide is discarded after script creation. If you select it from the list, the script criteria is saved in the associated Global Recording request.

   • On the Repository dataset field, type the data set name.

     • If the data set name includes wildcard characters, enter the first and last wildcard value to use for selecting the applicable segments and press Enter.
       For example, entering MY.DATASET.CAP?? with values 1 and 5, selects segments CAP01 through CAP05.

       Warning

       Important

       The First and last number fields are required if you specify a repository name containing wildcard characters in the Repository dataset field.

     • If the data set name does not include wildcard characters, press Enter.
   • To select the data set name from the list, use one of the following options:
     • UP and DOWN keys to scroll the list.
     • FIND primary command. The cursor moves to the first instance containing the specified FIND string. Press the RFIND key to find the next instance.

     • Type S next to the selected repository and press Enter.

       Warning

       Important

       You can select multiple repositories. Review Repository displays the appropriate screens for each selection.

   The Review Repository - Processing Options prompt appears.

3. Select the type of script to generate or review:
   • Type 1 to generate 3270 or LU0 scripts for all of the sessions captured in the selected repository. See Generate Scripts from a Selected Repository for information.
   • Type 2 to generate APPC scripts for all of the sessions captured in the selected repository. Refer to the Performance Test for Mainframe Servers User Guide for information on this option.
   • Leave the selection field blank to display a list of all sessions captured in the selected repository. Use this option to review repository contents, generate scripts from selected sessions, and review or modify script creation criteria. See Generate Scripts from Selected Sessions for information.

4. Press Enter to continue.

   Warning

   Important

   To review or modify existing script creation criteria, leave the field blank even if you intend to generate scripts from all of the captured sessions. The Session List screen allows you to review and modify script criteria.

    Review Repository - Dataset List screen

      ----------------------- Review Repository - Dataset List ---------- Row 1 of 3
      Command ===>                                                  Scroll ===> PAGE
   
      Specify a repository dataset name or select a repository from the list
      below and press ENTER to process it, or END to return.
   
      Repository dataset . . .
      First and last number. .                 (If wildcard in dataset)
   
      Line commands are: (S)elect
   
      S  Repository datasets                          Volser Referred Type Owner
      -  -------------------------------------------- ------ -------- ---- --------
         PMIJSS0.EXAMPLE.REPOS*                       SMS925 02/28/23 3270 PMIJSS0
         PMIJSS0.EXAMPLE.REPOS2*                      SMS925 02/28/23 3270 PMIJSS0
         PMIJSS0.SCRIPTC.REPOS*                       SMS926 01/25/23 3270 PMIJSS0
      ******************************* BOTTOM OF DATA ********************************

   The Repository datasets list is a list of all of the 3270/LU0 and APPC repositories you have created. In administrator mode, the list shows repositories created by all users on the system. If you select a repository from the list, any script creation criteria you supply is saved in the associated Global Recording request if you own the repository.
   Volser is the serial number of the volume on which the given repository is stored. This field shows MIGRAT for migrated data sets.
   Referred is the MVS reference date associated with the repository data set indicating the last time the data set was modified.Type specifies the repository data set type (3270 or APPC).
   Owner is the ID of the user who created the request associated with the repository data set. This field primarily supports administrator access to Global Recording. See Accessing Global Recording Administration.

 Generate scripts from a selected repository

This section describes the screens that appear if you select 1. Record ALL 3270 sessions (see the Review Repository - Processing Options prompt).

 Review Repository - Processing Options Prompt

The 3270/LU0 - Script Criteria screen appears if:

• No script creation criteria is defined. If you selected the repository data set name from the list on the Review Repository - Dataset List screen, the criteria you specified is saved in the associated Global Recording request.
• You entered a repository data set name in the corresponding field on the Review Repository - Dataset List screen. The script criteria you specified is discarded after the scripts are generated.

See Define Script Creation Criteria.

Otherwise, the Script Processing screen appears. The cursor starts in the Select processing option field.

 Script Processing screen

1. Enter 1 for background processing or 2 for foreground processing. The cursor automatically advances to the job statement area of the screen.
2. If you selected background processing, enter job statement information and press Enter. If you selected foreground processing, messages are sent to your TSO session.
   Depending on your selection, Review Repository either submits the job or initiates processing.
3. Press Enter to clear the messages and return to the Review Repository - Dataset List screen.

 Generate scripts from selected sessions

This section describes the screens that appear if you choose to review the sessions captured in the repository and generate scripts from selected sessions.

Review Repository processes the repository data set to create the list of sessions. It displays a processing status message that disappears when processing is complete. The length of time the message displays depends on the repository size. You can interrupt session processing by pressing the ATTN key.

After the processing message disappears, the Review Repository - Session List screen appears.

 Review Repository - Session List screen

See the online help for a description of the primary commands available on this screen.

1. If you want to review the script criteria before generating a script, enter a slash in the Review script create criteria field. The Script Criteria screen appears showing the existing script creation criteria.

   Warning

   Important

   If you entered the repository data set name in the corresponding field on the Dataset List screen, your script criteria changes are discarded after the scripts are created. If you selected it from the list, your changes are saved in the associated Global Recording request.

2. The (R)ecord line command generates a script from the selected session. In the S column, enter an R next to the sessions you want to script. Sessions selected for recording will be highlighted when scrolling the Session list.
   The lower portion of this screen shows the LU Type (3270 or APPC), Applid/Side-A, Termid/Side-B (LU name of the terminal accessing the application), Userid (an asterisk (*) to the left of the user ID indicates that multiple users signed on to this particular session while the session was logged on to VTAM), and Start Date and Time (date and time that Global Recording started capturing this session).

3. After you finish selecting sessions, press Enter.
   Review Repository displays the 3270/LU0 - Script Criteria screen if:

   • No script creation criteria is defined within the associated Global Recording request.
   • You entered the repository data set name in the corresponding field on the Dataset List screen.
   • You selected the Review script create criteria field on the Session List screen. See Define Script Creation Criteria.

   Warning

   Important

   The criteria you specify may be saved in the associated Global Recording request depending on how you selected the repository on the Dataset List screen. If you entered it at the top of the screen, the criteria is discarded after script creation is complete. If you selected it from the list, it is saved in the associated Global Recording request.

   If none of the above are true, the Script Processing screen appears. The cursor starts in the Select processing option field.

4. Enter 1 for background processing or 2 for foreground processing. The cursor automatically advances to the job statement area of the screen.
5. If you selected background processing, enter job statement information.
6. Press Enter. Depending on your selection, Review Repository either submits the job or initiates processing. If you selected foreground processing, messages are sent to your TSO session.
7. Press Enter to clear the messages and return to the Review Repository screen.

Defining Global recording manager lists

Within a Global Recording request, you either specify the terminals, applications, and user IDs to capture, or you specify a Global Recording Manager List. A Global Recording Manager List defines the terminals, applications, and user IDs to record or exclude from recording.

Use Global Recording Manager Lists to save time and work. For example, if the users you need to record do not have similar user IDs, you can either create a separate request for each user ID or you can define a Global Recording Manager List and create a request that uses that list.

The Global Recording Manager List screen displays lists created by all users on the system. You can use or copy any existing list, but you can edit and delete only the lists you create unless you have Global Recording administrator authority.

To use the Global Recording Manager:

1. On the Option line of the Global Recording menu, type 3 to select the Global Record Manager option and press Enter.
   Global Recording menu

      ------------------------------- Global Recording ------------------------------
      Option  ===>
   
      SNA (3270, LU0, APPC)
         1  Monitor Requests          Add, Review or Update your requests
         2  Review Repository         Review your captured sessions
         3  Global Record Manager     Manage Include/Exclude filter lists
   
      TCP/IP
         6  Monitor TCP/IP Requests   Add/Review your TCP/IP recording requests
         7  Create TCP/IP Scripts     Create TCP/IP scripts from a repository
   
   
            Enter END command to return to Performance Test for VTAM Main Menu.

   1. The Global Record Manager * Include/Exclude Lists screen appears. It displays a list of existing Include/Exclude lists.
      Global Record Manager * Include/Exclude Lists screen

      ---------------- Global Record Manager * Include/Exclude Lists ---- Row 1 of 6
       COMMAND ===>                                                  SCROLL ===> PAGE
      
       Line Commands:   A - Add     B - Browse    C - Copy    D - Delete    E- Edit
      
      
          Name      Type  Description                                        Creator
      
          CAPTURE2   IN                                                      USER25
          CHRISP     IN   CHRIS P. INCLUDE LIST                              HDACCP0
          CHRISP2    EX   THIS CAPTURES EVERYTHING BUT MY ID                 HDACCP0
          DANMIC     IN   LIST FRANCE                                        BFRMXA0
          DDDDDDDD   EX                                                      USER25
          FEDEX1     IN   GLOBALLY RECORD ONLY 5 USERS BY USERID             HDACCP0

       

2. To create a new list, position the cursor in the selection column on any of the existing list entries. Type A (add) and press Enter. See Create a New Global Recording Manager List for more information.

3. To browse, copy, edit, or delete a list, type the applicable line command in the selection column of the appropriate list and press Enter. Use primary commands to locate the desired list.

   • (A)dd displays the Add List screen. See Create a New Global Recording Manager List for more information.
   • (B)rowse displays the include/exclude list for browsing.
   • (C)opy displays the Copy List screen. See Copy an Existing Global Recording Manager List for more information.
   • (D)elete deletes the selected list. You can delete any list that you created as long as it is not currently in use by an active Global Recording request. Global Recording Manager prompts you for confirmation. Press End to delete the selected list. To exit the screen without deleting the list, type CANCEL on the command line and press Enter.
   • (E)dit displays the Edit List screen. This screen contains the same fields as the Add List screen. Modify any field except List Name, List Type, and Description, which are display-only fields.

   You can edit any list you create. If you edit a list that is currently in use by an active Global Recording request, the request is not affected. It continues to capture with the parameters of the original list. Stop and restart the request to apply your changes to an active request.
   Type specifies the type of list. IN indicates an include list. EX indicates an exclude list. Creator contains the TSO ID of the user who created the list.

 Create a new Global Recording Manager List

The Add List screen appears after you issue the A (add) line command on the Global Record Manager * Include/Exclude List screen.

 Global Record Manager * Add List Screen

1. Type the List Name of the Global Recording Manager List. Enter up to eight characters.
2. Specify the Global Recording Manager List Type (include or exclude). Enter IN to capture only the specified terminals, applications, and/or users. Enter EX to capture all activity except the specified terminals, applications, and/or users.
3. Enter an optional Description for the list. Enter up to 55 characters.

4. Term is the logical unit name of the terminal to record or exclude from recording. Enter one of the following:

   • A specific terminal ID.
   • An asterisk (*) to select all terminals.
   • A terminal prefix followed by an asterisk to select a group of terminals. For example, H8606* selects all terminals beginning with H8606.

   If you leave this field empty, but supply a value in the Appl or Userid fields on the same line, Global Record Manager inserts an asterisk when you save the list. This field holds eight characters. Press Tab to advance to the next field.

5. Appl is the ID of the application to record or exclude from recording. Enter one of the following:

   • A specific application ID.
   • An asterisk (*) to select all applications.
   • An application name prefix followed by an asterisk to select a group of similar applications. For example, to select all applications that have names beginning with CICS, enter CICS*.

   If you leave this field empty, but supply a value in the Term or Userid fields on the same line, Global Record Manager inserts an asterisk when you save the list. This field holds eight characters. Press Tab to advance to the next field.

6. Userid is the ID of the user to record or exclude from recording. Enter one of the following:

   • A specific user ID.
   • An asterisk (*) to select all users.
   • A user ID prefix followed by an asterisk to select a group of users. For example, USER* selects all user IDs beginning with USER.

   If you leave this field empty, but supply a value in the Term or Appl fields on the same line, Global Record Manager inserts an asterisk when you save the list. This field holds eight characters. Press Tab to advance the cursor.

7. Press END to continue or type CANCEL on the Command line and press Enter to exit the screen without saving the list.

 Copy an existing Global Recording Manager List

Copy an existing list to save time when creating a new list and to ensure full control over the lists you use. Although you can use Global Recording Manager Lists created by other users, you cannot edit or delete lists created by another user.

1. The Copy List screen appears after you issue the C (copy) line command on the Global Record Manager * Include/Exclude List screen.
   Global Record Manager * Copy List screen

   ---------------------- Global Record Manager * Copy List ----------------------
    COMMAND ===>
   
   
       From Name  QAGROUP1
       From Type  IN
       From Description  INCLUDE LIST_FOR QAGROUP1
   
   
   
   
       To Name  QAGROUP2
       To Type  IN
       To Description  INCLUDE LIST_FOR QAGROUP2
   
   
   
   
   
       Press END to copy and exit,  CANCEL to exit without copying

   From Name, From Type (IN indicates an include list and EX indicates an exclude list), and From Description are prefilled with the name, type, and description of the list being copied.

2. Enter a name for the new list, in the To Name field. This field holds up to eight characters.
3. Enter the type for the new list (IN or EX) in the To Type field. Enter IN to record the terminal, applications, and user IDs specified within the list. Enter EX to record all activity except for the terminals, applications, and user IDs specified within the list.
4. Enter a description, up to 55 characters, for the new list.
5. Press End to continue or type CANCEL on the Command line and press Enter to exit the screen without saving the list.

 Accessing Global Recording administration

Global Recording Administration provides:

• Access to all recording requests on the system
• Access to all capture repositories created by the requests on the system
• Authority to edit and delete any Global Recording Manager list

To access Global Recording Administration, type ADMIN on the Option line of the Global Recording menu and press Enter. The word “Administration” appears after the menu title.

The Global Recording options behave the same in administration mode, except the Monitor Request screen shows all of the requests on the system, the Review Repository option lists the repositories created by all of the requests on the system, and the Global Recording Manager allows you to edit and delete lists created by any user on the system.

Using the Global Recording batch interface

Performance Test for VTAM provides a batch interface for Global Recording. Use it 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.

The Global Recording batch interface also provides a script creation function. Set up the recording request to initiate script creation when the request ends or suspend script creation and schedule it to run at a later time. For example, if you are recording large volumes of traffic, schedule a job to create scripts in the evening when more system resources are available.

 Create a Global Recording request

Global Recording writes captured activity to a specified data set or range of data sets called a capture file or a repository. Testing scripts are generated from the capture repository. Global Recording can initiate script creation at the end of the recording request or you can initiate it later with a separate job (see Create Scripts) or with the Review Repository option in the online interface see (Reviewing Repositories and Creating Scripts). For example, capture an entire day’s activity and generate scripts in the evening when more system resources are available, or use Review Repository to generate scripts from selected sessions.

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 request parameters. Parameters are defined in extensible markup language (XML). The batch interface’s XML parser provides limited syntax support. Review Global Recording Request Parameter Syntax 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.
2. Use SQQFSAMP member DCIJCL (see DCIJCL — Sample JCL to Add or Manage Requests figure) to execute the ADD request function.
   1. Insert job statement information at the top of the sample.
   2. Ensure the UPROCS statement points to the procedures library that contains DCIPROC.

   3. 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). The key is written to the location specified on the FEEDBACK DD. To save the key in your personal library, specify a sequential data set, PDS(E) and member, or a generation data group (GDG).

      Warning

      Important

      Allocate the data set or GDG with a fixed-block record format and an 80-byte record length.

   4. On the SYSTSIN DD statement, specify ADD on the PARM keyword.

   5. On the SYSIN DD statement, either supply the name of the data set containing the request parameters or enter the parameters in-line.

      Warning

      Important

      In-stream parameters cannot exceed 80 bytes. If you edit the parameters on a PC and copy them back to a data set that now exceeds 80 bytes, point the DD to the data set rather than pasting the parameters into the job.

3. Schedule or submit the job.
   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.QQF800.SQQFSAMP')            <-REVIEW
   //DCI     EXEC PROC=DCIPROC
   //FEEDBACK DD *
   //SYSTSIN  DD *
     ISPSTART PGM(QACDCIP) PARM(ADD)                              <-REVIEW
   /*
   //SYSIN    DD  DISP=SHR,DSN=COMPWARE.QQF800.SQQFSAMP(DCIADDL2) <-REVIEW
   ******************************** Bottom of Data ********************************

    

 Global Recording request parameter syntax

Global Recording request parameters are defined in XML. Write the parameters from scratch, or start with a sample or generated parameter set. Store the parameters in a data set or paste them right into the JCL. Use a standard file editing tool to modify the parameters.

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 backslash inside the angle brackets. For example:

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

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 terminal parameter example:

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. Subparameters must be nested within opening and closing parent parameter tags. For example:

Depending on the request you are creating, there may be several levels of nesting. For example, all of the 3270 Global Recording request parameters are subparameters of the <LU2> protocol parameter. The start and end time and date parameters are subparameters of Scheduled_Capture, which is a subparameter of the <LU2> protocol parameter. For example:

Indenting nested tags is not necessary; however, it makes editing much easier. In the samples and generated parameter sets, each nesting level 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. They must be followed by two dashes and a closing angle bracket. For example:

 Global Recording request parameters

Global Recording request parameters are defined in XML. For syntax rules, see Global Recording Request Parameter Syntax.

Start with one of the following:

• The parameters from an existing request. See Retrieve the Parameters of an Existing Request.
• A parameters skeleton. See Generate a Request Parameters Skeleton.
• SQQFSAMP member DCIADXL2: Contains all available 3270/LU0 Global Recording request parameters.
• SQQFSAMP member DCIADDL2: Contains a subset of commonly used 3270/LU0 recording request parameters.

Store the parameters in a sequential data set 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.

Sample DCIADXL2

This section provides an illustration of sample DCIADXL2 and defines all available 3270 /LU0 Global Recording request parameters. Parameter hierarchy is defined within the parameter definitions.

 Protocol Parameter Tag and General Request parameter tags

LU2

Identifies the type of Global Recording request to add. Also use this parameter for non-standard 3270 requests, such as LU0 requests. This is a parent tag to all other parameters described in this section. Begin and end the XML input stream with opening and closing LU2 tags (<LU2> and </LU2>).

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

Terminal

The logical unit name of the terminal to record. Supply one of the following:

• A specific terminal ID, up to eight characters.
• An asterisk (*) to select all terminals.
• A terminal prefix followed by an asterisk (*) to select a group of terminals. For example, H8606* selects all terminals beginning with H8606.

You must supply a Terminal, User_ID, or GR_Manager_List tag with a value other than blank.

Application

The ID of the application to record. Supply one of the following:

• A specific application’s ID, up to eight characters.
• An asterisk (*) to select all applications.
• An application name prefix followed by an asterisk (*) to select a group of applications. For example, CICS* selects all applications with names that begin with CICS.

This tag is optional. If you do not specify an application ID, all applications accessed by the specified terminal and/or user ID are recorded.

User_ID

The ID of the user to record. Enter one of the following:

• A specific user ID, up to eight characters.
• An asterisk (*) to select all users.
• A user ID prefix followed by an asterisk (*) to select a group of users. For example, USER* selects all user IDs beginning with USER.

You must supply a Terminal, User_ID, or GR_Manager_List tag with a value other than blank.

GR_Manager_List

The name of the Global Recording Manager list to use for this request. Save time by creating Global Recording Manager lists that specify terminals, applications, and user IDs to include or exclude from capture. See Defining Global Recording Manager Lists.

You must supply a Terminal, User_ID, or GR_Manager_List tag with a value other than blank. If you supply a GR_Manager_List tag, omit the Terminal, Application, and User_ID tags.

GR_Manager_List_2

The name of the Global Recording Manager list to use as the second filter for this request. If this list is specified, GR_Manager_List must also be specified. The list can be either an Include or Exclude list. If GR_Manager_List and GR_Manager_List_2 are the same, logically they are equivalent to one list. If they are different, GR_Manager_List_2 will be applied to the result of GR_Manager_List.

 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 the entire block of tags if you want capture to begin immediately and remain active indefinitely.

The following parameters are Scheduled_Capture subparameters. Supply the applicable parameters between the opening and closing Scheduled_Capture tags.

Start_Date

The date to activate the request. Specify a two-digit month, two-digit day, and four-digit year separated by 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 to activate the request. Specify a two-digit hour, two-digit minute, and 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, two-digit day, and four-digit year separated by 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).

If you set the Force_At_End_Time recording option to 'Y', an end time and date are required.

End_Time

The time to deactivate the request. Specify a two-digit hour, two-digit minute, and 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 the Reuse_Capture_File tag to set to 'NO'.

If you specify an end time, an end date is required.

If you set the Force_At_End_Time recording option to 'YES', an end time and date are required.

Capture File Parameter Tags

Capture_File

Defines the data set to use for storing the captured data.

The following parameters are Capture_File subparameters. Supply the applicable parameters between the opening and closing Capture_File tags.

Dataset

Specifies the data set name to use for storing captured information. This is a required parameter.

To create a segmented capture file, use either the asterisk (*) or question mark (?) wildcard characters in the data set name. Define a range for the wildcard characters with the First_Number and Last_Number tags:

• Asterisk (*): Inserts an incremental value into the data set name qualifier in which the asterisk appears. This wildcard pads the incremental value with enough zeros to ensure an eight-character qualifier. For example, USER.#3270.REC* with first=1 and last=3 creates capture data sets: 

  USER.#3270.REC00001
  USER.#3270.REC00002
  USER.#3270.REC00003

• Question mark (?): Inserts the incremental value into the qualifier where the question marks appear. Enter at least one question mark for each digit of the value supplied on the Last_Number tag. For example, USER.#3270.REC?? with first=9 and last=11 creates capture data sets:

  USER.#3270.REC09
  USER.#3270.REC10
  USER.#3270.REC11

First_Number

Defines the first value to use for wildcard characters specified on the Dataset tag. 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. 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 data set. Valid values are 'APPEND' or 'OVERWRITE'. This tag is unnecessary if the specified data set does not exist. If the specified data set does exist, and you do not provide an initial disposition value, the batch interface appends the new data to the existing data.

Allocation

Defines allocation parameters for the capture file data set. If you do not supply allocation parameters and the specified data set 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 subparameters.

Supply the applicable parameters between the opening and closing Allocation tags.

Management_Class

The management class to apply to the new data set. Your storage administration defines Management classes.

Storage_Class

The storage class to apply to the new data set. Your storage administration defines Storage classes. Use this tag to override the default value.

Volume_Serial

The serial number of the volume on which the data set will be stored.

Device_Type

The type of device on which the data set will be stored. It can be a generic unit such as 'SYSDA'.

Data_Class

The data class to apply to the new data set. Your storage administrator defines data classes.

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

Primary_Quantity

The number of space units to allocate initially. After 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 data set.

Recording Option Parameter Tags

Recording_Options

Defines recording request actions.

The following parameters are Recording_Options subparameters. Supply the applicable parameters between the opening and closing Recording_Options tags.

Suspend_Script_Create

Suspends script creation. Supply this tag with a value of:

• 'YES' to create scripts later.
• 'NO' to automatically initiate script creation when the recording request ends. Be sure to supply script creation criteria.

If you omit this tag, the batch interface suspends script creation.

Reuse_Capture_File

This parameter applies only to segmented capture files. 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.

Force_At_End_Time

Issues a FORCE command at the end time specified in the request. FORCE terminates all recording sessions including in-flight sessions. Script creation begins immediately, unless you chose to suspend script creation. Be aware that you may lose buffered data resulting in partially recorded sessions.

To enable this option, supply this tag with a value of 'YES'. Be sure to supply a Scheduled_Capture tag with End_Time and End_Date values.

If you omit this tag or supply it with a value of 'NO', Global Recording issues a STOP command at the request’s specified end time. It stops recording new sessions, but continues to record all in-flight sessions. After all in-flight sessions end, recording terminates and script creation begins unless you chose to suspend script creation. This option ensures complete session captures, but it may delay script creation.

Event_Notification

Defines the type of messages sent to your TSO session. Supply a value of:

• 'ERROR' to receive error messages only.
• YES' to receive status and error messages.
• 'NONE' to disable event notification.

If you are recording a large number of sessions, consider disabling this option or selecting error notification to reduce the number of messages you receive. If you omit this tag, Global Recording sends all recording and script creation messages.

Record_From_Logon_Only

Begins recording upon logon if all other request criteria are met. If you specify a time frame for the request, recording begins only if the logon occurs during the specified time frame.

This option is enabled by default.

Supply this tag with a value of 'NO' to initiate recording as soon as the request criteria are met. Since recording can begin while sessions are in flight, you may need to edit the scripts to delete any partially recorded business transactions.

General Script Criteria Tags

If you supply the Suspend_Script_Create tag with a value of 'NO', script creation criteria is required.

Script_Criteria

Defines script creation parameters. The rest of the parameters described in the section (Description, Script_File, and Script_Create_Options) are all subparameters of this tag. Supply the applicable parameters between opening and closing Script_Criteria tags.

Description

A string of up to 55 characters that appears in the header section of the script.

Script File Tags

Script_File

The batch interface writes each script to a separate member of a PDS or PDSE. This block of tags defines the attributes of the PDS(E).

The following parameters are Script_File subparameters. Supply the applicable parameters between the opening and closing Script_File tags.

Dataset

The PDS(E) to contain the scripts. This is a required parameter. It accepts up to 44 characters.

Member_Prefix

A one- to six-character prefix that, in conjunction with the member suffix, forms the member name for each script created. This is a required parameter.

Member_Suffix

A numeric value that, in conjunction with the member prefix, forms the member name for each script created. The batch interface increments this value each time it creates a new script. Supply a suffix that in combination with the prefix equals eight characters.

• If you supply a suffix that is too short, the batch interface pads the suffix with zeros to the left. For example, if the prefix is OES and the suffix is 10, the first script member name is OES00010, and the next member is OES00011.
• If you supply a suffix that is too long, the batch interface truncates the digits on the left. For example, if you enter SCRIPT for the prefix and 1234 for the suffix, the first script member is SCRIPT34, and the next member is SCRIPT35.

This is a required parameter. It accepts up to seven digits.

Replace_Members

Overwrites existing members that have the same names as specified with the Dataset, Member_Prefix and Member_Suffix tags.

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', the batch interface does not overwrite existing members.

Session_Log_Member

A one- to eight-character member name to hold the session log. A session log contains an entry for each session, thus each script, created. Session logs contain the bulk of the input required for an Unattended Playback job. Save time preparing the job by starting with the session log. See Unattended-Playback-Dubbing-and-Comparison-for-3270-and-LU0-Scripts-VTAM to learn about playback statements you may need to add or modify.

Omit this tag if you do not need a session log.

Allocation

Defines allocation parameters for the script file data set. If you do not supply allocation parameters and the specified data set 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 subparameters.

Supply the applicable parameters between the opening and closing Allocation tags.

Management_Class

The management class to apply to the new data set. Your storage administrator defines Management classes.

Storage_Class

The storage class to apply to the new data set. Your storage administrator defines Storage classes.

Volume_Serial

The serial number of the volume on which the data set will be stored.

Device_Type

The type of device on which the data set will be stored. Can be a generic unit such as 'SYSDA'.

Data_Class

The data class to apply to the new data set. Your storage administrator defines Data classes.

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

Primary_Quantity

The number of space units to allocate initially. After 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.

Directory_Blocks

The number of blocks to use for a PDS directory. If the data set is a PDSE, the batch interface ignores this value.

Block_Size

The maximum length, in bytes, of the blocks of data that the system reads in as it processes a data set.

Record_Length

The maximum length, in bytes, provided for each record in the data set. Script data sets must be minimally 256 bytes. The record length must be at least four less than the block size.

Dataset_Name_Type

The type of data set to contain the scripts. Supply this tag with a value of 'PDS' or 'LIBRARY' (PDSE). If you omit this tag, the batch interface allocates the script file as a PDS.

 Script Create Option Tags

Script_Create_Options

Defines the format and contents of the scripts.

The following are Script_Create_Options subparameters. Supply the applicable parameters between the opening and closing Script_Create_Options tags.

Format_The_Recording

Applies a human-readable format to the scripts. Unformatted scripts contain hexadecimal data streams. If you are working with non-standard 3270 data streams, such as LU0, supply this tag with a value of 'NO'.

If you omit this tag or supply it with a value of 'YES', the scripts are formatted.

Record_Inputs_Only

Creates scripts that contain only user input keystrokes.

This option primarily supports stress testing, where recorded and actual output screen comparison is not required. You can also use it to create scripts for dubbing baseline scripts. For example, play back an inputs only script, with dubbing active, against the production version of the software to create a baseline script. Then play back the baseline script against the application you are testing to validate its responses.

To enable this option, supply this tag with a value of 'YES'. If you omit this tag, the batch interface generates the scripts with both the user input keystrokes and the resulting output screen images.

Row_Column_Format

Creates scripts containing input tags in (row,column) format as opposed to the standard relative input format. For example, in standard format the first input tag is:

In row,column format, the same input tag contains the position of the input field:

Correlating input data with the fields on the screen images contained in the script is easier if the input tag provides coordinates. Consider selecting this option if you intend to review the script for debugging or audit purposes. However, scripts in this format are not compatible with the Performance Test for VTAM’s script processors.

To enable this option, supply this tag with a value of 'YES'. If you omit this tag, the batch interface generates the scripts in standard relative input format.

Use_Message_Filters

Enables the use of message filters when creating scripts. Supply this tag with a value of 'YES', then use the Message_Filters block of tags to designate one or more filters.

 Message Filter Tags

Message_Filters

Designates the message filters to use for script creation and defines how to handle excluded messages.

The following parameters are Message_Filters subparameters. Supply the applicable parameters between the opening and closing Message_Filters tags.

Default

Defines the action to take for messages that do not match any of the specified filters. If you supply a Message_Filters tag, this parameter is required. Valid values are 'INCLUDE' or 'EXCLUDE'.

Each captured message is compared to all of the specified filters. The action defined by the Type of the last matching filter is taken. For example, the first filter is an “INCLUDE” filter and the second is an “EXCLUDE” filter. A message that matches both filters is excluded from the script.

If a message does not match any of the defined filters, the Default action is taken for that message. For example, to create scripts containing only output screens with PLAF on the first line, create the following filter. Set the filter type to INCLUDE. Set the Default to EXCLUDE.

To include all messages except output screens with PLAF on the first line, use the same filter, but set the filter type to EXCLUDE and the Default to INCLUDE.

Comments

Defines if and how excluded messages appear in the script. Supply this tag with a value of:

• 'YES' to change the excluded messages to comment lines. To include a specific transaction that was initially excluded, remove the comment indicator before playback.
• 'NO' to replace the excluded messages with a single comment line that indicates the message type, the name of the filter applied, and the date and time that filtering occurred. For example,

• 'CLEAR' to exclude the messages altogether.

If you omit this tag, the unwanted messages are replaced with a single comment line.

REXX_Dataset

The data set containing the REXX filter members. Supply a fully qualified data set name, but do not include a member name. If you supply a Message_Filters tag, this tag is required.

Report_Log_Dataset

The fully qualified sequential data set or PDS(E) in which the batch interface writes a filtering summary report. If you supply a PDS(E), specify a member with the Report_Log_Member tag.

If the specified data set:

• exists, the batch interface overwrites any information it contains.
• does not exist, the batch interface allocates it at report creation time.

If you do not want a summary report, omit this tag.

Report_Log_Member

The member in which the batch interfaces writes a summary report. This tag is required if you supply a PDS on the Report_Log_Dataset tag.

Filter Record="x"

Designates a filter to use for script creation. Supply the tag with a filter number enclosed in double quotation marks. For example, <Filter Record="1">. The last matching filter takes precedence, so list the filters from least to greatest priority. For example, if the first filter is an “include” filter and the second filter is an “exclude” filter, a message matching both filters is excluded from the script.

Provide this block of parameters for each filter designation.

The following parameters are Filter Record="x" subparameters. Nest the applicable subparameters between an opening <Filter Record="x"> tag and a closing </Filter> tag.

Type

The action to take when a message matches the filter. Supply a value of 'INCLUDE' or 'EXCLUDE'. This tag is required. See the description of the Default parameter for more details.

Name

The name of the member containing the filter code. This tag is required.

Parameters

The value assigned to the hs_parm variable within the REXX filter code. This tag is required only if the REXX filter code includes hs_parm.

 Check the Status of Existing Requests

Use the KEYS function to:

• Check the status of a specific Global Recording request.
• Generate status information for all of your existing Global Recording requests. 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 will record. LU2 indicates a 3270 or LU0 recording request.
• Status — The status of the request (Stopped, Active, or Disabled).
• Request ID — The six-byte ID assigned to the request.
• Capture File — The 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 (see the DCIJCL — Sample JCL to Add or Manage Requests figure) to execute the KEYS function.

1. Insert job statement information at the top of the sample.
2. Ensure 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 keys in your personal library, specify a sequential data set, PDS(E) and member, or a generation data group (GDG).

   Warning

   Important

   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 statement, either supply the name of the data set containing the request key or enter the parameters in-line. For example:

     // SYSIN DD *
        <LU2>
         <Request_ID>     C'QA_REQ’
         </Request_ID>
         <Capture_File>
          <Dataset>     ‘USER25.#3270.QA.REC??’
          </Dataset>
         </Capture_File>
        </LU2>

     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 existing 3270 and LU0 requests that you created, the KEYS function requires the protocol parameter. For example:

     // SYSIN DD *
        <LU2>
        </LU2>
6. Submit the job.

 Manage existing requests

Use the batch interface request management functions to:

• Stop recording
• Cancels and deletes a request
• Force a request
• Restart a deactivated 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.

Use SQQFSAMP member DCIJCL (see the DCIJCL — Sample JCL to Add or Manage Requests figure) to execute request management functions.

1. Insert job statement information at the top of the sample.
2. Ensure the UPROCS statement points to the procedures library that contains DCIPROC.

3. On the SYSTSIN DD statement, specify one of the following request management functions on the PARM keyword:

   Keyword	Description
   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 first. 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 in-flight sessions, use STOP instead. If a request contains script criteria and the suspend script creation option is not selected, script creation begins immediately. Warning Important If the request specifies segmented repositories, the Force command will cause an automatic switch to a new segment.
   STOP	Stops capture of new sessions and deactivates the request. Global Recording continues to capture all sessions that are in-flight at the time STOP is issued.
   RESTART	Restarts the request. On requests with a start/end time, the request becomes active as soon as the time frame specified within the request is met. Use this option to activate an inactive request. Warning Important The initial option selected when the request was added, to either OVERWRITE or APPEND, will be used for the restart on the repository file.
   DISABLE	Disables the request. When the Global Recording started task is brought up, all requests, except disabled requests, are restarted. Warning Important STOP or FORCE the request prior to disabling it.
   SWITCH	Closes the capture file segment that is currently being written and opens the next segment. This option is available only if the capture file data set 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 statement, either supply the name of the data set containing the request key or enter the parameters in-line. For example:

   // SYSIN DD *
      <LU2>
       <Request_ID>     C'QA_REQ’
       </Request_ID>
       <Capture_File>
         <Dataset>    ‘USER25.#3270.QA.REC??’
        </Dataset>
       </Capture_File>
      </LU2>

5. Submit the job.

   Warning

   Important

   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 the Parameters of an Existing Request.
   2. Modify the parameters. See Global Recording Request Parameters for parameter definitions.
   3. Use STOP, FORCE, or CANCEL 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 step c through step e as separate jobs or separate steps within a single job.

 Retrieve the parameters of 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 to be updated.
  • Modify the parameters.
  • STOP the request.
  • CANCEL the request.
  • ADD a new request using the modified parameters.

  Warning

  Important

  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 containing a complete set of parameters with default values.

Use SQQFSAMP member DCIJCL (see the DCIJCL — Sample JCL to Add or Manage Requests figure) to execute the VIEW function.

1. Insert job statement information at the top of the sample.
2. Ensure the UPROCS statement points to the procedures library that contains 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 data set, PDS(E) and member, or a generation data group (GDG).

   Warning

   Important

   Allocate the GDG with a fixed block record format and an 80-byte record 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 statement, either supply the name of the data set containing the request key or enter the parameters in-line. For example:

   // SYSIN DD *
      <LU2>
      <Request_ID>      C'QA_REQ’
      </Request_ID>
        <Capture_File>
        <Dataset>     ‘USER25.#3270.QA.REC??’
        </Dataset>
      </Capture_File>
     </LU2>
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 containing 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 (see the DCIJCL — Sample JCL to Add or Manage Requests figure) to execute the VIEW function.

1. Insert job statement information at the top of the sample.
2. Ensure the UPROCS statement points to the procedures library that contains 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 data set, PDS(E) and member, or a generation data group (GDG).

   Warning

   Important

   Allocate the GDG with a fixed block record format and an 80-byte record length.

4. On the SYSTSIN DD statement, specify VIEW on the PARM keyword.

5. On the SYSIN DD statement, supply the opening and closing protocol tags for the type of request you want to create. For 3270 or LU0 requests:

   // SYSIN DD *
      <LU2>
      </LU2>

 Create scripts

To maximize flexibility, the batch interface provides script create function.

• Generate scripts at any time. For example, if you are unsure of script creation criteria when you create the recording request, suspend script creation and run it later.
• Schedule script creation to run when maximum system resources are available. For example, if you are recording large volumes of traffic, schedule a script creation job to run in the evening.
• Create scripts with parameters other than those specified in the recording request. For example, the script criteria in the recording request are set up to generate stress testing scripts. However, you also need to generate unit-testing scripts. Run an independent script create with the appropriate criteria.
• Create scripts before recording ends if the capture file is segmented. For example, to create a script for a recently recorded session, SWITCH repository segments and run a script creation job against the closed segments.

To create scripts with the batch interface:

1. Define the script creation parameters. See Script Creation Parameters.

2. Use SQQFSAMP member SCJCL to execute the SCRIPTS function.

   1. Insert job statement information at the top of the sample.
   2. Ensure the UPROCS statement points to the Performance Test samples library SQQFSAMP at your installation.
   3. On the SYSTSIN DD statement, specify SCRIPTS on the PARM keyword.
   4. On the SYSIN DD statement, either supply the name of the data set containing the script creation parameters or enter the parameters in-stream.

   Warning

   Important

   • In-stream parameters cannot exceed 80 bytes. If you edit the parameters on a PC and copy them back to a data set that now exceeds 80 bytes, point the DD to the data set rather than pasting the parameters into the job.
   • If you plan to submit the job with a REXX queue command, put the parameters in an external file and remove all blank lines. Otherwise, parameter values are converted to uppercase and you may receive error messages.
   • Script create requires the availability of the LE runtime libraries for execution.

3. Schedule or submit the job.
   SQQFSAMP Member SCJCL — Sample JCL to Create Scripts

   ********************************* Top of Data **********************************
   //* INSERT JOB CARD HERE...............................................
   /*JOBPARM SYSAFF=sysn
   //*********************************************************************
   //* JCL TO CREATE 3270 OR APPC SCRIPTS INDEPENDENT FROM THE USER      *
   //* INTERFACE.                                                        *
   //*                                                                   *
   //* UPROCS:   DATASET THAT CONTAINS THE DCIPROC.                      *
   //*                                                                   *
   //*                                                                   *
   //* SYSTSIN:  TSO BACKGROUND INPUT STREAM.                            *
   //*           ISPSTART PGM(QACDCIP) - EXECUTE THE DCI PROGRAM         *
   //*           PARM(command) - IS THE COMMAND PASSED TO THE DCI        *
   //*                                                                   *
   //* SYSIN:    XML INPUT.                                              *
   //*                                                                   *
   //*********************************************************************
   //UPROCS  JCLLIB ORDER=('COMPWARE.QQF800.SQQFSAMP')            <-REVIEW
   //DCI     EXEC PROC=DCIPROC
   //SYSTSIN  DD *
     ISPSTART PGM(QACDCIP) PARM(SCRIPTS)
   /*
   //SYSIN    DD  DISP=SHR,DSN=COMPWARE.QQF800.SQQFSAMP(SCLU2)    <-REVIEW
   ******************************** Bottom of Data ********************************

    

 Script creation parameters

Like Global Recording request parameters, Script Creation parameters are defined in XML. For syntax rules, see Global Recording Request Parameter Syntax.

A script creation job requires a protocol parameter, capture file specification parameters, and script criteria parameters. Recording requests contain all of these parameters. You can use the parameters from an existing recording request as the input for a script creation job. For example, if script criteria was specified in the recording request, but script creation was suspended, use the VIEW function to retrieve the parameters (see Retrieve the Parameters of an Existing Request). Then use the output from the VIEW as the input for the script creation job. The script create function ignores irrelevant parameters.

If you intend to modify the script criteria or the request does not contain script criteria, start with sample SCLU2 located in SQQFSAMP.

Store the parameters in a sequential data set 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.

SQQFSAMP Member SCLU2 — Script creation parameters

This section provides an illustration of sample SCLU2 and defines all of the available script creation parameters. Parameter hierarchy is defined within the parameter definitions.

Protocol Parameter Tag and Capture File Specification Tags

LU2

Identifies the type of scripts to create. This is a parent tag to all other parameters described in this section. Begin and end the XML input stream with opening and closing LU2 tags (<LU2> and </LU2>).

Capture_File

Specifies the data set containing the captured information.

The following parameters are Capture_File subparameters. Supply the applicable parameters between the opening and closing Capture_File tags.

Dataset

The name of the data set that contains the captured information. This is a required parameter.

If the capture file is segmented, supply a First_Number and Last_Number tag.

First_Number

The first value to use for resolving the wildcard characters specified on the Dataset tag. If the data set name does not contain a wildcard character, this tag is unnecessary.

Last_Number

The last value to use for resolving wildcard characters specified on the Dataset tag. If the data set name does not contain a wildcard character, this tag is unnecessary.

 Event Notification Tags

Recording_Options

Provides the Event_Notification setting. This function uses the same event notification feature as the recording request ADD function. This is why the Event_Notification tag is nested within opening and closing Recording_Options tags. If you omit this block of tags, the batch interface sends all script creation messages to your TSO session.

Event_Notification

Defines the type of script creation messages sent to your TSO session. Supply a value of:

• 'ERROR' to receive error messages only.
• 'YES' to receive script creation status and error messages.
• 'NONE' to disable event notification.

If you are generating a large number of scripts, consider disabling this option or selecting error notification to reduce the number of messages you receive. Regardless of this setting, the batch interface sends a copy of all script creation messages to the JESMSGLG DD in the JES Job Log. The SYSPRINT DD summarizes script creation job messages.

 Script Criteria Tags

Defines script creation parameters. These are the same parameters as the script criteria parameters described in Global Recording Request Parameters. See General Script Criteria Tags through Message Filter Tags.

 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. If your installer accepted the default, PRGLOG resides in the JES job log.

The rest of this section provides information to help you troubleshoot recording request and script create errors.

 Recording request errors

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 status and error messages pertaining to request creation or modification while the started task reports status and error messages pertaining to recording.

By default, the batch interface reports its status and error messages to the PRGLOG in the JES job log.

The started task writes recording error and status message in its JES job log and SYSTEM log. However, the logs contain messages from all recording requests. To see the message pertaining to your requests, set the recording request Event_Notification parameter to 'YES' or 'ERROR'. Global Recording sends the applicable messages to your TSO session.

 Script create errors

The Global Recording batch interface initiates the script create function. If it cannot initiate script creation, it writes errors to the PRGLOG (for example, if a required parameter is missing or the parameter’s syntax is incorrect). Otherwise, it writes a single message to the PRGLOG indicating that script create completed with or without errors. If the message indicates that it completed with errors, review:

• JESMSGLG in the JES job log to see script creation status and error messages.
• SYSPRINT in the JES job log to see a script creation summary.

 Generating a Capture Segment summary

The Capture Segment Summary report indicates 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, generate this report to script activity that was captured on Monday morning from 8:00 am to 12:00 pm when you are not sure which repository segment contains the information.

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 (see the SQQFSAMP Member MCSREPT figure) in the Performance Test samples library, SQQFSAMP, or in your site’s JCL library.
2. Insert job statement information at the top of the sample.
3. Ensure the STEPLIB DD statement points to the Performance Test load library at your installation.
4. To write the report to a new or existing data set, replace SYSOUT=* on the CAPSUM DD statement with the appropriate data set information. The logical record length of the data set must be at least 132 bytes.
5. Supply report creation parameters after the SYSIN DD * statement. Put each parameter on a separate line. Parameter definitions follow the SQQFSAMP Member MCSREPT figure.
6. Submit the job.

 SQQFSAMP Member MCSREPT

Report generation parameters

NORECALL

Prevents recall of migrated data sets for report creation. This parameter, if specified, must precede all data set name parameters.

GMT

Reports time stamps in Greenwich Mean Time (GMT). This is an optional parameter. If omitted, Performance Test 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 about time adjustment. For example, a repository that was captured at 8:00 AM EST is sent to an office in California. If they run the report 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 data set name parameters.

DSN

The name of the capture repository. To report on multiple segments of a given repository, specify the data set name with the same 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 DSN to which they apply. For example,

FIRST

The first value used to resolve the wildcards in the repository name specified on the preceding DSN parameter.

LAST

The last value used to resolve the wildcards in the repository name specified on the preceding DSN parameter.

Review the report

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.

Capture Summary Report