Subject:	Re: We've been HAD!
Date:	1999/10/11
Author:	cory hamasaki <kiyoinc@ibm.XOUT.net>
	Posting History

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

-- a (a@a.a), October 11, 1999

Answers

What planet does Cory live on? Parallel implies cost. Not too many have parallel processing capabilities. Now, Cory, go put that tin foil hat back on.

-- the (aliens@among.us), October 11, 1999.

the (aliens@among.us),

Looks like you're the alien here. What planet do you come from?

Cory hit the nail square and center, at least from my almost 32 years in the business point of view. I'm in the middle of doing exactly what he describes, right here, right now. Cost is not a factor. Keeping production up and running is the only option.

Tick.. Tock... <:00=

-- Sysman (y2kboard@yahoo.com), October 11, 1999.

aliens,

What planet do you live on? Parallel implementations have to do with keeping an existing system online as pieces of a new system are brought online. When the new code has proved itself to function correctly the old code is phased out. For a time they operate in 'parallel', hence the phrase.

And Cory is right, in some 80 days if it ain't fixed and functioning correctly, they are SOL. They DO NOT have the option of falling back to old, non-compliant versions of the software to keep their business operations running. That's why 01/01/2000 is an immovable deadline.

-TECH32-

-- TECH32 (TECH32@NOMAIL.COM), October 11, 1999.

Aliens

I'm a UNIX guy so this isn't my area of expetise, but when working closely with host-heads they seem to speak of doing things like dividing their system up in to regions. They said they had a test region and a production region. So they had one big honking main frame but several regions on it. No need to purchase a second super expensive main frame to run in parrallel. Can any host-heads confirm or deny?

Watch six and keep your...

-- eyes_open (best@wishes.net), October 11, 1999.

Pay me now, or pay me later, but now ain't an option.

dave

-- dave (wootendave@hotmail.com), October 11, 1999.

aliens -

Ever deploy any major info systems (say, 500+ users)? If you used a "big bang", "do-or-die" cutover, and you lived to tell the tale, you were very fortunate indeed. Planning to slam a new system into place with no fallback is just plain lousy project management.

-- Mac (sneak@lurk.hid), October 11, 1999.

Now everybody just calm down! Mr. Koski...,ah, Hoff will be here any minute to dispell these nasty rumors.

-- a (a@a.a), October 11, 1999.

So Dr Altman is wrong, Y2K is tested end-to-end. What more could you want than parallel processing and its done all the time! MAC are you saying that businesses practice sound PM! Great news for Y2K!

-- thanks (for proving@polly.logic), October 11, 1999.

Sorry, 'a', I'm dealing with Cory over on c.s.y2k. Don't have time to deal with his mimic, as well.

Anybody who really wants to can follow the thread here:

http://x42.deja.com/=gh/[ST_rn= md]/viewthread.xp?thitnum=18&mhitnum=0&toffset=0&CONTEXT=939681472.790 822912&frpage=threadmsg_md.xp&back=comp.software.year-2000&new=0&rok=1

-- Hoffmeister (hoff_meister@my-deja.com), October 11, 1999.

Aliens - what a joke! You have no idea what you're talking about.

I've participated in to mainframe replacements. Both were critical, and both were DOD.

Specifically, in 1982-1983, we replaced an ancient IBM with a newer UNIVAC 90/60. We ran both for 18 months before starting to remove the IBM. This is typical operating procedure.

Think of it like road construction. You can't stop all traffic on the highways, so you block off lanes; go to single lanes; reroute, stripe the emergency lanes, build temporary overpasses, ALL KINDS of stuff.

In the meantime, traffic goes through. Frequently a little slower, but it goes through. Half of the effort to the construction is building and demolishing all the temporary structures.

The temporary structures during a mainframe replacement include parallel breakouts with each circuit separately patched out. All external circuits then have one or more patch bays that require wiring and patching. (Patching in my case was with 1/4" phono plug patchcords)

As you test each circuit, you patch it differently, or remove the patch (depending on how you wired them). Eventually, you get all of them done, and you can then (carefully!!!) remove all the wiring from the old system. Bear in mind, that these are in the same physical location as the new stuff, so if you drop a screwdriver - you may interrupt services.

This is all mind-numbingly tedious work. It requires crawling around behind vast patch bays with hundreds of thousands or even millions of discrete wiring connections.

You simply can't switch everything over and know if they'll work. You have to do it in stages. And the last stage - physical removal of the old wiring - can still screw things up.

Now do this all over the world, all at the same time.

Jolly

-- Jollyprez (jolly@prez.com), October 11, 1999.

Jolly et. al:

The discussion of this over on csy2k is long, multifaceted and very fascinating. Highly recommended. Basically, it seems that batch systems often ran in parallel, but for realtime systems as are much more common today, this is no longer feasible.

Jolly and Cory don't seem to realize that in most big companies, it's not 1982 any more...

-- Flint (flintc@mindspring.com), October 11, 1999.

FYI, what many seem to be referring to here are "phased" implementations. These are not the same as running parallel production systems, though Cory is trying to slide his original comments towards that and parallel testing.

Nobody disputes that parallel testing is done, and is indeed desireable. For that matter, running parallel production is desireable. But the logistics and cost make it extremely difficult when converting to systems like SAP, and it isn't even close to being SOP.

-- Hoffmeister (hoff_meister@my-deja.com), October 11, 1999.

You're both full of it. What you say is irrelevant to the issue. Wake the hell up and smell the coffee.

http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story /10-11-1999/0001040671&EDATE=

Infoliant Corporation on Y2K: We Are Moving in the Wrong Direction; Highest-Ever Percentage of `Negative' Changes Recorded

PITTSBURGH, Oct. 11 /PRNewswire/ -- As a striking follow up to the huge spike in Y2K compliance status changes recorded in August, Infoliant Corporation announced today that two-thirds (66%) of the status changes tracked by the Year 2000 Network Advisor(TM) knowledgebase in September were "negative."

There guys. Spin that.

-- a (a@a.a), October 11, 1999.

Flintie: "Jolly and Cory don't seem to realize that in most big companies, it's not 1982 any more..."

Well, I was thinking about a CICS system I worked on in the 1980's. The replacement system, a multi-million dollar Unix server (a 12 engine box), has been running parallel for 3 years.

We seem to be able to do it. I didn't realize that we were doing the impossible. I thought everyone hedged their bets, that everyone kept the old system going until they were 100+% sure that the new system was correct, reliable, maintainable, etc.

Too bad that the rules change in 81 days. By the way, the old system will be shut down on December 31, 1999.

We'll see. Good luck to everyone. I hope the pollies enjoy the next 50 days.

Oopsie, Nightly Business Report is talking about Y2K right now. They're estimating a $15-35 B-b-b-billion dollar insurance payout. Talking about litigation, damages, etc. Oh well.

-- cory (kiyoinc@ibm.XOUT.net), October 11, 1999.

For those who haven't been following the csy2k discussion:

Nobody has ever said it was impossible (as Cory falsely implies), they've said it's too expensive to maintain two systems and to get people to enter all the data twice, but differently.

It appears that in most organizations it isn't *being* done, even though it's possible. Cory has a knack for letting us generalize from single cases. At least this case doesn't seem to be a rumor.

-- Flint (flintc@mindspring.com), October 11, 1999.

Flintlock:

Two things, first, YES IT IS 1982 still in many mainframe shops. That's part of the whole problem with Y2K. 18 months ago I checked with friends still in the Navy, and that system I helped install in 1982 is STILL there, and STILL running on the same computer.

Second, over 80% of this system WAS NOT RUNNING IN BATCH MODE! These were circuits on the Navy's AUTODIN system. AUTODIN was (and apparently still is) the primary e-mail system for the US Navy. Also, many many "live" communications circuits were routed through that computer.

Among other (non-classified) systems that ran through the computer in real time included SSIX (submarine data comm.) CUDIX (Surface ship comm), CTF (Command task Force - various messages routed to fleets & ships including bogey tracking, submarine detection, etc. etc.)

So to say that it's not relevant to Y2K is laughable. Flint, Hoff, you guys *really* should do a little research before you start pulling wool.

Jolly

-- Jollyprez (jolly@prez.com), October 11, 1999.

Jolly,

Whoa, a blast from the past reading your description of patching out a system. Reliving that gave me shivers.

Back to the main topic here, waaaay back when, when I was working on mainframes, we had dual processors, and could run tasks, even op systems, in parallel, until we had proof that shutting the old down and taking the new wouldn't put us in limbo. Remember, we had a vested interest, as our paychecks were cut on this thing. Somehow I fail to believe that things have regressed to the point that this can't be done any more. I mean that was twenty-five years ago!

And as to the point about it not being 1982 anymore, as near as I can tell, virtually every line of code I have written with the exception of my Intro to Computing course is still in use, still in its original form, except for the stuff that got ported, and most of that was simply a 'translation' function. (This was what got me worried about this to begin with. We always figured that the stuff we were writing back then would be LONG gone before 2000 rolled around!)

-- just another (another@engineer.com), October 12, 1999.

Cory,

You optimist.

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

Wrong. Just because it is sound business practice to run in parallel, doesn't mean everyone does it that way. I know one PM who came close to screwing up Desert Shield by doing a hot cutover of a new system that didn't work right.

Hot cutovers are going on all over the world for Y2K. Going to be their own source of failures.

-- ng (cantprovideemail@none.com), October 12, 1999.