× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.