Re: Recovering from a hosed up CUME install

wrote:

Pete,

I had this problem once before, and I wrote a quick CL that applied
each PTF individually. I then IPLed, and then ran the program again, and
that actually fixed everything. When you do a APYPTF *ALL *TEMP *IMMDLY
(or
even delayed), it stops when it can't apply one. That is why I wrote a CLP
that would try to apply each and every PTF individually that wasn't Perm or
Temp Applied. You can do this now and see how many get applied.

Pete

Pete Massiello
iTech Solutions
http://www.itechsol.com

Add iTech Solutions on Facebook:
http://www.facebook.com/group.php?gid=126431824120
Add iTech Solutionw on LinkedIn:
http://www.linkedin.com/groups?gid=2206093





-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Pete Helgren
Sent: Wednesday, February 10, 2010 12:19 PM
To: Midrange Systems Technical Discussion
Subject: Re: Recovering from a hosed up CUME install

Thanks Rob. This is a very *vanilla* customer. Simple, small, 10
users, no system customization of any kind.

I think I'll try Pete's approach first, which is to just load and apply
delayed, the latest CUME. I don't think this will work because the
current PTF's that won't apply because of concurrent issues with pre and
co requisites will probably prevent the latest PTF's that may also have
a dependency on the hosed ones from applying as well. But, you never
know. I could get lucky.

If I am still in the same position after the CUME is applied, I'll slip
LIC and reload the OS, then load the CUME.

I ordered the "full boatload" of PTF's for this CUME, rather than
ordering just the ones that weren't on the system in anticipation of
slipping LIC and loading OS (17 CD's) With the slow connection they
have, it's been running 15 hours and we have 7 CD's to go. Could be a
long night.....

Pete


rob@xxxxxxxxx wrote:

Actually what he says about the subsystem descriptions may, or may not,

be

true. Here's the catch: If you do what I used to do, which is copy over
qbatch subsystem description from a backup library prior to the upgrade
after every upgrade then you'll notice you have to keep doing this

because

you lost your change. Why? Because somewhere in the internals of the
subsystem description is it's release level and if it's really old (V2 I
think) it cannot upgrade it during the OS upgrade so it replaces it. I
have thousands of job queue entries in QBATCH. Finally called IBM on

this

and the workaround is to recreate my subsystem description from scratch
(or manually add the thousands of job descriptions to the new qbatch). I
wrote a program to retrieve the attributes of the backup qbatch and

create

a new qbatch. Now IBM updates it fine and I don't lose my job queue
entries. Again, I only had to run the program once and every os upgrade
since then has been fine.

Perhaps if you are one of those shops that tried something clever and
restored a machine onto another machine because you were more than n-2
levels behind or just would rather spend a month cleaning up problems

than

a day doing two upgrades to get there the official way, then you may have
also fell into this trap.


Rob Berendt

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