Re: Weird MAxxxxx PTFs?

On 13-Jan-2016 13:07 -0700, Jeff Crosby wrote:

V7R1. I stumbled upon these PTFs under 5770999:

PTF IPL
Opt ID Status Action
MA38529 On order only None
MA38522 On order only None

No idea how long they've been there.

Is there neither an order-date nor a status-change-date that is presented with the request to DSPPTF 5770999 MA38529 [or DSPPTF 5770999 MA38522]? If not using OUTPUT(*), then with OUTPUT(*OUTFILE); my internet connection is wonky [1x vs 3G], so even if I could check, it could take;;; scratch that, I see there is at least a "Status date/time" under "1=General Information" from the interactive\display results of Display PTF (DSPPTF).

Never seen them start with "MA" before.

The PTF naming matching to an APAR number suggests a /fix/ was packaged as a "PTF" solely for the purpose of enabling ordering and delivery of code changes that are _not intended to be_ the eventual\final-form code-change\fix. Thus the PTF process was used as the means to deliver what is called a "Test Fix" [with a mnemonic of ¿TESTFIX or FIXTEST, or was that FIXTST?], typically to provide a "trap" or an effectively "debug capable" feature, as something to assist development in diagnosing a problem.

I searched cover letters online, but these don't seem to have a cover
letter so I didn't find anything.

The TextFix is not made public. Only the recipients of the order would have access to the Cover letter of the [pseudo-]PTF.

There are APARs with these numbers, though.

The text of the original APAR will be replaced by the text describing the problem that was corrected by the PTF [if one was eventually] provided using that same APAR number; i.e. the APAR for a TestFix sometimes will become the APAR for an actual final-form PTF.

What should I make of this?

There should be tight controls on the Test Fixes [e.g. they are released only in coordination with the order made by the customer], and the customer who orders them should always be *very aware* that they have ordered the fix, because their failure to be cognizant of the requirements for handling them could cost them trouble\time due to failures in applying real maintenance; i.e. no system should have an APAR=PTF in "on order" status without having been in consultation with IBM service\support about placing that order, because their system change-management procedures should be in place to track the order, apply, and removal and ensuring that activity will not impact their scheduled maintenance. The PTF load\apply process on a system prevents the TestFix from being accidentally permanently applied.

IIRC those two TestFix PTFs shown having On-Order status can be removed from the list using the Remove PTF (RMVPTF) and\or Delete PTF (DLTPTF) commands. Given the APARs since have delivered actual PTFs, there is no reason those PTF numbers should should remain in the list, so actually clearing them from that list would be ideal; i.e. there is no intention to obtain them, there may be no means to do so [they may no longer exist], and there is apparently no SCM tracking them to ensure that they would be handled without negative impacts, thus having removed from appearing in the list with the On-Order status would be a proper\expected effect.

FWiW: The standard\expected PTF naming may deliver either a final-form PTF or that PTF name delivered as a "Test PTF". Such a PTF designation implies that the PTF will be tested by the customer with an agreement thy will provide feedback on the effects; that if the PTF is deemed to have either introduced a problem or does not correct the expected error, then the customer agrees both to not permanently apply the PTF and to permanently remove the PTF if a new version of the same-named PTF must be created due to problems [irrespective of the problem being found by that customer or another]. The controls on ordering those PTFs should be quite similar to the TextFix.