Re: Recovering from a hosed up CUME install

[Jack Kingsley <iseriesflorida@xxxxxxxxx>]

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.