Re: Another PTF Question -- MIDRANGE-L

On 19-Dec-2014 13:53 -0600, Buddy McClean wrote:

On 12/18/2014 6:43 PM CRPence wrote:

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".

Just to clarify the above, the CPYSAVF "feature" noted, means to suggest the parameter by that name on the LODPTF command, not a command by that name. And, the LODPTF in this scenario [for a N+# PTF] I could imagine would fail even if able to get past the non-installed LICPGM(), because the Save File image is from a higher release, just as is noted in the most recent followup reply, the relevant portion of which is quoted later in this message. Again, as I'd alluded, I recall very little about dealing with PTFs delivered to an N-i release.

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?

Sorry, I redid the SNDPTFORD from the 3rd sample that I did and put
in the wrong Product ID. The original was 5770999-MF58616 that also
produced a list in the job log similar to the one I posted.

QMF58616 *FILE SAVF PTF 5770999-MF58616 V7R1M0

QSI43588 *FILE SAVF PTF 5770SS1-SI43588 V7R1M0
QSI46137 *FILE SAVF PTF 5770SS1-SI46137 V7R1M0

Of course when I do DSPSAVF FILE(QGPL/QMF58616)

Message . : File cannot be restored, displayed, or listed.
Cause . . : The file was saved from a more recent release of the
operating system or the CD-ROM was not created correctly. The
operation was requested for save file QMF58616 in library QGPL.

So, no way to verify the .SAVF before the intended release is
loaded.

I am not so sure. I expect that the PTFs registered into *SERVICE must be made visible somehow, even if not via Display PTF (DSPPTF). If not easily shown elsewhere, then I would be satisfied seeing what is a known\verified-to-be-complete list of Qptf_id files in QGPL. Problem is, without the SNDPTFORD tooling determining\generating the requisite list according to what [is obviously not installed on my system but what maybe already] exists in *SERVICE, where would I get that list if not by some documentation\TechNote provided by IBM.?

Note: I had avoided the term "loaded into *SERVICE" to differentiate from a PTF being "loaded into the LICPGM()"; thus why I chose "registered into *SERVICE" to avoid confusion for use of "loaded" being clarified with specifically "into what". Now seeing "loaded" used in yet another context... Ugh. The new release will be "installed" :-)

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 ) )

Sounds good I will give it a try

I did some more searching with regard to *SERVICE. The snippet of text I quoted, most notably "put into *SERVICE..." from the following doc link could be helpful:

<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/apis/qpzlogfx.htm>
_Log Program Temporary Fix Information (QPZLOGFX) API_
"...
The Log PTF Information (QPZLOGFX) API allows you to specify the device from which PTFs are loaded as *SERVICE. You can use the QPZLOGFX API to indicate that a PTF or cover letter should be put into device *SERVICE.

PTFs are put into *SERVICE when they are received on the system using the Copy PTF Save File (CPYPTFSAVF) or Send PTF Order (SNDPTFORD) command. These commands put information about the PTF into the PTF database files so that the PTF can be displayed with the Display PTF (DSPPTF) command. The PTF is then loaded from device *SERVICE using the Load PTF (LODPTF) command. PTFs received on the system by any other method are not in *SERVICE.
...
Request type
INPUT; CHAR(10)

The type of log operation to be done.

The possible values are:

*LOGPTF The PTF is to be put in device *SERVICE. Product information from the save file is checked against the product information passed into this API. Therefore, the PTF must exist in the save file specified on the qualified file name parameter.
...
..."

I have no idea what are the capabilities allowed with regard to extracting PTF information from a save file created at a "more recent release of the OS"; for the PTF [PZ] feature of the OS or specifically for that API.