Re: Authorizations needed for OpsNav SQL Performance Monitor

Be clear, the noted APAR was mentioned to prevent a mis-reference; instead it seems I may have caused one.? That APAR is *not* the problem encountered in the original posting. I mentioned the APAR because I expected someone might search the IBM APAR database and find it and describe it as an 'apparent match', when in fact it is not related.

The origin of the missing authority to that file, is by some other origin. Perhaps the user QAUTPROF is not the owner of that file on the failing system; I did not notice that the reason the authority was *ALL due to that profile being the owner. And then I should have suggested *instead*, that the recovery should have been:
CHGOBJOWN QUSRSYS/QAUGDBLL *FILE QAUTPROF CUROWNAUT(*REVOKE)

With regard to that APAR and no PTFs found in searches...
Finding no PTF implies no PTF exists [but not if/what future release the fix might be included]. That specific APAR addresses a problem with authority to the QRCYiasp libraries for the user QAUTPROF. The correction could be done as part of the i5/OS, regardless that the APAR was both written against and remains with, the client GUI feature 5722XE1. And FWiW the internal tracking for that APAR has no correction 'in plan' which means its closing status of UR1 = "fixed in a future release" is IMO little different than having been recorded instead as PRS = "permanent restriction".

Some more comments relating to the question of APAR corrections...
Unfortunately the APAR & PTF externalized tracking information lacks support for a clear distinction of what base release the correction was provided. For any PTF that may be in progress of being created, or either an announcement or the general availability of a new release into which a correction for a PTF is eventually provided, _no information_ would be made available. Providing that information is an effective statement of availability; not generally permissible except as part of legally reviewed announcements, to avoid pre-announcing something that might never happen for whatever reason. IMO the APAR should be updated after a PTF is released or the new release into which its fix has become Generally Available, to indicate that release where one should expect the problem will no longer exist; alas, they are not -- I doubt it has ever been articulated as a concern at COMMON or similar. So even if the release v5r4m0 had been the release into which the fix was provided [irrespective of any existing PTF(s)], that information is not currently made available. Some similar information is provided however. If a PTF *was* provided in release n, then the fix must exist in n+1. Such PTFs are identified/tracked in a cross-reference listing which is publicly available for upgrade planning purposes. Thus you can know if you will _not_ have a fix in n+1 [probably a separate listing for n+2], but you can not know if a defect will _no longer exist_ in n+x unless there is a PTF somewhere between n & n+x; because, again, theAPAR does not show a "release fixed in" value -- even after that release is GA.

Regards, Chuck
-- All comments provided "as is" with no warranties of any kind whatsoever.

Dan wrote:

On 5/22/07, CRPence <crp@xxxxxxxxxxxxxxxxxxxx> wrote:

Seems the necessary authority is missing for the functional profile
for the feature.? Grant the expected authority of *ALL to the user
QAUTPROF for the noted file; i.e. GRTOBJAUT QUSRSYS/QAUGDBLL *FILE
QAUTPROF *ALL
There is a seemingly similar, but unrelated error documented on the
IBM support page; in case someone might redirect to the APAR= SE26496
http://www.ibm.com/systems/support/i/databases/index.html

Thanks Chuck!

"This problem will be fixed in a future release." - Is this an i5/OS release
or an OpsNav release?

Is there a way to know whether available PTFs and or service packs address a
problem identified by a specific APAR? I searched all PTF cover letters on
IBM's site for *SE26496* and drew a blank.

- Dan