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