The worst failures of y2k according to Cory's Charlotte's web (one of the most shocking articles I've read, that makes the things that Gary North writes about look like child's play to what Hamasaki has written.) The worse y2k failures will be from all the system changes and repairs that the programmers have made to the computers, embeds, software code in order to squash y2k out of the system may in fact have made the problem worse in the long run.

The larger the system, the higher and longer the failure residue rate, the higher probability that there will be a failure or one sort or another. This isn't good news for many banks who are running now without having completed a full year of testing. I don't like what Cory Hamasaki had written, but there's a lot of hard truth to the technical problems he has written about y2k.

-- Brent Nichols (b-nichol@ihug.co.nz), January 05, 2000

Answers

Question: Who is Cory Hamasaki? Also, where can I find the Charlotte Web article? Thanks much =)

-- Dee (T1Colt556@aol.com), January 05, 2000.

Yes. We know. We've heard. Again. And again. And again.

I was kind of hoping that we would lose all the pointless repetition and speculation and repetition after rollover, and just get failure reports.

Ah well.

-- Servant (public_service@yahoo.com), January 05, 2000.

"Charlotte's Web" is really infomagic's first installment of his "SET RECOVERY ON" series - posted on Hamasaki's website. I have reposted the Complete infomagic earlier in this forum. Scroll down or search for SET RECOVERY ON and you can read ALL about "Charlotte's web"

-- Why Me (Doom@gloom.com), January 05, 2000.

Well, first, it wasn't CORY who wrote it but InfoMagic.

Somewhere down the list is a complete reprise of Info's writing. I'll hang a link in a bit, or you can go to

http://www.kiyoinc.com/current.html

(cut n paste I AM lazy) and look through Oh, what 101 103 or 104 to see them. they are listed in his TOC's for each issue so you can find them as INFOMAGIC.

Chuck

-- Chuck, a night driver (rienzoo@en.com), January 05, 2000.

Servant, we can HOPE but it appears that there is an influx of people who haven't been folowing things who have stumbled into our little corner of CyberSpace (or the SWAMP as others will have it but I alwasy considered that that was the tent Hawkeye and BJ used on MASH so it's actually a compliment).

NAH

-- nah (not@new.person), January 05, 2000.

Link

Look at #100 - #103 - #107 (Infomagic)

-- Teague Harper (tharper@cyberhighway.net), January 05, 2000.

I don't think I wish to read anymore about Charlotte's web, the whole thing is depressing beyond belief. It's message is simply death by 1,000 cuts. It shows the ripple global effect, the futile efforts of the programmers being outnumbered by failing computers, the disturbing thing is, y2k makes this charlotte's web scenario very possible. Now time will tell if we have a charlotte's web case on our hands or just a bump in the road.

-- Brent Nichols (b-nichol@ihug.co.nz), January 05, 2000.

I worked my company's Y2K readiness team for over two years. Because I'm a systems person, I was involved in testing all our apps. and systems (network included). Systems we have are on IBM mainframes as well as Unix servers. Clients have PCs or MACs they use to connect to our network with and from there to wherever their app. happens to reside.

The Y2K related problems we corrected did NOT involve making lots of changes to lots of code. The bugs were few and the code to fix them was small. (Of course we re-tested after the corrections.)

We prepared our operating systems and other products on our systems (like language compilers) by obtaining vendor supplied patches. Patches were not as large as others we've applied for other problems. Tested patches very thoroughly.

I do not know anyone who had to supply miles of code to fix this problem. It was not a big deal to fix.

If there are any Y2K-related problems still lurking they will be fixed and will not cause death by papercuts. I am making this statement after having worked on the problem and not just based on what I feel or believe with no facts.

-- Chris Josephson (chrisj62954@aol.com), January 05, 2000.

Thanks for the info folks...I read over some of the info at the web site. One more question...I still can't find where it says who Cory Hamasaki is. Is he a software engineer? I am trying to establish his credibility. Please excuse my ignorance, I don't know much about software and programming.

-- Dee (T1Colt556@aol.com), January 05, 2000.

Chris, you are looking at the problem from your own viewpoint. That is, the programs you dealt with were not date intensive, or you would have had to make major changes.

Ask Citibank whether they spent all that money on coding or on parties for their programmers.

Some entities won't be bothered at all, some will have major problems. One of the big contentions on this forums has always been that those who are seeing major problems see the world through their own eyes, as do those who never had date related processing in their systems. Sort of like two blind men describing an elephant from different vantage points.

-- (4@5.6), January 05, 2000.

Dee, You can check out www.russkelly.com/expert.html and scan down to Cory Hamasaki's name. It gives his credentials.

-- Marsha (MSykes@court.co.macon.il.us), January 05, 2000.

Marsha--Thank you for the link. Looks like Cory's credentials are impressive. This will help me in trying to understand the posts. Have a good day! =)

-- Dee (T1Colt556@aol.com), January 05, 2000.

Responding to:

Chris, you are looking at the problem from your own viewpoint. That is, the programs you dealt with were not date intensive, or you would have had to make major changes. Ask Citibank whether they spent all that money on coding or on parties for their programmers.

Some entities won't be bothered at all, some will have major problems. One of the big contentions on this forums has always been that those who are seeing major problems see the world through their own eyes, as do those who never had date related processing in their systems. Sort of like two blind men describing an elephant from different vantage points. =====================================================================- ----------------------------------------------------------+++--------- -

We DID test date intensive systems. We tested ALL our systems: payroll,payables,receivable,pensions,personnel, etc..

These are very date intensive. Our payroll and personnel systems are extremely date intensive. For example: data for our hourly people is entered electronically and all resumes received by our company is stored and manipulated electronically.

Granted we do not have the volume of a Citibank, but extrapolating from what we uncovered is not that difficult.

I never implied that money was spent on parties. Neither did I imply there was never a problem. There WAS a problem to resolve. It just was not the HUGE problem it was made out to be. We spent 2 years working on this problem. We did not waste our company's time or money. I doubt very much if any other Y2K teams did either.

-- Chris Josephson (chrisj62954@aol.com), January 05, 2000.

I first began my y2k obsession in 4/98 with Scary Gary's site, rendering me an instant doomer (8+). Then, on hearing of Hamasaki, I later moderated my view (5-8) to accomadate his opinions borne from a resume of impressive depth as well as width.

He was somewhat of a doomer (7 on the 1-10 scale) but was hedging in his predictions, like I was until Dec. 30-31. His writing was fun as well as informative, and he has an easy sense of humor which helped me cope with the idea of TEOTWAWKI. Also he had some interesting guest writers. Cool. He made no bones about the fact that he only knew what he was talking about in lieu of the large, cantankerous "enterprise systems" that run the payrolls and accounts of mega-corporations. While he could claim "expert" status in other areas, he did not choose to, and made it equally clear that most of his opinions were not to be taken too seriously. See the disclaimer on his weather reports.

I have little inkling what to think now that the fit hasn't collided with the shan. Not only that, I can't even get the faintest whiff of any. It seems that the current problems we see now can be readily explained as nothing but "background noise." Yeah, maybe some of them are actually "Y2k problems" but they are obviously of limited, isolated impact.

My biggest fear was that the ability to fix y2k problems would be hindered by already-ongoing y2k problems--thus initiating the first spins of the devolutionary spiral that would gradually suck the world into darkness. It ain't happening. If I weren't such a friggin addict on this forum, I'd have "gone home" by now.

SO WHAT IS YOUR POINT!!?? Well my point is that I'm actually very curious about those "large enterprise systems that run the corporate world." Did they fail? Are backups in place? Why aren't we seeing any (known) impact there? Is this yet another 11th hour miracle? Seems to be.. hmmm...makes me wonder...but I doubt I'll ever hear the whole story, as is the case with just about everything of importance...

-- coprolitlh (coprolith@rocketship.com), January 05, 2000.

Coprolith,

I'm with you. I figured it would probably be a 3-7, but was totally unprepared for a 0.03! How is it that all the developing countries that were "so far behind" and spent so little, and were using all that old pirated software on old used equipment, sailed through this thing with the same results as the US, UK, and Austrailia (These countries spent lots of time and money).

Are the big enterprise systems really running smoothly now? Would we know it if they weren't?

-- Berry Picker (BerryPicking@yahoo.com), January 05, 2000.

To Corprolith and Berry:

I can't explain how other shops did it, but we have a large enterprise system on IBM 'big iron' and this is what we did to get our systems ready for Y2K:

Starting about 2 years ago we (the systems group) listed all the products that run on our system. Everything from the operating system itself (which is really a big program) to home-grown utilities we had written for our users.

Every product was assigned to a team member whose responsibility it was to ensure it was Y2K compliant according to the vendor. In order to achieve compliance, some products needed patches/fixes, while other products needed a new version installed. We did this gradually. We tested the upgrades and patches as we went. Our home grown utilities were examined and tested for problems as well.

While we were working on getting our systems ready, the programmers were doing the same with their programs. Our network and PC/MAC support people were doing the same thing in their areas. There were also teams formed to find out about phones, lights, heat, etc.. in our area. It was a large team of people, but we all worked on areas we knew very well.

Our company gave top priority to becoming Y2K ready so we had the resources we needed. It was a project, just like many others with specifications, status reports, etc... all the electronic paperwork that accompanies projects these days.

Our target date for being Y2K ready was mid-1999. We performed many clock forward tests during the project as each piece was updated to be sure the updates worked. I worked on the systems assiting the programmers as they tested their updates and was surprised (as were the programmers) how minor the problems were that we encountered. We did not have to modify as much code as I thought we would. We tested several dates in 2000, not just 1/1/2000.

During the Y2K rollover weekend our systems were left up. Each department had to designate a person to have their applications tested by midnight Saturday (New Year's day). We had staff onsite in anticipation of making last minute corrections. Our CEO wanted everything working by Monday. It was. By breaking down the large enterprise systems into easily managed parts we were able to ensure that everything was ready. I imagine other shops did the same. The enterprise systems are not really that complex when you break them down.

We employed a similar strategy for departmental systems that run on Unix servers.

-- Chris Josephson (chrisj62954@aol.com), January 06, 2000.