Re: Upgrade Issue

Justin, I can tell now what happened afterward,We do had Software support
call available and went on with their help.The error we noticed in the log
were as follows

Message . . . . : File not selected. File label or file name mismatch for
file /QPTFMNT/QPTFGRP/CUMEGRP.G00.

Message . . . . : Superseded licensed internal code fixes not applied.
Cause . . . . . : *APYPERM was specified for superseded PTFs (SPRPTF) when
loading program temporary fixes (PTFs), but superseded licensed internal
code fixes cannot be applied permanently because the wrong copy of licensed
internal code is being used.

Support first told us that we might be using the old LIC level 545-A
currently 545-F is available. And LIC ptfs were installed but OS one's
require IPL.
Though we have used the same image catelogue last month for the upgrade and
such problem was not there. One fact was missing that we had to scratch
install back to V5R3 on the same machine two weeks back due to some prob
with WebSphere for which Support said it may be problem with indexing then
as you had tried a V5R4 install on same server.

But we first did a IPL from B side and then ftped the new CUM and gave a try
for it . It all worked.



Rhishabh Srivastava


On Sun, Nov 22, 2009 at 4:58 AM, Justin C. Haase <jchaase@xxxxxxxxx> wrote:

The INZSYS doesn't run until the system restarts after completion of the OS
upgrade, so that's no problem. Chapter 8, step 5 of the V5R4
upgrade/install guide will help out with this - as well as page 168 of the
same manual. But I wouldn't get too wrapped around the axle with INZSYS -
if there's an operation you can't do because INZSYS hasn't run, it will
tell
you.

You can spin PTFs immediately after the OS upgrade and before INZSYS is
done, but you can NOT do it if you've IPLed after the upgrade unless INZSYS
has run. And if you IPL the system restricted and then start the
controlling subsystem manually, INZSYS will not run by itself. There's all
the rules and regulations in the "INZSYS Recovery" section of the manual.

But typically, you'll get done with the OS and LPP install, verify GO
LICPGM
option 50 shows good for your LPPs, then spin your PTF package, and
finally IPL to B-side. When it comes up on the B-side, things start and
INZSYS runs. And you're also back in your normal controlling subsystem.

What kind of console are we talking here? LAN? Twinax? What SRC is on
the
display now? Does this system have software support? There's lots of ways
I could think to *try* to recover this, but I wouldn't do it on anything
but
a system I knew I had a clean backup of prior.

I'd think the safest way would be to work on getting your console back and
then burn the .iso's to CD and just do the PTF load the "old way." Then
involve IBM if that spin doesn't work.

But - if it had software support, I'd be on 800-IBM-SERV even if I had some
ideas. I'm sure they've seen this before.

Let us know what happens.

jch

On Sat, Nov 21, 2009 at 6:32 AM, Rhishabh Srivastava <rhishabh@xxxxxxxxx

wrote:

I am undergoing an Upgrade of a IBM iseries system model 820 from V5R3 to
V5R4M5 . After the OS got installed INZSYS did not ran on the system.
QSYSSBSD is the subsystem avialable in restricted state. Without noticing
whether the INZSYS has ran , we started applying the CUM PTF. This
installation failed . In the log it was not showing which PTF created
problem. We tried to start the TCP services so that another copy of image
catalogue can be taken but Ethernet line was not getting varied on .

Reason

for this was it was in lock by some other device(console). For this we

used

control panel Function 65 - Deactivate remote service so that console can
release the only available Ethernet Line.
It did not help but resulted in loss of Console. I would like to know if

an

IPL to DST is suitable in such case or not (when the CUM PTF installation
is
not successful , INZSYS has not ran and QSYSSBSD is in restricted state

).

Looking forward to know what are the implications of doing a IPL in case
CUM
PTF installation has failed.

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