Setting up a Strobe XCF group

This topic provides instructions for configuration tasks not covered in the Installing.

Perform either of the following tasks that are required at your site:

• Task 1.1: Set Up a Strobe XCF Group
• Task 1.2: Customize Strobe Procedures
• Task 1.3: Customize the Module Descriptor Program
• Task 1.4: Customize the Loading of Data Collectors
• Task 1.5: Configure HCI for Strobe Web Services

Task 1.1: Set Up a Strobe XCF Group

To set up the Strobe XCF group, specify a group name for the XCFGROUP keyword of the PARMLIB member. Strobe establishes the group at initialization

Operating System Requirements

IBM z/OS Version 2.1 or more current with XCF services is required.

Requirements

Ensure that the following requirements are in place:

• A given system can be a member of only one Strobe XCF group.
• Starting from release 21.01 or later, Strobe in XCF group might be at different releases, so versions earlier than 21.01 are not compatible.
• The following data sets must be shared by all members of a Strobe XCF group:
  • Queue data set
  • System message data set

Recommendations

If you are using Strobe in a multisystem environment, we recommend:

• While each member of a Strobe XCF group can have its own unique functions, each member of the Strobe XCF group has identical user exit routines, PARMLIB members, and system security databases.

• Allocate the following data sets to be shared across the Strobe XCF group:

  • Strobe log data set
  • AutoStrobe data set
  • Request group dat aset
  • History data sets.

  Warning

  In a multisystem environment, Strobe assumes that one security database is shared by all systems in the Strobe XCF group, although access rules for each system can vary. If the systems do not all use the same security database, requests may have different characteristics on different systems, leading to unexpected results.

Migrating Data sets Across Different Environments

If characteristics differ between your current Strobe environment and the environment where you are installing the new release of Strobe, you must set different parameters in the migration process JCL. For example, you need to do so when migrating from:

• Local to XCF mode
• XCF to local mode
• One XCF group name to a different XCF group name.

In addition, so that you can copy queue or request group data sets from one MVS system to another, the migration process provides a COPY parameter that makes copies of new Strobe release data sets so you can use them on another MVS system with a different XCFGROUP or SMF ID.

In these situations, request migration is a two-step process:

1. Migrate the contents of the previous queue data set to the new Strobe release, as described in Task 4.2 Migrate Strobe Requests in the Installing.

2. Run an additional migration process to specify the characteristics of the new environment, or to copy requests to a different system.

   Tip

   When you change the XCFGRP or SMFID, only completed requests are migrated.

Member MIGRXCFQ migrates from a Local to an XCF Environment, from an XCF to a Local Environment, or from one XCF Group Name to another. Member MIGRSMFQ copies measurement requests between installations of Strobe.

Follow these steps to migrate data sets to run either MIGRSMFQ or MIGRXCFQ. Edit either the MIGRXCFQ or MIGRSMFQ member, making the following changes:

• Edit the parameter specified in the MIGRATE step of either the MIGRSMFQ or MIGRXCFQ to specify the required migration parameters, as listed in Parameters for the Migration Process.

Migration Parameter Examples

This section provides examples of different migration situations. Your specific environment may require a different set of parameters.

Migrating from a Local to an XCF Environment

If your previous release of Strobe ran on a single local MVS system and you are installing the new release of Strobe in a multi-system environment, you must:

1. Migrate the queue data set to the system that will be used as the Strobe single point of control. (In a multisystem environment, you can use only one queue data set.)
2. If using AutoStrobe, migrate your group data set elements to a single group data set on the same system as the queue data set so that all instances of Strobe within the sysplex can use the same groups.

You do not need to specify INVERID because it has the correct default value of B:

//MIGRATE EXEC PGM=STRBCMIG,REGION=4M,COND(4,LT),
// PARM=’COPY,INSMFID=SYS1,OUTXCFGRP=GROUPI’

Migrating from an XCF to a Local Environment

To migrate from an XCF environment to a local installation, use the INXCFGRP and OUTSMFID parameters. INVERID is not required because Strobe does not use a version ID with XCF group names.

Migrating from One XCF Group Name to Another

To migrate from one XCF group name to another, use the COPY function with INXCFGRP and OUTXCFGRP parameters:

//MIGRATE EXEC PGM=STRBCMIG,REGION=4M,COND(4,LT),
// PARM=’COPY,INXCFGRP=OLDGROUP,OUTXCFGRP=NEWGROUP’

Copying Measurement Requests Between Installations of Strobe 

You can use the migration process to copy Strobe measurement requests that ran in one MVS environment so Strobe can use them on another MVS system. The following example copies completed measurement requests from a system with SMFID SYS1 to a system with a SYS5 SMFID. The default for the INREL parameter with COPY is 1702.

//MIGRATE EXEC PGM=STRBCMIG,REGION=4M,COND(4,LT),
// PARM=’COPY,INSMFID=SYS1,OUTSMFID=SYS5’

1. If the Strobe session manager is running, use one of the following MVS console commands to stop it:
   1. STOP STRBSM (production version)
   2. STOP STRTSM (test version).
2. Add a job card to the MIGRATEQ member.
3. Change $INSTHLQ to the high-level qualifier of the new queue data sets and $OLDHLQ to the high-level qualifier of the existing queue data sets.

Parameters for the Migration Process

Task 1.2: Customize Strobe Procedures

The Strobe JCL procedures are members of the hlq.SSTRPROC data set. Review the procedures to determine which ones are useful for your installation. You can modify the Strobe procedures and copy them to your system procedure library.

Functions of the Procedures

The following table displays the procedures and their associated functions.

• CI (C/370)
• CX (CA Optimizer COBOL post-processor)
• X2 (CA Optimizer/II COBOL post-processor)
• FG (FORTRAN G-level)
• FH (FORTRAN H-level and VS)

Changing the Procedures

Review the unit and region parameters to verify that they are appropriate for your installation. Take care when modifying space and region specifications; insufficient sizes may cause the profile job to terminate abnormally.

Customizing the STRIPROF Procedure

To specify which TCP/IP stack to use in the STRIPROF procedure, use the ISTROPT DD along with the TCPSTCK=parm. Insert this DD below the //PROFILE step in STRIPROF as follows:

//ISTROPT DD *
TCPSTCK=STACKNAME
/*This change requires that you apply Strobe current maintenance to take effect.

Procedures Invoking Language Processors

The STROzz procedure invokes the language processors and is most likely to require further customization. You can modify this procedure to match your installation standards, or you can modify copies of your installation’s existing procedures to incorporate the Strobe components. Do not suppress the compiler listing options (SOURCE, PMAP, and VERB in COBOL; LIST and ESD in assembler; and so on), because the Strobe indexing programs, which process the compiler SYSPRINT data sets, require both the source text listing and the object text listing.

Report Parameters

You can change the SORTSIZ and LINEMAX report parameters.

• SORTSIZ controls the amount of main storage available to the system sort. SORTSIZ can be from 12000 to 999999.

  • To allow the sort program to claim all available main storage, use 999999.
  • To use your sort system default, specify a null value.

  The larger the value of SORTSIZ, the more rapid the sort, provided that there is sufficient real storage to preclude excessive paging.
  If your installation has a sort product that uses a secondary space allocation, you can change data definitions for sort work data sets in the reporting facility. You may need to add a SORTLIB data definition statement.

• LINEMAX specifies the number of lines printed on each page of the Strobe Performance Profile. LINEMAX value must be between 45 and 80.

Task 1.3: Customize the Module Descriptor Program

The Strobe module descriptor program, STREMODS, provides function descriptors for MVS system and subsystem modules (modules whose names begin with the prefixes IGG, IDA, DFS, and so on). STREMODS is link-edited into the Strobe library and loaded by the Strobe reporting facility.

You can add module names and function descriptors for your own programs and subsystems and change descriptors for module names already in the STREMODS program. For specific details, see the comments in the sample USERMOD UM0MODS, found in the hlq.SSTRSAMP library.

You can find the sample source in members @TREMOD1 and @TREMOD2 of the hlq.SSTRSAMP library. Make your own copies of the members and rename them STREMOD1 and STREMOD2.

Adding and Changing Module Descriptors

Member UM0MODS of your Strobe hlq.SSTRSAMP data set provides a sample SMP/E USERMOD that you can use to add and change module descriptors.

1.Add your module name to the eight-character field and its corresponding descriptors to the 24-character field. For example:

   DC CL8'modname',CL24'module descriptor'The module name field must be exactly eight characters long. The descriptor field must be exactly 24 characters long. The number of entries you can add to a single control section or the number of control sections that you can create is limited only by the size of your region.

2.Using SMP/E, RECEIVE and APPLY the customized version of the UM0MODS USERMOD that you have built.

Task 1.4: Customize the Loading of Data Collectors

When Strobe measures a target program, it determines whether it should invoke any of the available data collectors. Strobe searches LINKLIST for a module that has a prefix of STRB and a suffix that contains the first four characters of the target program name. The Strobe data collectors use the IBM- or vendor-supplied name for the subsystems that they support.

If you use the Strobe Db2 data collector, Strobe invokes it for all measurement sessions. If the Db2 data collector determines that the target region does not support Db2, the data collector disables itself.

If you use nonstandard names to initialize any of these subsystems, link edit the data collector again, supplying the alias you are using. You cannot rename the data collector.

The Strobe Interface supports user-written data collector programs that supplement performance data collected by Strobe and its options. Part 6, Strobe Interface in the Using-Strobe-options describes the interface and explains how to code a data collector program.

Task 1.5: Configure HCI for Strobe Web Services

Strobe Web Service in support of iStrobe and the SQLAF analysis feature requires that BMCs Host Communications Interface (HCI) software be installed and configured.

If you have configured HCI for use with the Workbench for Eclipse, you may use the same HCI to support Strobe. You just need to ensure that the HCI JCL and the STASK PROC contains a STEPLIB DD pointing to the Strobe authorized load library SSTRAUTH. For SQLAF support, the STASK PROC must also contain your Db2 load library SDSNLOAD.

If your site is not using the Workbench for Eclipse or you don’t want to use the same HCI, follow the procedures for Strobe described in the Host Communications Interface (HCI) Configuration and Administration section of the Enterprise Common Components Advanced Configuration Guide.