Thanks Chuck, beginning to make sense.
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.
CRPence <CRPbottle@xxxxxxxxx> 12/18/2014 12:12 PM >>>
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.
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.?
midrange.com
