Re: Recovering from a hosed up CUME install

OK. I can look at that. I wish there was an easy way to see the PTF "chain". That is, which unapplied PTF's have CO or PRE reqs that haven't been applied or met. That would tell me if I had one PTF that was missing that was a pre- or co req for other PTF's that weren't applied. I have a feeling that is what the issue is because a year or so ago when I ran into this, I tried to individually apply the PTF's and eventually got down to a bunch that just wouldn't apply. They all seemed to be contingent on same few PTF's that weren't applying, but as I investigated the "core" group of them, they all seems to be contingent on the same group of PTF's and they seemed to have a "circular" logic. That is PTF A needed PTF B which needed PTF C which needed PTF A again. I took copious notes which I eventually couldn't decipher...

Maybe I'll build a spreadsheet and see if I can figure out which PTF is the culprit. I wish I could get the list of required co and pre reqs with the DSPPTF *OUTFILE. That way I could use query or SQL to find the missing link.

Pete


Pete Massiello 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