Re: PFA (Now, an HZR subject)
Runtime Diagnostics is not a monitor. It is a point-in-time diagnostics tool that you use when there is a problem on your system as an aid to diagnosing the problem. The fact that you are using runtime diagnostics when there are no issues on your system and it is returning no events is good! See How Runtime Diagnostics Works in z/OS Problem Management for more information. Also, from the redbook Extending IBM z/OS System Management Functions with IBM zAware: If you choose to automate calls to Runtime Diagnostics, such as invoking it every hour, it is likely that events will be issued even though you are not experiencing soft failures. Some of the events also occur when the system is behaving normally, but they are not a real issue unless you have noticed that the system is having problems. These events are probably not indicative of a system problem at that time and you might waste time investigating these events when no system problem is occurring. This point is especially true for the address space execution and global resource contention categories. For more information about starting and controlling Runtime Diagnostics, refer to z/OS Problem Management, G325-2564. Karla Arndt z/OS Predictive Failure Analysis and Runtime Diagnostics -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PFA
/pfapath indicates the home directory of the pfauser. So, yes, /u/pfa is fine if your pfauser is pfa. See the book z/OS Problem Management for Steps for Installing PFA. And yes, using a zAAP is recommended so that the java functions can be offloaded to it. Karla Arndt z/OS Predictive Failure Analysis and Runtime Diagnostics -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PFA_ENQUEUE_REQUEST_RATE
Mark, I honestly cannot respond as to how to investigate CATALOG-specific problems. I hope someone else can respond to that part of your question. Looking at the numbers you have from the PFA check and Runtime Diagnostics results below, it looks like CATALOG is really very consistent across all 3 time periods for the rate of enqueues per the amount of CPU used. So, PFA determines that the really low current rate is unexpected and significantly lower than normal. Like you said, PFA then calls RTD and if RTD corroborates that there might be something wrong with that address space, the exception is issued. In order for RTD to issue the enqueue contention event, the address space would have had to have been waiting for 5 seconds. A few questions for you: 1) How often does this occur? 2) Does it occur randomly or at a certain time of day/week/month? 3) Does it occur when a certain workload is running? 4) Do you have all the PFA and RTD PTFs for R13? (I don't know of any particular fix that would change your results especially since the results look valid, but I always encourage everyone to keep up-to-date with PFA PTFs.) I cannot answer the question as to why CATALOG would be in enqueue contention to determine if this is a real problem or just the way CATALOG works in your environment. After you investigate it, if you determine that it's just the way it works and you'd prefer to avoid the exceptions by having PFA ignore that address space, you can put CATALOG in the EXCLUDED_JOBS file for that check. Karla Arndt IBM PFA and Runtime Diagnostics for z/OS -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Runtime Diagnostic messages
Runtime Diagnostics is a point-in-time diagnostics tool that should be used when you think there is something wrong on your system and don't know what it could be or where you should start your investigation. It is invoked by F HZR,ANALYZE (starting in R13) after it has been started. Prior to R13, it was invoked using its start command. PFA uses Runtime Diagnostics to corroborate a too low condition is some of PFA's checks. When PFA thinks a rate is too low, it invokes Runtime Diagnostics and if there's an event, issues the PFA exception and includes the Runtime Diagnostics events in the PFA report. This output is what you would have been seeing in the PFA_SMF_ARRIVAL_RATE check's report. There has been a lot of recent work to reduce the number of exceptions from PFA. Therefore, I would encourage you to get all the latest PFA PTFs and to stay current on those. There are some additional PTFs that should be available soon in this too low checking as well. More information on both Runtime Diagnostics and PFA as well as the integration between them can be found in z/OS Problem Management. Karla Arndt z/OS Predictive Failure Analysis and Runtime Diagnostics -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yan: keeping csaAll and csaTotals for a long time in pfa
Please open a PMR and pax the PFA_COMMON_STORAGE_USAGE/data directory to us and we'll take a look at it. All of the PFA files should be self-maintaining and I'm not aware of any open issues in this area. Also, please make sure you have all the latest PFA PTFs. There have been a lot of changes lately to reduce false positive exceptions. Karla Arndt z/OS Predictive Failure Analysis -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
