Re: Another PTF Question

I still am working on getting SNDPTFORD to function. I deleted the
service Cfg and created a new one, still doing the same thing.

I suspect I will need to apply required PTF's to the current release (
SF99610 with ESA ptfs SF99626 ) maybe that will fix it.

If I don't do that, in a perfect world ( which I don't really want to
count on ), I can

Use the ptf's I got from Fix Central in a .BIN file. The ones I can't
get SNDPTFORD to download.

I did try the CPYPTF from the .BIN file on IMGCLG to a .SAVF - worked
fine.

The LODPTF issued the error that the *SAVF was in the wrong format for
the current release.

This is where the perfect world would start.

Do the upgrade, PTFCPY the .BIN to a *SAVF then try the LODPTF again
from the *SAVF and it would work since the release is now the same.
And hope the PTF's in the *SAVF are not required on any step in this
process.

CRPence <CRPbottle@xxxxxxxxx> 12/19/2014 3:00 PM >>>

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 whe

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

ter.

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.