We've been HAD!
hoff_meister
isn't *just* Y2k! Abso-posi-lutely, there has been a *massive* coverup
going on for *years* regarding these so-called "computer-systems". TPTB
have been pulling the wool over *all* our eyes!
Look, people, just did my own search of bit.listserv.ibm-main.
These are the "super-geeks" of the mainframes. The systems that run the
civilized world. The "best of the best"!
There are, Oh, 50,000 of these running the world. From Dee Cee to Duh
Moine, even hear Klinton "slipped" a few of these over to China!
And here's the harsh truth, folks. You think these things are actually
working? HAH! They're NOT!
This has to be the biggest scam running! These things BREAK! All the
time! Failure upon Failure!
Don't believe me? Look for yourself! This is just for September!
http://x42.deja.com/=dnc/qs.xp?ST=PS&svcclass=dnyr&QRY=*&defaultOp=AND&D
BS=1&OP=dnquery.xp&LNG=ALL&subjects=&groups=bit.listserv.ibm-main&author
s=&fromdate=Sep+01+1999&todate=Sep+30+1999&showsort=date&maxhits=100&uni
q=938870109.248184862
Page after Page. Personally, stopped after I reached 1100, and hadn't
even made it back to September 17th!
Every one a problem, a failure, or someone who didn't know how to
actually do something! Screaming HALP!
Like Cory says:
---------
"In most cases, the big shops right-sized so much in the 1980's that
there wasn't anyone left with two good synapses to rub together."
---------
The evidence is right there, for all to see, if you *just open your
eyes*.
But this is *bigger* than just Y2k! I mean, only *67* mentioned either
"Y2k" OR "Date" in any way! Folks, these things just CAN'T be working
NOW! They CAN'T! I mean, well over 2,000 messages? Just from September?
Must be about 4% of these mainframe shops! And these are the
"super-geeks"; what about the rest?
Sure, a couple hundred might be running OK. Some quick fixes. Some poor
geek doing 36 hour days, bleary-eyed, staring at his console. But the
evidence is overwhelming.
Look, *read* Gary North! And we're expected to *believe* that these
systems run civilization today? The "Systemic, Cross-Cascading
Failures" would have sent us "InfoMagic" long ago!
The coverup must be HUGE! How many people are hidden in the backroom,
under the platform, doing the jobs the mainframes are *supposedly*
doing? No wonder unemployment is at all-time lows!
Need MORE proof? Again, Cory points the way:
------
"The ones in worse shape are those that went balls to the wall and bet
the firm that some wacky new technology would replace the legacy system.
We've seen several reports about SAP flops, Peoplesoft vaporware (the
University problem), and other situations that will hit the wall in 91
days."
-----
How much clearer can it be? But Cory is too focussed. These things
*supposedly* have been hitting the wall for the *LAST 5 YEARS*. We're
supposed to believe there are over 20,000 installations of this "wacky
new technology" and "vaporware"? HAH! NO WAY!
Again, look at the InfoMagic probability model, fer Chr*st's sake!
"Charlotte's Web"! It's SYSTEMIC! The DIVISION OF LABOR! *IF* all
these systems were *really* installed, causing all these errors (just
look at Hershey or World Bank!), we'd HAVE to be well down the
de-evolutionary spiral! There's absolutely NO WAY we could have
survived this long, if these things were *actually* running!
And this involves the BIGGEST CORPORATIONS IN THE WORLD! Look at their
SEC filings. "SAP" *supposedly* implemented all over the place!
Look Folks, there's only ONE possible explanation. We've been had!
These systems DON'T DO ANYTHING! THEY CAN'T BE!
Hoffmeister
Sent via Deja.com http://www.deja.com/
Before you buy.
g.k. cooper
<hoff_m...@my-deja.com> wrote:
>>The coverup must be HUGE! How many people are hidden in the backroom,
>>under the platform, doing the jobs the mainframes are *supposedly*
>>doing?
Wow, you're way out there. I'll take the next elevator, thanks.
coop
Pat Meadows
since he posted. I'd write, but I don't have his e-mail
address.
He used to post occasionally on another newsgroup I read,
but he hasn't been there recently either.
Pat
rhol...@wco.com
Sarcasm, son, sarcasm. Quite nice, too!
Got any more 12-hour gold tips? I wanna bet against your info...
Robert
rhol...@wco.com
It's so good I can't snip it.
Robert
> The coverup must be HUGE! How many people are hidden in the backroom,
> under the platform, doing the jobs the mainframes are *supposedly*
D. Scott Secor - Millennial Infarction Mitigator
news:9Cr+N7dJoyifoH...@4ax.com...
As long as we are reminiscing, has anyone heard hide-nor-hair of TVP
(Turkey-Vulture Paul)?
I certainly hope that DoeJoe's health problems didn't get the better of him.
Ciao,
--
D. Scott Secor, Year 2000 Institute Site Index -- http://y2k.board.org/
Defining Compliancy Down -- it "worked" so well in our government
education system. So why not go from 100% compliance to 100%
readiness to, as Sen. McClintock said, "we're at the average level"?
B
<gasp> Real Name, so perhaps he's just busy, and not extinct.
Pat Meadows wrote:
> Has anyone heard from DonJoe? It's been quite a while
> since he posted. I'd write, but I don't have his e-mail
> address.
>
> He used to post occasionally on another newsgroup I read,
> but he hasn't been there recently either.
>
> Pat
Tom Benjamin
>Look, people, just did my own search of bit.listserv.ibm-main.
Less than 90 days from rollover, who cares? Gary North is irrelevant and so
is this argument. Why don't you put up your feet and watch the show? The
argument is over. You won, okay? Who cares?
Everything is normal. Systems are always breaking. We gotcha. Hey, didn't
somebody make this argument about once a week for the past two years? Who do
you think you are convincing? Do you need more evidence? Figure to do one
more research project to top things off? The IT professionals are going to
pull it off, for sure. (Oops, sorry. The IT profession did pull it off.) You
went and proved Yourdon and his statistics are all wrong. Hurray for Hoffie.
The only thing left to do is put up our feet and wait to see whether Hoffie
was right or not. Yourdon no longer has anything to lose, has he? You proved
him wrong. So why do you keep trying to prove it again and again? You aren't
worried because you are the only one who can be wrong from this point on,
are you?
Nah. Relax. Pull up a chair. Watch the show.
Tom
Tom Ambrose
>Has anyone heard from DonJoe? It's been quite a while
>since he posted. I'd write, but I don't have his e-mail
>address.
<SNIP>
DonJoe is alive but struggling with his health problems. Please keep
him in your prayers.
Tom Ambrose
g.k. cooper
wrote:
>>The only thing left to do is put up our feet and wait to see whether Hoffie
>>was right or not. Yourdon no longer has anything to lose, has he? You proved
>>him wrong. So why do you keep trying to prove it again and again? You aren't
>>worried because you are the only one who can be wrong from this point on,
>>are you?
You nailed it, Tom. I've already admitted that I was wrong on
several fronts with regards to y2k and "spike dates".
It's time to watch the show.
coop
BOZO999
Tom Benjamin wrote:
>
> Nah. Relax. Pull up a chair. Watch the show.
>
> Tom
That's the spirit Tom. Don the rubber nose, and confess your sins.
Repudiate all your past doomer statements, and ESPECIALLY repudiate
preparation. We're going to have PollyBrood convergence, but we won't
converge in the middle like R.Holland predicted. We're all going to be
Pollies, and I've got the rubber nose concession. Group hug!
BOZO
Undisputed ruler of the Polly-verse
Hoffmeister
>
<snip>
No No, Tommie, I'm "with the program" now! I "Get It"!
See, Tommie, when the rollover comes and goes, it's just *more* proof!
Little or no problems? HAH! Just as I figured, 'cause NO WAY can these
*supposed* systems actually be running! If they *were*, it'd be
TEOTWAWKI for sure! Can't you understand? Like Yourdon has said
repeatedly, IT projects are *always* late.
No, it'll be the "long, slow grind" downward. But the REAL reason will
be "they" will run out of people to keep upping the so-called
"productivity" improvements these *supposed* systems have been
producing. Sooner or later, the BIG LIE will be exposed!
It's the only answer, Tommie. Why no increase in programmer demand?
Simple; everyone was taken in, actually *thinking* these things had to
be repaired! When in reality, TPTB *knew* their wasn't anything *to*
fix!
Hoffmeister
Tom Benjamin
Hoffmeister wrote in message
>No No, Tommie, I'm "with the program" now! I "Get It"!
Who cares any more? We'll see if you are right or not. We'll see if the IT
profession does a good job when push comes to shove. From this point on it
is *your* reputation that is on the line, not Yourdon's. (Mind you, you
aren't willing to put *your* reputation on the line are you, oh, anonymous
one?)
You don't need *more* proof do you? Yada, yada, yada. It's a done deal.
Yesterday's news. Why do you need more proof?
I don't. Relax. Put your feet up, completely confident in the IT profession.
Weren't you the one who proved that we get more errors in a typical day than
we will on New Year's? We're going to find out whether Hoffie was right.
Eighty some odd days. Can't you hardly wait?
Tom
allyson
<p...@meadows.pair.com> writes
> Has anyone heard from DonJoe? It's been quite a while
>since he posted. I'd write, but I don't have his e-mail
>address.
>
>but he hasn't been there recently either.
>
>Pat
say if he sounded fine, but was making plans for the future...which is
always a good sign (if we have a future that is)
Ally.
Remove dash to reply
Some horrible person has been forging my email address to post unpleasant
messages PLEASE NOTE...the real Ally does not post to unsavoury news groups or
send unpleasant email.
Jed Brulen
report:
By golly I have heard from Turkey Paul lately. He is quite healthy and
in fact even robust while he finishes off his preparations (which never
seem to ever be finished). He is I think you used to say feng shui-ing.
g.k. cooper
>>Got any more 12-hour gold tips? I wanna bet against your info...
What do you think it's going to do?
coop
Hoffmeister
>
> Hoffmeister wrote in message
>
> >No No, Tommie, I'm "with the program" now! I "Get It"!
>
> Who cares any more? We'll see if you are right or not. We'll see if the IT
> profession does a good job when push comes to shove. From this point on it
> is *your* reputation that is on the line, not Yourdon's. (Mind you, you
> aren't willing to put *your* reputation on the line are you, oh, anonymous
> one?)
>
You're right, Tommie. I don't post my name. I also don't target people
on "Welfare", "Social Security", "Medicare" and "single mothers barely
able to support three kids" with pyramid scams for a bunch of video
tapes and conference calls.
Which is the greater wrong? Hey, I'll let people decide for themselves.
> You don't need *more* proof do you? Yada, yada, yada. It's a done deal.
> Yesterday's news. Why do you need more proof?
>
> I don't. Relax. Put your feet up, completely confident in the IT profession.
> Weren't you the one who proved that we get more errors in a typical day than
> we will on New Year's? We're going to find out whether Hoffie was right.
> Eighty some odd days. Can't you hardly wait?
>
> Tom
Actually, looking forward to it Tommie. But of course, the *new* line
is it won't get *really* bad till what, September 2000 now?
Borrowing a tag-line from Paul Davis:
"TEOTWAWKI just ain't what it used to be"
Hoffmeister
Ralph Daugherty
> <snip>
> Look Folks, there's only ONE possible explanation. We've been had!
> These systems DON'T DO ANYTHING! THEY CAN'T BE!
You think they're not doing anything now, just wait. We're not talking
about the other problems going away and being replaced with Y2K problems,
we're talking about the normal level of problems that will be considered just
noise in what's about to take place. A whole different ballgame next year.
Ralph
Na Kaula
Beeks in drag? "Queen of the Universe"?
...another one *plonks* the dust!
--
Y2K?
Y-not2K!
(Remove the underscore for e-mail)
Tom Benjamin
>You're right, Tommie. I don't post my name. I also don't target people
>on "Welfare", "Social Security", "Medicare" and "single mothers barely
>able to support three kids" with pyramid scams for a bunch of video
>tapes and conference calls.
What does this have to do with you or your reputation being on the line? Can
I post my name and not target "Welfare"? Do I have to dump on "Medicare"
because I do use my name?
>Actually, looking forward to it Tommie. But of course, the *new* line
>is it won't get *really* bad till what, September 2000 now?
So let's look forward to it, instead of covering the same old ground, okay?
January 15th is my date. We'll know about the computer failures by then, and
we'll know whether you are right or not. It will probably take another six
months to see exactly how far offbase you are but we will know whether it is
an event or not by then for sure.
So relax. What's the big deal?
Why are you rushing to prove something that you have already proven a
million times? Y2k has been thoroughly debunked. Debunked to death.
Especially TEOTWAWKI. Everything is normal, and everybody is behaving
normally.
Relax. Let's watch the show. Nothing is about to unfold.
Tom
Henry Ahlgrim
>
<<< snip shocking revelations. >>>>>
Dammit Hoffy, now you've blown our cover!!
--
White, wheat, or raisin
Henry Ahlgrim
****************************************************
A novel approach to Y2K --> http://www2.gol.com/users/doitnow/
****************************************************
BOZO999
Plonking is the sincerest form of flattery. Did you see me get
*plonked*, Mr. Sherman? Na Kaula thinks I'm you, dressed up like Freddy
Mercury. Ol' JD's a quick study. He graduates from shit to shinola in 24 hours.
BOZO999
Undisputed Ruler of -bks- Impersonation/Simulation
Hoffmeister
>
<snip>
> What does this have to do with you or your reputation being on the line? Can
> I post my name and not target "Welfare"? Do I have to dump on "Medicare"
> because I do use my name?
>
No, *you* don't have to do any of the above.
My point, apparently missed, is that someone who *does* do such things,
probably doesn't care too much about his "reputation", at least in the
sense you seem to imply.
Just my opinion, obviously.
> So let's look forward to it, instead of covering the same old ground, okay?
> January 15th is my date. We'll know about the computer failures by then, and
> we'll know whether you are right or not. It will probably take another six
> months to see exactly how far offbase you are but we will know whether it is
> an event or not by then for sure.
>
The six months is a little hedge, but gotta admire you for sticking to a
date. The party line is a-changin', though.
> So relax. What's the big deal?
>
> Why are you rushing to prove something that you have already proven a
> million times? Y2k has been thoroughly debunked. Debunked to death.
> Especially TEOTWAWKI. Everything is normal, and everybody is behaving
> normally.
>
> Relax. Let's watch the show. Nothing is about to unfold.
>
> Tom
Tommie, what's the problem, guy? Comparing the number of my posts to
yours, I certainly find your advice to "relax" a little strange. Or are
you following Yourdon's lead to "lighten up"?
Methinks you miss the main point, Tommie. The past year has *not* been
"business as usual".
Yourdon, et al, weren't necessarily wrong on the potential for errors
and system failures on the previous "key dates"; the problem was the
resulting effects. What Yourdon describes as "covering up" and "denial"
of problems is in reality the *function* of system maintenance, and
production support.
In fact, I think "InfoMagic" actually identified the largest potential
risk, in the massive upheaval in systems that has occurred, either
through replacement or remediation.
Where all of the above *failed* is in the resulting effects, which have
been decidedly minimal. No "systemic, cross-cascading failures".
Nothing even close.
Hoffmeister
Bradley K. Sherman
Tom Benjamin <benj...@prcn.org> wrote:
>So let's look forward to it, instead of covering the same old ground, okay?
>January 15th is my date. We'll know about the computer failures by then, and
>we'll know whether you are right or not. It will probably take another six
>months to see exactly how far offbase you are but we will know whether it is
>an event or not by then for sure.
Another ticket on the Flaming Revisionist Riverboat to Richmond!
--bks
Tom Benjamin
Bradley K. Sherman wrote in message
>Another ticket on the Flaming Revisionist Riverboat to Richmond!
Another boring unsubstantiated post from the boring fraud in San Francisco!
Can't you be the eensy-weensy-teensy tiny bit interesting? Are there any
interesting people in your area? Are there any interesting ideas in your
head?
I guess not. Are you smart as computer programmers go? Typical? Or one of
the really stupid incompetent ones? I guess our only hope is that you are
one of the stupid ones. If you are typical, it probably is the end of the
world.
Tom
Dean T. Miller
>Where all of the above *failed* is in the resulting effects, which have
>been decidedly minimal. No "systemic, cross-cascading failures".
>Nothing even close.
I'm seriously puzzled. What year is this?
Why should there be anything close to "systemic, cross-cascading
failures" at this time in 1999?
Most of the failure charts (Gartner Group, et. al.), that I've seen
over the past 2 years, project a fairly low incidence of failure by
this date. We shouldn't have heard about any DMV problems in NY or
NV; we shouldn't have heard about any food stamp problems in NJ or CO;
we shouldn't have heard about a candy company having $30 million
problems.
It's too early in the 'game.'
In case you've forgotten, here's the primary scenario.
Prior to 1/1/00, Y2k related failures** will occur with increasing
frequency AND BE FIXED in a timely manner. The frequency of
occurrence is based on the number of systems that must use a date past
12/31/99 for their processing. For this reason, the failure rate was
expected to jump on specific dates, as the systems passed the 2000
threshold. These dates were 1/1/99, 4/1/99, 7/1/99, 10/1/99 and then
monthly until 12/1/99, then weekly. Also, accounting systems starting
new fiscal years where the end of the fiscal year passed the 2000
threshold would see an increase in failures. But remember, most of
these failures would be fixed before causing unmanageable problems.
When the frequency of failures -within an organization- passes the
point where failures cannot be fixed before other failures occur, then
a cascading effect will begin. This effect will cause increasing
inefficiencies within the organization -- delayed production,
shipping, payroll.
Some organizations, especially those that have fully remediated or
replaced their systems (and tested them), may never reach the point
where the cascade occurs. But all signs to date indicate that the
overwhelming majority of organizations, large and small, started too
late and will experience the failure cascade.
As the failures increase, the cascade will affect external
organizations. These organizations will, in turn, have an effect on
other organizations. As the cascade increases, the economy will
increasingly be negatively affected. People will be laid off and
unable to continue spending as they have, resulting in more lay offs
-- and bankrupcies. This is the Infomagic spiral.
Most of this won't occur until after 1/1/00, possibly several months
after.
The charts also project a failure spike for a few days beginning on
1/1/00, for embedded system failures. IMO, most people seem to have
interpreted the charts very optimistically in this area. They seem to
think that the charts say that embedded system failures will last only
a few days. In a few cases that may be true, but these charts are
intended to show a RATE of failure -- not a duration of the problems
caused by the failures. The actual consequences of the embedded
'spike' could last for weeks, months or years.
** Y2k related failures means: 1)date processing failures in
unremediated computer systems, 2)date processing failures or bugs
introduced into remediated computer systems or 3) failures in new
systems which have replaced existing systems that were expected to
fail due to date processing. This DOES NOT include date-related
failures for dates such as 9/9/99 or 12/31/99, but does include JAEs
(fiscal year setup problems in accounting systems).
-- Dean -- from (almost) Duh Moines (CDP, KB0ZDF)
Ralph Daugherty
A great summarization for lurkers, Dean. Thanks.
Ralph
Neason
Steve
On Fri, 8 Oct 1999 17:50:45 -0400 (EDT), Bru...@webtv.net (Jed Brulen)
wrote:
Bradley K. Sherman
Tom Benjamin <benj...@prcn.org> wrote:
>
>I guess not. Are you smart as computer programmers go? Typical? Or one of
>the really stupid incompetent ones? I guess our only hope is that you are
>one of the stupid ones. If you are typical, it probably is the end of the
>world.
>
Hey, Tom, by your new estimate that we won't know anything till
15 January and the tally won't be in till June, does that mean
that I can wait till 10 January to do my panic shopping? Can
I put off getting ammo for the old Colt Commander till May?
Will the 6500 Watt generators be available in February for a
fraction of their current price?
--bks
Hoffmeister
>
>
> I'm seriously puzzled. What year is this?
>
> Why should there be anything close to "systemic, cross-cascading
> failures" at this time in 1999?
>
> Most of the failure charts (Gartner Group, et. al.), that I've seen
> over the past 2 years, project a fairly low incidence of failure by
> this date. We shouldn't have heard about any DMV problems in NY or
> NV; we shouldn't have heard about any food stamp problems in NJ or CO;
> we shouldn't have heard about a candy company having $30 million
> problems.
>
> It's too early in the 'game.'
The Gartner Group Failure charts deal with date-processing errors only.
See the report at:
http://www.gartnerweb.com/public/static/y2k/00081966.html#0016
The errors I'm referring to are due solely to the replacement and
remediation of so many systems in such a short time period. See:
http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001FmM
In short, using the same basic estimates from Capers Jones, the number
of system errors from these replacements and remediation are orders of
magnitude greater than potential Y2k errors. And these account for
virtually *every* case of "Y2k-related" failure to date.
>
> In case you've forgotten, here's the primary scenario.
>
> Prior to 1/1/00, Y2k related failures** will occur with increasing
> frequency AND BE FIXED in a timely manner. The frequency of
> occurrence is based on the number of systems that must use a date past
> 12/31/99 for their processing. For this reason, the failure rate was
> expected to jump on specific dates, as the systems passed the 2000
> threshold. These dates were 1/1/99, 4/1/99, 7/1/99, 10/1/99 and then
> monthly until 12/1/99, then weekly. Also, accounting systems starting
> new fiscal years where the end of the fiscal year passed the 2000
> threshold would see an increase in failures. But remember, most of
> these failures would be fixed before causing unmanageable problems.
>
> When the frequency of failures -within an organization- passes the
> point where failures cannot be fixed before other failures occur, then
> a cascading effect will begin. This effect will cause increasing
> inefficiencies within the organization -- delayed production,
> shipping, payroll.
>
Hmmm. Yes, but if an even *higher* rate of errors has already been
encountered, *without* such "cascading effects", it would be fairly
reasonable to assume Y2k would not cause them, either.
> Some organizations, especially those that have fully remediated or
> replaced their systems (and tested them), may never reach the point
> where the cascade occurs. But all signs to date indicate that the
> overwhelming majority of organizations, large and small, started too
> late and will experience the failure cascade.
>
Again, the "failure cascade"? And again, why has it not occurred to
date? Errors due to implementations are even more severe than Y2k
errors. Where are the "systemic, cross-cascading defaults"?
> As the failures increase, the cascade will affect external
> organizations. These organizations will, in turn, have an effect on
> other organizations. As the cascade increases, the economy will
> increasingly be negatively affected. People will be laid off and
> unable to continue spending as they have, resulting in more lay offs
> -- and bankrupcies. This is the Infomagic spiral.
>
> Most of this won't occur until after 1/1/00, possibly several months
> after.
>
Ahh yes, the *new* party-line. No more cities resembling Beirut? Or
has Beirut suddenly become a "nice place to visit"?
> The charts also project a failure spike for a few days beginning on
> 1/1/00, for embedded system failures. IMO, most people seem to have
> interpreted the charts very optimistically in this area. They seem to
> think that the charts say that embedded system failures will last only
> a few days. In a few cases that may be true, but these charts are
> intended to show a RATE of failure -- not a duration of the problems
> caused by the failures. The actual consequences of the embedded
> 'spike' could last for weeks, months or years.
>
> ** Y2k related failures means: 1)date processing failures in
> unremediated computer systems, 2)date processing failures or bugs
> introduced into remediated computer systems or 3) failures in new
> systems which have replaced existing systems that were expected to
> fail due to date processing. This DOES NOT include date-related
> failures for dates such as 9/9/99 or 12/31/99, but does include JAEs
> (fiscal year setup problems in accounting systems).
>
> -- Dean -- from (almost) Duh Moines (CDP, KB0ZDF)
I don't expect it, but if you are interested, read through the link I
gave. Then we can discuss rates of errors, and "failure cascades".
Hoffmeister
Bradley K. Sherman
And another ticket on the Flaming Revisionist Riverboat to
Richmond for Dean T. Miller who wrote in 1998:
| The Jo Anne Effect problems have already started, and will
| continue to increase as more and more systems look ahead
| into 2000. The '99' problems will hit the first time systems
| using this delimiter are run -- which could be the first day,
| first week end, month end, quarter end, etc.
(http://x28.deja.com/getdoc.xp?AN=383671268&CONTEXT=937264746.886636577&hitnum=4)
--bks
Ralph Daugherty
> <snip>
> Again, the "failure cascade"? And again, why has it not occurred to
> date? Errors due to implementations are even more severe than Y2k
> errors. Where are the "systemic, cross-cascading defaults"?
Where did you get the idea that errors due to implementations are more
severe than Y2K errors? Most decidedly not (or in current parlance, NOT).
Read Dean's post again and note that the implementation failures occurring
this year are being fixed. When Y2K failures occur in droves then an
organization will not be able to successfully fix on failure. It will no
longer be business as usual then for that organization. The cascading effects
snowball as a loss of business effect ripples through the economy.
Your false assumptions are throwing you way off.
Ralph
Hoffmeister
>
> Hoffmeister wrote:
> > <snip>
> > Again, the "failure cascade"? And again, why has it not occurred to
> > date? Errors due to implementations are even more severe than Y2k
> > errors. Where are the "systemic, cross-cascading defaults"?
>
> severe than Y2K errors? Most decidedly not (or in current parlance, NOT).
> Read Dean's post again and note that the implementation failures occurring
> this year are being fixed. When Y2K failures occur in droves then an
> organization will not be able to successfully fix on failure. It will no
> longer be business as usual then for that organization. The cascading effects
> snowball as a loss of business effect ripples through the economy.
>
> Your false assumptions are throwing you way off.
>
> Ralph
Where did I get the idea? Oh, I don't know, maybe from observing the
types of errors that occur during date-processing, as opposed to the
errors that I've been living with during system implementations for the
past 3-4 years. In particular, the last week and a half.
As for occurring in "droves", again, if you really want to discuss this,
read the links. Almost no question errors from system implementations
in the past year are orders of magnitude higher than potential Y2k
errors. But again, you *might* have to read the link.
Hoffmeister
Tom Benjamin
>My point, apparently missed, is that someone who *does* do such things,
>probably doesn't care too much about his "reputation", at least in the
>sense you seem to imply.
Forget this, okay? We are making too much of what I will admit was a Bradley
Sherman cheap shot. I don't care who you are. It does not matter anyway. The
only thing that counts with me is the quality of the idea and the quality of
presentation.
>Yourdon, et al, weren't necessarily wrong on the potential for errors
>and system failures on the previous "key dates"; the problem was the
>resulting effects. What Yourdon describes as "covering up" and "denial"
>of problems is in reality the *function* of system maintenance, and
>production support.
Who are you trying to convince with this argument?
Let's see, this is only the 14,473rd time I have heard this. Everyone has
made up their mind. A lot of people agree with you. They have been convinced
by the brilliance of your argument. I've made up my mind too, but I don't
agree with you. I could explain why, but it is an argument you have heard
14,221 times. What's the point?
So why did you bother? That is a very interesting question, I think. One
plausible explanation is that you have a need to keep convincing yourself
that you are right. Will Pollyanna handwaving will get louder and louder and
screechier and screechier as we approach the date, even though nobody is
really arguing with them any more? "Nothing happened this week", the Pollies
will twitter in their Polly threads. "See nothing happened! Again!"
Part of the show, I guess, but my advice is to pull up a chair and relax.
Unless you feel the need to convince yourself some more.
Tom
Tom Benjamin
Bradley K. Sherman wrote in message
>Hey, Tom, by your new estimate that we won't know anything till
>15 January and the tally won't be in till June, does that mean
>that I can wait till 10 January to do my panic shopping? Can
>I put off getting ammo for the old Colt Commander till May?
>Will the 6500 Watt generators be available in February for a
>fraction of their current price?
You can do whatever you want. I don't care. Is this boring, or what? Is it
supposed to be funny? Do other boring people find it funny? That must be it.
Tom
Hoffmeister
>
<snip>
> Who are you trying to convince with this argument?
>
> Let's see, this is only the 14,473rd time I have heard this. Everyone has
> made up their mind. A lot of people agree with you. They have been convinced
> by the brilliance of your argument. I've made up my mind too, but I don't
> agree with you. I could explain why, but it is an argument you have heard
> 14,221 times. What's the point?
Don't sweat it, Tommie. You're in pretty good company in not being able
to "explain why".
>
> So why did you bother? That is a very interesting question, I think. One
> plausible explanation is that you have a need to keep convincing yourself
> that you are right. Will Pollyanna handwaving will get louder and louder and
> screechier and screechier as we approach the date, even though nobody is
> really arguing with them any more? "Nothing happened this week", the Pollies
> will twitter in their Polly threads. "See nothing happened! Again!"
>
> Part of the show, I guess, but my advice is to pull up a chair and relax.
> Unless you feel the need to convince yourself some more.
>
> Tom
Don't know, Tommie, but if anyone is getting "screechier" around here, I
don't think it's me.
Hoffmeister
Ralph Daugherty
>
> Where did I get the idea? Oh, I don't know, maybe from observing the
> types of errors that occur during date-processing, as opposed to the
> errors that I've been living with during system implementations for the
> past 3-4 years. In particular, the last week and a half.
You, too. I'm having a lot of fun myself.
> As for occurring in "droves", again, if you really want to discuss this,
> read the links. Almost no question errors from system implementations
> in the past year are orders of magnitude higher than potential Y2k
> errors. But again, you *might* have to read the link.
Not sure what you're saying here other than I should read *the* link. I
really don't care what the link says, in my opinion Y2K errors will cause
programs to crash and burn, with a liberal sprinkling of bad data coming from
who knows where, in more potent ways than that which occurs during a new
system implementation. My opinion is as good or worthless as anyone else you
care to cite.
I will not dispute your contentions that the situations are similar, nor
that a system implementation is not a walk in the park.
Ralph
Dean T. Miller
Hoffmeister <hoff_m...@my-deja.com> wrote:
>Dean T. Miller wrote:
>> It's too early in the 'game.'
>
>The Gartner Group Failure charts deal with date-processing errors only.
>See the report at:
>
>http://www.gartnerweb.com/public/static/y2k/00081966.html#0016
>
>The errors I'm referring to are due solely to the replacement and
>remediation of so many systems in such a short time period. See:
>
>http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001FmM
>
>In short, using the same basic estimates from Capers Jones, the number
>of system errors from these replacements and remediation are orders of
>magnitude greater than potential Y2k errors. And these account for
>virtually *every* case of "Y2k-related" failure to date.
Correct. These are 'extra' bugs not shown on Gartner Group's chart.
The reason we've heard of the problems with replacement systems is
because the number of errors exceeded the fixable threshold -- there
were lots of bugs all at once. IOW, one bug couldn't be fixed before
the next one popped up.
The chart shows only expected 2000-related problems; the kind that
won't make the news because they will be fixed before causing external
problems.
>> When the frequency of failures -within an organization- passes the
>> point where failures cannot be fixed before other failures occur, then
>> a cascading effect will begin. This effect will cause increasing
>> inefficiencies within the organization -- delayed production,
>> shipping, payroll.
>
>Hmmm. Yes, but if an even *higher* rate of errors has already been
>encountered, *without* such "cascading effects", it would be fairly
>reasonable to assume Y2k would not cause them, either.
Again, it's still too early to see any noticeable volume of cascading
errors (unless you're a candy distributor). The problem arises from
the accumulation of errors within many companies, and that most likely
won't happen until after 1/1/00 (though some think it could happen in
December).
>> Some organizations, especially those that have fully remediated or
>> replaced their systems (and tested them), may never reach the point
>> where the cascade occurs. But all signs to date indicate that the
>> overwhelming majority of organizations, large and small, started too
>> late and will experience the failure cascade.
>
>Again, the "failure cascade"? And again, why has it not occurred to
>date? Errors due to implementations are even more severe than Y2k
>errors. Where are the "systemic, cross-cascading defaults"?
I really am puzzled, now, about why you think these "defaults" should
be present. We're still in 1999.
Even companies that have date-related processing errors in their
ordering or scheduling systems won't necessarily realize the problem
until parts (supposedly) on order show up missing, or too few or too
many widgets are produced. Even though the errors might have already
occurred, the errors won't become apparent until after 1/1/00.
>> As the failures increase, the cascade will affect external
>> organizations. These organizations will, in turn, have an effect on
>> other organizations. As the cascade increases, the economy will
>> increasingly be negatively affected. People will be laid off and
>> unable to continue spending as they have, resulting in more lay offs
>> -- and bankrupcies. This is the Infomagic spiral.
>>
>> Most of this won't occur until after 1/1/00, possibly several months
>> after.
>
>Ahh yes, the *new* party-line. No more cities resembling Beirut? Or
>has Beirut suddenly become a "nice place to visit"?
As I said, this is a refresher. I wrote almost the same scenario over
a year ago.
As Tom B. has repeatedly pointed out, look-ahead failures either 1)
aren't critically important or, if they are they 2) won't be
discovered until 2000.
Y2K Whit
>severe than Y2K errors? Most decidedly not (or in current parlance, NOT).
>Read Dean's post again and note that the implementation failures occurring
>this year are being fixed. When Y2K failures occur in droves then an
>organization will not be able to successfully fix on failure. It will no
>longer be business as usual then for that organization. The cascading
>effects
>snowball as a loss of business effect ripples through the economy.
>
> Your false assumptions are throwing you way off.
>
> Ralph
>
>
Damn...Ralph.. I'm in one of my personal-polly-denial-phases right now.. your
posts make it hard for me to stay there... because I KNOW your background, and
qualifications.. it's hard to pretend that you don't know what your talking
about..sigh...
SaintWhit
Hoffmeister
>
> Correct. These are 'extra' bugs not shown on Gartner Group's chart.
> The reason we've heard of the problems with replacement systems is
> because the number of errors exceeded the fixable threshold -- there
> were lots of bugs all at once. IOW, one bug couldn't be fixed before
> the next one popped up.
>
Yep. The kind that accompany virtually *every* major software
implementation.
> The chart shows only expected 2000-related problems; the kind that
> won't make the news because they will be fixed before causing external
> problems.
>
Don't know about the "won't make the news" part.
> Again, it's still too early to see any noticeable volume of cascading
> errors (unless you're a candy distributor). The problem arises from
> the accumulation of errors within many companies, and that most likely
> won't happen until after 1/1/00 (though some think it could happen in
> December).
>
<snip>
>
> I really am puzzled, now, about why you think these "defaults" should
> be present. We're still in 1999.
>
> Even companies that have date-related processing errors in their
> ordering or scheduling systems won't necessarily realize the problem
> until parts (supposedly) on order show up missing, or too few or too
> many widgets are produced. Even though the errors might have already
> occurred, the errors won't become apparent until after 1/1/00.
>
<snip>
>
> As I said, this is a refresher. I wrote almost the same scenario over
> a year ago.
>
> As Tom B. has repeatedly pointed out, look-ahead failures either 1)
> aren't critically important or, if they are they 2) won't be
> discovered until 2000.
>
> -- Dean -- from (almost) Duh Moines (CDP, KB0ZDF)
I snipped the stuff in between, because you're essentially making the
same point. I don't think I changed the content.
My point is there is nothing "mystical" or "magical" about Y2k bugs;
they are, in fact, rather ordinary. The problem has never been *how* to
fix them, but rather *finding* them all.
Except for a *very* small percentage, I'm *not* referring to
"look-ahead" failures at all. I'm referring to errors that accompany
new implementations. The software replacements and modifications
re-implemented into production in the past year, simultaneously, without
a doubt dwarf anything seen previously.
Using metrics from Capers Jones, and some very conservative assumptions,
it is apparent that the rate of errors introduced into production in the
past year is *orders of magnitude* higher than errors that can be
expected from the rollover to 2000. And that several comparable
two-week periods have already been experienced, with error rates *at
least* as high as the rollover. And thus far, there is absolutely *no*
evidence of "cascading failures" from these errors.
Again, I'm *not* referring to "look-ahead" errors. That's not the
point. Systems and users don't care whether failures are caused by
invalid converted data, incorrect software installations, bad
communication parameters, or "date processing". If we have survived
essentially unscathed from periods of comparable error rates previously,
there is no reason to believe we won't at the rollover.
Hoffmeister
Dean T. Miller
Hoffmeister <hoff_m...@my-deja.com> wrote:
>Dean T. Miller wrote:
>>
>> Correct. These are 'extra' bugs not shown on Gartner Group's chart.
>> The reason we've heard of the problems with replacement systems is
>> because the number of errors exceeded the fixable threshold -- there
>> were lots of bugs all at once. IOW, one bug couldn't be fixed before
>> the next one popped up.
>>
>
>Yep. The kind that accompany virtually *every* major software
>implementation.
Well, sort of. Usually this number of bugs (or poor specialized
settings -- Hershey is implementing an "ERP solution," as I recall)
doesn't get into production. Most are ferreted out before going
full-bore for the gusto. This implies to me that there was some kind
of pressure to move the software to the production arena before it was
fully tested.
With normal IT processes, the $30 million Hershey debacle shouldn't
have happened.
>> The chart shows only expected 2000-related problems; the kind that
>> won't make the news because they will be fixed before causing external
>> problems.
>
>Don't know about the "won't make the news" part.
If a bug is found and fixed, why is it newsworthy? As everyone knows,
bugs pop up all the time, everywhere. Even if they're date-related,
an occasional bug isn't a big deal. Only when the number of bugs
passes the manageable threshold will they possibly make the news --
and only if the end effect of the bugs is to do something very
noticeable by the outside world, like forgetting to print and mail
thousands of retirement pension checks.
>My point is there is nothing "mystical" or "magical" about Y2k bugs;
>they are, in fact, rather ordinary. The problem has never been *how* to
>fix them, but rather *finding* them all.
I fully agree. The only real problem is the sheer number of 'bugs.'
(They aren't/weren't bugs until 2000 came along -- the code works fine
for dates prior to 2000, so normal bug-finding procedures don't work.)
But it's the huge incidence of incorrect date processing coupled with
a too-late start by most organizations that will be the back breaker.
That's why I like the "polishing marbles in the Grand Canyon" analogy.
>Except for a *very* small percentage, I'm *not* referring to
>"look-ahead" failures at all. I'm referring to errors that accompany
>new implementations. The software replacements and modifications
>re-implemented into production in the past year, simultaneously, without
>a doubt dwarf anything seen previously.
Fer sher. But I'd bet we haven't seen most of the replacements come
on line as yet (to my knowledge, there's no data regarding what
percentage of systems have been replaced vs. those remediated).
>Using metrics from Capers Jones, and some very conservative assumptions,
>it is apparent that the rate of errors introduced into production in the
>past year is *orders of magnitude* higher than errors that can be
>expected from the rollover to 2000.
Hmm. I haven't seen those metrics (have I?). I sure can't figure out
why this would be correct, given the CIO magazine report that says a
large percentage (40+%??) of companies haven't rolled-out their Y2k
fixes for critical systems as yet -- and 12% say they won't before
2000. And the numbers on non-critical systems is completely lacking
-- as is discussion of what effect they will have on an organization's
efficiency.
>And that several comparable
>two-week periods have already been experienced, with error rates *at
>least* as high as the rollover. And thus far, there is absolutely *no*
>evidence of "cascading failures" from these errors.
Could you point me to some place that has these numbers? I must have
really missed something here.
>Again, I'm *not* referring to "look-ahead" errors. That's not the
>point. Systems and users don't care whether failures are caused by
>invalid converted data, incorrect software installations, bad
>communication parameters, or "date processing".
Yup.
>If we have survived
>essentially unscathed from periods of comparable error rates previously,
>there is no reason to believe we won't at the rollover.
This is where we disagree. :)
I'll have to see how the error rates over the past few months could
come within an order (or two) of magnitude to those of the first few
months of 2000.
Help me out here -- where do your numbers come from?
Hoffmeister
> Well, sort of. Usually this number of bugs (or poor specialized
> settings -- Hershey is implementing an "ERP solution," as I recall)
> doesn't get into production. Most are ferreted out before going
> full-bore for the gusto. This implies to me that there was some kind
> of pressure to move the software to the production arena before it was
> fully tested.
>
> With normal IT processes, the $30 million Hershey debacle shouldn't
> have happened.
>
Yeah. I heard they were putting in some software. Called SOP, or EAP,
or something like that.
There's *always* pressure to move the software into production. Most
new implementations experience a high rate of errors initially.
>
> If a bug is found and fixed, why is it newsworthy? As everyone knows,
> bugs pop up all the time, everywhere. Even if they're date-related,
> an occasional bug isn't a big deal. Only when the number of bugs
> passes the manageable threshold will they possibly make the news --
> and only if the end effect of the bugs is to do something very
> noticeable by the outside world, like forgetting to print and mail
> thousands of retirement pension checks.
>
Granted. Some refer to this as "denial" and "coverups"; me, I see
normal maintenance and production support.
> I fully agree. The only real problem is the sheer number of 'bugs.'
> (They aren't/weren't bugs until 2000 came along -- the code works fine
> for dates prior to 2000, so normal bug-finding procedures don't work.)
>
> But it's the huge incidence of incorrect date processing coupled with
> a too-late start by most organizations that will be the back breaker.
> That's why I like the "polishing marbles in the Grand Canyon" analogy.
>
"Normal" bug-finding procedures usually involve test systems. From what
I've seen, testing with the date rolled forward does a fairly decent
job.
>
> Fer sher. But I'd bet we haven't seen most of the replacements come
> on line as yet (to my knowledge, there's no data regarding what
> percentage of systems have been replaced vs. those remediated).
>
<snip>
> Hmm. I haven't seen those metrics (have I?). I sure can't figure out
> why this would be correct, given the CIO magazine report that says a
> large percentage (40+%??) of companies haven't rolled-out their Y2k
> fixes for critical systems as yet -- and 12% say they won't before
> 2000. And the numbers on non-critical systems is completely lacking
> -- as is discussion of what effect they will have on an organization's
> efficiency.
>
I gave a link before. Over on EY's board:
http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001FmM
Just from personal experience, I'd say the *vast* majority of
replacements are already online. The SOP(?) market began to really
bottom early this year; by July, virtually *nothing* was available.
Price, Anderson, et al, *all* have massive numbers of consultants
"riding the bench". Best guess is the "peak" was somewhere between
Sept, 1998 and July, 1999.
Not to say there aren't still projects going. Just that the "peak" has
already occurred.
The surveys reflect when they will be "complete". Certainly, none I'm
aware of are holding remediated systems to be somehow implemented "in
mass". They may still have some to re-implement, but the ones already
done have been placed back into production. This is another problem
with using comparisons of software development projects, as Yourdon
does. While it *may* be that the percentages hold for being "complete",
even those *not* complete have large percentages of individual
applications complete, and re-implemented.
>
> Could you point me to some place that has these numbers? I must have
> really missed something here.
>
<snip>
>
> I'll have to see how the error rates over the past few months could
> come within an order (or two) of magnitude to those of the first few
> months of 2000.
>
> Help me out here -- where do your numbers come from?
>
Again, see above.
Hoffmeister
Dr John Stockton
Oct 1999 22:12:13 in news:comp.software.year-2000, allyson <ally@wooden-
house.demon.co.uk> wrote:
>In article <9Cr+N7dJoyifoH...@4ax.com>, Pat Meadows
><p...@meadows.pair.com> writes
>> Has anyone heard from DonJoe? It's been quite a while
>>since he posted. I'd write, but I don't have his e-mail
>>address.
>>
>> He used to post occasionally on another newsgroup I read,
>>but he hasn't been there recently either.
>>
>>Pat
>He posted today on sci.agriculture.poultry, I don't know him so I can't
>say if he sounded fine, but was making plans for the future...which is
>always a good sign (if we have a future that is)
One might suspect that he's chickened out.
--
© John Stockton, Surrey, UK. j...@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
<URL: http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL: ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ;
<URL: http://www.merlyn.demon.co.uk/clpb-faq.txt> Pedt Scragg: c.l.p.b. mFAQ.
Ralph Daugherty
> <snip>
> My point is there is nothing "mystical" or "magical" about Y2k bugs;
> they are, in fact, rather ordinary. The problem has never been *how* to
> fix them, but rather *finding* them all.
> Again, I'm *not* referring to "look-ahead" errors. That's not the
> point. Systems and users don't care whether failures are caused by
> invalid converted data, incorrect software installations, bad
> essentially unscathed from periods of comparable error rates previously,
> there is no reason to believe we won't at the rollover.
As you can imagine, I disagree entirely. The second the data starts
mangling about 99's and 00's the results are hardly ordinary. Whatever
software has not been advance date tested will encounter these results live,
and the program will come tumbling down at that point, not to run again until
the program is modified and with no legacy program to use in the meantime.
Comparing what's about to take place to multi-year phased in system
implementations while the legacy code is still operable is a joke.
Ralph
Hoffmeister
<snip>
>
> As you can imagine, I disagree entirely. The second the data starts
> mangling about 99's and 00's the results are hardly ordinary. Whatever
> software has not been advance date tested will encounter these results live,
> and the program will come tumbling down at that point, not to run again until
> the program is modified and with no legacy program to use in the meantime.
>
> Comparing what's about to take place to multi-year phased in system
> implementations while the legacy code is still operable is a joke.
>
> Ralph
I agree, it *is* a joke, but not in the way you imply.
A subset of the code is susceptible to invalid processing of dates.
During initial implementation, virtually *all* code is open for errors.
Y2k won't cause initial data conversion errors.
Y2k won't cause software to be installed incorrectly.
Y2k won't cause hardware incompatibilities.
Y2k won't cause communication parameters to be missing.
Y2k won't cause capacity problems not duplicated in testing.
As for "legacy code" being operable, I've yet to see a large-scale
implementation revert to the old system. Not saying it hasn't occurred,
just that this is usually a much more painful option than working
through the errors themselves. Once transactions start processing,
reverting back is in essence a reverse conversion, and one which
*doesn't* have the luxury of a few months of design and testing.
Hoffmeister
Charlie
>essentially unscathed from periods of comparable error rates previously,
>there is no reason to believe we won't at the rollover.
on a smaller scale, in reference to my company's efforts, it has been
interesting to note that the 'majority' of our Y2K related errors have been
contributed to by (a) 'fixing' things that should have been left alone in the
first place... and (b) errors encountered that were introduced by 'Y2K'
fixes...
we were fortunate to have a fully functional year 2000 lpar to roll into, and
equally fortunate to have a user community with a strange sense of humor...
Charlie Tabbut
http://www.discover.net/~ctabbut
Ralph Daugherty
>
> I agree, it *is* a joke, but not in the way you imply.
>
> A subset of the code is susceptible to invalid processing of dates.
>
> During initial implementation, virtually *all* code is open for errors.
>
> Y2k won't cause initial data conversion errors.
>
> Y2k won't cause software to be installed incorrectly.
>
> Y2k won't cause hardware incompatibilities.
>
> Y2k won't cause communication parameters to be missing.
>
> Y2k won't cause capacity problems not duplicated in testing.
>
> As for "legacy code" being operable, I've yet to see a large-scale
> implementation revert to the old system. Not saying it hasn't occurred,
> just that this is usually a much more painful option than working
> through the errors themselves. Once transactions start processing,
> reverting back is in essence a reverse conversion, and one which
> *doesn't* have the luxury of a few months of design and testing.
I agree that reverting to legacy code once the decision to go live is
difficult, but we have all seen the reports of new systems being pulled out
and the old systems being put back into production. That will no longer be an
option in a few weeks.
Ralph
Jacques Bernier
You cruisin' fer a spankin'?
JB
cory hamasaki
Dean T. Miller
Hoffmeister <hoff_m...@my-deja.com> wrote:
>"Normal" bug-finding procedures usually involve test systems. From what
>I've seen, testing with the date rolled forward does a fairly decent
>job.
This is one area where there's no data -- how many, or what
percentage, of organizations are testing with rolled-forward dates? I
had assumed that most everyone was, but Cory's reports from the
mainframe forums strongly imply that some (large) companies are just
now setting up time machines.
>I gave a link before. Over on EY's board:
>
>http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001FmM
Okay, I'll check it out.
>Just from personal experience, I'd say the *vast* majority of
>replacements are already online. The SOP(?) market began to really
>bottom early this year; by July, virtually *nothing* was available.
>Price, Anderson, et al, *all* have massive numbers of consultants
>"riding the bench". Best guess is the "peak" was somewhere between
>Sept, 1998 and July, 1999.
I've been aware that the ERPeople market has softened, and I'll agree
that probably means that the companies that have been implementing
replacements no longer need the specialists. But why they aren't
needed is another question. I've heard of some companies that stopped
conversions to SAP, et. al., because they wouldn't be completed in
time. These companies are going to struggle along with their current
systems over the century change.
>The surveys reflect when they will be "complete". Certainly, none I'm
>aware of are holding remediated systems to be somehow implemented "in
>mass". They may still have some to re-implement, but the ones already
>done have been placed back into production.
It depends on what method of remediation is used. If date expansion
is used, then usually everything has to be changed at once since date
expansion implies a database conversion. Windowing can be implemented
a program or subsystem at a time.
>This is another problem
>with using comparisons of software development projects, as Yourdon
>does. While it *may* be that the percentages hold for being "complete",
>even those *not* complete have large percentages of individual
>applications complete, and re-implemented.
One percentage does apparently hold. That's the 15% failure rate of
systems that have had routine maintenance changes.
Dean T. Miller
Hoffmeister <hoff_m...@my-deja.com> wrote:
>As for "legacy code" being operable, I've yet to see a large-scale
>implementation revert to the old system. Not saying it hasn't occurred,
>just that this is usually a much more painful option than working
>through the errors themselves. Once transactions start processing,
>reverting back is in essence a reverse conversion, and one which
>*doesn't* have the luxury of a few months of design and testing.
Isn't this exactly what the FAA has been doing? We hear about this
because it's both a gov't agency and extremely public. We don't know
about most of the times it happens.
allyson
<j...@merlyn.demon.co.uk> writes
>snip<
>One might suspect that he's chickened out.
>
still it might be considered better than being "up before the beak"
...then your chickens come home to roost:o)
Ally.
Remove dash to reply
Some horrible person has been forging my email address to post unpleasant
messages PLEASE NOTE...the real Ally does not post to unsavoury news groups or
send unpleasant email.
Demon have traced the ISP of the culprit, email has been sent to the relevant
abuse dept.
Don Scott
wrote:
>
>For those of you who are not IT professionals like Hoffy, Ralph, Andy,
>BOZO999's alter ego, etc. Big systems are never "cut over", balls to
>the wall. You're never in a fix or fail situation. You run the old
>system in parallel with the new for months, sometimes for years.
>Gradually, as your confidence in the new system increases, you turn off
>the old system.
>
>Typically, the parallel runs include defined milestones, test criteria.
>
This is illogical semantics in its worst form.
Big systems are indeed "cut over". All the time.
*If* you choose to run the old system after cut over, you are
typically doing it *only* as a fallback measure, very rarely as a
duplicate, redundant process.
Real-time systems, of course, are rarely "fall-back-able", so you may
run the old system for a few hours at most, with the (false?) hope
that, in an emergency, you would be able to cut back to the old system
and later recover the few hour gap of transactions.
Manual-process intensive systems, such as payroll, are sometimes run
in parallel, but once again, you lose that parallelism after one pay
period since no one is going to plan duplicate input of all the
payroll changes for an extended period of time.
Cory may be confusing parallel "testing" with cutover, but during the
test period, everyone understands that the old system is still the
master, still the priority.
Once cutover occurs, the new system inherits the master designation,
along with the priority.
After cutover, you *often* make the FOF vs. fallback decision. Every
good cutover plan has a detailed fallback plan, so its easy to
determine which is the easiest path to re-establishment of service -
spend an estimated n hours on FOF or spend a known x hours on
fallback.
This cutover progression is so common, and so obvious to me, I have to
wonder what Cory means by "big systems are never cut over" and talk of
*years* of parallel processing. Cutover of MVS operating systems are
a prime example of these principles. I think Cory may be having a
senior moment.
DS
The Goobers
[snippage]
> For those of you who are not IT professionals like Hoffy, Ralph, Andy,
> BOZO999's alter ego, etc. Big systems are never "cut over", balls to
> the wall. You're never in a fix or fail situation. You run the old
> system in parallel with the new for months, sometimes for years.
> Gradually, as your confidence in the new system increases, you turn off
> the old system.
>
> Typically, the parallel runs include defined milestones, test criteria.
>
> As the new system stabilizes and the output is validated, the old system
> is phased out.
Mr Hamasaki, all due respect but I have found this Respected Tradition
to be on the wane over the past decade and change; it was replaced with
a dual chorus of 'Costs too much!' and 'We can't afford to make
mistakes, we do it right the Very First Time!'.
A story: years ago I was working in Hartford, CT, with a Major
Insurance Company rewriting their long-term disability management system
for a new database (IMS to DB2). At one point early on I was called to
attend a meeting... this miserable, stinkwad, two-bit, gut-crawling
idiot who was so stupid he had to have his initials monogrammed on his
cuffs in case he forgot who he was announced that there would be *no*
period of parallel testing between the two systems. Folks got a bit...
upset and he squelched their complaints by announcing 'Nope, no way,
costs too much money, the old system costs US$500,000 per month to run
and we're just going to cut over.'
In the silence which almost always follows the Mentioning of a Large Sum
of Money (note: I believed then, as now, that this sum was completely
fictitious; very few IMS systems written fifteen years ago cost this
much to run) I said 'That's a sum of money, true... has anyone
calculated how much it will cost to fix things when six months after
cutover folks discover that they've been pumping out bad checks for the
past half-year?'
'That's a good question,' he intoned, '... I'll get back to you on
that.'
I was never asked to attend a meeting with him ever again and I retained
that particular gem for future use.
DD
Henry Ahlgrim
>
> cory hamasaki wrote:
>
> [snippage]
>
> > For those of you who are not IT professionals like Hoffy, Ralph, Andy,
> > BOZO999's alter ego, etc. Big systems are never "cut over", balls to
> > the wall. You're never in a fix or fail situation. You run the old
> > system in parallel with the new for months, sometimes for years.
> > Gradually, as your confidence in the new system increases, you turn off
> > the old system.
> >
> > Typically, the parallel runs include defined milestones, test criteria.
> >
> > As the new system stabilizes and the output is validated, the old system
> > is phased out.
>
> Mr Hamasaki, all due respect but I have found this Respected Tradition
> to be on the wane over the past decade and change; it was replaced with
> a dual chorus of 'Costs too much!' and 'We can't afford to make
> mistakes, we do it right the Very First Time!'.
>
> A story: years ago I was working in Hartford, CT, with a Major
> Insurance Company rewriting their long-term disability management system
> for a new database (IMS to DB2). At one point early on I was called to
> attend a meeting... this miserable, stinkwad, two-bit, gut-crawling
> idiot who was so stupid he had to have his initials monogrammed on his
> cuffs in case he forgot who he was announced that there would be *no*
> period of parallel testing between the two systems.
Over the years I have worked for/with so many clones of that guy that
your to-a-tee description left me ROTFLMAO.
--
White, wheat, or raisin
Henry Ahlgrim
****************************************************
A novel approach to Y2K --> http://www2.gol.com/users/doitnow/
****************************************************
Hoffmeister
>
> Noo-noo, Hoffy. You're not making any sense. Or maybe you are, maybe
> you're doing a reverse BOZO999.
>
> On Sun, 10 Oct 1999 19:13:21, Hoffmeister <hoff_m...@my-deja.com>
> wrote:
>
> > I agree, it *is* a joke, but not in the way you imply.
> >
> > A subset of the code is susceptible to invalid processing of dates.
> >
> > During initial implementation, virtually *all* code is open for errors.
>
> As much as I'm an anti-Microsoft programmer, Bill Gates had it right
> when he discussed software flaws in terms of aircraft. I don't recall
> his specific example but it was something to the effect that a bolt
> failing in the tail wouldn't cause the right engine to fall off. In
> software, it will.
>
> You're implying that the date flaws are in a *small* portion of the
> code, while the implementation of a SAP is a *big* chunk of possibly
> flawed code. How big is code? How much does it weigh? Can I slap a
> tape measure around it?
>
> It ain't true Hoffy.
What "ain't" true, Cory?
How much does it weigh? Beats me. I was using "function points" as
measurements.
http://www.spr.com/library/0funcmet.htm
And yes, a subset. Capers Jones estimates 15% of the function points
contain date references:
http://www.year2000.com/archive/proby2k.html
Howard Rubin estimates 3% of Lines of Code contain date references of
any kind.
http://www.hrubin.com/headline/more.html
So yes, we're talking of a subset of code. Or do you have better
numbers than Jones or Rubin?
>
> > Y2k won't cause initial data conversion errors.
> >
> > Y2k won't cause software to be installed incorrectly.
> >
> > Y2k won't cause hardware incompatibilities.
> >
> > Y2k won't cause communication parameters to be missing.
> >
> > Y2k won't cause capacity problems not duplicated in testing.
> >
> > As for "legacy code" being operable, I've yet to see a large-scale
> > implementation revert to the old system. Not saying it hasn't occurred,
> > just that this is usually a much more painful option than working
> > through the errors themselves. Once transactions start processing,
> > reverting back is in essence a reverse conversion, and one which
> > *doesn't* have the luxury of a few months of design and testing.
>
> Two words, Hoffy. Parallel Processing. Remember now?
>
> > Hoffmeister
>
> How about a big Oopsie for the crowd. Shout it out, guy.
>
> cory hamasaki http://www.kiyoinc.com/current.html
>
> For those of you who are not IT professionals like Hoffy, Ralph, Andy,
> BOZO999's alter ego, etc. Big systems are never "cut over", balls to
> the wall. You're never in a fix or fail situation. You run the old
> system in parallel with the new for months, sometimes for years.
> Gradually, as your confidence in the new system increases, you turn off
> the old system.
>
> Typically, the parallel runs include defined milestones, test criteria.
>
> As the new system stabilizes and the output is validated, the old system
> is phased out.
>
> Instead of a reverse conversion, parallel processing allows you to
> simply defer or push back the milestone. Oh lookie, something is
> screwed up in subsystem XYZ, keep running the old system until we
> figure out what's wrong. This accomplishes the same thing as a reverse
> conversion.
>
> Hoffy knew this but in his polly-esque rave, he forgot about that for a
> moment.
>
> in 82 days, this won't be an option. Then it really will be OOPSIE
> time.
>
> Everyone, please thank Hoffy for making the best Doomer case of the day.
>
BS, Cory. Maybe in the "old" days of batch processing, but not today.
"Parallel Processing" is a nice dream, bit it just don't happen. You
don't cutover to SAP, and expect the users to continue entering CICS or
IMS transactions on the legacy system.
Especially with interfaces, parallel processing opens up a whole 'nother
can of worms. Are they all shut down? Are we posting dual entries?
How much do you get out, Cory? While we *might* run parallel for a time
during "testing", once cutover to production happens, it's balls to the
wall. This ain't batch processing in bulk, Cory. This is online,
real-time, and it's hard enough to get the users to start entering in
SAP to begin with, much less have them doing dual entry. We aren't
talking theoretical models here, Cory. This is the *real* world.
Hoffmeister
The Goobers
[snippolinio]
> Over the years I have worked for/with so many clones of that guy that
> your to-a-tee description left me ROTFLMAO.
Pfoo... you'se jes' easily amused.
DD
Tom Beckner
Hoffmeister
>
<snip>
>
> Isn't this exactly what the FAA has been doing? We hear about this
> because it's both a gov't agency and extremely public. We don't know
> about most of the times it happens.
Wasn't aware the FAA was running "parallel". Do you have more info?
I was aware they were both modifying the existing system, as well as
rolling out a new one. This double coverage I've seen at more than one
client, but it doesn't mean they are running parallel after the new
system is implemented.
Hoffmeister
Hoffmeister
>
<snip>
>
> is used, then usually everything has to be changed at once since date
> expansion implies a database conversion. Windowing can be implemented
> a program or subsystem at a time.
>
It's not all or nothing. Even if App 'A' is reading App 'B' files, and
App 'B' uses expansion, usually only a small number of routines in App
'A' need to be modified.
The same holds true for more defined interfaces.
Hoffmeister
cory hamasaki
hoff_meister
Gee, don't know, Tom.
I *do* know GM is still producing the cars, Goodyear is still producing
the tires, and Mobil and a boatload of other oil companies are still
producing the motor oil and gas.
Now, I *wonder* what they all have in common?
Hoffmeister
Sent via Deja.com http://www.deja.com/
Before you buy.
Joe Lakey
>
> JRS: In article <IfBgmHAt4l$3E...@woodenhouse.demon.co.uk> of Fri, 8
> Oct 1999 22:12:13 in news:comp.software.year-2000, allyson <ally@wooden-
> house.demon.co.uk> wrote:
> >In article <9Cr+N7dJoyifoH...@4ax.com>, Pat Meadows
> ><p...@meadows.pair.com> writes
> >> Has anyone heard from DonJoe? It's been quite a while
> >>since he posted. I'd write, but I don't have his e-mail
> >>address.
> >>
> >> He used to post occasionally on another newsgroup I read,
> >>but he hasn't been there recently either.
> >>
> >>Pat
> >He posted today on sci.agriculture.poultry, I don't know him so I can't
> >say if he sounded fine, but was making plans for the future...which is
> >always a good sign (if we have a future that is)
>
Certainly would be nothing to crow about.
Joe Lakey
Dean T. Miller
kiy...@ibm.XOUT.net (cory hamasaki) wrote:
>For those of you who are not IT professionals like Hoffy, Ralph, Andy,
>BOZO999's alter ego, etc. Big systems are never "cut over", balls to
>the wall. You're never in a fix or fail situation. You run the old
>system in parallel with the new for months, sometimes for years.
>Gradually, as your confidence in the new system increases, you turn off
>the old system.
>
>Typically, the parallel runs include defined milestones, test criteria.
>
>As the new system stabilizes and the output is validated, the old system
>is phased out.
Is this really the case with "ERP solutions?" I've never been
involved with one, but I'll bet that running parallel doesn't work
well. You'd have to have bunches of format conversion programs to put
the data from the new system (or old system) into proper shape for
automated data comparisons. Validating isn't easy since most ERP
stuff means changes to the business model for most companies.
cory hamasaki
The Goobers
[snippage]
> It's like the recipe for a something
> you'd find on a grill at an Oktoberfest.
Lederhosen? A dirndl? Oh, I'm sorry... that's *grill*, not *girl*.
DD
Hoffmeister
>
> On Mon, 11 Oct 1999 13:51:59, Hoffmeister <hoff_m...@my-deja.com> wrote:
>
> > How much do you get out, Cory? While we *might* run parallel for a time
> > during "testing", once cutover to production happens, it's balls to the
> > wall. This ain't batch processing in bulk, Cory. This is online,
> > real-time, and it's hard enough to get the users to start entering in
> > SAP to begin with, much less have them doing dual entry. We aren't
> > talking theoretical models here, Cory. This is the *real* world.
>
> Not enough, it seems. My clients ran one online system for 3 years in
> parallel. Of course, if this monster failed, they would have been out
> of business. You would have seen them on the cover of Time, Newsweek,
> People, Business Week, and Hustler Magazines, "XYZ International Fails
> due to computer problems!"
Used to happen quite a bit, Cory. Just haven't seen it with the ERP
packages. I mean, not at all.
Tell us, since this is *obviously* such common practice, why didn't
World Bank just spit those checks out from their "parallel" system.
I'm sure it's just a matter of flicking a switch for Hershey to start
processing orders from their "parallel" system, as well.
Or how 'bout those colleges and their "Vaporware" solution/problems.
Cory, better *remind* them about those "parallel" systems; they sure are
missing the boat, not flipping that switch.
>
> How did these wizards of IT manage to do this while you claim that it is
> beyond mortal human ability and current technology? I'd like to say
> that when they retain consultants like me, miracles happen, we do the
> impossible, I'm amazing, they scatter rose petals before me and sound
> trumpets as I enter their HQ.
>
> Sadly, I mostly just hang around and watch as doofuses from other
> beltway bandits set up parallel feeds, transaction reformatters,
> bridges, infopumps, and data-diverters. Clueless, low-intensity
> geeks, Bell-heads, Lan-boyz, and such organize automated FTP sessions,
> set phase-in schedules, Sometimes, it's a few people in one department
> who are doing parallel testing, sometimes they print virtual reports
> and scan the totals for match/no matches. Techno-hint, Perl and Rexx
> are excellent for doing this scanning.
>
Sure, parallel "testing". Happens pretty regularly.
Running parallel in *production* is another story.
> Saaay, if such pin-heads can figure out how to run parallel, maybe one
> or two others have too. Maybe not all companies are in the same
> situation as Bang and Olufsen, Hershey Foods, Samsonite, etc.
>
Oops, you're right. Forgot Bang and Olufson.
> So it comes down to this, Hoffy the polly claims that it's common
> practice to go balls to the wall, slam that new system in place, and
> fix, fix on failure. He-men programmers not efete, timid, clueless
> light-weights like me. Testing? Parallel runs? IV&V? That's for
> wimps. Got a million lines of untested source? Slam it in, after all,
> didn't you get a clean compile?
>
Testing? Yes. Parallel runs in test? Yes. IV&V? Well, haven't
actually seen much of that, either.
C'mon, Cory. People aren't as clueless as you seem to think. Sliding
in that "million lines of untested source" is really pretty funny.
> In the other corner, I'll make a two line change, timidly move it to
> the Base-0 system, run a regression suite. No problems, we move it to
> Integration-Test, unleash real users. Gradually, carefully, promoting
> the source, testing the binary, checking for side effects. Prod-Test,
> Production.
>
Yep. It's called "testing", Cory. *Not* running "parallel" production
systems.
> And at any stage in the game, we're prepared to declare that the change
> has failed. Failed, back to square zero. We can't take an outage.
>
> Maybe the pollies are the bravehearts and we're the cowards.
>
Cory, you seem a might confused here. Jumping back and forth between
"testing" procedures and running "parallel" production systems.
'Course, don't blame you for trying to change the focus. Just try and
make it a little less obvious next time, OK?
Hoffmeister
cory hamasaki
phystad
>
> cory hamasaki wrote:
> >
> > Not enough, it seems. My clients ran one online system for 3 years in
> > parallel. Of course, if this monster failed, they would have been out
> > of business. You would have seen them on the cover of Time, Newsweek,
> > People, Business Week, and Hustler Magazines, "XYZ International Fails
> > due to computer problems!"
>
> Used to happen quite a bit, Cory. Just haven't seen it with the ERP
> packages. I mean, not at all.
>
Does Feb of 1997 qualify as 'the old days'? That was when an
international corp, with millions of dollars in federal contracts,
sent out duplicate paychecks/direct deposits to each and every one of
its 8,000+ employees -- one check/deposit from the old payroll system,
and one from the new one, running in parallel...
The duplicate paper checks were Fedexed to each site, and some site
managers had distributed them, before the alarm went out from HQ. The
direct deposits had been posted to employee accounts more than 30
hours before the corp transmitted requests to each bank to back out
half of the transactions (although my [former*] bank, and most others,
allowed the corp to back out the dupe deposits anyway, even though it
was clearly over the time limit).
*Yes, that is why it's my former bank.
--
Pam
Unofficial c.s.y2k smallish FAQ
http://www.computerpro.com/~phystad/csy2kfaq.html
phystad
>
> Dean T. Miller wrote:
> >
> <snip>
> >
Hoffmeister, I'm not sure why you snipped your own words that Dean
responded to; Dean didn't say anything at all about systems running in
parallel, and wasn't responding to anything you didn't say about
systems running in parallel, and if you hadn't snipped your chunk out
of Dean's post, your sleight of hand would have been blatantly obvious
to everyone. What Dean quoted from your post to respond to was:
Hoffmeister wrote...
>
>As for "legacy code" being operable, I've yet to see a large-scale
>implementation revert to the old system. Not saying it hasn't occurred,
>just that this is usually a much more painful option than working
>through the errors themselves. Once transactions start processing,
>reverting back is in essence a reverse conversion, and one which
>*doesn't* have the luxury of a few months of design and testing.
>
to which Dean responded...
>
>Isn't this exactly what the FAA has been doing? We hear about this
>because it's both a gov't agency and extremely public. We don't know
>about most of the times it happens.
>
Clearly, Dean is pointing out to you one very public occurrence of "a
large-scale implementation revert[ing] to the old system" (more than
once, in several locations). You said you'd never seen a large-scale
reversion, Dean reminded you of one; try to keep up, hoffy.
Hoffmeister
<snip>
>
> Does Feb of 1997 qualify as 'the old days'? That was when an
> international corp, with millions of dollars in federal contracts,
> sent out duplicate paychecks/direct deposits to each and every one of
> its 8,000+ employees -- one check/deposit from the old payroll system,
> and one from the new one, running in parallel...
>
> The duplicate paper checks were Fedexed to each site, and some site
> managers had distributed them, before the alarm went out from HQ. The
> direct deposits had been posted to employee accounts more than 30
> hours before the corp transmitted requests to each bank to back out
> half of the transactions (although my [former*] bank, and most others,
> allowed the corp to back out the dupe deposits anyway, even though it
> was clearly over the time limit).
>
> *Yes, that is why it's my former bank.
>
I've seen things like this happen, but from running parallel "testing".
You actually provide one of the main reasons parallel production systems
aren't run.
Anyway, the point is *not* that it *can't* be done, just that it *isn't*
done on any kind of regular basis. So whether it *can* be done or not
is immaterial, and saying that merely flipping a switch to some
"parallel" system is an option that goes away in "8x days" is ignoring
the fact that it *isn't* an option in most implementations today.
Hoffmeister
Hoffmeister
>
> On Mon, 11 Oct 1999 22:38:00, Hoffmeister <hoff_m...@my-deja.com> wrote:
>
> I say that it's a good idea to run parallel production. (I have clients
> who do this.) Hoffy argues but oddly seems to be going doomer.
>
Nope. Not arguing whether or not "it's a good idea". Have even stated
that "it is a good idea". The point, Cory, is whether or not "it is
currently done" to any sort of degree.
> > Used to happen quite a bit, Cory. Just haven't seen it with the ERP
> > packages. I mean, not at all.
> >
> > Tell us, since this is *obviously* such common practice, why didn't
> > World Bank just spit those checks out from their "parallel" system.
> >
> > I'm sure it's just a matter of flicking a switch for Hershey to start
> > processing orders from their "parallel" system, as well.
> >
> > Or how 'bout those colleges and their "Vaporware" solution/problems.
> > Cory, better *remind* them about those "parallel" systems; they sure are
> > missing the boat, not flipping that switch.
>
> I agree, some companies set themselves up to fail.
>
> > Sure, parallel "testing". Happens pretty regularly.
> >
> > Running parallel in *production* is another story.
>
> So they have no way out. And what? This is smart? I don't think so.
>
Again, whether or not "this is smart" is not the issue.
Credit for trying to change the discussion around yet again, though.
> > Testing? Yes. Parallel runs in test? Yes. IV&V? Well, haven't
> > actually seen much of that, either.
>
> Hmmmm, no IV&V.
>
Nope. Can honestly say I've not been on an implementation where any
outside firm performed any sort of code review or validation.
I've had internal audit departments review documentation, etc. But
then, that sort of thing doesn't seem to pass the "doomer" definition of
IV&V.
> >
> > C'mon, Cory. People aren't as clueless as you seem to think. Sliding
> > in that "million lines of untested source" is really pretty funny.
> >
> > Yep. It's called "testing", Cory. *Not* running "parallel" production
> > systems.
> >
> > Cory, you seem a might confused here. Jumping back and forth between
> > "testing" procedures and running "parallel" production systems.
> >
> > 'Course, don't blame you for trying to change the focus. Just try and
> > make it a little less obvious next time, OK?
>
> They build a parallel test environment, run, what, 2 or 3 representative
> transactions through and don't keep the system running? What are they
> afraid of? The cost? MIPS and DASD are cheap.
>
No. Typically, we run parallel interfaces, sometimes for up to a
month. One project ran them for six months.
We've also hired some temps on other projects to input transactions.
But these are usually a day or two behind the actual production. And
usually run for about a week.
That's OK for testing purposes, but we typically don't get the
corrections, etc. And we typically only parallel a subset of the
transactions.
Yep, mostly the cost. Not DASD and MIPS, though some projects are
looking to dump the maintenance cost of the legacy software ASAP.
Mostly personnel. Kinda tuff to tell management they just spent a
couple million on SAP, in most cases because costs will be reduced, then
tell them they have to double their staff for oh, 6 months or so.
> I was part of the team that made a *big* system go live on multiple
> 3084s and 3380 disks. A quarter billion dollars worth of hardware.
>
> This system now runs in the background on a 9672 G5. We haul much more
> data now but at no cost. The multi hundred thousand dollar 3380's (a
> big .6 gig) are slack bytes on 30 gig SCSI disks in a RAID box. Total
> cost of operation is so small that you can't calculate it.
>
> Get this. The new system has been rehosted once on new hardware and the
> old system is still running in parallel, just in case. This is a
> bet-the-business on it system.
>
> I suppose you don't believe that some firms run hot spares? Do you know
> about the disaster recovery business?
>
Yeah Cory, I know about disaster recovery. But most are NOT running
"hot spares". Most are paying for the availability of space at sites.
They ship off the tapes, and once a year get to run a drill off-site.
But those sites are seriously over-booked, and definitely *don't* have
the amount of equipment equal to customers, and definitely aren't
running "hot spares".
Remember the San Fran earthquake, Cory? Remember how those "hot-sites"
were so over-booked that they couldn't support all their clients? It's
sort of like the insurance biz; they aren't planning on a massive
disaster hitting a majority of their clients at the same time.
> I don't get it. You're arguing that it's normal to have extended (2
> hours to 2 weeks) outages, that real-time systems can't be run in
> parallel, that no one does IV&V.
>
> I'm not sure which side of the case you're arguing.
>
Reality, Cory. Reality.
Hoffmeister
Ralph Daugherty
>
> Dean T. Miller wrote:
> >
> <snip>
> >
Read in to be truncated for 2 digit processing, then windowed back out to
storage? Oh, only the input is expanded? Yeah, need to get rid of those
century numbers. They're such a pain.
Ralph
Hoffmeister
Sure beats holding App B up until App A gets completely remediated.
Happens both ways, as well. SAP for example will automatically window
dates through most interfaces *from* two-digit dates. As well, have
written many interfaces out of SAP that truncate the date, to maintain
compatibility with existing interfaces.
Hoffmeister
Ralph Daugherty
I agree, Hoff, often necessary during conversions and phased in
implementations.
Ralph
Alwyn Aubrey
davis...@my-deja.com wrote:
>
> Cory - if I remember my old high school class in vocational agriculture
> correctly, you looked up a recipe for preparing the pancreas of a cow!
> That's the real meaning of the English term sweetbread, if my memory is
> accurate 30 years back.
>
> This page is from Brown University - there are several sweet bread
> recipes on it. If you are looking for a sweet bread with a trace of
> ginger flavor, the one they call Portugese Sweet Bread is probably it.
> Come to think of it, PAN DUCE is Spanish, so it might be what you want.
>
sweet bread in Spanish would be pan dulcé.....¡Bring on the meñudo!
Na Kaula
In article <380126ec...@news.microtec.net>, jber...@microtec.net
(Jacques Bernier) wrote:
>Naughty, naughty Dr.John. Doin' a litlle OT for a change.
>
>You cruisin' fer a spankin'?
>
>JB
>
>On Sun, 10 Oct 1999 15:09:16 +0100, Dr John Stockton
><j...@merlyn.demon.co.uk> wrote:
>>
>>One might suspect that he's chickened out.
--
Y2K?
Y-not2K!
(Remove the underscore for e-mail)
cory hamasaki
davis...@my-deja.com
correctly, you looked up a recipe for preparing the pancreas of a cow!
That's the real meaning of the English term sweetbread, if my memory is
accurate 30 years back.
This page is from Brown University - there are several sweet bread
recipes on it. If you are looking for a sweet bread with a trace of
ginger flavor, the one they call Portugese Sweet Bread is probably it.
Come to think of it, PAN DUCE is Spanish, so it might be what you want.
http://www.brown.edu/Students/Brown_Hawaii_Club/Projects/Local_Kine_Reci
pes.txt
If not, try this
http://www.suresave.com/hawaiikitchen/hawaiikitchen.html
Hoffmeister
does.
Hoffmeister
> loaf of soft buttery bread. It's like the recipe for a something
> you'd find on a grill at an Oktoberfest.
>
> cory hamasaki http://www.kiyoinc.com/current.html
> 81 Days, 1,953 Hours.
>
Dean T. Miller
kiy...@ibm.XOUT.net (cory hamasaki) wrote:
>On Mon, 11 Oct 1999 21:23:03, dtmi...@midiowa.net (Dean T. Miller) wrote:
>
>> Is this really the case with "ERP solutions?" I've never been
>> involved with one, but I'll bet that running parallel doesn't work
>> well. You'd have to have bunches of format conversion programs to put
>> the data from the new system (or old system) into proper shape for
>> automated data comparisons. Validating isn't easy since most ERP
>> stuff means changes to the business model for most companies.
>
>???? Would you have bunches or are there only a few points? For
>payroll, you have the database which has to be converted anyway and the
>time and attendance records. You might not want to refresh the new
>database from the old but having the code to do it once means you can
>run the Info-Pump again if you have to.
Certainly it can be done. And should be done! But probably isn't
being done with most conversions.
>How do you validate the system? How do you know that everyone's
>information was captured and is correctly processed? You can compare
>the results between the two systems, you have to ignore the new
>functionality but can validate on the data that flows through both.
Yup. And you run parallel until you're fairly confident that a really
high percentage of exceptions have been put through the ringer. I
know the drill. But is it being done by most organizations? I doubt
it.
>What happens if you have to pull the plug on the new system and don't
>maintain the old?
Same problem after 1/1/00.
>Other than clean 0Cx abends (and user programmed halts), large systems
>are a bear to debug.
So are small systems. I'm certainly not putting down mainframes, but
the system complexity of small and medium businesses, especially using
non-COTS software, is close to that of organizations using mainframes.
The processing volumes aren't of the same magnitude, but the range of
processing is. Which means the debugging can be just as hard.
>As for a full BIZ-process re-engineering, I'm not sure. I did a custom
>job in the mid 1980's but this was a new system that replaced paper
>procedures. The fall back was paper.
It's becoming more apparent that businesses are running new production
systems without any fallback (and without adequate testing). But,
that's to be expected, given the late start most of them had to solve
their Y2k problems.
phystad
>
> Nope. Can honestly say I've not been on an implementation where any
> outside firm performed any sort of code review or validation.
>
> I've had internal audit departments review documentation, etc. But
> then, that sort of thing doesn't seem to pass the "doomer" definition of
> IV&V.
>
Hoffy, maybe you missed all the discussion about what IV&V means, who
dreamed it up, and how long it's been around? "Doomers" didn't invent
IV&V, and "doomers" haven't redefined IV&V -- although some of us,
optimists and pessimists alike, are sticklers for correct usage of the
phrase.
The words 'validation' and 'verification' can be hard to pin down, and
it seems many organizations have chosen to redefine the stringent
processes specified by the DOD/NASA originators of IV&V. The word
'independent' is harder to get around though, isn't it?
Or maybe your definition of IV&V is "internal vagueness and vapor"?
rhol...@wco.com
g.k. cooper <g.k.c...@news.net> wrote:
> On Fri, 08 Oct 1999 19:06:16 GMT, rhol...@wco.com wrote:
>
> >>Got any more 12-hour gold tips? I wanna bet against your info...
>
> What do you think it's going to do?
>
> coop
Linger.
D. Scott Secor - Millennial Infarction Mitigator
news:hkaul-ya02408000...@news.lava.net...
> He's got an actual sense of humor!? I'm in shock.
Actually, Dr. John can be quite funny at times (sometimes unintentionally).
I recall that he even maintains a humor page amongst his other niceties.
Just don't piss him off. He carries a HUGE grudge ... you think that he'd
be tired by now <rimshot>.
Ciao,
--
D. Scott Secor, Year 2000 Institute & Board of Inquiry, Mpls., MN USA
The Pollyannas in rest of the world may be toast ... but here in MN
they'll be Lefsa! Ya shuuure, you betcha! ... http://y2k.board.org/
Hoffmeister
>
<snip>
Sorry, Pammie, I tend to <snip> to reduce space. Assume people can
follow a thread.
You're correct, though, and I apologize to Dean in not addressing the
actual point he raised. Haven't been on c.s.y2k as much, and getting
used to following multiple threads again. Been caught up in the
"parallel" system discussion.
But I'll still ask for info on what new system implementations have been
"backed out" at the FAA after going live. Not saying it hasn't
happened; not saying it *doesn't* happen. Just want to know what you're
referring to.
I'm aware of the ARTS 6.05(??) upgrade that was backed out, but that
appears to be more of a release upgrade than a new implementation.
Hoffmeister
Dr John Stockton
1999 12:25:01 in news:comp.software.year-2000, D. Scott Secor -
Millennial Infarction Mitigator <y...@uswest.net.NO$PAM> wrote:
>Na Kaula <hkaul@_lava.net> wrote in message
>news:hkaul-ya02408000...@news.lava.net...
>> He's got an actual sense of humor!? I'm in shock.
>
>Actually, Dr. John can be quite funny at times (sometimes unintentionally).
>I recall that he even maintains a humor page amongst his other niceties.
>
>Just don't piss him off. He carries a HUGE grudge ... you think that he'd
>be tired by now <rimshot>.
A convincing public apology, not cross-posted, in each of the relevant
public forums that you have to my knowledge abused, including, IIRC, the
newsgroup to which you fairly recently posted HTML and one or more GIFs,
will put it into the public semblance of abeyance - provided that you
consistently maintain in News the reasonable brevity that you have
recently shown yourself capable of.
Otherwise you must continue to bear the consequences of your actions.
--
© John Stockton, Surrey, UK. j...@merlyn.demon.co.uk Turnpike v4.00 MIME ©
Web <URL:ftp://garbo.uwasa.fi/pc/link/tsfaqn.zip> - Timo Salmi's Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> L about usage of News.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Ralph Daugherty
>
> D. Scott Secor -
> >
> >Actually, Dr. John can be quite funny at times (sometimes unintentionally).
>
> A convincing public apology, not cross-posted, in each of the relevant
> public forums that you have to my knowledge abused, including, IIRC, the
> newsgroup to which you fairly recently posted HTML and one or more GIFs,
> will put it into the public semblance of abeyance - provided that you
> consistently maintain in News the reasonable brevity that you have
> recently shown yourself capable of.
>
> Otherwise you must continue to bear the consequences of your actions.
I would call this a good example, Scott.
Ralph
phystad
>
> Sorry, Pammie, I tend to <snip> to reduce space. Assume people can
> follow a thread.
>
> You're correct, though, and I apologize to Dean in not addressing the
> actual point he raised. Haven't been on c.s.y2k as much, and getting
> used to following multiple threads again. Been caught up in the
> "parallel" system discussion.
>
Does that mean other people shouldn't "assume [you] can follow a
thread"?
>
> But I'll still ask for info on what new system implementations have been
> "backed out" at the FAA after going live. Not saying it hasn't
> happened; not saying it *doesn't* happen. Just want to know what you're
> referring to.
>
I sure hope that you really do want a factual response this time, and
won't accuse me of overwhelming you with a too-voluminous response
(again) -- I'll try to keep my citations succinct.
I'm puzzled by your sudden insertion of a distinction between "new
system implementations" and "upgrades". When did you decide we were
talking only about totally new systems?
I will only include references for which I have a URL, and pertinent
snippets of quotation from each article, in the interests of brevity.
Some of the sites may require (free) registration.
====================
http://chicagotribune.com/version1/article/0,1575,SAV-9810290173,00.html
COMPUTERS WORRY AIR CONTROLLERS
NEW RADAR PUTS JETLINERS IN JEOPARDY, UNION SAYS
By Jon Hilkevitch Tribune Transportation Writer
October 29, 1998
Part of the FAA's reason for shifting over the summer to the new
technology, which is also being used in Denver, Dallas and New York
City, is that efforts are being made to make it compatible with the
Year 2000 (Y2K) computer fix that the FAA is working on. The system it
replaced two months ago is not immune from the Y2K bug, officials
said.
The technology, called the Automated Radar Terminal System III-E
Version 6.05, provides the identity, air speed and other vital data
about aircraft in a controller's assigned sector. But Kurt Granger,
the controllers association's president in Elgin, said, "We are
experiencing numerous instances of the computer completely dropping
critical flight information . . . and the FAA has decided to gamble."
===========
http://www.star-telegram.com/news/doc/1047/1:NE21/1:NE21110298.html
Updated: Monday, Nov. 2, 1998 at 22:29 CST
Radar system at D/FW flawed, controllers say
By G. Chambers Williams III Star-Telegram Staff Writer
D/FW AIRPORT -- A high- tech radar operating system installed Sept. 19
at Dallas/Fort Worth Airport has so many problems that air traffic
controllers say they are having trouble keeping track of planes over
the Metroplex, the controllers union said yesterday.
D/FW's Tracon is one of five nationwide that have the radar system.
The others are in Southern California, New York, Chicago and Denver.
In the six weeks since the system began operation at D/FW, controllers
have logged more than 200 incidents involving about a half-dozen
recurring problems.
Similar problems have been reported at the other radar approach
facilities where the system is operating, the union said. But the FAA
says that safety has not been compromised.
D/FW controllers didn't expect to test an unfinished system on live
traffic in the nation's third-busiest air traffic area, where the
radar facility handles 4,200 flights a day, Keller said.
"Shall we sit around and gamble for two months while they fix it? We'd
rather not. We know the older system is reliable. We used it for two
years, and we'd like to go back to it until the new one is ready."
=================
http://www.idg.net/new_docids/new_docid_9-80028.html
11/12/98 06:04 PM
Glitch pulls plug on air traffic radar
By Kathleen Ohlson
In addition to Los Angeles, the failure affected airports in San
Diego, Burbank, Ontario, Costa Mesa, and Long Beach, in Southern
California, said Kevin Van Uden, NATCA facility representative.
The FAA has also added the software to systems at other major
airports, including Dallas/Fort Worth and Chicago. Those airports are
both going back to an older version of the application, said Scott
Keller, national representative, Arts3E for NATCA.
================
http://www.gcn.com/archives/gcn/1998/november23/3.htm
GCN November 23, 1998
FAA pulls tracking app from two radar centers
By Frank Tiboni GCN Staff
At radar centers serving major airports in Chicago and Dallas, FAA in
recent weeks reverted to an old version of the Automated Radar
Terminal System -- one that is not 2000-ready.
Complaints from air traffic controllers at Chicago’s O’Hare
International Airport led FAA early this month to pull the plug on the
latest ARTS version there. Last week, air traffic controllers at the
Dallas-Fort Worth International Airport also stopped using the
upgrade, Version 6.05, because of problems related to keyboard
commands, FAA officials said.
================
http://chicagotribune.com/version1/article/0,1575,ART-28177,00.html
Bugs force FAA to put older radar system back
Agency vows remedy before Y2K deadline
By Jon Hilkevitch Tribune Transportation Writer
May 07, 1999
The malfunctioning air-traffic radar system that was taken out of
service this week after causing serious delays at Chicago's two major
airports will be repaired by June 30, the Federal Aviation
Administration said Thursday.
Restoration of the balky system is important beyond its advanced
technology: It's the only software used to direct local air traffic
that is Y2K compliant. The system has failed repeatedly since last
summer -- and has been removed entirely twice -- so officials are
eager to reinstall it with plenty of time to spare before New Year's
Day in case more glitches occur.
An older radar system that was re-activated Thursday as a temporary
backup is not Y2K certified, meaning hardware and software using
date-dependent information could shut down computers or generate
inaccurate data on Jan. 1.
====================================
A number of articles from the Chicago Tribune and the New York Times
are no longer freely available; if you'd like to pay for them, search
the ChiTrib or NYTimes archives for the first two weeks of May 1999,
for 'radar' and 'failure'.
An article on Y2knewswire contains direct quotes from these and other
articles,
http://www.y2knewswire.com/19990607.htm
I assume you don't consider Y2knewswire a credible source, and perhaps
are wary of the Chicago Tribune, Dallas Star-Telegram, IDG News,
and/or the NY Times, but I hope you find Government Computer News to
be a valid news source for information about a government agency's
computer woes.
If anyone has seen reputable (I specifically exclude PR puff pieces
from FAA or their contractors) reports that any Y2k-compliant air
control/radar system has been SUCCESSFULLY implemented, I'd appreciate
a URL.
D. Scott Secor - Millennial Infarction Mitigator
news:3803B8CB...@ee.net...
I plead the Fifth ... I refuse to answer on the grounds that it may
incinerate me. ;-)
Ciao,
--
D. Scott Secor, Year 2000 Institute & Board of Inquiry, Mpls., MN USA
Home of the Daily Hemorrhoid Examiner -- hundreds of news links
plus 450 popular comic links -- URL: http://y2k.board.org/g_news.html
Na Kaula
Millennial Infarction Mitigator" <y...@uswest.net.NO$PAM> wrote:
>I plead the Fifth ... I refuse to answer on the grounds that it may
>incinerate me. ;-)
Were you a bad boy, Scott? Shame on you!
Go spank yourself! <g>
hoff_meister
phystad <phy...@computerpro.com> wrote:
> Hoffmeister wrote:
> >
> > Sorry, Pammie, I tend to <snip> to reduce space. Assume people can
> > follow a thread.
> >
> > You're correct, though, and I apologize to Dean in not addressing
the
> > actual point he raised. Haven't been on c.s.y2k as much, and
getting
> > used to following multiple threads again. Been caught up in the
> > "parallel" system discussion.
> >
>
> Does that mean other people shouldn't "assume [you] can follow a
> thread"?
>
"assume" whatever you want. I apologized to Dean for not addressing his
point; you can obviously do as you please.
> >
> > But I'll still ask for info on what new system implementations have
been
> > "backed out" at the FAA after going live. Not saying it hasn't
> > happened; not saying it *doesn't* happen. Just want to know what
you're
> > referring to.
> >
>
> I sure hope that you really do want a factual response this time, and
> won't accuse me of overwhelming you with a too-voluminous response
> (again) -- I'll try to keep my citations succinct.
>
> I'm puzzled by your sudden insertion of a distinction between "new
> system implementations" and "upgrades". When did you decide we were
> talking only about totally new systems?
>
> I will only include references for which I have a URL, and pertinent
> snippets of quotation from each article, in the interests of brevity.
> Some of the sites may require (free) registration.
>
<snip>
(Note: I snipped the articles Pam posted. Anyone wanting to review can
see her post)
Again, I said I was aware of the ARTS upgrade. I believe all the
articles were referring to this.
The whole discussion has revolved around the implementation of "new"
systems, Pam.
Not saying reverting to a previous version of the same system is
necessarily an *easy* task, just that it is usually *far* easier than
converting to a completely new system, then converting back.
I'll "assume" I don't need to detail the differences for you. If I'm
mistaken, I'm sure you'll let me know.
> ====================================
>
> A number of articles from the Chicago Tribune and the New York Times
> are no longer freely available; if you'd like to pay for them, search
> the ChiTrib or NYTimes archives for the first two weeks of May 1999,
> for 'radar' and 'failure'.
>
> An article on Y2knewswire contains direct quotes from these and other
> articles,
>
> http://www.y2knewswire.com/19990607.htm
>
> I assume you don't consider Y2knewswire a credible source, and perhaps
> are wary of the Chicago Tribune, Dallas Star-Telegram, IDG News,
> and/or the NY Times, but I hope you find Government Computer News to
> be a valid news source for information about a government agency's
> computer woes.
>
You're right, I don't consider Mikey Adams' "experiment" to be a
"credible source". I do not and have not disputed the ARTS upgrade
problems that occurred; I already acknowledged them.
> If anyone has seen reputable (I specifically exclude PR puff pieces
> from FAA or their contractors) reports that any Y2k-compliant air
> control/radar system has been SUCCESSFULLY implemented, I'd appreciate
> a URL.
>
Don't know, Pammie. Does the GAO count?
Hoffmeister
Dean T. Miller
Thanks for providing the references. It would have taken me hours to
hunt them down.
phystad <phy...@computerpro.com> wrote:
>I will only include references for which I have a URL, and pertinent
>snippets of quotation from each article, in the interests of brevity.
>Some of the sites may require (free) registration.
>
>http://www.idg.net/new_docids/new_docid_9-80028.html
>
>11/12/98 06:04 PM
>Glitch pulls plug on air traffic radar
>By Kathleen Ohlson
I'm not sure why anyone would think that IDG wasn't a good (polly)
source. They publish many industry magazines, and pretty much follow
the 'party line.'
davis...@my-deja.com
Alwyn Aubrey <alwyn...@earthlink.net> wrote:
>
>
> davis...@my-deja.com wrote:
> >
> > Cory - if I remember my old high school class in vocational
agriculture
> > correctly, you looked up a recipe for preparing the pancreas of a
cow!
> > That's the real meaning of the English term sweetbread, if my
memory is
> > accurate 30 years back.
> >
> > This page is from Brown University - there are several sweet bread
> > recipes on it. If you are looking for a sweet bread with a trace of
> > ginger flavor, the one they call Portugese Sweet Bread is probably
it.
> > Come to think of it, PAN DUCE is Spanish, so it might be what you
want.
> >
>
>
>
Ha - you're right. Mea culpa. Either duce is Portugese, a language
about which I know zip, or the Hawaiians eventually dropped the 'L'.
But I am pretty sure that is the bread recipe he is looking for. Even
if it isn't, Portugese Sweet Bread is pretty good. My recipe doesn't
call for ginger, but otherwise is much the same. Maybe the ginger
makes it Hawaiian? Mine goes nice with some butter, right out of the
bread machine.
My Spanish is rusty as an old saw.