On 11-Jan-2016 15:37 -0700, Evan Harris wrote:
On Tue, Jan 12, 2016 at 10:33 AM, Buck Calabro wrote:
On 1/11/2016 3:31 PM, Evan Harris wrote:
I looked at the cover letters for the PTFs noted; they seemed to
be concerned with changing an incorrect owner rather than
anything drastic, so that would explain why there were no version
no. changes or other visible differences.
My confidence is low that the description of a given PTF closely
tracks what that PTF delivers. IBM seem to have got... terse of
late.
You might be right. I found it interesting that details in the
cover letter of the owner being changed matched the name of the
person maintaining the wiki (i.e. kadler).
Coincidence ? Maybe. It would be interesting to know what owner is
reported on a system where these PTFs have not been applied yet.
From the Cover Letter:
Files were owned by KADLER
CORRECTION FOR APAR SE63080 :
-----------------------------
Files are now owned by QSYS
The maintenance-owner is responsible for the PTF properly maintaining
any Special Instructions in the PTF Cover Letter; maintaining them only
in a developerWorks wiki is [IMNSHO] quite inappropriate.
The /owner/ of the "Files" is almost surely a reference to what was
saved on media from the system on which the PTF was produced; i.e. the
STMF objects in the PTF save file [IIRC within a save file object
provided with the PTF]. Thus likely: • for any system without a user
profile named KADLER, onto which the PTF effects restore (RST) of those
files from the save file, errors would be logged about "file assigned to
user QDFTOWN" • for any system with a user profile named KADLER, onto
which the PTF effects (RST) of those files, the files would be
incorrectly owned by the user KADLER instead of the intended user
profile [for which a DLTUSRPRF KADLER could have the effect of deleting
system-supplied objects]. If accurate, the prior PTF presumably was
/defective/; irrespective the PTF ever being marked\called-out as such.
In review of the APAR SE63080 I see the Error Description likely
confirms what I stated above, per "Some files shipped by SI57254 were
owned by KADLER, leading to warning message in job log."; though of the
caveat of the incorrect ownership, the message identifier as symptom,
and CHGOWN as corrective action [which typically would be in the PSP
text for the defective PTF] were left unmentioned. As well, with a
quick search, I see no indication that SI57254 was marked defective
[even though likely marked as undeliverable, e.g. as a requisite, except
when ordered explicitly].
Sadly, a system on which PTFs are generated, no non-system user
profile should ever exist; such an error, therefore, would seem to be
impossible.
However IIRC, those "Files" as object(s) could have been delivered in
the form of a Save File vs the objects themselves; given a save file
were to still allow only one save-command, that would remain a
requirement. If so, then presumably a flaw with the PTF generation
process [persists], whereby the object(s) delivered in the form of a
Save File are [still] not being verified as valid; i.e. the process may
simply _assume_ the maintenance-owner had correctly created the objects
that were saved in the save file, created properly in every way [in ways
unknowable to the PTF system and process] _including the owner_ of the
objects, despite the validation of that particular _owner_ attribute
could be automated. The objects that would have been saved into a SAVF
packaged as part of a PTF image, likely originated from a [developer's]
system rather than having been created on, prepared on, and then saved
from the PTF system, specifically because that PTF system must remain
pristine; thus the possibility opened for the error.
<<SNIP>>
<<SNIP>>
midrange.com
