I'll start off by saying, that I'm a private pilot that uses GPS for navigation. I don't know anything about shipping, but I presume that the systems on the ships are similar to systems on planes..

GPS is used for navigation! Not collision avoidance. Yes, there are systems under development for aircraft (and shipping?) that compute trajectories using GPS positions, but these are NOT IN WIDESPREAD USE. In other words, it's the pilots responsibility to avoid collisions.

Once again, another Y2K predictor date has come and gone with no observable effect. I've prepared myself and my family, but I don't believe in 'voodoo' superstition. There is nothing about equipment compliance that cannot be tested in a lab.

Yes, there are Y2K failures, and YES, finance companies, banks, etc are spending lots of money. Software ALWAYS fails.. I've been fixing systems for 14 years.. Software is written by humans that make mistakes. I make money by fixing software. I've seen much more severe system bugs than what can be caused by date rollovers.

I have been reading Y2K stuff for a year. I see no basis in the belief in 'cascade failures' caused by Y2K. When I look around at stores like my local COSTCO, I see shelves stocked to the ceiling with Y2K goods that have jacked up prices. COSTCO has a financial incentive to keep stocked up so they can charge us the max. Banks and networks have financial incentives to stay up, etc..

There are several alternatives to the car I drive, to where I buy my food, etc.. Where I live there are several water suppliers, food suppliers, etc..

I don't want to be inflammatory, but look at this analytically. Where is the threat?

I guess I'm like Mulder, 'I want to believe'.. But I can't jump on a bandwagon about some bug. There should be better statistics on actual Y2K failures, specifically what chips have problems, etc.. I don't see it.

-- Bryce (bryce@seanet.com), August 24, 1999

Answers

Bryce, not sure if you saw this story today but it's interesting...cruise ship and cargo ship bump overseas...cruise ship was built in 1992.

Anyway...you need to do some more research...and look a whole lot harder if you've been at it for "a year". Especially if you can't understand the difference between the GPS and Y2k glitches.

By the way, Y2k glitches have been happening for years.

Mike

==============================================================

-- Michael Taylor (mtdesign3@aol.com), August 24, 1999.

Bryce, you said: Once again, another Y2K predictor date has come and gone with no observable effect.

GPS has nothing to do with Y2K. People predicted scattered failures in older receivers, and that's pretty much what happened.

If you really ARE a private pilot, they tend to do a lot of studying. Do some more...

-- Dennis (djolson@pressenter.com), August 24, 1999.

Michael,

Ships have been bumping into each other since the middle ages. Like I said, legally, it's the pilots responsibility to avoid collisions.

The GPS rollover has been bundled in with Y2K on this board, but I'll conceed that it's different.

As I've written in other posts, my company has tested about 2000 of our PCs and we have and IBM mainframe that has been running in the Year 2000 for months. I don't see a failure.. Shouldn't we be able to observe problems with our routers, Front End Processors or mainframes when we roll the dates forward?

Why isn't there a press statement like the stuff that came out about the Pentium when they had a floating point problem? Could it be that there is NO specific chip that ANYONE can name for independent validation?

Like I said, embedded problems should be easy to observe and independently validate.

-- Bryce (bryce@seanet.com), August 24, 1999.

Bryce: None of your company's computers or systems have been running in the year 2000; not a single one, and not a single one will do this for another four months and a few days. Setting the clocks ahead may have its uses but it's just not the same as actually being in 2000. I wouldn't count too many digital chickens if I were you.

-- cody varian (cody@y2ksurvive.com), August 24, 1999.

my company has tested about 2000 of our PCs and we have an IBM mainframe that has been running in the Year 2000 for months.

Hey Bryce, you have an IBM mainframe that has been running in the year 2000 for months? How long did it take to make compliant? And why is it using the year 2000 right now? Is this a test computer, or is it performing realtime office functions?

Thanks, Owl

-- owl (new@new.com), August 24, 1999.

Bryce,

.....and I guess I am like my Uncle Vito who says; the longer I live, the more I realize just how STUPID people really are !!!

-- 2 la8 4u (thin the herd@NOW.com), August 24, 1999.

Hi Owl, Cody,

The mainframe is only running test functions. Mainly the newer VM/ESA OS and our own test tools. We write emulation, gateway and middleware products for IBM environments. I'm an NT systems programmer (not a mainframe guy), but I connect with the products we write and I can run complex test programs that we use to excercise our terminal emulators and middleware.

I suppose that the equipment is not really running in the year 2000, all we can do is try to simulate it the best that we can..

I realize that many problems will come at the applications level.. look ahead dates, financial computations.. stuff that should have been coded with 4 digit dates, etc..

I honestly don't believe that flaky application code can cause TEOTWAWKI. I believe that a widespread embedded software problem could cause it though..

For instance if all of a series 704XX chip was Y2K prone, and this series of chip was used in everything.. Then, yes, I can see a potential for widespread failure.. I just don't see anyone naming a family of chips or describing software problems that are 'scalable' (I mean that could be extrapolated to all systems).

I mean, ANY team of electrical engineers could choose to pick on a particular chip family, show a Y2K failure, publicize it, and become famous.. So why hasn't this happened.

-- Bryce (Bryce@seanet.com), August 24, 1999.

Bryce,

First, this statement of yours is not quite accurate:

Once again, another Y2K predictor date has come and gone with no observable effect.

Few people predicted major problems due to the GPS rollover. Also, the rollover was not the same glitch as the "99" and "00" problem we know as Y2K, and, there have been observable effects. You can find these effects on the following thread, especially towards the end of it:

http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001HTg

"***Submit any GPS failures***"

Here's a snip from one of the articles on that thread:

[snip]

Starting at 9 a.m. Sunday, the glitch caused some receivers to work slowly, point to wrong locations or not switch on at all.

An article in today's Asahi newspaper warned that the car navigator problem was a precursor to what could happen next year, when a glitch is expected to cause old computer systems that can't understand the year 2000 to malfunction.

Pioneer made 270,000 of the 340,000 old-style navigation systems sold in Japan. Pioneer realized the problem in 1996 and began a campaign in 1998 to get the word out so that repairs could be made in advance. Those who brought in their systems ahead of time totaled 150,000.

On Sunday, 770 repairs were completed. But thousands more are expected.

[snip]

You mentioned embedded systems. Here are some links you might want to check out:

Embedded systems fault casebook http://www.iee.org.uk/2000risk/Casebook/eg_index.htm#TopOfPage

Allen-Bradley http://domino.automation.rockwell.com/webstuff/y2k.nsf

Texas Instruments http://www.ti.com/corp/docs/year2000/dspsds.htm

Motorola http://mot-sps.com/y2k/realtimeclocks.html

A good, basic article about embeddeds:

http://www.jsonline.com/bym/tech/0214chips.asp

"Problems lurk in more than just computers"

I don't know whether Y2K next year will be a bump in the road, cause significant disruptions, or perhaps be even worse. I do know it isn't 2000 yet, and that a majority of problems are predicted by the GartnerGroup to happen after this coming December.

Most of the people who prepared for the recent Texas hurricane may not have ended up having to use their hurricane preps, but I don't think anyone would call them irresponsible for making those preparations.

-- Linkmeister (link@librarian.edu), August 24, 1999.

FOLLOWING SNIPS TAKEN FROM A WHITE PAPER BY
Paula D. Gordon, Ph.D.
Director of Special Projects

http://www.gwu.edu/~y2k/keypeople/gordon/embedded.html

A CALL TO ACTION :

NATIONAL AND GLOBAL IMPLICATIONS OF THE
YEAR 2000 AND EMBEDDED SYSTEMS CRISIS
A Working White Paper

Part 2: The Embedded Systems Crisis: Immediate Actions Needed
by Paula D. Gordon, Ph.D.
Revised February 25, 1999

(also posted in the archives at http://www.year2000.com

and

http://www.itpolicy.gsa.gov/mks/yr2000/y2kconf/papers/paper64.htm)

(snip)

The Embedded Systems Crisis

It is estimated that there may be from 10 to 25 billion embedded systems in existence. It is known that some small percentage of these are date sensitive. Of these a small, but significant percentage are not Year 2000 compliant. Estimates range from 0.2% to over 1%. That would mean that from 20 million to 250 million embedded systems failures could occur owing to the Year 2000-related non-compliance problems. (Source: The Gartner Group).

These include small failures that can have major impacts. Malfunctions could occur in all manner of equipment, devices, appliances, and systems found in homes, hospitals, buildings, plants, facilities, and systems. Malfunctions could occur as well in everything from rail and subway systems to water purification plants, wastewater disposal plants, oil and gas pipelines, oil refineries, oil tankers, off shore oil platforms, chemical plants,manufacturing plants, coal-fired plants, nuclear power plants, nuclear and other hazardous waste facilities and laboratories, biological and chemical warfare storage facilities, and weapons systems of all kinds.

There is simply not sufficient time and manpower to identify, assess, repair, replace, or "work around" all of the date sensitive embedded systems prior to January 1, 2000. (Indeed, some malfunctions could be triggered well in advance of that date.) Efforts are destined to be far less than 100% successful in making necessary repairs or taking other preventive or mitigative actions. In many cases, shut downs will be the only viable alternative.

The failures that are bound to occur may be expected to have an impact on the health and safety of nearby populations, on social cohesion and civility, on food and water supplies, on the economy, on foreign relations, and on the sustainability of the environment. Such impacts could affect small areas, as well as large regions all over the world. Commonsense dictates that greatly expanded efforts be made by the public and private sectors, nationally and globally, to identify, prioritize, and minimize the risks posed by those date sensitive embedded systems posing the greatest threats.

Current efforts to address Year 2000 computer software and hardware problems and embedded systems problems are grossly inadequate nationally and globally. In addition, efforts to address these problems tend to be based on a limited awareness and understanding of the nature and scope of the crisis. The problems are being poorly and unrealistically defined. Even the efforts to address the problems as presently understood are falling far short of the mark.

(/snip)

Identical chips may act differently in different systems. (snip) In cases where a replacement chip is required, it may not be possible to identify the vendor or the vendor may be out of business. It may not be feasible to manufacture a replacement chip.

Malfunction of an embedded system may trigger other failures and the source of those failures may not necessarily be detectable. (/snip)

Dr Gordon's homepage at http://www.gwu.edu/~y2k/keypeople/gordon/

Executive Summary

Table Of Contents

White Paper: Part 1

White Paper: Part 2

White Paper: Part 3

White Paper: Part 4 (NEW)

White Paper: Part 5

References and Resources

-- flb (fben4077@yahoo.com), August 24, 1999.

"There is nothing about equipment compliance that cannot be tested in a lab. "

I'm sorry folks, but I'm going to have to violently debunk this myth. You cannot test a system in isolation from it's environment, and expect the results to be a perfect analogy of how the system will respond in the real world. Sure, you can get a pretty good idea, but if lab testing was so good, woth decent quality control you could guarantee equipment/systems for a lot longer than the present periods.

I have worked with oilfeield test instrumentation, ultrasomic test equipment et al and belive me, the kit gets a better test in the field than on the test bench. You can heat it, freeze it, bury it, boil it and bake it, but the chap in the filed will ALWAYS without exception manage to break it in ways the original designer/QC engineer/tester will have never dreamt of.

This may only cover 1-5% of tested systems, but 1-5% of mission critical systems is a lot of system.

Get real. Bench testing, regression testing is on an accurate indication of what will happen - not total proof.

-- Rob Somerville (merville@globalnet.co.uk), August 24, 1999.

Bryce, 148.34N 15.46W,My costco garmin gps bit it. 6 hours later my cook dropped the sextant. Plan on making landfall somewhere between Siberia and New Zealand---Are pilots having the same problems?I'm out of here ,the batteries are getting low and the cooks fallen overboard.Sure glad I won't be flying with you new years.

-- Cappy Bligh (cruiser@mid pacific.com), August 24, 1999.

Bryce;

Please remeber y2k failures have only happened to look ahead systems or people tinkering with their systems trying to get them ready for rollover. Come New Years Evil, they will all have to deal with the year 2000 in REAL TIME, online!

-- FLAME AWAY (BLehman202@aol.com), August 25, 1999.

Errrrrr.,,, remember

-- FLAME AWAY (BLehman202@aol.com), August 25, 1999.

Bryce,

You don't see it because it is not there.

the IEE list is nothing more than a bunch of examples of software problems, the semiconductor manufacturer lists is lists of RTC's (which work just fine-it's the bios that need fixing) and as for Paula Gordon, she has absolutly no clue as to what she is talking about!

As for the group of "embedded experts" running around running their mouths, they do nothing but prove that they are not (experts). None of them can do bolean algebra, much less know what it is.

-- Cherri (sams@brigadoon.com), August 25, 1999.

Cherri,

You're saying you agree with Bryce that there's no info about what embeddeds specifically have problems? Again...

Texas Instruments: http://mot-sps.com/y2k/realtimeclocks.html

For example, at the TI site, notice the ones marked "NOT Year 2000 Ready".

-- Linkmeister (link@librarian.edu), August 25, 1999.

Typo. The TI link again is:

http://www.ti.com/corp/docs/year2000/dspsds.htm

-- Linkmeister (link@librarian.edu), August 25, 1999.

Thanks Linkmeister, The strftime() call TI mentions is not commonly used IMO.. I've NEVER used it. I guess that there could be some programmers that use it, but probably a small percentage.

I'm still reading your links.. It's good to see hard information from vendors.

Bryce

-- Bryce (Bryce@seanet.com), August 25, 1999.