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
midrange.com
