GiAPA Release Notes

New GIA2701 message suggestion use of command GIAPA902 will appear if generated graph cannot be displayed automatically.

If security code invalid for actually used serial number, an explanatory message will be shown on the GiAPA Menu.

In rare cases where long object names (typically e.g. java names) cannot be found, a message will explain the problem.

The steps involved in running a free GiAPA trial were optimized.

As jobs process an increasing number of records and rows, certain columns in the "Details for Jobs" report needed to be expanded to accommodate all the digits in the numbers of I/Os.

Under rare circumstances, a user queue timing issue could cause an abnormal termination during the expansion and analysis of collected resource usage data.

The GIAPA200 command (Submit job generating automatic performance analysis report) has been enhanced to allow the specification of an input member name. It also enables users to define whether the resulting graph should be overwritten daily, weekly, or monthly.

The GIAPA012 command (Watch job through additional HotSpots) has been updated to accommodate cases where also the user name is unknown.

Increased focus on security risks means that the save file for new installation of GIAPA now is shipped without adopted QSECOFR authority for the programs used to collect data. This change removes the only possible security risk within GiAPA: the option of defining a user exit program to be called during data collection. Such a user exit program could contain unwanted code. The optional user exit program is intended for e.g. defining department codes per user profile names, an option paving the way for generating graphs or statistics per department, per application, etc.

As a replacement for use of adopted QSECOFR authority for the GiAPA data collection, CL source code to a program GIAPAUSER is supplied in the GIAPALIB/GIAPAEXAMP source file. This program may be compiled and called to create *USRPRF GIAPAUSER, which can be specified as USERNAME for GiAPA data collection jobs running command GIAPA110. Alternatively the comments in the source code can be used to see which authorities are needed to run GiAPA collections of resource usage data.

Command  GIAPA060 (“Merge two graphic data files”) was not being used and has been removed.

“General Terms and Conditions of Sale and Delivery for GiAPA” has been updated to include the following text: iPerformance will in connection with the release of a new version / model of GiAPA deposit a copy of the source code in escrow known to the law firm Joachim Brøns, Amagertorv 33, 1160 Copenhagen, Denmark, telephone 40785796.

The new command GIAPA200 “Submit batch run of option 20, selection 1 for last date collected” is the result of a suggestion from a GiAPA customer, who wanted to generate the automatic performance analysis html-report for the previous day in an unattended night batch job scheduled to run after command GIAPA140’s expansion and analysis of collected GiAPA data.

GIAPA200 will select data for the latest analyzed date found in the library specified, but excluding any data collected on the day where the command is running. Intended to show results for yesterday, GIAPA200 will only select data from one day. The result may even be sent attached to an Email.

The programs behind commands GIAPA021 and GIAPA031 (also available from GiAPA Menu option 99) were rewritten, resulting in a better and more informing display of the attributes for User Index and User Space.

Error correction: The update to version 6 introduced an error: On two displays the CPU percentage calculation for individual jobs shows a value 10 times too high. Because the error occurred within the program displaying the data, re-expansion of collected data will not be required to obtain the correct results after this modification is installed.

Error correction: On the “Automatic Performance Analysis” displays, the collection time displayed may be too long when only parts of one or more data collections were included in the expansion and analysis.

An American user kindly shared some results from GiAPA’s SQL Observer with us. It showed that certain Plan Cache record types apparently could occur more times for an Access Plan that what was assumed when SQL Observer was designed – several showed 9 times, being the maximum value. Therefore, this count has been changed to allow two digits.

Data Library default value can be selected: Several of our customers prefer to store GiAPA performance data in a special data library rather than in GiAPALIB, which is the standard default value. If data area GIAPALIB/DTALIBNAM TYPE(*CHAR) LEN(10) is created specifying another library name for the VALUE keyword, that name will be used as default data library when using the GiAPA Menu.

The layout of file GIAPA612P1 used by the new SQL Observer feature announced with version 6 was changed in connection with the improvements for display of stored Plan Cache data announced with V06M01A. Unfortunately this change made it impossible to keep all old data in file GIAPA612P1 (error message "Duplicate key" might be generated during the update of the file layout). To avoid this problem, the update to V06M01B will delete all old data in GIAPA612P1.

Major improvement to GIAPA's SQL Observer: Sufficient testing of this feature was difficult due to our lack of larger production data bases accessed by SQL. Having gained some experience through both users and IBM assisting us, the match routine between the data from different Job Watcher tables and the dumped Plan Cache data has been completely rewritten. SQL Observer will now report Plan Cache dumps for all jobs selected when starting the data collection, even when more jobs use the same SQL against the same data and therefore shares access plan.

Error corrected: Automatically generated graph for CPU by job and user did not show Serial and LPAR number.

Error correction: Command GIAPA610 of SQL Observer (= GiAPA Menu option 61) ended abnormally when length of SQL statements exceeded 32 K.

Keyfields for file GIAPA612P1 modified (New layout causing new version number).

Automatic deletion of old “Current User” records in GIAPA612P5 added.

Results from larger tests of the newly introduced SQL Observer feature inspired us to various improvements in the data collection, whereby now also the unique Plan Cache numbers for access plans and the number of dumps available are shown. Furthermore a redesign of the files/tables containing the SQL Observer data enabled a more efficient data collection.

However, please observe that this update will delete any earlier collected SQL Observer data.

Internal arrays for storing all resources used by all jobs during the standard GiAPA data collection have been increased to accomodate larger servers / LPARs, and internal user spaces will be kept for analysis if data collection should end abnormally.

Only a few changes to the security code routine in connection with SQL Observer.

Repeated appearance of page documenting Plan Cache dumps for a Job and QRO-code corrected.

Option *NONE (meaning “Select all”) added to keyword JOB in command GIAPA610 (= compliance with command ADDJWDFN).

Duplication of lines on SQL Observer’s list of user names are removed.

(A few only “cosmetic” modifications are not listed here.)

A line showing values for SQL Observer (Job GIAPAJWCOL) has been added to the totals for CPU usage shown in GiAPA Menu option 16, selection 7.

Error correction: Date calculation for deletion of obsolete Plan Cache dumps could cause abnormal end around change of year.

A keyword parameter in command GIAPA610 has been updated to match all options in CL command ADDJWDFN.

The intensive and increased use of SQL has made optimization of frequently used SQL statements one of the most rewarding ways of saving server resources. GiAPA never offered analysis of the efficiency of the Access Plans selected by the Query Optimizer, because this function is offered by IBM’s “SQL Performance Center” in the Database section of the Access Client Solution (ACS) tool.

However, the Plan Cache data needed as input for IBM’s performance analysis is not dumped automatically given it would consume excessive resources. An IBM performance expert recently suggested that a tool offering an automated and user-controlled dumping of Access Plans that might be wanted for analysis could be a popular option. This idea is implemented as the “SQL Observer” in GiAPA version 6.

We trust that you will find this new feature is rather powerful. However, to get the wanted result it is very important to understand the somewhat tricky “rules of the game” for collecting Plan Cache data. Therefore, please see the documentation in the User Manual describing GiAPA Menu options 61 – 63, or use this link https://www.giapa.com/images/PDF_files/SQL_Observer.pdf.

-   -   -   -   -   -   -   -   -   -   -   -   -  

Function Type USR added: The table of function types has been updated with the new USR = User (Type of active job).

Error correction: The calculation of CPU percentage in the Job Summary and Interval Details reports was incorrect in certain cases when allocated CPU resources was less than 1.

Sorting Data Base Files: The SORTDB command (from QUSROOL) was moved to GiAPA Menu option 99.

Totals for automated analysis improved: The user selected limit for minimum run time savings to be selected is now also reflected on the page showing total savings (GiAPA Menu option 20, selection 4).

Many smaller changes: Several minor updates were made – the details are not listed here. A total of 52 programs and 16 files were modified or added.