Re: PTF install questions -- MIDRANGE-L

System is V5R4M0. Moving to eithr 6.1 or 7.1, depending on the whim of a
vendor. Not sure when. As I understand it, money was spent to extend
service on v5r4. I know nothing about the details - I am too far down the
food chain. A drop dead date from IBM that can be extended? Just
confusing.

I tried your suggestios on DSPPTF OUTPUT(....). Nothing for IPL action or
action pending.

When I weded out Permanently applied and Superceeded, this was all that
remained:

5722SS1 SI41557 Save file only
5722SS1 SI41456 On order only
5722SS1 SI41112 On order only
INFOAS4 II12302 Cover letter only

I am wondering if CPD35F8 is like that message in PDM "Information about
new tools - press F1 for details".

Under GO LICPGM option 50, I changed the start date to go back two years,
if possible.

Nothing there except:

Apply PTF started.
Applying of PTFs for product 5722SS1 completed successfully.
Applying of PTFs for product 5722ST1 completed successfully.
Applying of PTFs completed.
Server IPL required.
PTFs applied or removed during IPL.

There are two SCPF jobs. Status of OUTQ entered system 4/23/13 and status
ACTIVE entered 8/28/13.

Saw a lot of object moved, ptf successfully applied, trigger program
removed, trigger added
.

The running CPF has MCH3402 from program #sv14ckp to program QTNEND "Tried
to refer to all or part of an object that no longer exists."
But, that is the second message in the joblog. First is that Subsystem
QSYSWRK in library QSYS being started.

Nothing else looked odd.

John McKee

On Wed, Aug 28, 2013 at 9:54 AM, <rob@xxxxxxxxx> wrote:

Read my email again, slowly.
Yes, some cleanup was done. It cleaned up some of the backup ptf files.
Like the QSF00001S1 mentioned in my previous email - not the QSF00001
downloaded.
Then, again, if it's been awhile since you IPL'd, any number of cleanup
steps could have happened to free up space also.

Let's get back to the CPD35F8 Server IPL required.
I suggest performing the following:
GO LICPGM
50. Display log for messages
If you can't find anything glaringly obvious in there then do a WRKJOB
SCPF. This is the job that applies PTFs during an IPL. You may have more
than one. Look at the joblog for the active one and the most recent
completed one. See if anything there grabs you by the gills.
Follow that with
DSPPTF OUTPUT(*OUTFILE)
then concentrate on these
SELECT SCPPID, SCPTFID, SCSTATUS, SCIPLACT, SCACTP, SCAACR
FROM rob.dspptf
ORDER BY scstatus, scppid, scptfid
The ones that are permanently applied, and have no action required nor
action pending can be ignored.

As far as this:
<snip>
You stated that RESTART(*YES) did not qualify as a server IPL and that
entire frame would have to be IPLed.
</snip>
Let's put this into context. This will not make a difference on most of
your traditional LPP and OS ptf's. What it will make a difference on is
firmware PTF's. If you have your firmware set to upgrade from OS and not
HMC (always! set that to HMC if you have a HMC) then, yes the firmware PTF
may require the whole frame to be IPLd.
I forget how old 5722999 is and what level of OS that indicates (please
post the OS and don't make us look up ptf MFsuchandsuch to see what
version you are running).
DSPFMWSTS is a command useful for displaying your current firmware level.
Older versions of the OS may not have it. If you are upgrading firmware
from the IBM i os, and you're on your service partition then DSPPTF
LICPGM(*FMW) may work. 7.1 infocenter says so but I upgrade from HMC so
it throws me an error.
V5R4 infocenter covers this, and your exact message, at

http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzam8/rzam8fixinfocumpacklevel.htm

I have no idea how much longer a full IPL will be. Depends on the
firmware upgrade, your hardware, phase of the moon, etc.

Are there any possible negatives of a full server IPL? Well, the risks
are this:
1 - You could have a bad copy of firmware that you install. But I say the
risks of that are slim to none, providing your cume level is somewhat
recent.
2 - It will test some hardware more thoroughly. If the hardware is bad,
or on the brink, it may find out (the hard way). There are some people
that think that hard drives are like car engines, starting them up are the
hardest thing on them. Since you aren't planning on leaving it powered
off for days, weeks, etc then "stiction" is probably not a factor.
Now that I've covered my a$$, I'd have to say your risks of a full IPL are
slim.

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: John McKee <jmmckee@xxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 08/28/2013 10:06 AM
Subject: Re: PTF install questions
Sent by: midrange-l-bounces@xxxxxxxxxxxx

Thanks Rob.

From previous posts, I somehow got the idea that pefmanent application

did
the cleanup. In fact, our disk usage is down considerably, so *some*
cleanup was performed. Which may have led me to believe the save files
would have also gone away.

Any idea why DSPPTF is still insisting that a server IPL is required? And,
how to get rid of it?

This link leads me to believe the upgrade to v5r4 years ago missed
something:

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzahc%2Fpostinstallationchecklist.htm

Found this post from a long time back. You stated that RESTART(*YES) did
not qualify as a server IPL and that entire frame would have to be IPLed.
Does that mean changing restart type from *IPLA to *FULL - this is non HMC
system. Any wild guess how much longer an IPL takes when *FULL is
specified? Beyond IPL time, are there any other negatives? Is this a
sleeping dog that is best ignored?

John McKee

John McKee

On Wed, Aug 28, 2013 at 8:33 AM, <rob@xxxxxxxxx> wrote:

Applying a PTF permanently does not get rid of that PTF's save file.

What

it gets rid of is just a little more complicated.
Let's say PTF SF00001 fixes PGMA in QSYS. As part of the temporary

apply

of SF00001 it backs up PGMA into a new save file; let's say QSF00001S1.
Then it restores the new PGMA from QSF00001. QSF00001S1 will stay there
until you permanently apply SF00001. Then it's gone. However that
doesn't get rid of QSF00001. For that, see

http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzam8/rzam8fixcleanup1.htm

Now, if you upgrade your OS and haven't applied SF00001 permanently

before

the upgrade you will have QSF00001S1 out there for all eternity. This

is

why you should always apply PTF's permanently before upgrading your OS.

I

figured this out the hard way and had these back up files from several
releases back.

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: John McKee <jmmckee@xxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 08/28/2013 09:21 AM
Subject: PTF install questions
Sent by: midrange-l-bounces@xxxxxxxxxxxx

Been a LONG time since I have IPLed the system.

Yesterday, I permanenyly applied all PTFs not requiring an IPL. Then,

set

the others to apply during next IPL. I initiated the IPL and all went
well.

I was looking for some ancient PTFs that I had previously seen in QGPL
that
had been located by ANZOBJCVN. I was surprised by the large number of
SAVF
still in QGPL.

For instance, DSPPTF for 5722999 shows MF41260 as permanenyly applied.

Bottom of screen is message CPD35F8 Server IPL required.

On PWRDWNSYS, restart type is set to *IPLA and DSPIPLA shows *SYS for
restart type.

The SAVF is named QMF41260. Could this be a duplicate and thus just be
deleted?

What about the message stating server IPL required?

Thanks.

John McKee
--
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.