Create a form
Start the IMS Performance Analyzer ISPF dialog.
On the primary option menu, select Report Forms.
The Report Forms panel lists existing forms.
Enter NEW on the command line to create a form.
In this example, we’ll create a form that ask questions about CPU-intensive transactions; colloquially known as the CPU “heavy hitters”.
Enter the form name CPUHEAVY.
You can create a list form, which reports individual transaction instances, or a summary form, which uses statistical functions to summarize transactions. Or you can model the new form on an existing list or summary form.
You can also choose which sets of fields to include in the form.
In this example, we’ll create a summary form that includes IMS fields.
Select the Summary type with the options Include IMS fields and Specify Field Categories.
On the next panel, we’ll specify which categories of IMS fields we want to include.
We’ll include fields that identify transactions. This category contains character fields, such as names, types, and IDs, and some time-of-day fields.
Select Identification, and then press Enter to create the form.
Edit the form
This is the new form.
All new forms are based on a default form that is supplied with IMS Performance Analyzer. The default form offers a starting point for new users.
The top-to-bottom order of fields in the form reflects the left-to-right-order of columns in reports. The field at the top of the form will be the first column of the report.
The “End of Report” line marks the end of the fields that will appear in reports based on this form.
The IMS fields that we chose to include are listed below the “End of Report” line. You can select fields below the EOR line and move them above the line.
Enter a description for the form, “CPU heavy hitters”.
Set Precision to 6. This is the number of digits that reports will show in the fractions of a second for time-based fields. A Precision value of 6 means that reports will show times to microseconds.
Set Digit Grouping to SEC. Time-based field values will be reported in seconds with a separator to mark the decimal point, and no other separators.
Notice the EOR reset message in the top-right corner. Changing details such as precision affects how many fields can fit within the number of characters specified by the Page Width field, which affects the position of the EOR line.
We’re going to summarize performance by program name.
Overtype the default TRANCODE key field with PROGRAM, and then press Enter.
Typically, depending on your IMS configuration, many transaction codes might invoke the same underlying program. Summarizing by program name can offer useful insights, especially to the IMS application developers who are responsible for those programs.
If we weren’t sure of the field name, we could have pressed PF4 and picked PROGRAM from a prompt list of field names.
We’ll keep transaction count as the second field, but we’ll delete all the other fields in the default form.
You can use the DD line action to delete a block of fields, just like deleting a block of records in the z/OS ISPF editor.
Enter DD next to the third field (INPUTQ), and then scroll to the bottom of the form.
Here we see the “identification” IMS fields that were included in the new form when we selected that field category.
We didn’t actually need to include those fields, because we don’t need those fields for this example. We did it just to show that you can selectively add categories of fields to new forms. You can add any fields you like while editing a form, but this feature offers an easy way to populate a new form with the fields that you are likely to need.
For this example, however, we’re not going to use these fields.
Delete them all: enter DD next to the last field.
We’re left with an almost-empty form. Let’s insert the fields we need for this example.
Enter I next to TRANCNT, to insert a new field.
Enter the field name CPUTIME, enter D for Descending under the Sort Order column, and enter TOTAL under the Function column.
Reports based on this form will show total CPU time by program, and the programs will be sorted in descending order of total CPU time. That is, the programs with the highest total CPU time will be at the top of the report. Here, total CPU time is the sum of the CPU times of the IMS transactions that ran that program.
Note that the key field, PROGRAM, specifies an ascending sort order. However, we’ve specified a sort order on a non-key field, CPUTIME, so the sort order of the key field is ignored.
Let’s insert average CPU time after the total CPU time.
Insert a new row, and then enter CPUTIME with the function AVE.
Insert another new row, and then enter CPUTIME with the function RANGE.
The RANGE function enables you to ask questions about ranges of field values.
To specify range parameters, scroll right by pressing PF11.
Enter >0.2 under the From column and PERCENT under the Report column.
Here, we’re asking, “What percentage of transactions (that ran this program) had a CPU time greater than 0.2 seconds?”
When you press Enter, the label “Seconds” appears next to the CPUTIME field, identifying the units of the range values.
Let’s repeat that field with a different range.
You can use the R line action to repeat a field, just like repeating a record in the z/OS ISPF editor.
Enter R next to the range-based CPUTIME field.
Overtype the From column value with >0.5.
Here, the question is “What percentage of transactions had a CPU time greater than 0.5 seconds?”
These types of questions are useful for contractual agreements that require a certain percentage of transactions to run within a certain time.
We could use the same technique to ask similar questions about response time.
Add a third range, for CPU times greater than 2 seconds.
Okay, we’ve added three columns to the form for CPU time ranges. The range values match our expectations for transaction CPU times. Anything over 0.2 seconds is not good. Over 0.5 is bad. Over 2 is ugly!
Ideally, we’d like to see 0% in all three report columns. Nonzero values in these columns will give us a quick indication of problems in each range.
You can copy fields in a form, just like copying records in the z/OS ISPF editor.
Enter C (Copy) next to the CPUTIME field with the AVE function, and then enter A (After) next to the last range-based CPUTIME field.
On the new copy, overtype the AVE function with MAX.
The MAX function shows the maximum value of a field.
Here, the MAX function answers the question, “What’s the single worst CPU time?”
Insert average, range, and max columns for the overall IMS transaction process time (PROCESS field).
This is the finished report form.
For more information about the functions that you can specify in a summary form, see the IMS PA documentation topic “SUMMARY Report Form” in IBM Knowledge Center.
Let’s use this form to create a report.
Exit the form editor.
Notice that our new form now appears in the list.
Create a report set
Back at the primary menu, select Report Sets.
Let’s create a report set.
Enter NEW on the command line of the Report Sets panel.
Name the report set CPUPROF, for CPU profiling, including reports based on the CPU heavy hitters form that we’ve just defined.
Select the Log type; this report set will use IMS logs.
Enter a description for the report set, “CPU profiling“.
Enter COLLAPSE on the command line, to collapse the tree of available reports.
Enter S next to Form-based Transaction Transit Reports.
Enter S next to Summary.
Select CPUHEAVY as the form for this report.
In this example, we’ll create a human-readable report.
We could also use the form to create an extract in comma-separated values or similar format for use in other applications.
Submit the report
Enter RUN on the command line to run this report.
In this example, we’re only running a single report.
More typically, in a production environment, you’d define multiple reports in a report set, and then use IMS PA to create all of those reports in a single pass of the log data.
Specify the run options for the report, such as the IMS system name.
Defining IMS systems to IMS PA is straightforward, but it’s outside the scope of this recipe. For details, see the IMS PA documentation topic “Systems and Files” in IBM Knowledge Center.
When we defined this particular IMS system to IMS PA, we explicitly specified its log data set names, so we don’t need to use DBRC to select the logs.
We’re not going to specify a report interval, so the report will be based on the entire contents of the logs.
Press Enter to create the JCL.
An ISPF edit session opens, showing the JCL.
Scroll forward to see the IMS PA commands.
The IMSPALOG SUMMARY command reproduces the details of the form that we defined earlier.
The blue highlighting shows additional options that we didn’t define in the form.
Let’s take a brief look at those additional options:
- TOTALS is not relevant here, because our form has only a single key field.
- INTERVAL does not apply, because our form does not summarize over time intervals.
- STARTLVL and COMPLVL specify which transactions to include in the report, based on what level of information the input log contains about when the transactions started and when they completed. STARTLVL(2) and COMPLVL(3) are the default values.
- TRANMIX specifies which types of transactions to include, such as Fast Path or BMP. TRANMIX(1) includes all types of transactions.
For more details on all of these options, see the IMS PA documentation topic “SUMMARY: Transaction Transit Summary report and extract (Form-based)” in IBM Knowledge Center.
Enter SUB to submit the JCL.
View the report
Here’s the report.
In addition to showing us the top “CPU heavy hitter” programs, the report offers many useful insights into the performance of those programs.
- Transactions that ran the BANKING program used the most CPU time. None of those transactions used more than 2 seconds of CPU time. While process times are always higher than CPU times, in this case, the process times are much higher, and the maximum process time of 187 seconds deserves further investigation.
- Of the top 8 programs in this example, the MOBILE program has the highest transaction count, but also the lowest average and maximum CPU times. While each of these transactions uses a relatively small amount of CPU time, the large number of transactions results in a high total CPU time.
For more information about IMS PA, see: