|
I guess the point is
that we can understand overengineering the upper limit, but not the lower
limit. IBM can say that the cumulative PTF will take up to 8 hours to load
for the folks with dog systems, minimal interim PTFs, and lots of licensed
products. Why suggest a range of 4 to 8 hours if they're going to be wrong
about the lower limit of 4 hours? If someone has a rocketship of a system
with little storage utilized, base OS/400 products, and a fairly up to date set
of PTF's he or she can probably load the cume in less than an
hour.
I think it's a
reasonable concern. These instructions are read by a broad audience,
including seasoned system admins and first timers. I would be likely to
lose confidence and look for problems if an upgrade ran much faster than
anticipated. When you've scheduled down time it would be a disaster to
assume that IBM just mis-reported the time estimates and find out you blew the
cume after you've turned the system back over to
production.
We once had a
seasoned IBM AS/400 SE helping us with an OS upgrade. One of the steps
gave an estimate of 2 - 18 hours, and it ran for us in 40 minutes. The SE
was on the phone (and the call queue) with the support center for another three
hours verifying that the step completed properly.
It would be smarter
to define an upper limit so that you'll know when you might be in trouble, and
provide some sort of measure of success to check before moving
on.
the expression, I believe, is
"You'd complain if you didn't get hung with a new rope." The point
being...focus on important stuff, let the trivia go,
To all the self appointed kings of the
list:
The monday after the upgrade there were
problems. crtdspf was returning an MCH type error, license keys were
invalid, users were having to respond to msgs saying "the grace period for the
use of their printer would expire soon".
Before the cause of the problems was
identified, there was valid, non trivial concern that the ptf load, which the
ibm document stated would take a minimum of 4 hrs had only taken 50 minutes.
Something might have been missed, maybe we had received an incorrect cume,
...
The question, posed to the list leaders
and everyone else was to ask what ibm bases its estimates on.
Now the kings make important
contributions to the list. I have learned from their responses. I wish
them well, maybe a larger cubicle. Let them be assured that their role as list
leaders will not be challenged.
_______________________
|
| rob@dekko.com
Sent
by: owner-midrange-l@midrange.com
05/16/2001 10:36 AM
Please respond to MIDRANGE-L
|
To:
MIDRANGE-L@midrange.com
cc:
Subject: Re: why cum ptf apply
faster than predicted? |
I bet you'd complain if you got hung with a
brand new rope!
Be happy. Find a real problem. Spend some
quality time with a pretty
friend.
(Some people may not get
the first line. That's okay - I never did
either.)
Rob
Berendt
==================
Remember the Cole!
"Steve Richter"
<srichter@AutoCoder
To: <MIDRANGE-L@midrange.com>
.com>
cc:
Sent
by: Subject:
Re: why cum ptf apply faster than predicted?
owner-midrange-l@mi
drange.com
05/15/01 09:58 PM
Please respond to
MIDRANGE-L
>There are some situations where loading and
applying PTF's can take
longer -
>particular if you need certain
prerequisites, if some PTF's are applied
they
>need to be unapplied
before the new ones go on, it depends how many are
>superseded, what
group PTF's you have installed etc. etc.
>
good explanation
of the reason for the high side estimate.
But the low side estimate
still remains questionable. The cover letter said
4 to 8 hours.
Is
the 4 and 8 hour figure the value for the best and worse case
scenario
on
a baseline system?
ex: 4 hrs if loading cume on top
of a new release on a 520, 8 hrs if
loading
on top of a prev cume on the
same 520?
Steve
+---
| This is the Midrange System
Mailing List!
| To submit a new message, send your mail to
MIDRANGE-L@midrange.com.
| To subscribe to this list send email to
MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email
to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the
list
owner/operator:
david@midrange.com
+---
+---
|
This is the Midrange System Mailing List!
| To submit a new message, send
your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send
email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send
email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to
the list owner/operator:
david@midrange.com
+---
| 
midrange.com
