Re: Another PTF Question

Very useful stuff. thanks Chuck,

Thanks for hanging in there with me everyone.

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

It would have to be that way since the reason *service is the only option, is because the ptf's 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.

So I sent the ptf order by this.

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

It appeared to download the specific ptf requested. QGPL has a .SAVF with that name. 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>

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.

CRPence <CRPbottle@xxxxxxxxx> 12/18/2014 4:31 PM >>>

On 18-Dec-2014 14:13 -0600, Buddy McClean wrote:

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

On 18-Dec-2014 10:37 -0600, Buddy McClean wrote:

<<SNIP>>

The documentation says that the PTFs need to be loaded from
*SERVICE. It also says that they can be download from fix central
and loaded via *SAVF. The option on loading a PTF has either
*SERVICE or *SAVF.

The Device (DEV) parameter of the Load PTF (LODPTF) does support
both special values. When *SAVF is specified, that is a request to
redirect to the information provided on the Save File (SAVF)
parameter. When the value *SERVICE is specified, the implication is
that the /Load/ request is to obtain the PTF images whence they
were placed by the "service support system"; as I recall, these
were always individual PTF save files [named Qptf_id in QGPL], but
possibly they could be stored elsewhere.?

When they say *SERVICE in the documentation, do they also mean
*SAVF if you downloaded it manually and is it a matter of just
creating a SAVF and using FTP to get the .BIN moved to the
Iseries.

A *FILE object with the SAVF attribute may have any various
content; e.g. a binary image as the effect of an operation such as
SAV, SAVOBJ, etc. If that content of the Save File just happens to
be a binary PTF image, that would not necessarily be known to the
PTF [PZ] feature of the OS; a PTF image that is _in_ *SERVICE is a
PTF [that is in a Save File] that previously has been /registered/
with the PTF feature of the OS. For example, if I issue the Create
Save File (CRTSAVF) command and then copy the binary records of the
save-file from another Save File with PTF content into my new\empty
save file that I had just created, e.g. copied via FTP PUT, then
that new Save File is unknown to the PTF feature; the new save file
was never /registered/ with the PTF feature of the OS.

Basically does *SAVF imply *SERVICE, just from a different source
( manual vs automatic download ).

Somewhat; only *if* the SAVF was created by a download feature
which implicitly /registered/ the PTF image [that happens to be
stored in the Save File] with the PTF [PZ] feature of the OS. AFaIK
the manual vs automatic is not germane; the /download/, however
performed, must have registered the PTF image [irrespective of
whether that is stored in a Save File or elsewhere; i.e. I am
unsure if a PTF might reside in *SERVICE, but in a form other than
a SAVF image] with the PTF feature of the OS. I recall that the
Send PTF Order (SNDPTFORD) would, for a specific set of PTFs
[optionally with requisites requested to be included] would create
save files into which the PTF images were deposited, and those PTF
Save Files would be implicitly registered with *SERVICE.

When I download the individual PTF, I get a .BIN file, the same
as when I download more than one. There are several PTFs that
need to be applied this way, can they all be combined into one
download and one .bin file to copy to one SAVF?

A PTF save file is, AFaIK still just _one_ PTF. I do not believe
the .BIN format is compatible with the SAVF format; i.e. I do not
expect the binary data records of a .BIN can be copied into a SAVF.
As I recall, the .BIN format is used for image catalogs.

See my reply further below for a correction with regard to "_one_"
just above. The other commentary just above is probably an accurate
reflection about the different delivery formats.

Or is it risky to apply a PTF if it was not really required, so
individual PTF downloads would be the way to go
<<SNIP>>

I am not sure I understand the question. If a PTF is available for
download and applicable to the installed product\release, then the
PTF should be available for loading and applying without much
concern.?

<<SNIP>>
The only way to use the *SERVICE option of the load ( which they say
I have to use ) is to use the SNDPTFORD system or SYSTEMS DIRECTOR to
take the downloaded .SAVF , register it, then put it up for apply.

I have never used SNDPTFORD and don't know if it even works, but
this might be the day.

Perhaps a link to the specific documentation would help. The alluded
as a stated requirement, seems baffling; there would seem to be no valid
reason that any instructions should limit the loading of PTFs from
*SERVICE.? AFaIK the PTFs should be required to exist in *SERVICE only
if\when that system will be used to distribute the PTFs; i.e. the system
on which the PTFs are loaded into *SERVICE will be the "service support
system" I had mentioned earlier.

Hmmm, looking at the LODPTF docs, I see that also if "the Save System
Information (SAVSYSINF) command" needs to include those PTFs; apparently
upon Update System Information (UPDSYSINF) processing. Perhaps those
actions are part of the "preparing for 6.1 to 7.1 upgrade"; part of the
original topic that I had /snipped/ because I had intended only to
discuss *SERVICE and *SAVF, which as a topic is irrespective of release
or upgrade activity.

FWiW, a PTF that is loaded to a system, can also be optionally loaded
into *SERVICE. If a PTF that is being loaded can be copied into
*SERVICE in the same action, I just can not make sense of an implication
that a PTF may be loaded only using the DEV(*SERVICE). See the Copy PTF
Save File (CPYSAVF) parameter of the Load PTF (LODPTF) command for how
to specify "whether to copy PTF save files into *SERVICE when PTFs are
loaded.":
<http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/cl/lodptf.htm>

P.S. My prior implication that a save file would have only one PTF is
clearly incorrect, at least according to the Copy Program Temporary Fix
(CPYPTF) documentation; an example invocation even shows copying all
PTFs for a product into one save file. My recollection was surely
clouded by my having mostly created PTFs, for which each was built as an
image in a Save File.