Re: Another PTF Question

On 18-Dec-2014 17:18 -0600, Buddy McClean wrote:

<<SNIP>>

Loading a PTF into *SERVICE from optical would be my top option, but
I think I got SNDPTFORD to work at least most of the way.
More of that below.

In this case the PTF being loaded into *SERVICE is not the same
release that is on the machine. Which I don't think is a problem.
(also below).

I do not recall, but I expect the Load PTF (LODPTF) using the Copy Save File (CPYSAVF) feature to copy PTF save files into *SERVICE when PTFs are loaded would not function in that scenario; i.e. I expect the result would be effectively "product\feature not installed".

It would have to be that way since the reason *SERVICE is the only
option, is because the PTFs have to do with optical load and are
needed to get optical to work after update to 7.1.
After they are in effect, optical is the way to go for all the rest
of them.

OK, I understand now. The pre-requisite PTFs for the function allowing the loading of PTFs from optical, must be loaded into *SERVICE prior to an upgrade that wants to [automatically] load the PTFs from the image catalog [during an automatic upgrade]; i.e. if done manually, all the ordering and applying of the pre-requisites could await the completion of the manual install to the new release.

So I sent the PTF order by this.

SNDPTFORD PTFID((SI43588 5770999 V7R1M0))
defaults include : Order-*required Reorder-*NO Checkptf-*no

In effect, the request was:

SNDPTFORD PTFID((SI43588 5770999 V7R1M0)) ORDER(*REQUIRED)
REORDER(*NO) CHKPTF(*NO)
/* presumably also: */ DLVRYFMT(*SAVF)

Hmm. That seems suspect, to have effected what is described later. What is apparently a proper specification, would seem to require the following request, whereby the Element 2 (Product) of the PTF Identifier (PTFID) should have been [¿and possibly was actually?] the value 5770SS1 rather than 5770999?:

SNDPTFORD PTFID((SI43588 5770SS1 V7R1M0)) ORDER(*REQUIRED)
REORDER(*NO) CHKPTF(*NO)

It appeared to download the specific PTF requested. QGPL has a .SAVF
with that name.

The PTF 5770SS1-SI43588 exists; a save file QSI43588 exists in QGPL with that PTF Identifier shown when Display Save File (DSPSAVF) is requested?

Even though one of the last steps is to attempt to DIAL out and that
doesn't work. I don't think that is causing any of this.

But I get this in the job log. The PTF I asked for was not in the
list. Or is this list just telling me they downloaded something I
didn't specifically order by name.

<big snip>
PTF 5770999-MF52688 V7R1M0 not ordered.
PTF 5770999-MF52686 V7R1M0 not ordered.
PTF 5770999-MF52561 V7R1M0 not ordered.
PTF 5770999-MF52480 V7R1M0 not ordered.
PTF 5770999-MF52279 V7R1M0 not ordered.
PTF 5770999-MF52109 V7R1M0 not ordered.
<big snip>

That list appears to be a subset of the PTFs listed as pre-requisites for the ordered PTF: <www.ibm.com/support/docview.wss?uid=nas3b3d4b42795ddaf238625788f00479960>

Message ID . . . : CPF8C99 Severity . . . . : 40
Message type . . : Diagnostic
Date sent . . . : 12/18/14 Time sent . . . : 16:21:59
Message . . . . : PTF 5770999-MF52688 V7R1M0 not ordered.
Cause . . . . . : The program temporary fix (PTF) you specified,
MF52688 for product 5770999 release V7R1M0 with minimum level
of 00 and maximum level of 00, was not ordered for one of the
following reasons:
-- PTF is for an option not installed or supported.
-- PTF is for a VRM not installed or supported.
-- PTF is for a NLV not installed or supported.
-- PTF is for a Level not installed or supported.
If the level is *N, no level is present.
Recovery . . . : Specify the value *NO in Check PTF (CHKPTF)
parameter or specify another PTF, then try the request again.

Are these the prereq's that should have downloaded but didn't? It
sounds like it is rejecting them for not matching the current level
of the machine, currently at 6.1, even if the CHECK PTF parm is
default *NO.

Despite the apparent implication by the "Recovery" of that msg CPF8C99 apparently having been issued for each of the requisite PTFs, AFaIK the CHKPTF(*NO) applies only to the selected PTFs; i.e. applies only to those PTFs identified in the PTF Identifier (PTFID) parameter. The ORDER(*REQUIRED) specification determines if requisites will be included; I would hope\expect that the requisites would similarly not be checked against the available\installed products.

I recall very little about how ordering PTFs from newer releases functioned using SNDPTFORD, but the following request might circumvent the issue, by directly requesting each of the requisites [note that the original PTF is not included in this request]?:

SNDPTFORD ORDER(*REQUIRED) REORDER(*NO) CHKPTF(*NO) PTFID(
( 5770999 V7R1M0 MF53007 ) (5770999 V7R1M0 MF53018 )
( 5770999 V7R1M0 MF52979 ) (5770999 V7R1M0 MF52041 )
( 5770999 V7R1M0 MF52109 ) (5770999 V7R1M0 MF52119 )
( 5770999 V7R1M0 MF52158 ) (5770999 V7R1M0 MF52246 )
( 5770999 V7R1M0 MF52247 ) (5770999 V7R1M0 MF52248 )
( 5770999 V7R1M0 MF52249 ) (5770999 V7R1M0 MF52259 )
( 5770999 V7R1M0 MF52260 ) (5770999 V7R1M0 MF52261 )
( 5770999 V7R1M0 MF52263 ) (5770999 V7R1M0 MF52265 )
( 5770999 V7R1M0 MF52267 ) (5770999 V7R1M0 MF52268 )
( 5770999 V7R1M0 MF52276 ) (5770999 V7R1M0 MF52277 )
( 5770999 V7R1M0 MF52278 ) (5770999 V7R1M0 MF52279 )
( 5770999 V7R1M0 MF52280 ) (5770999 V7R1M0 MF52281 )
( 5770999 V7R1M0 MF52480 ) (5770999 V7R1M0 MF52561 )
( 5770999 V7R1M0 MF52686 ) (5770999 V7R1M0 MF52688 )
( 5770999 V7R1M0 MF52689 ) (5770999 V7R1M0 MF52690 )
( 5770999 V7R1M0 MF52728 ) )