Re: Recovering from a hosed up CUME install

I have two. One that has to be applied delayed and the other
immediate. When I attempt to load them it says they are already
loaded. Well, more accurately I get CPF3616 - All the program temporary
fixes (PTFs) that you requested to be loaded for product 5722SS1 *ONLY
either already exist in the library or are for options that are not
installed.

Pete


Jack Kingsley wrote:

Pete do you have any that are looking for save files that you may or may not
have.

On Wed, Feb 10, 2010 at 3:31 PM, Pete Massiello
<pmassiello-ml@xxxxxxxxxxxx>wrote:

Pete,

One last item on this. Sometimes it wants one PTF to be perm
applied, before it applies another temporarily. If going through the PTFs
one at a time doesn't work, you could try and perm apply everything and see
if that gets you out of the crazy cycle.

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 3:07 PM
To: Midrange Systems Technical Discussion
Subject: Re: Recovering from a hosed up CUME install

551 are not applied. BTW since the I started having this issue,
whenever I IPL I attempt to apply PTF's before we bounce in the hope
that it will finally apply the PTF that is causing the issue. There
have probably been 6 IPL's since the problem originally started.

Perhaps Pete's method will work....I'll use the outfile option in a CL
and then try to apply each one. If I change QSTRUP so that all of the
servers and services don't start every IPL, I might be able to run 4 or
5 bounce and apply cycles tonight and see if that gets the correct PTF
to apply.

Pete

Jack Kingsley wrote:

Have you attempted to dump the ptf's via dspptf to an outfile to see how
many are not applied.

On Wed, Feb 10, 2010 at 12:54 PM, Pete Massiello

<pmassiello-ml@xxxxxxxxxxxx

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.

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