Start the Global Recording started task

Start the BMC License Management before starting the Global Recording started task. Start the started task after each IPL to ensure successful Global Recording requests. Either:

• Manually start it by issuing the START command described in this section.
• Have your MVS Systems Programmer add the start command to the COMMND00 member to have the MVS Master Scheduler automatically start the task after every IPL.

To start the Global Recording Started Task, issue the START command on the MVS Console. The syntax of the command is as follows:

S GRTASK,P=parmTo specify more than one parameter, place the comma-delimited parameter string in single quotes.

S GRTASK,P='parm,parm'Control the way the started task behaves with the following start command parameters.

EMERGENC

Shuts down Global Recording started task quickly and performs minimal clean up. All VTAM intercepts are preserved but disabled.

STARTUP

Starts up the Global Recording started task.

TEST

Writes Performance Test debugging messages to the log. Consult with BMC Customer Solutions before using this option.

BKUSES

This is the default. When Global Recording is shutting down, user id information is backed up in the Global request file. You can override this parameter using the following MODIFY command before shutdown:

NOBKUSES

When Global Recording is shutting down, user id information will not be backed up in the Global request file. You can override this parameter using the following MODIFY command before shutdown:

QUIET

Suppresses the following messages when you start up the Global Recording started task.

{{code language="none"}}
SVMAN601I HIPERSTATION SUBSYSTEM IS ALREADY ACTIVE
SVMAN602I IT MUST BE SHUTDOWN FOR A STARTUP TO TAKE PLACE
SVMAN603I START HIPERSTATION USING SHUTDOWN AS THE EXEC PARAMETER
SVMAN604I WHEN SHUTDOWN COMPLETES, RESTART NORMALLY
{{/code}}It also suppresses all console messages or TSO TPUT messages, as well as the following recording request initiation messages:

ETGRPX103I GR INITIATED FOR REQUEST nnnnn
ETGRPX1041 SIDE A: netida.lunamea SIDE B: netidb.lunameb
ETGRPX1051 LOGMODE: llllllll
ETGRPX1061 TP: tttttttt

Change the behavior of an existing Global Recording started task with any of the following MODIFY commands. Issue the applicable MODIFY command on the MVS Console while the task is running.

EXCLUDE

Excludes the logical unit (LU) from recording. The specified LU is excluded even if it is explicitly requested in a Global Recording request.

F GRTASK,EXCLUDE,luname

Stops collection of all VTAM (3270/APPC) traffic.

MQ_SYNCPOINT

This command affects Global Recording of MQ activity.

MQ_SYNCPOINT=YES causes Global Recording to capture all syncpoint events (MQ COMMITS and BACKOUTS).

MQ_SYNCPOINT=NO causes Global Recording to capture only relevant syncpoint events—that is, the MQ COMMITs or BACKOUTs associated with recorded GET, PUT, or SET events. Eliminating irrelevant syncpoint events from capture can result in smaller repositories and lower processing requirements for script creation.

F GRTASK,MQ_SYNCPOINTUse this command to:

• Override default behavior. If neither MQ_SYNCPOINT=YES nor MQ_SYNCPOINT=NO are specified in the HSCM PARMLIB member, Global Recording captures all syncpoint by default.
• Override an MQ_SYNCPOINT specification in the HSCM PARMLIB member.
• Return to capturing all syncpoint after the MQ_SYNCPOINT=NO modify command was issued.

YESNFLS

This command applies only to Performance Test for VTAM and the APPC option in Performance Test for Mainframe Servers.

YESNFLS activates “early flush” logic in Global Recording. That is, it causes Global Recording to flush and process the global capture buffers when a BIND or UNBIND occurs, minimally 15 seconds after the last flush.

By default, Global Recording flushes and processes global capture buffers after they fill with data. If a captured session begins and ends before the buffer fills, the User count on the Global Recording Monitor Request screen and the Active Sessions screen will not reflect the existence of the session because the captured information has not been processed. If you are capturing data on a low-volume test system, enable NFLS early flush logic with the YESNFLS command to flush and process global capture buffers upon initiation and termination of captured sessions. This remedies the omission or delay of request monitoring information.

Do not use this command if you are capturing activity on a system with a continuous volume of traffic such as a production system. It could potentially result in lost messages and greater CPU utilization.

F GRTASK,YESNFLSUse this command to:

• Override default behavior.
• Override an NFLS=NO specification in the HSCM PARMLIB member.
• Activate “early flush” after the NONFLS modify command was issued.

NONFLS

This command applies only to Performance Test for VTAM and the APPC option in Performance Test for Mainframe Servers.

NONFLS ensures Global Recording flushes and processes global capture buffers after they fill with data.

F GRTASK,NONFLSUse this command to:

• Override an NFLS=YES specification in the HSCM PARMLIB member.
• Return to normal buffer processing after the YESNFLS modify command was issued.

HSDBG

Enables debugging option nnn. Consult with BMC Customer Solutions before using the command.

F GRTASK,P=HSDBG,nnn

NADR

Enables or disables tracing for the specified luname. Consult with BMC Customer Solutions before using the command. To enable tracing, issue the following command:

F GRTASK,NADR,lunameTo disable the trace, issue the same command without the luname parameter.

DISPLAY_DEBUGGING_INFORMATION

Writes the specified number of Global Recording diagnostic messages (nnn) to the log. Consult with BMC Customer Solutions before using the command. If used improperly, the system log may be flooded with messages.

F GRTASK,DISPLAY_DEBUGGING_INFORMATION,nnn

Shut down the Global Recording started task

Shut down the Global Recording started task with either the:

• MODIFY command (F GRTASK,SHUTDOWN)
• MVS STOP command.

It can take several minutes after issuing the command before the Global Recording started task to end completely. If the started task does not end after several minutes, enter the MVS CANCEL command to finish the shutdown.

Monitoring volume and performance

Global Recording statistics are provided to assist in tuning global capture buffer requirements controlled by the parameters ECSA_BUFFER_COUNT/ECSA_BUFFER_SIZE and TCP_MQ_ECSA_BUFFER_COUNT/TCP_MQ_ECSA_BUFFER_SIZE. Global Recording stores captured VTAM, TCP/IP, and MQ data in global capture buffers before writing the data to DASD. Tuning the global capture buffers will prevent over allocation of common storage as well as prevent Global Recording capture data loss. The statistics display volume and size of VTAM, TCP/IP, and MQ traffic as well as high-water marks for a specified cycle and the maximum. Use the statistics to tune buffer allocations for current throughput, to plan for increased data volume, and to determine levels of traffic before capture initiation on new systems.

Statistics are available online and in a job sysout. The sysout has unique line identifiers to enable sites to programmatically produce graphics, generate historical databases, or assist in monitoring high-water marks of ECSA usage or other statistical data. Refer to Global Recording - Statistics Summary and Sysout Example for examples of statistics online and in a job sysout.

ECSA Current Used and ECSA Max Used display the amount of ECSA data, for ECSA_BUFFER_COUNT/ECSA_BUFFER_SIZE and TCP_MQ_ECSA_BUFFER_COUNT/TCP_MQ_ECSA_BUFFER_SIZE, that is in use at any time and the maximum used for the life of the Global Recording task. ECSA Max Used must allow for spikes in daily volume and should not be reduced to the ECSA Max Used level. Additionally, ECSA Cycle Max Used can be used to monitor ECSA usage for specific periods of the day to determine the periods of largest data traffic.

Global Recording - Statistics Summary screen

Sysout Example

This section discusses the following topics:

• Set Duration of the Statistics Cycle
• Start and Stop Statistics Monitoring
• Access Statistics Information.

Set duration of the statistics cycle

Statistic CYCLE information is reset based on the frequency of the report generation. The default frequency is 15 minutes. This can be altered by issuing the MODIFY command STATS_FREQUENCY,newfreq where newfreq is numeric. The newfreq will take effect on the next frequency cycle (for example, if the default frequency is in use and the cycle just occurred), then altering STATS_FREQUENCY will require 15 minutes before the newfreq will become the CYCLE frequency. The Statistics Monitoring CYCLE allows snapshots of volume, HVCOMMON utilization, etc. to be used to plan for max HVCOMMON utilization and determine throughput. STATS_FREQUENCY can be specified in the HSCM PARMLIB member used during startup.

Start and stop statistics monitoring

Monitoring can be started by issuing the MONITOR command either through the HSCM PARMLIB member or via a MODIFY command. Monitoring can be stopped by issuing the MONITOR command via a MODIFY command. Results of monitoring can be written to a JES or DASD data set. STATS and STATSOFF control the output generation.

Statistics are generated when either the Statistics Monitor is activated (MONITOR) or when STATS has been issued and a Global Recording request is active. Monitoring allows capture without requiring that a request be active.

Monitoring can be terminated via the MONITOR command, however statistics will still be collected if a STATS was performed and a Global Recording request is active. Also, if monitoring is active and STATS was not performed, STASTICS will still be generated without CYCLE processing for online viewing only.

Access statistics information

Statistics can be viewed online by entering STATS on the Option line of the Product Menu. The initial view will be for all technologies: VTAM, TCP/IP, and MQ. From the Option line, specifying VTAM, TCP, or MQ can further expand each technology.

Statistics can also be viewed by browsing the statistics output data set. The data set is available when STATS has been previously processed and when STATCLOS is processed (to deallocate the data set from Global Recording). Each line in the statistics output data set has a unique identifier that can be used to programmatically process the information into presentations, etc.

Global Recording startup parameter values are also available by entering GRPARMS from the Option line of the Product Menu. The values displayed will not reflect changes entered via the MODIFY command.

Optimizing Global Recording performance

Global Recording initialization parameters and commands affect the performance of Global Recording and potentially the whole system. Manual installation of Global Recording requires editing your HSCM PARMLIB member based on the type of traffic your users need to capture. The Guided Configuration generates the parameters based on information provided on the Guided Configuration screens.

The default values in the sample members and the default values on the Guided Configuration screens support testing in most moderate-volume systems—100K to 200K of data per second—as follows:

• For VTAM, that is 200 to 1000 terminals sending 500-1000 byte messages approximately every five seconds.
• For TCP/IP, that is 50 to 100 connections sending 5-10K messages approximately every five seconds.
• For MQ, that is 50 to 250 sessions sending 2-4K messages approximately every five seconds.

You can optimize both Global Recording and system performance by establishing values better suited for your system. If you are testing in a low-volume system (20-30 terminals) or a high-volume system (over 1000 terminals), the default settings may result in delayed recording request monitoring information, error messages, or even lost data due to slow processing or insufficient common storage.

The rest of this section describes how to optimize Global Recording performance for each method of installation.

Dedicate resources to capturing relevant traffic

Dedicating resources to capturing only relevant traffic can improve performance. There are four parameters in the HSCM PARMLIB member—GLOBAL_RECORD_CAPTURE_LU1, ENABLE_3270, ENABLE_APPC, and ENABLE_LU0—that can be used to disable unneeded functionality. Alter the settings as described in HSCM00 to disable the functions.

Ensure buffer settings are appropriate

Proper buffer settings have the biggest impact on Global Recording performance. To establish the correct number and size of global capture buffers, determine how many kilobytes of data flow through the system per second for each type of traffic your users need to record. Gather typical and peak rates. Performance Test offers utilities that report traffic volumes and HVCOMMON usage information. See Monitoring Volume and Performance.

Global Recording stores captured information in global capture buffers. It typically flushes and processes these buffers after they fill with data. For optimum performance, Global Recording needs to flush and process one to two buffers per second. Use your typical data flow to determine the buffer length required for optimum performance. For example, if your typical data flow is 150K/second, set the buffer length between 75K and 150K. ECSA_BUFFER_SIZE is the buffer length parameter for VTAM. TCP_MQ_ECSA_BUFFER_SIZE is the buffer length parameter for TCP/IP and MQ.

Set the buffer count high enough to accommodate peak volume. To determine the number of buffers required, multiply the peak-to-typical volume ratio by three or four. For example, if peak volume is 450K per second and typical volume is 150K per second (a ratio of 3:1), set the buffer count between 9 and 12.

All of these parameters are specified in the HSCM PARMLIB member. Modify and refresh the member so the new values are used the next time Global Recording is started.

Enable early flush for low-volume test systems

By default, Global Recording flushes and processes global capture buffers after they fill with data. If a captured session begins and ends before the buffer fills, the User count on the Global Recording Monitor Request screen and the Active Sessions screen will not reflect the existence of the session because the captured information has not been processed.

If you are testing VTAM applications in a low-volume system test system (20-30 terminals conducting a total of 2K to 6K of traffic per second), activate “early-flush” logic to improve performance. This logic causes Global Recording to flush and process the global capture buffers when a BIND or UNBIND occurs, minimally 15 seconds after the last flush.

Do not use this option if you are capturing activity on a system with a continuous volume of traffic such as a production system. It could potentially result in lost messages and greater CPU utilization.

Ensure count parameters are accurate

Upon startup, Global Recording establishes information tracking tables based on user, terminal, session, connection, and call count parameter values. It stores these tables in ECSA storage. If your actual counts are higher than the values specified on these parameters, Global Recording must allocate additional ECSA storage. While processing ECSA allocation, Global Recording may fall behind in processing captured traffic, which produces error messages and compromises performance.

Set the count parameters to accommodate peak volume. Performance Test offers utilities that report volume and usage information. See Monitoring Volume and Performance. When you have determined peak volumes, set the following parameters accordingly:

• For VTAM traffic, set MAXIMUM_3270_SESSIONS to the maximum number of users and terminals you expect to access the system at one time. This number is the same as the number of active VTAM sessions.
• For TCP/IP traffic, set MAXIMUM_TCP_CONNECTIONS to the maximum number of connections you expect to be open on the system at one time.
• For MQ traffic, set MAXIMUM_MQ_CONNECTIONS to the maximum number of sessions and objects (queues) you expect to be open on the system at one time.

Additionally, for TCP/IP or MQ capture set the MAXIMUM_CONCURRENT_TCP_MQ_CALLS parameter to the maximum number of TCP/IP and MQ calls expected to execute on the system at one time.

Set or modify TCP/IP or MQ record limit

If you know the maximum message size sent or received by the TCP/IP or MQ applications your users are testing, consider using the MAXIMUM_TCP_RECORD_SIZE parameter to set a limit on the size of message allowed for capture.

If MAXIMUM_TCP_RECORD_SIZE=0 or is not specified, its value will be the product of TCP_MQ_ECSA_BUFFER_COUNT * TCP_MQ_ECSA_BUFFER_SIZE.

If MAXIMUM_TCP_RECORD_SIZE is specified, its value should be less than the product of TCP_MQ_ECSA_BUFFER_COUNT * TCP_MQ_ECSA_BUFFER_SIZE—unless BUFFER_LATCH_WAIT=YES is used. With BUFFER_LATCH_WAIT=YES, the MAXIMUM_TCP_RECORD_SIZE can be up to 2,147,483,647.

When the TCP/MQ message size is larger than the value specified for MAXIMUM_TCP_RECORD_SIZE, error message TCPRC101E will be written to the GRTASK log.

BUFFER_LATCH_WAIT Parameter

The BUFFER_LATCH_WAIT parameter affects Performance Test wait behavior as follows:

• If BUFFER_LATCH_WAIT=YES, Global Record will wait to get an HVCOMMON buffer when no buffer is available.
• If BUFFER_LATCH_WAIT=NO, Global Record will not wait to get an HVCOMMON buffer when no buffer is available. The data to be captured will be ignored and the repository will not contain the ignored record.

High-volume capture best practices

This section suggests ways to optimize Global Recording for high-volume capture.

PARMLIB settings

The best setting will be obvious for some parameters and less clear for others. When unsure, use the default setting, then adjust if necessary. Finding the right values can be an iterative process of reviewing Global Recording task messages, updating parameter settings, and restarting the Global Recording task.

Collecting statistics without recording data

Using data from Global Recording statistics to understand the data flow rate on your system will help you to choose the best parameter settings. The information gathered can help you predict how much data you can expect to record when you activate your requests. To collect statistics without recording data:

1. Add a DD statement for file STATDD (//STATDD DD SYSOUT=*) to the JCL for the Global Recording task.
2. Set HSCM parameters STATS=YES and MONITOR=YES.
3. Start the Global Recording task.

VTAM Parameters

For VTAM global buffers, Global Recording will allocate storage equal to the product of the ECSA_BUFFER_COUNT and ECSA_BUFFER_SIZE parameter settings. As of the July 2019 cumulative maintenance release—specifically with PTFs QFS044A and QFS051A—these buffers are located in high virtual common (HVCOMMON) storage. Message SVMAN107I during Global Recording startup indicates that the VTAM buffer relocation maintenance has been applied. If you have this maintenance applied, set ECSA_BUFFER_COUNT and ECSA_BUFFER_SIZE to their maximum values. Unlike ECSA, there is a vast amount of HVCOMMON storage available, so setting these parameters to their maximum values should cause no concern.

Sets the number of Global Recording buffers in common storage available to contain data while it is being transferred into the Global Recording address space.

ECSA_BUFFER_SIZE

The length of each buffer in kilobytes.

Only 26 bytes of ECSA is reserved per session, so it is not very costly to reserve extra space for sessions. Estimate the maximum number of 3270 sessions expected, then set a value that is somewhat higher than your estimate. How much higher you set the value should be based on how confident you are in the accuracy of your estimate. Message SVNET910I MORE NADRS NEEDED in the Global Recording log indicates that the value should be increased.

TCP and MQ parameters

For TCP and MQ global buffers, Global Recording will allocate storage equal to the product of the TCP_MQ_ECSA_BUFFER_COUNT and TCP_MQ_ECSA_BUFFER_SIZE parameter settings. As of the April 2019 cumulative maintenance release—specifically with PTF QFS030A—these buffers are located in high virtual common (HCOMMON) storage. Message SVMAN106I during Global Recording startup indicates that the TCP/MQ buffer relocation maintenance has been applied. If you have this maintenance applied, set TCP_MQ_ECSA_BUFFER_COUNT and TCP_MQ_ECSA_BUFFER_SIZE to their maximum values. Unlike ECSA, there is a vast amount of HVCOMMON storage available, so setting these parameters to their maximum values should cause no concern.

Sets the number of Global Recording buffers in common storage available to contain data while it is being transferred into the Global Recording address space.

TCP_MQ_ECSA_BUFFER_SIZE

The length of each buffer in kilobytes. For the best performance, this parameter should be set to a value greater than the larger of TCPMAXRCVBUFRSIZE, TCPRCVBUFRSIZE, or TCPSENDBFRSIZE in your TCPCONFIG parameter, up to its maximum value of 1024K.

The maximum number of TCP/IP connections expected to occur on the system at one time. Enter a value between 0 and 65,535. Upon startup, Global Recording creates information tracking tables in ECSA storage based on the specified maximum number of concurrent TCP/IP connections and the maximum number of simultaneous TCP/IP and MQ calls. If the actual counts are higher that these values, Global Recording will allocate additional ECSA storage. While processing ECSA allocations, Global Recording may fall behind in processing captured traffic, which can produce error messages and compromise performance. Enter an accurate value to minimize CPU usage, eliminate unneeded data movement, and ensure optimum Global Recording and system performance. Message TCPRC-0910I MORE TADRS NEEDED in the Global Recording log indicates that the value should be increased.

MAXIMUM_MQ_CONNECTIONS

The maximum number of MQ queue manager connections, plus the maximum number of objects (queues) expected to be open on the system at one time. Enter a value between 0 and 65,535. Upon startup, the Global Recording task creates information tracking tables in ECSA storage based on this value and the maximum number of simultaneous TCP/IP and MQ calls. If the actual counts are higher that these values, the Global Recording task will allocate additional ECSA storage. While processing ECSA allocations, the Global Recording task may fall behind in processing captured traffic, which can produce error messages and compromise performance. Enter an accurate value to minimize CPU usage, eliminate unneeded data movement, and ensure optimum Global Recording and system performance. Message TCPRC-0912I MORE QARDS NEEDED in the Global Recording log indicates that the value should be increased.

MAXIMUM_CONCURRENT_TCP_MQ_CALLS

The maximum number of TCP/IP and MQ calls expected to occur on the system at one time. Enter a value between 1 and 65,535. Upon startup, the Global Recording task creates information tracking tables in ECSA storage based on the specified maximum number of concurrent TCP/IP connections and the maximum number of simultaneous TCP/IP and MQ calls. If the actual counts are higher than these values, the Global Recording task must allocate additional ECSA storage. While processing ECSA allocations, the Global Recording task may fall behind in processing captured traffic, which can produce error messages and compromise performance. Enter an accurate value to minimize CPU usage, eliminate unneeded data movement, and ensure optimum Global Recording and system performance.

Global Recording started task

Ensure the Global Recording started task priority is higher than terminal processing facilities and batch jobs with high TCP and MQ activity. This will allow the Global Recording task to keep up with collecting and writing the communication traffic being captured.

Use the QUIET startup parameter on the Global Recording task. This will suppress many messages that are typically unwanted in the case of high volume recording from being written to the global record log.

Global Recording requests

Global Recording requests with no filter criteria are likely to capture far more data than you are really interested in. Use filter criteria that are as selective as possible on your recording requests to minimize DASD use and processing overhead for the Global Recording task and script create requests on the repository.

Select

Suspend script creation: Decouple script create activity from Global Recording activity and do script create when convenient if scripts are needed.

Error event notification: Sends error event messages to your TSO session.

Deselect

Normal event notification: Suppress many messages of little value for high-volume recording that would clutter your TSO session.

Record from LOGON only: This option is used when only complete sessions—that is, from logon to logoff—are desired. This is typically not the case for high-volume capture.

Avoiding file I/O delays

Global recordings of long duration and/or large amounts of data that use a wildcard data set name with a first and last segment number will produce a series of data sets that make up your repository. These data sets have a qualifier with an incrementing number, beginning with your FIRST value and ending with your LAST value. Ensure the data set names that will be created by your recording are not migrated or don’t exist. Recall of migrated data sets will suspend writing captured data to DASD, causing a backup of data in global and work buffers and potential loss of data if the data set recall takes too long.

Plan your data set allocation to typically hold at least 30 minutes worth of data. If new repository segment data set allocation occurs too often—for example, every few seconds—the delay in writing captured data to DASD during allocation will cause a backup of data in global and work buffers with a potential loss of data.

When sizing your data sets, consider information generated by the statistics and monitoring data produced in Collecting Statistics Without Recording Data. You can also start a “dry run” request with an estimate of the needed size. Determine how long Performance Test takes to switch to new segments during slow, moderate, and peak times for the data being recorded, then extrapolate from your results.

Ignoring unneeded data

The following parameters can be used to limit the data captured by Global Recording.

ENABLE_APPC

If you will not be capturing APPC traffic, set this to NO.

ENABLE_LU0

If you do not need to capture LU0 sessions, set this to NO.

GLOBAL_RECORD_CAPTURE_LU1

If you do not need to capture LU1 type 3270 data traffic, set this to NO.

MQ_SYNCPOINT

If you do not need the COMMIT and BACKOUT syncpoint events recorded along with your MQ GET, PUT, and SET data, set this to RELEVANT.

Reducing unneeded processing

The following parameters can be used to limit the amount of processing performed by Global Recording.

ENCRYPT_VTAM

If it is sufficient to encrypt only passwords (VTAM inputs) and APPC FMH-5 data in the repository data sets, set this to NO.

ENCRYPT_TCP

If you do not need TCP/IP data encrypted in the repository data sets, set this to NO.

ENCRYPT_MQ

If you do not need MQ data encrypted in the repository data sets, set this to NO.

Changing the started task subsystem name

When the Global Recording started task first starts, it adds a 4-byte subsystem name that is defined in the AQQFMOD library member SVSSCTID. It reuses the subsystem name on subsequent starts. The default subsystem name is C'SVW.', where '.' is hexadecimal 12. In other words, the system name in hexadecimal format is X'E2E5E612'. Most sites operate with the default. However, you may need to modify the subsystem name for one of the following reasons:

• To conform to your site’s standards.
• To prevent conflict with another subsystem.
• To secure sensitive information. The SSCT entry contains pointers to the data areas that Global Recording uses.

To set the started task subsystem name:

1. On line 17 of SQQFSAMP member UMSSCT1 (SQQFSAMP Member UMSSCT1), replace D8C1C8E5 with a new subsystem name in hexadecimal format.

   Warning

   Make sure the subsystem name is different than the started task name or you will receive errors that may require an IPL to remedy.

   SQQFSAMP Member UMSSCT1
   

   ++USERMOD(UMSSCT1)  /* PERFORMANCE TEST - USERMOD FOR SSCT NAME */.
   ++VER(CPWR)         /* COMPUWARE */
     FMID(MQQF170)     /* PERFORMANCE TEST FOR VTAM BUILD 051 */
     .                 /* */
   ++ZAP(SVSSCTID)     /* NAME OF MODULE. */
     DISTLIB(AQQFMOD)  /* DDNAME OF DLIB. */
     /* */.
   *************************************************************
   NAME SVSSCTID
   *************************************************************
   * VERIFY EXISTING SSCT NAME  (C'SVW.'=X'E2E5E612')         */
   * VER 0000 E2E5E612    /* IN ORDER TO REUSE SAME USERMOD   */
   *                      /* VER IS COMMENTED OUT.            */
   *************************************************************
   * REPLACE WITH NEW SSCT NAME (C'QAHV'=X'D8C1C8E5')          *
   *        ********                                           *
   REP 0000 D8C1C8E5
   *        ********    /* MAKE SURE YOU CHANGE ONLY 4 BYTES  */
   *                    /* OF SUBSYTEM NAME IN HEX VALUE.     */
   *************************************************************
2. In SQQFSAMP member UMSSCTJ1, supply site-specific values and submit the job to make Global Recording use the SSCT name specified in Step 1.