Re: 7.2 Python PTFs FYI

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>>