Planning to measure by using AutoStrobe

With the installation of AutoStrobe at your site, you will be able to take advantage of its various functions to augment application measurement and performance management.

The following table summarizes the additional benefits you receive from AutoStrobe:

The following are the various AutoStrobe components that provide the aforementioned functionality:

• Multiple and every step measurement
• Wildcard job name designation
• Measurement scheduling
• Concurrent group and triggered application measurement
• Measurement history tracking
• Threshold status assignment
• Measurement list candidate list selection
• Application performance monitoring.

Measuring Multiple Steps or All Steps of a Job

With AutoStrobe, you can easily measure multiple steps of a job with a single action. As shown in the following figure, when you submit a measurement request for a job that is not yet executing, you can specify a list of job step names, job step numbers, or program names to be measured. Or, you can specify that Strobe measure all steps of the job. This capability eliminates the need to submit an individual measurement request for each job step.

Measuring Multiple Steps in a Job

When measuring multiple steps in a job, consider how you will specify what you want Strobe to measure. You can specify lists of program names, procedure step names, or procedure step numbers, or measure all of the steps in the job. If the same measurement parameters apply to each of the steps you want to measure, consider using one measurement request to measure the multiple steps. For more information, see Measuring Multiple Steps in a Job (AutoStrobe Only).

Identifying the Job Name Using the Wildcard Character

By including a wildcard character (*) in the job name, you can measure a job without knowing the entire job name. For example, a production job that is automatically initiated by a vendor’s scheduling package appends an arbitrary sequence number to the end of the job name. With this AutoStrobe function, you do not have to know the sequence number to measure the job. You can specify one or more initial characters of the job name and an asterisk (*) when you submit the measurement request for a job that is not yet executing. Strobe finds the first job that meets the search criteria and measures it.

See Specifying the Target Job Name for more information about specifying jobs using the wildcard character (*).

To ensure an accurate match, specify as complete a string as possible before submitting the request.

Scheduling a Measurement Request

As shown in the following figure, users with AutoStrobe installed at their site can also schedule a measurement request, or a request group, to initiate measurement sessions automatically on certain dates and times. This scheduling capability conveniently enables you to submit Strobe measurement requests ahead of time. It also simplifies measuring the performance of production applications, for instance, that execute at predictable times.

To schedule a measurement request, specify a starting date and an ending date, and a pattern of reoccurrence, such as every Monday and Friday at 6:00 a.m. Optionally, you can specify a list of specific dates and times. Strobe automatically initiates measurement sessions on these scheduled dates and times.

Submitting a Scheduled Measurement Request

For a scheduled request, Strobe will automatically initiate measurement sessions up to three times a day for a maximum of 52 weeks. When the schedule is close to expiring, Strobe issues a message indicating that it is time to reschedule the request.

When creating a schedule for a measurement request or a request group, you can designate specific dates and times that you want to include, or exclude from, your overall schedule. The ability to add or exclude specific dates is an important and powerful option to keep in mind as you design your schedules. Make sure to tailor your schedule to accommodate holidays or other dates you may want to add or omit. For example, you may want to exclude Monday holidays from your overall schedule, and instead substitute Tuesdays.

Keep in mind that when you submit a request group with a schedule, the schedule applies to each request group element in the request group. When you are viewing the status, each request appears as deferred (not yet active or queued) until it reaches the scheduled date and time. At this point the status of the request is changed from deferred to queued, awaiting the activation of the target program, or immediately changed to active.

Saving the Measurement Request in a Request Group

If you submit the same measurement request frequently, consider saving the measurement request in a request group. This option lets you quickly and easily submit an identical measurement request step the next time you want to measure the job. For more information on how to plan for and use request groups, see Creating, Saving, and Submitting Measurement Request Groups.

Creating, Saving, and Submitting Measurement Request Groups

You can create and save groups of Strobe measurement requests to be processed at a later time. These collections of measurement requests are called request groups. Each of the measurement requests in a request group is known as a request group element.

Benefits of Using Request Groups

As shown in following figure, a request group is a time-saver; you can repeatedly measure the same set of jobs without recreating the individual measurement requests each time. This function is especially convenient during critical production times, such as the end of the month or business quarter, when a specific set of jobs is regularly run.

A request group can contain a single request that you plan to submit frequently. For example, you may want to measure the performance of an application after each milestone in the development process. You can create a request group containing a measurement request that specifies the application as the target job and submit this request group whenever you want to measure the application, without reentering the measurement parameters. This approach ensures that you measure the application in a consistent manner by removing the possibility of inadvertently omitting or changing any of the measurement request parameters.

In addition, you can schedule a request group, using the approach described in Scheduling a Measurement Request.

Submitting a Request Group

The contents and function of a request group can vary from simple to complex. For example, you may want a request group that measures three different jobs scheduled to run this afternoon. Or you may have another request group with a request group element that will be triggered by the activation of a particular target job.

Planning for Request Groups

The first step is to identify the opportunities for incorporating request groups into the measurement process. For example, do you:

• Measure the same jobs at approximately the same time on particular days?
• Have multiple online regions that you need to measure at approximately the same time on any given day?
• Have several jobs that you need to measure later in the day?
• Want to see the overall performance impact of an application across multiple address spaces?
• Measure the same application regularly during its development?

These are all good situations to use request groups.

Creating AutoStrobe Request Groups

The second step is to create the request groups. How do you go about creating request groups? Plan them and then create them all at once? Or do you create them gradually over time, as a part of your normal use of Strobe? This AutoStrobe function offers you the flexibility of either approach. No matter how you create the request groups, structure them according to your measurement goals. The following table offers some suggestions for defining request groups.

You can create associations between request group elements and measure jobs that are executing in different, but related, address spaces at the same time. For example, you can measure an IMS application that processes data managed by Db2, as shown in the following figure. By reviewing the Performance Profiles for both the IMS and the Db2 regions, you can analyze the complete performance impact of the application. Measuring multiple address spaces can be particularly useful during the testing phase of application development.

Submitting a Concurrent Set of Requests

Once a request group is submitted, the activation of one request can immediately activate one or more related requests. These request group elements are called trigger requests and related requests, respectively. A collection of one trigger request and one or more related requests is known as a concurrent set. When the trigger request becomes active, its measurement session and the measurement sessions of the related requests both begin at the same time and end at the same time.

To measure multiple address spaces concurrently, set up a request group containing one trigger request and one or more related requests. After measurement, Strobe reports the application performance data for each region individually.

After you submit a request group that contains a concurrent set, all related requests in the concurrent set are considered deferred requests until they are activated by the trigger request.

Collecting Measurement Session History

With AutoStrobe, you can collect and store measurement session history information as you create a Performance Profile. When you specify this option, selected measurement session data, and several calculated values, are saved in the history data set. The measurement session data is essentially the information you would see on the Measurement Session Data report in the Strobe Performance Profile. The calculated values are items such as the annual cost per year for a selected job step, transaction, or DBRM.

To minimize the time needed to manage application performance proactively, you can streamline the process of collecting measurement session history by combining the scheduling and automatic Profile creation functions. Once you have identified a target job step, create a schedule for the request selecting the automatic Profile creation option and the measurement session history collection option. When you submit the request, Strobe will perform the following tasks:

• Initiate measurement sessions according to the schedule
• Create the Performance Profile
• Save a measurement session history record for that Profile.

Automating the process makes it easier to manage application performance proactively.

For more information, see Specifying Sample Dataset Information.

Comparing Application Performance Data Over Time

With AutoStrobe, you can collect and store historical information about the measurement session as you create a Performance Profile. When this option is specified, Strobe saves selected historical information for the measurement session, as well as some calculated values, in the history data set, as shown in the following figure. This process is called creating a measurement session history record.

To minimize the time needed to manage application performance proactively, you can streamline the process of collecting measurement session history by combining the scheduling and automatic Profile creation functions. This process is described in Automating-the-Collection-of-Measurement-Session-History. Automating the process makes it easier to manage application performance proactively.

Collecting Measurement Session History

Viewing Measurement Session History

You can view the measurement session history by any one of three views:

• Job name, step name, and program name
• Transaction name
• DBRM name.

You can specify filters and sorting criteria to obtain a more selective view of the measurement session history. Strobe then displays a summary list matching the specified filters in the requested sort order. Each row in this summary list represents a set of measurement session history records. Selecting an item from this summary view produces a detail view listing each iteration of the measurement sessions associated with the summary row.

At this detail level, you can quickly identify application performance anomalies that warrant further analysis, and see the cost savings resulting from application performance improvements.

Comparing Measurement Sessions

By selecting one measurement as a baseline, you can then compare other measurements of the job step or online region to see changes in application performance. Also, you can see calculated costs per run and total cost per year, relative to the baseline measurement.

For more information, see Working-with-AutoStrobe-Measurement-History-Information.

Identifying Measurement Sessions That Exceed Thresholds for Resource Utilization

To create a measurement status category such as CPU time consumed, AutoStrobe users can set a threshold that will cause measurement requests to appear on a Strobe- Status panel field that indicates when the threshold is exceeded.

The measurement requests that exceed the threshold criterion you specified are separated from other completed measurement requests, making it easy for you to identify those requests that warrant further investigation. The following lists the types of measurement data for which thresholds can be set for batch applications:

• CPU Time
• Session Time
• Wait Time
• Stretch Time
• Execution Time Percent
• Wait Time Percent
• EXCP Count
• Total Samples Processed.

For complete information about setting measurement thresholds, see Setting AutoStrobe Measurement Thresholds.

Planning for AutoStrobe Batch Candidate Lists and Batch Monitoring

The AutoStrobe candidate list and monitoring function automates Strobe measurements of batch programs. As shown in the following figure, you need to consider two aspects of this function:

1. Building measurement candidate lists and then adding measurement requests for applications demonstrating poor or abnormal performance.
2. Managing the measurement candidate list, the monitoring and measurement process, and the resulting performance data.

Batch Candidate List Building and Monitoring

AutoStrobe Measurement Batch Candidate Lists

You can issue AutoStrobe batch measurement requests on a job-by-job basis. If you identify the jobs that you think should be monitored, AutoStrobe will begin collecting basis data for them, which is a collection of performance statistics that reflect how the job runs each time. After AutoStrobe has gathered enough data to determine what is normal performance for the job, it will prompt measurement each time the job performance deviates too far from that norm.

If you aren’t sure what job steps should be AutoStrobe monitor candidates, you can determine what job steps in your system might offer performance improvement opportunities by either of two options.

AutoStrobe SMF Candidate Utility PreLoader

The AutoStrobe SMF Candidate Utility reviews Session Management Facility (SMF) summary data sets and using a set of performance thresholds builds an AutoStrobe measurement candidate list. Then you can choose whatever batch job steps on the list that should be monitored by AutoStrobe.

AutoStrobe AutoLoader

We recommend you first run the SMF Candidate Utility, then you can run the AutoStrobe Autoloader to supplement the candidate list. Each time a batch job ends, its resource consumption is noted. If any of a set of calculated thresholds are exceeded, the job is added to the candidate list.

For more information about the AutoStrobe SMF Candidate Utility or the Autoloader, see Building-and-processing-AutoStrobe-batch-candidate-lists.

Managing AutoStrobe Batch Measurement Candidates and Requests

Once you have built a list of batch measurement candidates and/or have selected job step(s) for monitoring and measurement, you can begin managing them. The Strobe- AutoStrobe Candidate Processing panel provides the ability to review performance data about jobs that have been placed on the measurement candidate list and even add AutoStrobe measurement requests from the panel.

The Strobe- AutoStrobe Request Status panel allows you to manage jobs being monitored and measured by AutoStrobe. You can also manage these jobs’ basis data from this panel on the Strobe- AutoStrobe Basis Data panel. To review or delete basis data for jobs no longer being monitored and measured by AutoStrobe, you can go to the Strobe- AutoStrobe Archived Data list panel. Managing-AutoStrobe-Batch-Candidate-Processing-and-Monitoring explains how to use these panels to perform AutoStrobe management tasks.

Planning for AutoStrobe CICS Transaction Monitoring

AutoStrobe provides the following two functions to help you to detect when CICS transactions are performing poorly:

• Create Transaction Candidates
• Monitor Transactions

You can use these functions together to tune your CICS transactions. The Create Transaction Candidates function builds a list of CICS transactions that are candidates for monitoring. You can use this list as input into the Monitor Transactions function, which monitors CICS transactions and triggers a measurement or warning whenever a transaction exceeds an average CPU or response time threshold.

If you already know what transactions you want AutoStrobe to monitor for abnormal behavior, see Using-AutoStrobe-to-Monitor-CICS-Transactions. Otherwise, you can use AutoStrobe to create a list of potential CICS transactions for monitoring. See Using-AutoStrobe-to-Identify-CICS-Transactions-for-Monitoring for information on how to create a list of CICS transaction candidates by submitting a Create Transaction Candidates request.

Where to Find More Information

The following table points you to where in the manual to find full details about AutoStrobe functions and tasks.