Updating GiAPA

To update to the current GiAPA release please

1. Click here: Download latest update

2. Download the zipped iSeries save file, unzip it on your PC

3. Use e.g. FTP to send the save file to an existing *SAVF on your iSeries

4. Terminate GiAPA data collection

5. (To be on the safe side, you may want to back GIAPALIB up first, but it shouldn’t be necessary.)

6. Restore the save file to GiAPALIB:


7. Run command


8. If resulting data from GiAPA analysis is stored in other data libraries than GIAPALIB, command GIAPAINST must be used for these libraries also to convert to new data base layouts.


Incorrect logical read count may cause MCH1210 error in GIAPA192 statement 638.00. IBM has issued PTF MA49235 to correct the error.


V05M00E released October 1st, 2021

The IBM Performance Collector API data should for single threaded jobs be 100 % accurate. However, the API only includes I/O counts (and overflows) for the initial thread. Multithreaded jobs often make most I/Os within other threads, and these I/Os are not included in the I/O-counts of the API.

To compensate for this limitation GiAPA now calculates the sum of physical I/Os of the thread I/O counts retrieved from the “Open List of Threads” API during HotSpots. This has proven to give a reasonable order of magnitude for the total auxiliary I/Os.


V05M00D released July 19th, 2021

Only very minor changes:

A "File not found" message could be issued when running option 14 (analysis) after manually having changed "Product Libary" to contain other than GIAPALIB.

 Explanatory comments added to GiAPA Trial menu. 


V0500C released July 3rd, 2021

Correction of problem for the HTML documents generated by GiAPA Menu Option 20 (Fully Automatic Performance Analysis), which showed special some characters used by non-English languages incorrectly (example: ö).

Apple Mac users only:

IBM did not implement the STRPCO command used by GiAPA Menu option 20 to show the results in html format for Apple Mac computers. To see the results in HTML format, Apple Mac users must

  1. Start IBM’s Access Client connection to the Power i Server.
  2. Open “Finder”.
  3. In the Finder window, press Command-K, which opens the “Create connection to Server” window.
  4. In the input field at the top, run the following statement:   Smb://xxx.xxx.x.xxx/GIAPA , where xxx.xxx.x.xxx must be the IP-address of the server
  5. When connected, a window containing the generated output is displayed.
  6. Double click on the file name GIAPA20 to see the result in HTML format.


V05M00B released May 28th, 2021

Warning message GIA0070 ("Job exceeded defined limit fpr pages allocated")  has been updated and will only be issued for job types B and I. This will avoid the message being sent e.g. for save operations which are handled by tasks (job type V). Field "Pages allocated" can now also show negative values - this change was needed because e.g. reorganization of a file with many deleted records or deletion of a large object could cause "Pages deallocated" to be higher than "Pages allocated" for a job.


V05M00A released May 10th, 2021

Rarely occurring sequence error in program GIAPA149 during data expansion and analysis has been corrected.


V05M00 released April 27th, 2021

A major new version introducing fully automatic performance analysis in the new option 20 of the GiAPA Menu. This is too much to explain here - a picture tells more than a thousand words, so please  see 

          https://www.giapa.com/GiAPA_V5_Menu_Option_20.pdf !

(We have experienced problems, mainly when using Apple (iPad or MAC), when trying to display the results from this new option in HTML format. We are working on finding a solution. In the meantime the results can be seen within the 5250 environment.)


V04M03K released August 10th, 2020

Command GIAPA045 (Where-used for programs) will now automatically display result if running in interactive job.

Automatic analysis of program performance (GiAPA Menu option 19) improved to run more efficiently and to avoid sporadic abnormal termination if scroll down was used after display of last record.


V04M03J released July 20th, 2020

A GiAPA user in Germany wanted to produce management level graphs showing overall resource usage without necessarily having to first run the full expansion and analysis of the collected data. A new command GIAPA055 allows generation of GiAPA standard graphs (Good Morning Report, and Top CPU Jobs) and any user defined graphs based on the raw=unexpanded data.

Error corrected: Jobs opening very many files could cause a sequence error message to be issued in the last step op the data analysis.


V04M03H released June 18th, 2020

The program matching file usage data from different HotSpot intervals has been entirely rewritten, allowing GiAPA’s analysis of the collected data to produce more correct file usage statistics and use less time. The logic of this program is probably the most complex within GiAPA because the data to be matched has no unique keys: A file may be opened several times within a job, and some jobs open hundreds of files. For details on the improvements obtained please follow this link: GiAPA file matching routine.

Also, as a consequence of servers getting more powerful, coping with more jobs running in parallel, GiAPA’s internal tables storing data for all active jobs have been increased to accommodate more jobs.


V04M03G released January 28th, 2020

Correction of command GIAPA050 causing error "Parameters do not match".


V04M03F released January 6th, 2020

Unexpanded GiAPA data members from year 2020 were not shown in correct descending date/time sequence - the sort routine has been rectified.

In connection with the V04M03E change of the default CPU limit for collecting HotSpot information it may be interesting to know exactly how much CPU the GiAPA data collection programs use. A new selection 7 from the GiAPA Menu option 16 will show this in detail.

Error correction: GiAPA Menu option 21, selection 2, might show a slightly too high value for the CPU used in excess of the assigned capacity for uncapped LPARs, if the CPU-assignment contained a decimal.

The text of the warning showed when analyzing GiAPA data from another LPAR was improved/clarified.


V04M03E released December 2nd, 2019

The default CPU limit for collecting HotSpots has been changed from 5.5 % to 4.0 %. The new limit will cause GiAPA to collect call stack and file usage data when a job has used 600 milliseconds within a 15 seconds' collection interval (the old 5.5 % limit coresponded to 825 milliseconds). GiAPA will therefore probably collect around 25 % more HotSpots, thus allowing detection of additional optimization potential.

GiAPA Menu option 19, selection 1 (analyze per user program name across all jobs) will now also show statistics for the most used JAVA classes.

GiAPA Menu option 18, selection 5 is modified to show the full class name for JAVA.

Minor improvements in the editing of call stacks for multithreaded jobs. 


V04M03D released November 5th, 2019

Information in file GIAPA192P3 consolidated meaning that new members will occupy less space.

Help texts for “F1=Optimization tips” edited and extended for Automated Program Performance Analysis – help text is now available for > 95 % of active programs.

Duplicates removed from Lock Wait Report (GiAPA Menu option 19, selection 3).

Clear function for File Check data (GiAPA Menu option 85) improved to do a 100 % clean up.

Export function for unexpanded data (GiAPA Menu option 71) will now include record and I/O statistics from object description for most used files.

Improved layout for total I/O statistics on the Automatic File Analysis (GiAPA Menu option 19, selection 2). 


V04M03C released August 10th, 2019

Important: Data field sent with message GIA0070 changed. In the previous release we announced a new “Allocation Trap Feature” sending warning message GIA0070 to QSYSOPR MSGQ if a job allocates more pages than a user defined limit. After request from a GiAPA user the first data field in the message was changed to 33 bytes with a layout like this


so that it could be used directly as operand after e.g. the HLDJOB CL command. 

The remaining changes were minor justifications, like improved scroll up / scroll down functions and help text clarifications for automated performance analysis, and extension of an internal overflow table used during data collection. 

V04M03B released May 7th, 2019

Minor update: New server models added, and layout of file for rejected records updated.

V04M03A released April 22nd, 2019

Error in GiAPA results:

The column reporting “Maximum Pages Used” has not been able to show values higher than 16,777,215 pages work space allocated by a job. The size of any data written to QTEMP is included in this total, and GiAPA has simply shown a blank value if more pages were allocated by a job – the field was not defined large enough to cope with e.g. the very large SQL table builds on today’s larger servers.

To rectify this, the fields sizes in several GiAPA data base files had to be increased. Therefore, updating GiAPA will take somewhat more time than normally – how much depends mainly on the number of records in the members of file GIAPA143P1 used to keep detailed information per collection interval for all jobs.

You might therefore consider using GiAPA option 82 to remove old expanded data before updating GiAPA to V04M03 (= reduce the time needed for file conversion), and to back up GiAPA data before updating.  

The update routine has been changed: Instead of calling program GIAPAINST after having restored the new GiAPA update save file, you must use command GIAPAINST.

In addition, if you have stored the results of GiAPA analysis runs in other data libraries (and not only in GIAPALIB), you must also run command GIAPAINST against each such library to ensure that the files are converted to the new layouts.

Important GiAPA improvement: “Allocation Trap Feature”:

 This option was suggested by an American GiAPA user experiencing performance problems when a job allocated excessive temporary storage, sometimes adding up to several terrabytes – typically caused by SQL code looping while writing to a work file in QTEMP. European GiAPA sites have reported similar cases. Now GiAPA can warn QSYSOPR if excessive work space is allocated.

It works similar to GiAPA’s well-known and popular LoopTrap feature which sends a warning message to QSYSOPR if a job is looping, using CPU without showing any I/Os.

To activate the Allocation Trap Feature please use GiAPA Menu option 78 to modify the new User Installation Parameter defining the limit for when to send a warning. The shipped default value of 999,999,999 pages is so high that a message probably never will be sent.

Message GIA0070 severity code 60 is sent to QSYSOPR if a job allocates more work space than the number of pages (one page = 4K) specified in the Installation Parameters. If a job continues to exceed the limit message GIA0070 is repeated every 20 minutes.

Sort criteria 16 ‘Max pages used’ from the selection panel for the GiAPA Job Performance Summary report (Menu option 15) can be used to find a suitable number of pages to specify as limit for this parameter. Run the report on data for a few busy days and set the limit to e.g. ten times the highest value reported for a single job.


V04M02F released March 19th, 2019

Problem fixed: "Duplicate key" error message could appear when generating graph data from scheduled job.

Additional data needed for AI-analysis (GiAPA Menu option 19) will be included when exporting collected performance data in unexpanded format (GiAPA Menu option 71).

GiAPA Menu option 24 (Statistics by current user) has been improved to include

  -  new selection 2 combining current user and job user

  -  new F10 option resulting in summary by user name

Text for command GIAPA021 (display user index attributes) corrected


V04M02E released November 6th, 2018

Improved report of programs/jobs in lock wait status (Menu option 19, selection 3).

Batch jobs using commands to generate several sets of graph input data could end abnormally with duplicate record message due to timing problem caused by the high processor speed of very large servers.

Text for actual program activity in automated performance analysis improved.

Repeated generation of call stack pie charts for a generic job name could result in incorrect data being shown.


V04M02D released September 24th, 2018

Error correction: Problem in data collection program code could cause expansion to terminate abnormally with security code error type F.

Text generated for stacked diagrams improved.


V04M02C released August 23rd, 2018

GiAPA Menu option 16 selection panel was improved to keep any specified job name selection.

Both data collection and analysis runs are modified so that the cause of any problems for a GiAPA run (e.g. locks of an object needed) is shown in a new GIA0003 message appearing in the job log.

Problem fixed: F10=Details from Job Performance Summary Report would cause dump if no detail records were kept for the job.

Run date and from/to time was added to pie charts showing active programs of job call stack.

Problem fixed: Generation of graph data would sometimes fail if F21 was used to limit time interval from Call Stack report.

Explanatory texts for active function in option 19, selection 1 (Program analysis) was improved.

 Problem fixed: Use of F4 from option 19, selection 1 (Program analysis) might fail to show previous program, and change of number of HotSpots to show might cause the first record to be skipped.

Code has been added to support the FTP keywords PORT and SECCNN, thus enabling the use of the values *IMPLICIT and *KERBEROS.

 Batch job use of command GIAPA110 to start GiAPA data collection while collection was already active would stop the old collection and start a new. This was changed to cancel the new start if collection is running.


V04M02B released May 23rd, 2018

Last GiAPA version that can run under operating system versions 5.4 and 6.1.

New Lock Wait report available as selection 3 under GiAPA Menu option 19.

Processor type is displayed in stead of processor feature, and display of server type and PVU is added to "Statistics from Data Expansion". Furthermore, to support Power 9 servers, auxiliary storage is now shown in GB and memory size in MB (hitherto MB and KB), and main storage size exceeding 2 TB can now be handled.

Due to a change in Op.Sys 7.3 the generation of some GiAPA diagrams could give error message "Input data incomplete" - this problem has been removed.


V04M02A released Febrary 28th, 2018

User total for seconds of wait time on job queues is defined with "only" 9 digits. Data on a GiAPA customer server exceeded that limit and caused GiAPA expansion run to end abnormally. Now the maximum of 999,999,999 (= 277 thousand hours) will be recorded if the user total has a higher value.


V04M02 released February 15th, 2018

New alternative and powerful ways of analyzing program and file performance

The GiAPA Menu comes now with a new option 19 “Program or file performance analysis”. This option provides complete usage statistics for the programs or files based on HotSpots for all jobs included in the expanded data.

Traditionally GiAPA mainly pinpointed jobs that cause many HotSpots. Option 19 analyzes the data across all jobs and will in addition display/identify a program or file that only appears in a few HotSpots per job if:

- the job is running very frequently, or

- the program or file is used by many different jobs.

In addition the new analysis

- combines more information on one screen, allowing for easier identification of optimization potentials, and

- offers tips that reveal which code modifications may result in improved performance.

The overall idea is of course in line with GiAPA’s original objective: to enable the average programmer or operator to become an expert in application performance optimization.

Please see the description of the new options in slides 10 through 21 of Tutorial 8 !

This release also allows selection on lower case job names (i.e., task names are also supported), and gives a more correct I/O count in HotSpots for data base files of long running jobs being active more than one day.