|
Granted, I should have no trouble getting the final ptf's to 6.1 using
IMGCLG. And loading the 3 - 7.1 ptfs to *SAVF.
I was trying to load the 3 ptf's needed for OPTI into *SERVICE the same
as SNDPTFORD would do. I'm guessing that it is possible
to do a SNDPTFORD on a future release so they will be ready to load
from *SERVICE when at the future release?
But it looks like I will have to wait until I am at 7.1 to test the
idea that I can load these ptf's into *service from a *SAVF
created by CPYPTF , as long as I do the CPYPTF on 6.1 so IMGCLG will
work.
I understand what you are saying, but didn't you say you are doing a<rob@xxxxxxxxx> 12/22/2014 3:43 PM >>>
CPYPTF from the images? To me that implies that you are doing an image
catalog already. Sure, maybe you do need these PTF's on before you can
do
a V7 upgrade from image catalog. I get that. However, it doesn't say
you
can't even use an image catalog to apply 6.1 PTFs. What do you think
about that?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Buddy McClean" <Buddy.McClean@xxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion"
<midrange-l@xxxxxxxxxxxx>
Date: 12/22/2014 04:31 PM
Subject: Re: Another PTF Question
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
The ptf's are for 7.1 to recognize optical image files and must be
loaded from *SERVICE.
Why the preoccupation with save files?<rob@xxxxxxxxx> 12/22/2014 3:27 PM >>>
You've already created the image catalog. Probably loaded it to a
virtual
optical drive. Why not do the LODPTF from, oh, let's say, OPTVRT01?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Buddy McClean" <Buddy.McClean@xxxxxxxxxxxx>
To: <midrange-l@xxxxxxxxxxxx>
Date: 12/22/2014 03:58 PM
Subject: Re: Another PTF Question
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
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.
On 19-Dec-2014 13:53 -0600, Buddy McClean wrote:CRPence <CRPbottle@xxxxxxxxx> 12/19/2014 3:00 PM >>>
On 12/18/2014 6:43 PM CRPence wrote:roduct\feature not
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 "p
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:
n Display Save FileSNDPTFORD 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
(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" :-)
thatEven though one of the last steps is to attempt to DIAL out and
<www.ibm.com/support/docview.wss?uid=nas3b3d4b42795ddaf238625788f00479960>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:
not installed or supported.
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
level-- 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
ter.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
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.
--
Regar
ds, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
