GiAPA is rather flexible. When shipped, the parameters are set to a reasonable average value suitable for most installations, but the limits for e.g. how many resources a job may use before it should be checked and reported varies of course depending on applications and machine size.
This is a list of some of the possibilities for modifying the way GiAPA works:
When starting GiAPA, the user can specify if, and limits for when, looping jobs should be reported. A list of jobs that never should be reported looping is available.
Exception reports are normally wanted - installation parameters control the limits defining what an exception is. Examples:
- how much CPU should a job use before GiAPA takes a closer look at the job?
- how many records should a file access before GiAPA should keep the details for the file?
- how many call levels of program stacks should be kept?
- for how many threads should call stacks be requested for multi-threaded jobs?
It may also be specified which jobs never should be analyzed in details, although they use a lot of resources (Typical example: Mirroring software).