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( name) MBROPT(*ALL) ALWOBJDIF(*ALL)
7. CALL GIAPALIB/GIAPAINST
V04M00S released 13 Feb 2017
Current user name (when present in jobs like e.g. QZDASOINIT) will now replace the Job User name in file GIAPA144P3 used as input for user defined graphics (or for user queries).
Job Accounting codes con now be made available as UserField1 in file GIAPA144P3, thus allowing user defined graphics or queries to show resource usage (including CPW) based on the job accounting code for the (current) user. To activate this option, simply compile RPGLE source program GIAPA_UE1F in GIAPALIB/GIAPAEXAMP into GIAPALIB as GIAPA_UE1 (UE1 --> User Exit 1). The program will then automatically fetch job accounting codes from the user profiles during the expansion and analysis of GiAPA performance Data.
Limits for rejecting records with unlikely values during expansion and analysis has been changed to accept a higher number of I/O per 15 seconds.
V04M00R released 12 Jan 2017
Error corrected: CPW value calculation problem for LPARs with less than 1 CPU assigned.
Limit for automatic change from seconds to hours in diagram values was changed from 3600 to 10800 seconds (3 hours).
V04M00P released 09 Jan 2017
Error correction: CPW value could not be specified in GiAPA installation parameters.
V04M00O released 06 Jan 2017
GiAPA adds calculation of CPW: A number of our users have wanted to be able to generate line diagrams or bar charts showing CPW usage. This can now be selected when defining graphical output from GiAPA Menu options 16, 21 and 26. To enable this calculation the user must define the CPW value per processor in a new user installation parameter (Menu option 78). Combined with the very simple data expansion user-exit, groups of jobs can be defined based on job name, user or type. This could give CPW usage statistics per hour for e.g. applications, divisions, departments, etc.
The global analysis of file data per job name (Menu option 22, selection 2) has been enhanced with the possibility for using F9 to request a (generic) call stack report for any jobname displayed. The call stack report displayed by this option also allows an analyzed call stack report, or display of an entire call stack.
V04M00N released 17 Oct 2016
Loop Trap function is modified to never report operating system tasks.
Calculation of disk space occupied by deleted data base records has been changed to result in a more precise value (Menu option 52).
Error corrected: GiAPA Menu option 78 would sometimes ignore F3=Exit.
V0400M released 15 Aug 2016
New command GIAPA045: A user wanted to be able to see which jobs ran a given program, and also if CPU usage by that program caused GiAPA to generate HotSpots. Command GIAPA045 was added to allow this
New command menu: A new option 99 from the GiAPA main menu will display a new menu containing all the most used GiAPA commands.
When a call stack only contained a menu, GiAPA might incorrectly show the previous old NonQ-program in stead of blanks. This was correct together with two other minor errors (edited list of rejected performance data records, and display of number of superfluous I/Os).
V04M00L released 15 July 2016
Several GiAPA users have wanted an easy way to delete old data for which an expiration date was not defined. Two commands have been added to facilitate this:
GIAPA819 deletes raw GiAPA performance data data older than a user specified date.
GIAPA829 deletes expanded and analyzed GiAPA data data older than a user specified date.
V02M00K released 09 June 2016
Expansion runs after updating GiAPA to V04M00J could result in error message "User parm E030 not found". Corrected.
V04M00J released 24 May 2016
This new option was included to improved support of installations not having Job Accounting active and running a large number of very small jobs. GiAPA Menu option 21 now includes a new selection 9 that calculates a recommended default CPU millisecond value to be used for the very small jobs starting and ending within a 15 seconds collection interval and therefore not passed to GiAPA by the Performance Collector API. (The new selection 9 is not displayed if Job Accounting is active, but may be used anyway.)
Test installations (identified by not having a valid product license code) will when starting GiAPA see a simplified menu, limited to contain options needed to collect GiAPA performance data, and to export the data for analysis by GiAPA's product suport.
V04M00I released 02 May 2016
Delete function for records in MULTI_LPAR member of input data to user defined graphics failed. This was fixed.
Records having status "Wait" in the Call Stack display can now through the use of F20 be excluded from the statistics shown in the pink line at the bottom of the display, thus resulting in a better overview of job activities during the active time for the job.
Problem solved: Security code installed using command GIAPA009 could result in error message when using certain options of the GiAPA Menu.
V04M00H released 30 Mar. 2016
Timing problem on microsecond level in GiAPA HotSpot data collection for jobs having hundreds of files opened could cause expansion and analysis to fail. This error has been corrected.
Resource Usage Summary (GiAPA Menu option 21, selection 2) would overflow if total job queue wait time exceeded 9999 hours. The field was enlarged to allow max 999.999 hours. Same change was made for the corresponding reports available from GiAPA Menu option 16, selections 1, 2 and 3.
V04M00G released 21 Mar. 2016
GiAPA security code is removed from user installation parameters. Command GIAPA009 must be used to install security code.
Selection on Current User name added to GiAPA Menu option 16, selection 2=Interval details.
*PREV keyword for User Defined Graphs (Menu option 26) did not work correctly for selections on MONTH. Fixed.
GiAPA restart time at midnight adjusted 15 seconds to avoid incorrect overlap into next day.
Any changes needed to security codes during GiAPA update will now be made automatically.
F6 selection to only include intervals with significant CPU usage for Menu option 16, selection 2=Interval details, has been changed from 1 second to 5,5 % CPU usage (this improvement is only important for LPARs with less than one processor).
V04M00F released 15 Feb. 2016
The GiAPA User Manual has had a major revision with hundreds of changes and clarifications.
GiAPA "Good Morning Report" can now be scheduled to run in unattended batch simply by using command GIAPA052.
The list of diagrams uses a timestamp down to milliseconds as sort key for showing last generated or used diagram first. On very fast servers the generation of two diagrams scheduled to run in batch could be created within the same millisecond, thus causing a "Duplicate key" error. This problem has been solved.
The LoopTrap exception list of job names can now through use of F23 accept lower case letters.
V04M00E released 06 Jan. 2016
Command giapa140 (analyze data in batch) improved to provide more correct expansion statistics. Run time for expansion job optimized.
Use of F21 to set time limits for call stack analysis could result in abnormal end. Fixed.
Cosmetic improvement: Code modified to avoid various error messages (MCH2601, CPF7054, MCH2401, CPD0078) in job logs during data collection.
Automatic data collection termination for restart at midnight changed from 0:00 to 23:59
V04M00D released 23 Dec. 2015
Job GIAPARESTR could enter message wait with CPF1342. Corrected.
V04M00C released 18 Dec. 2015
New command GIAPA052 offers an easy way to run the most popular graphs interactively or in scheduled batch - see description in the updated GiAPA User Manual.
New command GIAPA070 runs directly on unexpanded data, producing file containing extensive CPU usage information per hour and day, and optionally a line diagram showing CPU usage graph per day or per month - see description in the updated GiAPA User Manual.
Start-up time for data collection optimized for job accounting information.
The standard diagram showing CPU and I/O usage when F11 is used from GiAPA Menu option 16 and 21 has been improved to also show total disk I/Os.
Call stack analysis on one or two levels has been improved to disregard last user program if last user program is in one of the last called levels.
Collection run statistics can now be shown even if data collection was ended abnormally.
Text generated for user defined charts was improved.
Error in RPGLE compiler could cause message MCH1210 in program GIAPA115 job GIAPAHOTSP. Problem avoided.
Default value for command GIAPA130 keyword STOPRESTRT is changed from N to Y, because this keyword (allowing user-selected immediate restart of GiAPA) is not needed any more. This means that GIAPA can be ended by using command GIAPA130 Y.
V04M00A released 21 Aug. 2015
Statistics for current user (Menu option 24) now appears sorted descending on CPU time used.
New F6-option from GiAPA Menu option 16, selection 2 could cause loop - error corrected.
Job and User summary graph on CPU time with values exceeding one hour might fail to convert seconds to hours. Corrected.
V04M00 released 11 Aug. 2015
This new version represents the first step towards a GiAPA including graphical user interface. We are not there yet, but some basic structure needed for GUI was included, and we expect to release GUI version of all the most used reports later this year. The GiAPA Menu has been completely renewed, partly as a consequence of our new GiAPA logo.
User installation parameters are moved from menu option 88 to menu option 78, where they logically belong. Existing user parameter values are kept.
A few more objects must be omitted to avoid abnormal end if GIAPALIB is backed up using “save while active” during performance data collection. For version 4 please specify OMITOBJ((GIAPALIB/*ALL *USRSPC) (GIAPALIB/*ALL *USRQ) (GIAPALIB/GIAPA115* *USRIDX))
We are often asked by new users how they can verify if the GiAPA data collection is running. To accommodate this we added selection 5 to menu option 81. It will display the number of records per type, and may even be used for the member actually receiving data.
CPU time usage shown in diagrams have hitherto been in seconds. The generation of charts has been improved to show the time in CPU hours if the average of the values exceeds 3600. At the same time CPU percentage has been changed to include an optional decimal.
When GiAPA Menu option 21 is used to see which jobs used the most CPU during certain time intervals, several jobs having the same name may be shown. It has not been straight forward to find e.g. which QZDASOINIT job to look at. To cope with this, a new function key option has been added to GiAPA Menu option 16, selection 2. Using F6 will now give a report where each interval only shows jobs having used at least 1 second CPU, sorted descending by CPU usage.
A new GiAPA Menu option 89 will tell if the current user profile has sufficient authority to start GiAPA data collection.
A few menu options were not used anymore and have therefore been removed.
The rules of the game for physical I/Os shown on the Job Performance Summary report have been documented. For multi-threaded jobs, the IBM Performance Collector API only supplies the I/Os for the initial thread of the job, although most I/Os normally are made by other threads. To get accurate disk I/O totals for multi-threaded jobs we recommended activating Job Accounting. This enables GiAPA to fetch the correct number of auxiliary I/Os at job end.
Command GIAPA020 keyword USRINX have been changed to follow the IBM standard naming USRIDX.
V03M01L Released 14 May 2015
As the servers get larger, so do the applications. In response to requests from customers the maximum number of opened files supported by GiAPA within one job has been increased from 800 to around 2.400, and the number of threads supported within a job has been increased from 999 to 5000.
GiAPA expansion needed job control rights, because the job used CHGJOB to set a lower priority. Now expansion can run without any special authority.
The default user parameter defining if call stack should be retrieved for a treads being in wait state was changed from *YES to *NO.
V03M01K released 13 Apr. 2015
LoopTraps could be generated too early if tasks use much CPU in one data collection interval after not having used any resources in several intervals. This problem was fixed.
NEW REPORT listing of records rejected during data expansion and analysis: The records from performance collector APIs contain very rarely values that simply cannot be true, like a CPU percentage of several thounsand percent. To avoid getting false summaries, GiAPA will reject such records, and the statistics for the expansion (option 5 from the panel where expanded members are selected) will show an error message in red color telling the number of records rejected. A new F21 now displays such rejected records.
V03M01J released 10 Apr. 2015
Special job type code H for HotSpot on Job Performance Summary selection failed to exclude *BATCH, *INTERACT, ... summary records.
Submitted FTP transfer af graphics data to "master" LPAR might fail after April 1st. Corrected.
Window showing many INFOR M3 user names overlaying threaded call stack report has been moved one line up to avoid overlapping function key line.
FTP password for receiving LPAR did not accept case sensitive passwords. Fixed.
V03M01I released 17 Feb 2015
Expansion of consolidated members has been modified to avoid skipping records.
Tasks using less than one millisecond CPU are now ignored by GiAPA.
Generic LIST/NOLIST selections in user defined graphics used incorrectly only length of first value.
Graph on CPU seconds generated from menu option 21 showed value being 1000 times too low.
Column heading for M3 User/Class statistics (Menu option 25) has been clarified.
V03M01H released 05 Dec. 2014
Last position of field "Current user" (last field on line) was missing on "Details per Interval" report.
Analyzed call stack report failed to appear in V03M01G.
Negative page allocation (due to incorrect input from API) reset to zero.
V03M01G released 26 Nov. 2014
A new GiAPA Menu option 24 “CPU usage per current user” will generate CPU usage statistics per current user and job for jobs like QZDASOINIT, which starts under a general QUSER name, but then have different users attached. Observe that the data must have been expanded with option “Keep detailrecords?” = *YES to allow generation of these statistics.
Major change to collection of HotSpot data on thread level: We have been proud of GiAPA’s ability to collect comprehensive performance data and still only use minimal resources. For installations predominantly running single-threaded jobs the CPU usage normally is less than 0,1 %. But on installations running e.g. ERP software written in JAVA, where jobs may have over 100 threads, each having its own call stack, we have seen GiAPA CPU usage exceeding 2 %.
To minimize CPU usage the rules for collecting HotSpot information on thread level have been changed. Extensive tests have shown that data collection on servers running merely only multithreaded jobs now is down to 0,2 %, which we consider acceptable.
The resources used by retrieving the call stacks and open file information for threads were hitherto controlled by two installation parameters.
A maximum limiting how many threads each HotSpot should collect data for (this parameter has been kept).
A lower limit for the CPU usage of the thread in percentage of the total CPU used by the job. This installation parameter has been removed, because it appeared not be precise enough to select only currently active threads, especially if the jobs had been active several days.
The installation parameters controlling when call stacks should be retrieved are now
A maximum limiting for how many threads each HotSpot should collect data for a job (default = 5 threads).
A miminum CPU milliseconds that a thread should use within the last 15 seconds before call stack is retrieved (default 100 milliseconds).
A yes/no option if call stack and file information should be collected for threads being in WAIT state when the HotSpot is taken. Default is 0 = *NO.
Threads having used resources frequently reach wait state before the HotSpot occurs, this probably making the call stack less interesting. A value of 1 = *Yes causing the HotSpot collection for multithreaded jobs to also collect call stacks in wait state may result in GiAPA collecting so many call stacks that CPU and I/Os consumption is increased significantly without really providing much more relevant information.
The installation parameters can as usual be adjusted via the GiAPA Menu option 88.
In addition to above installation parameters, GiAPA will now skip any thread where the CPU usage is less than half a second since the current data collection started.
These new settings have proven to save quite some resources when running with the default parameter values. Collecting more details for a larger number of threads will obviously use more resources, but the user can now much better control the collection, so resource usage normally stays very low while still allowing more granular analysis in special cases.
Another change in V03M01G means that the CPU used by jobs and threads (shown in “Call Stack and Thread Overview for Job”) now show the resources used since the current data collection was started. (It used to show the total CPU time used by the job/thread since the job started.)
- - - - - - - - -
Error corrected: Some graphs generated from data shown from GiAPA Menu option 18 might hitherto show incomplete key values.
The possibility for generating graphics reflecting pages allocated was added to GiAPA Menu option 16.
The appearance of graphics for M3/Movex statistics was enhanced.
Data collection might end abnormally with message CPF0A43 “Performance data not available” if the server was so overloaded that no data was collected by the API, or with message CPF0A45 “Cannot copy performance data” if GIAPALIB was being saved, and *USRSPC objects were not excepted from the backup. GiAPA will now accept up to 5 consecutive messages before terminating.
V03M01F released 23 Sep. 2014
Error correction - only important for customers using INFOR's M3 software: GiAPA expansion and analysis could fail with message MCH1210 if more than 9 users simoultaneously were using the same class.
V03M01E released 16 Sep. 2014
Important new feature for M3 customers: GiAPA can now from the M3 server view "Grid" fetch the name of the end user who currently is running in the M3 class active within a thread causing a HotSpot. A new function key option (F16), added to call stack reports, can therefore be used to show who was using the M3 class running in the thread at a given time. Furthermore a new GiAPA Menu option 25 offers statistical reports telling how often the different users and/or classes were recorded within GiAPA HotSpots.
Any thread with status "RUN" within multithreaded jobs triggering HotSpots will now be processed, independent of the CPU time used by the thread. This change is an improvement for jobs running across several days and frequently initiating new threads, which otherwise could be ignored.
Sort descending on date was added to member list for expanded and unexpanded members to export or manage (Menu options 71, 72, 81 and 82).
V03M01D released 04 Sep. 2014
Operating system tasks sometimes change job name during the run. This could cause GiAPA to interpret the task as new, thus giving incorrect statistics for the first interval of the "new" task. The logic to handle this was improved to cope with this odd problem.
GiAPA Graphics generated in a new data library might fail due to file GIAPA262P1 missing. A duplicate object for the file was added.
The first instead of the selected member name was showed in the title of the Graphics Selection Display (Menu option 16 selection 4). Corrected.
Job status has been added to panel showing the *INITIAL thread for multithreaded jobs call stack report.
Detail records will now be kept for intervals where transaction time exceeds one minute (Job Summary Report + F10).
Logic in connection with termination of performance data collection has been improved to avoid loss of the last few accounting records or locking of the file used to transfer end-of-job accounting information.
The limit for number of different object names within one performance data analysis run was changed from 32767 to 65535 (maximum for the internal object name table).