Re: qtemp performance oddity.

On 28 Feb 2013 14:07, bryan dietz wrote:

DESCRIPTION OF PROBLEM FIXED FOR APAR MA25264 :
<<SNIP>>
If one of those PTFs has been permanently
applied, the current PTF can be used to undo those changes.
Once the current PTF has been permanently applied, an install
is required to reapply MF24711 or MF26466.
<<SNIP>>

On Thu, Feb 28, 2013 at 5:01 PM, CRPence wrote:

That MF26466 may have been what changed QTEMP libraries to
temporary objects; I seem to recall the decision about temp vs
perm was related to the security level. If so, do not apply that
PTF; regardless, the latest is best applied, typically.

Hmmm... OK, so those PTFs do not seem like a backout of the changes as a final effect, but as an Oops, I perma applied the /trade-off/ PTF and I now realize the trade-off of the longer IPL is not what I want.

So... apply the supersede MF28377, which if the former makes the
QTEMP libraries temporary, presumably the latter changes the
code back to making the QTEMP libraries permanent.

Per above... this is not the "typical" case where the latest is the best. Instead, choose which poison... and the latest PTF allows some medicine that is less painful than surgery if the latest poison is worse than the prior.

<<SNIP>>

Thinking more about this... the PTFs I was thinking about with regard to how the QTEMP libraries were created and processed would have been OS WM anyhow; not LIC.

However, the "CIRCUMVENTION FOR APAR MA22147 : Run the system at security level 50." is presumably based on the /assumption/ that the WM changes which made QTEMP libraries temporary objects would be in effect; i.e. using QSECURITY=50 to avoid the sync write issues would only be true if the storage were temporary... which is what I recall the /fix/ to use temporary QTEMP libraries entailed... and which was backed-out because the problems that causes for the database which requires that the QTEMP libraries span the pwrdwn\IPL sequence.