CRPence <CRPbottle@xxxxxxxxx> 12/18/2014 6:43 PM >>>
On 18-Dec-2014 17:18 -0600, Buddy McClean wrote:
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.
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
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
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)
/* 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
(PTFID) should have been [¿and possibly was actually?] the value
rather than 5770999?:
SNDPTFORD PTFID((SI43588 5770SS1 V7R1M0)) ORDER(*REQUIRED)
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
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
operating system or the CD-ROM was not created correctly. The
requested for save file QMF58616 in library QGPL.
So, no way to verify the .SAVF before the intended release is loaded.
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.
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.
That list appears to be a subset of the PTFs listed as
for the order
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
-- 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
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
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