× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 05-Aug-2014 19:48 -0500, Jim Essinger wrote:
On Aug 5, 2014 12:16 PM, "James H. H. Lampert"wrote:

I just got confirmation from the customer: removing SI51172 solved the
problem.

We were asked whether there was any reason to expect it to return if the
customer applies the superseding PTFs SI52478 and/or SI53118. I said that
the general consensus "among those who know more about such things than I
do" was that it most likely wouldn't, and that there was no reason to
expect it to return.

Any recommendations on the superseding PTFs? Install one? Install both?
Ignore them?

My advice is to install both. The last one fixed the problem for me.

FWiW:

I offer a "picture" of a PTF supersede chain; shown since the pre-PTF code level, called *BASE, presented in a pseudo-code resembling a free-form CLP; each request appearing as Rqs#. For the sake of simplicity, each PTF /adds/ a new request [with a higher digit] to denote the change to the code, until the final fix that instead modifies a prior code change [the original request since denoted with an 'x' suffix] to prevent the defect inserted with the earlier code change:

code-lvl pseudo-code
-------- ----------------------------------------------
*BASE: pgm Rqs1 /*noConditionOf:cpd0193*/ endpgm
SI51172: pgm Rqs1 Rqs2 /*causes:cpd0193*/ endpgm
SI52478: pgm Rqs1 Rqs2 /*causes:cpd0193*/ Rqs3 endpgm
SI53118: pgm Rqs1 Rqs2x /*stops:cpd0193*/ Rqs3 endpgm

The APAR SE58912 which delivers SI53118 claims to /fix/ the problem identified as having a symptom MSGCPD0193. Because the previous PTF SI52478 makes no such claim, any expectation that any earlier PTF in the chain [specifically SI52478] would stop the problem introduced with the even earlier PTF SI51172, seems folly.

The /chain/ implies that each successive PTF contains the same code changes from the prior fixes. An exception to the PTF chain including successive fixes [as visible in the source] would occur when a defect introduced by a prior fix must be removed with changes made in a newer fix; the supposed case, as shown above, whereby the Rqs2 was modified to become Rqs2x that stops the error condition CPD0193. The prior fix is shown to have added Rqs3, but had not also made any changes to Rqs2 that had introduced the failing code.

Even if SI52478 had the fix [Rqs2x], then there would be almost no purpose in applying both PTFs; to install both would require installing the older PTF first and then the newer PTF. Having done so, the older PTF would have been implicitly permanently applied. And if SI52478 did not have the fix, then if for any reason the newer PTF SI53118 had to be removed [e.g. perhaps yet another defect was inserted; perhaps even worse than the last one], the only way to remove the newer defect would be to re-install the feature\LPP. Thus I would recommend to *not* install both PTFs; install *only* the latest supersede.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.