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:
RSTOBJ *ALL GIAPALIB *SAVF SAVF(savfname) MBROPT(*ALL) ALWOBJDIF(*ALL)
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.
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.
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.