Conference evms::y2k

    ------------------------------
    
    Date: Tue, 21 Jan 1997 12:15:14 EST
    From: [email protected] (Jim Rees)
    Subject: Apollo date bug coming soon
    
    Year 2000 is coming earlier for users of Apollo workstations.  At 14:59
    GMT
    on November 2, 1997, the high bit of the Domain/OS system clock will
    become
    set, and system bugs will prevent machines running unpatched software
    from
    booting.  HP has released a fix, but it only runs on newer equipment,
    and
    has a bug of its own.  Users of Apollo machines built before the dn3000
    will
    simply be out of luck.
    
    Details are available at <http://pisa.citi.umich.edu/date-bug>.
    
    ------------------------------
    

I think that we owe a lot of respect to the engineers of this swiss 
company. 
IWC was actually founded by a Bostonian in 1868, so all you New 
Englander may be proud as well.
Personally, I'm italian, but I own two of their watches, so I can
be a little proud too... (not the "Da Vinci", though, too expensive...)

Anyway, very clear and interesting explanation of the rule about leap 
years!

-----------------------------------------------------------------

From I.W.C.( International Watch Company of Schaffhausen ) Web page
at: http://www.w-o-s.com/iwc.html

-----------------------------------------------------------------

The automatic Da Vinci Chronograph from IWC with perpetual calendar and
moon phase display on its tenth birthday. A watch with over 500 years ahead
of it.We hate to admit it, but it's true: there simple isn't the time to
celebrate the special anniversaries of every single model manufactured by
IWC. On the other hand, in view of its enormous significance in the history
of watchmaking the idea of ignoring the Da Vinci's tenth birthday was quite
unthinkable. After all, when it first appeared at the Basel Exhibition in
1985, this was the watch that stood all of our ideas about what constituted
a modern watch on their head. This little watch - the world's first
automatic chronograph to feature a perpetual calendar, year display and
perpetual moon phase display- also marked the beginning of something that
few considered possible in this computerized age of ours: the Renaissance
of the complicated, mechanical watch movement.
So how could a wristwatch like the Da Vinci take on the less complicated
and infinitely more numerous models produced by the competition? The answer
is quite simple: many of the ideas embodied by the Da Vinci- much like
those of its ingenious predecessor and namesake, Leonardo- look much
further into the future than into the past. Over 500 years, to be precise.
And that is something at which we intend to take a more detailed look in
the next few minutes.


The Da Vinci's perpetual calendar. From IWC. One of the masterpieces of the
century.

Perhaps it seems presumptuous to use terms like "Masterpiece" and "century"
in connection with an invention that is only ten years old. But as you
discover more about its development- and its direct consequences - you
realize you have almost no other choice. Because the Da Vinci's calendar
and movement have links to more that a single century: they are a
distillation of the centuries that lie behind us. And stretch into the
seconds, minutes, hours, days, months, years, decades and centuries that
lie ahead. The train of thought that takes us so far into the future goes
back all the way to Da Vinci himself. Many of the revolutionary mechanical
principles he developed have retained their significance in watchmaking
down to this day. And they are principles on which we base our own work,
helping us to surmount imagined barriers and make the apparently
complicated simple enough for everyday use.

Take Kurt Klaus, for example, head of development with IWC. In the late
seventies, he was so obsessed by the idea of a wristwatch with a mechanical
calendar ( including a moon phase display ), programmed to remain accurate
for over half a millennium, that he spent virtually all his working and
leisure time hammering away at the problem until he hit upon an ingeniously
simple solution. The answer was a perpetual calendar that would require no
adjustment for a much longer period than any other before it and, unlike
its predecessors, actually deserve the name "perpetual". But of course, if
the days, weeks, months, years and phases of the moon shown by the movement
were to be those laid down by the Gregorian calendar, Klaus's invention was
also going to have a master the vagaries of that selfsame calendar.

According to Pope Gregory XIII's calendar, the solar- or "tropical" - year
lasts exactly 365 days, five hours, 48 minutes and 46 seconds or 365.242192
days. We compensate for the slightly less than quarter of a day extra by
adding the 29th of February every leap year. By doing so, we are of course
overcompensating by a few decimal places, and so the 29th of February is
omitted every 100 years. This, in turn, slight undercompensates, and so the
leap year is left untouched every 400 years. And because this, too, amounts
to a very slight overcompensation, the 29th February is omitted every 4000
years.

The task of a perpetual calendar, then, is to make allowance for the
differing lengths of the months, the years and the centuries. Just like the
one in the Da Vinci, which comes astonishingly close to solving the problem
once and for all, and even recognizes all the leap years. Until the year
2100, that is. Because that year, according to the Gregorian calendar,
there will be no 29th February, and so your watchmaker will have to make a
tiny adjustment on the 1st of March, if at all possible. This is why you
can allow your Da Vinci simply to follow the course of time and rely on it
without worrying about adjustments or following complicated instructions
for use. Every single one of its functions can be advanced via the crown.
Your Da Vinci measures the exact time in seconds, minutes and hours, all by
pure mechanics. And has a stop watch function, accurate to one-eighth of a
second, which also counts the minutes and hours. Its also has an automatic-
and purely mechanical - lunar display to show you the current phase of the
moon. And displays for the date, day of the week and month, again all
mechanical and all automatic. It knows automatically whether there are 28,
29, 30 or 31 days in the month. And, for the first time in watchmaking
history, has a fully automated, mechanical, four-digit year display. It
will go on displaying all this information accurately until the year 2499.

In a sense, it's a great pity that during this time you will probably never
have the same view of the working of the calendar than you do here. Take
the train between the anchor drive cog and the century display, for
example, which has a reduction ratio of 1:6315840000: this is the first
time such mechanism has ever been featured in a wristwatch, and every 100
years it causes the century slide to advance by 1.2 millimeters. During the
time that elapses between two such movements, the balance completes no
fewer than 25,245,000,000 beats.

All things considered, is there really a better way of describing it than
as one of the "Masterpieces of the century".
---------------------------------------------------------------------------

YEAR 2000 INSURANCE
Marsh & McLennan Inc. is offering businesses a hedge against Year 2000
problems.  The New York insurance broker will sell up to $200 million worth
of insurance against business losses caused by the policyholder's own
computer system, or by another company's neglect to become Year
2000-compliant, or by data supplied by another company's computers.  Before
the policy is issued, however, Marsh & McLennan will enlist experts to make
sure that the policy-buyer is taking all possible steps to avoid Year 2000
problems.  (Information Week 3 Feb 97)

From:	http://www.unisys.com/marketplace/year2000/faq/faqsand.htm
                   ^^^^^^


******************
Digital Equipment Corporation had a similar problem with the DECsystem-10 in
1975 because of field overflow. DEC's advisory late in 1974 had this to say
(quoted in First Data Corporation, Newsletter 20, December, 1974):

"When the software for the PDP-6 was being designed in 1964, a 12-bit date
format was established. In order to maintain compatibility with old programs,
that format was retained in successive monitor releases. Unfortunately, the
12-bit format cannot represent any date after January 4, 1975. Therefore, a
DATE75 project was initiated in order to convert DEC-supplied software to a new
15-bit format that properly represents dates well into the next century.
Support for 15-bit dates was designed to minimize conversion problems. Programs
coded in a simple, straight-forward fashion will work properly with 15-bit
dates without any modification.

"Our experience in actually converting our existing software has been
considerably more difficult than we ever anticipated. We keep finding new
DATE75 problems. As a result, we have been forced to release a large amount of
software on the November distribution tape; and customers will not have as much
time as we would wish to install it all. Naturally, we recommend installing all
of this software well before January 5, 1975. If this is not done, many DATE75
problems will be encountered. Keep in mind that DATE75 problems are essentially
cosmetic. It is a nuisance to have files with incorrect creation and access
dates, but it is not a catastrophe."

But, "When a file gets an erroneous date because of a DATE75 problem, it may
not be saved and restored in the intended fashion by FAILSAFE [the backup
daemon]. This is a serious problem since it can result in files appearing lost."

And, "We regret very much the lateness of the delivery of this software. We
simply did not anticipate all the problems we would encounter. Customers should
take advantage of the lesson we learned so painfully by immediately upgrading
their DEC software to the versions released on the November tape, and by
starting conversion of their own software... Our experience indicates that it
is not sufficient for a programmer to simply 'think through' a program's
structure and functions to determine whether it has a DATE75 problem. It is not
sufficient merely to give the program a quick test with a monitor set to a date
after January 4, 1975. It is necessary to run the total system for several
hours in order to find all the subtle DATE75 problems."

"Please keep in mind that DATE75 fixes have proven incredibly error prone. You
must use great care and very thorough testing in order to be confident that
DATE75 problems have been fixed... Most of the problems we found were in cases
where we believed our programs followed these [omitted] procedures. Do not
believe yours do!"

 -- Dave Rybarczyk 

   Originally from:

	Risks-Forum Digest  Monday 31 March 1997  Volume 18 : Issue 96
>
> FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
> (comp.risks) ACM Committee on Computers and Public Policy, Peter G. 
> Neumann, moderator
>
> ------------------------------
>
> Date: Thu, 27 Mar 1997 11:10:33 -0700
> From: "Jack K. Horner 120775" <[email protected]>
> Subject: Re: Risks Associated with the Year 2000 Problem
>
> [This is message sent to Rick Light <[email protected]> in response
> to a forwarding of a comment on the appended message from the 
> U.S. House Science Committee, particularly relating to those Y2K
> problems resulting from the omission of the "19" in the calendar
> year.  It is reproduced with the permission of the author.  PGN]
>
> The problem is potentially much messier than just the occurrences of the
> literal value "19" in date types.  ANYTHING in software that merely
> _acts as if_ the first two digits of the date are "19" will have
> insidious effects.
>
> About a year ago, I worked on an analysis of the Global Positioning
> System (GPS) ground station code to try to characterize the Y2K problem.
> We found no less than ten types of manifestations of the problem in a
> survey of a randomly selected sample of 10% of the code. The occurrence
> of the literal value "19" was only one of these ten types.  Other types
> included  type overflow problems at various dates throughout 1999, Y2K
> arithmetic that implicitly assumed no dates later than 31 Dec 99 were
> possible, and implicit module-interface date-type conversions. These
> problems are potentially infinite in their variety, and not all can be
> detected with tools.  Furthermore, in GPS it is not possible to
> construct good test cases to see what will happen at the millennium
> start, because the future (time-) states of the system depend on
> physical values (orbital elements, pole wander, Jovian gravitational
> force) that can be determined with sufficient accuracy only from the
> actual operation of the system within about three months of the time of
> interest.   Approximately 1% of the total GPS code is affected by this
> class of problems, or affected it.
>
> The GPS user-equipment code is in even deeper trouble because of the Y2K
> problem, and the breakage will occur well before Jan 1, 2000.  Date, in
> the GPS signal standard, uses exactly thirteen bits (these bits represent 
> a time-unit offset from a conventional epoch date).  This allocation is
> burned into proms on all existing GPS user equipment.  On about August
> 20, 1999, the actual date value will overflow this 13-bit type, and the
> equipment will fail to produce correct time or position information.
> Best estimate is that there are ~10^6 pieces of user equipment that will
> be immediately affected. Everybody who depends indirectly on those
> pieces of equipment (meaning all the rest of us) will also be affected.
> The GPS standards committee is desperately trying to figure out what to
> do with the problem.
>
> Various well-calibrated software estimation models (SLAM, REVIC,
> PRICE-S) predict that fixing the Y2K problem in systems of about 500,000
> lines of code or larger will take more time than is available between
> now and the year 2000, regardless of how many programmers are thrown at
> the job.  Most of the US's military command-and-control systems contain
> more than 500,000 lines of code.
>
> GPS is now the primary means of distributing time standards throughout
> the US, and throughout much of the world.  (The accuracy of the atomic
> clocks on board the GPS satellites is second only to those maintained by
> the primary standards clocks in Washington.)  Thousands of large
> financial computers ultimately take their time calibration from GPS,
> every day.  Interest on overnight multi-billion-dollar short-term 
> electronic-funds transactions is computed at millisecond granularity,
> derived from the GPS standard.
>
> Place your bets.
>
> Jack Horner, CIC-8
>
>>Notice From:
>>United States House of Representatives
>>Committee on Science
>>F. James Sensenbrenner, Jr., Chairman
>>George E. Brown, Jr., California, Ranking Democrat
>
>>CONSUMER RISKS ASSOCIATED WITH YEAR 2000 PROBLEM CITED
>>
>>Washington, DC -- Rep. Constance A. Morella, chair of the Committee on
>>Science's Subcommittee on Technology, along with several of her
>>colleagues sent a letter today to the Clinton Administration requesting
>>information on the Year 2000 problem.
>>
>>"We initially thought the problem affected just computer software and
>>programs, but we are now learning that the magnitude and scope of the
>>Year 2000 challenge seems to be growing beyond just computers," Morella
>>stated.  "If consumer products which contain microchips are affected, we
>>need to know whether agencies are addressing this fact and whether the
>>American public is being adequately informed."
>>
>>The Year 2000 problem involves embedded microchips which are present in
>>many every day conveniences such as microwaves and elevators.  Most of
>>these products have internal timers which are programmed with the "19"
>>prefix.  When the year 2000 is ushered in, computers which are
>>programmed with the "19" prefix will interpret  the year to be 1900 -
>>not year 2000.  Some experts are predicting that if corrective actions
>>are not taken by the year 2000, businesses and possibly some sectors of
>>the government could face operational and fiscal disasters.
>>
>>"The Year 2000 problem poses a daunting challenge to consumers,
>>businesses, and government alike," said Representative Bart Gordon,
>>ranking Democrat on the Subcommittee who also signed the letter.  "I
>>look forward to working with Chairwoman Morella to increase the public's
>>awareness of the potentially catastrophic consequences if the Year 2000
>>problem is not addressed."
>>
>>The letter was drafted after a hearing last week in which several
>>witnesses reiterated their concerns about potential serious safety
>>consequences associated with the Year 2000 problem.  One study discussed
>>predicted that more than one-half of all organizations world-wide will
>>not fully complete the Year 2000 effort.
>>
>>"If the long-term forecast for the Year 2000 problem is dismal, there
>>must be a realization of failure, and new strategies must emerge from
>>this realization,"  Morella said.  She also said the response to the
>>inquiry would assist her Subcommittee with identifying Year 2000
>>situations which may affect the health and safety consequences of
>>consumers.
>>
>>In addition to Morella and Gordon, the letter was also signed by
>>Representative Stephen Horn, chair of the Government Reform and
>>Oversight Committee's Subcommittee on Government Management,
>>Information, and Technology and Representative Carolyn Maloney, ranking
>>Member on the Subcommittee on Government Management, Information and
>>Technology.
>>

    Trivia:
    
    As of midnight this Saturday, i.e. the start of Sunday 6th April 1997,
    there will be exactly 1000 days left until January 1st 2000.
    
    Just thought you'd all like to know...
    
    - Richard.

    re Trivia,
    
    An atomic clock counting off those 1000 days will be started at
    Greenwich on Sunday morning.
    
    Jc
    

    Hi John...
    
    Then there's something odd about this entry in today's VNS:
    
    A SHOWPIECE clock designed to display the second-by-second countdown of
    the last 1,000 days to the year 2000 will be inaccurate by at least one
    second when it is switched on at midnight today.
    
    "Midnight today" is 24 hours early by my calculations. :-)
    
    - Richard.
    
    ps. While I agree that THE Greenwich is the right place to have such a
    clock, purists might say that it should be in New Zealand, since they
    will be the first to "experience" the year 2000.

    Geographically, isn't the westernmost tip of the Aleutians to the West
    of the International DateLine, and hence might be even earlier ?

    No, a quick look at a map shows that the most easterly point in the
    International DateLine is just off the eastern tip of Siberia. 
    
    Since it's covered with solid ice at that time of year, perhaps that's
    where we should plan to go party. :-)
    
    - R.

    For my money, I think I would rather party on Kwajalein Island.  Their
    19 hours ahead of Mountain time, so at this writing its 0230 Saturday,
    and they have several VAXen to play with.  So we could swim, build sand
    castles or analyze y2k crash dumps :)
    
    Don..

Re: .14

>    ps. While I agree that THE Greenwich is the right place to have such a
>    clock, purists might say that it should be in New Zealand, since they
>    will be the first to "experience" the year 2000.

Somewhere under http://www.greenwich2000.com/millennium.htm you'll find an
"explanation" for why the new millenium starts in Greenwich and not some spot in
the middle of the Pacific.

The purists will be arguing that the millenium - wherever it starts - will start
in 2001 ... :-)

Antonio (two parties ... hooray!)

  I don't understand how year 2000 problems can occur with microwave ovens
and other devices that have timers but don't store and use dates. If the
appliance doesn't have a facility for the user to set a date, it wouldn't be
able to store a date. Unless it has a backup power supply to keep the clock
running when the appliance is unplugged. And there would be no reason for a
microwave to have a backup power supply. (Non-volatile memory can store user
settings when the appliance is unplugged, but this is different.)
  I think the author of the statement a few replies back (quoted from the
Internet) may have gotten confused between appliances with timers, such as
microwave ovens, and other appliances such as VCRs that DO store and use
dates.

    re .19
    
    I assume you are writing re .11
    
    Well it did come from the House of Reps! What can you expect?
    
    I can't see how a microwave oven can have a problem. Nevertheless the
    thrust of the committee's message was that non-esoteric, consumer items
    can have a problem too e.g. elevators, air-conditioners, VCRs. Perhaps
    a microwave oven is a dud example.

    certainly you must agree that microwave ovens, TVs, etc. have a
    software component.  Therefore, software bugs can and do occur in
    these beasts.  I would not expect anyone other than the manufacturer
    to know the details of a particular problem.
    
    Just because you don't see a date function on the product does not mean
    that it does not share components with higher-end models that do
    incorporate dates.
    
    Mark

  Mark,

>    Just because you don't see a date function on the product does not mean
>    that it does not share components with higher-end models that do
>    incorporate dates.

    That may well be the case, but if there is no external interface by which
  a date can be set, how does the device "know" what the date is? If the date
  isn't known or the device "guesses" the date, then there can't be a problem
  at midnight 1-JAN-2000. There *might* be a rollover problem at some other
  (random?) time, but that's another issue entirely.

    Some press reports seem to have got hold of this issue and blown it out
  of all proportion in their inimitable style. For instance, I heard one
  radio announcer claim that *pacemakers* might stop working. That sort of
  report is just plain misleading and, to my mind, irresponsible. Another
  said that at least one airline in the US will ground all planes across the
  transition (the whole 24 hours? anyone know if this is true?)

    Yes, there will be problems, but I certainly don't expect all of western
  civilization to grind to a halt at the stroke of midnight!

						John Gillings, Sydney CSC

        >Yes, there will be problems, but I certainly don't expect all of
        >western civilization to grind to a halt at the stroke of midnight
    Correct!

    From what I see of the problem, there are three type of
    companies.

    a)Those that have already foreseen the problem and are
    complaint.

    b)Those that recognize the problem and are doing
    something about it, they will succeed because they are
    professionals and when they set about the task they will
    complete it.

    c)Those not so successfully companies.


    Of the last type of company, if they have major problems
    in supplying goods/services to their customers they will
    either a) loose customers, b) be the subject of
    takeovers or c) go out of business.

    Example: When a supermarket can not stock its shelves
    the customers will go somewhere else.

    As for embedded systems, I understand that one telephone
    company in Scandinavia will have to send a person up
    every pole to change a chip, and an oil company that
    will have engineers to change a chip on certain
    production platforms.

    The good companies will do what it takes to success,
    other companies will not.


    There are always alternatives, other companies, other
    methods. If your microwave stop working, you will use  a
    stove, of buy a take-away, or a new microwave, even sue
    the manufacture. But you probably not buy XXX brand
    again.

    Company XXX may have a big problem after the year 2000
    if it has many disaffected customers

    Peter

    Just to reply to my own reply!


    The solution to the year 2000 problem is just for people to do their
    job.

    Example: If a printer will not print the invoices, what do you do 
    you fix the printer, fit a new ribbon etc. If the program that that
    prints the invoices not not work because of the date, you fix the
    program.

    If it is a small program you edit it yourself. If it is a big program
    or you have many programs you buy a tool. If it is an even bigger
    program or suite of programs - you send your code of to a code factory or
    you set up a year 2000 team.  If it is an embedded chip, you do a 
    product recall or send some one out to change the chip. 


    I entered this reply, because lots of companies seem enter into a period of 
    discussion of `year 2000' problem, where really all they should do is 
    start work - to highlight the problem where it occours and then fix any 
    problems they find. Actually this is normal business practice if you
    think about it - If you known a reason why some part of the business
    will not work you go about fixing it.
    
    As stated in the earlier reply, those companies that `fix' the year
    2000 problems will succeed, maybe do even better, picking up customers 
    (business) from those who don't.
    
    Peter
    
                                         

    The companies that haven't got it all sorted out and tested by the time
    we get to 1-Jan-2000 have something in their favor:
    
    !-Jan-2000 is a Saturday, and assuming that the following Monday is a
    holiday, they have a long weekend to get those last minute bugs fixed
    before business starts again in earnest on the Tuesday (Wednesday in
    Scotland).
    
    - Richard.

    Well, yes, but don't oversimplify the problem too much. I keep seeing
    visions of Ross Perot telling me to "just look under the hood" to find
    out how to fix the U.S. Government. 
    
    Y2K doesn't involve fixing things that are broken, but fixing things
    that will break under special circumstances sometime in the future.
    Most people can't realistically set up a parallel production system and
    run it under full load to "see what breaks and then fix it."
    
    I especially worry about .-2:
    
  >  b)Those that recognize the problem and are doing
  >  something about it, they will succeed because they are
  >  professionals and when they set about the task they will
  >  complete it.
    
    Consider the history of large software projects coming in to
    specification, on time, and on budget. I wish I had the
    citation, but I've read that something like 50% of large systems
    projects get scrapped due to design problems, cost overruns, and
    so on. Y2K can't be scrapped, and it has a deadline set in stone.
    It differs from most projects in this respect.
    
    Not to come down too hard on our fine profession, but this one's going
    to be a tough bugger... I don't fall in with the doomsday crowd - I
    think most companies will deal with it, but only through a lot of work, 
    and a realization that the problem must not be taken lightly.
    

    re .last few
    
    And no amount of testing and code-inspection can guarantee that all
    problems are found even in professional companies. The reality is that
    something can be overlooked, perhaps not even tested because noone
    conceived of the possibility that it might break, and sometime after
    1-JAN-2000 will start malfunctioning, either subtly or otherwise.
    
    Consequently from the point of view of "Western Civilisation", we need
    to focus on the basics, on the crucial, on the life-threatening e.g.
    energy generation and distribution, other utilities, food distribution,
    traffic lights, communication systems, medical related things, mass
    transport, defence systems. That should be enough to keep us out of
    mischief. Personally I don't see mal-functioning VCRs or microwave
    ovens as threatening our existence, particularly since it's likely that
    only the timer part would stop working.

>        Consider the history of large software projects coming in to
>        specification, on time, and on budget. I wish I had the
>        citation, but I've read that something like 50% of large systems
>        projects get scrapped due to design problems, cost overruns, and
>        so on. Y2K can't be scrapped, and it has a deadline set in stone.
>        It differs from most projects in this respect.
    
    
    Recently, I have been doing some work for an international distribution
    company, is split into two. 
    
    The international division running on Alpha/Vms hardware, I get on with
    very well they are a nice group of people. Are they Year 2000
    compliant? They have been for several years!!!

    In the same building but run as a different company, the domestics
    warehouse and freight forwarding. They have just done a migration
    project to Digital Unix. The project went over time/over budget by a
    factor of 2. Are they Year 2000 compliant? No Have they started? No.

    On the basis of there current situation, let's fast forward to the year
    2000. The international division will survive and possibly thrive,
    picking up business. The domestic division will have gone over budget,
    run late on their Year 2000 project. The customers that currently use
    their services will go elsewhere and won't comeback. The domestic side
    will shutdown or get taken over and a new computer system put in and
    the current programmers will go elsewhere!! 


    So in conclusion, Year 2000 will just be another year in the general
    business battleground of takeovers and restructuring - even though at a
    slightly faster pace.

    Of course if you work for a company that's not year 2000 compliant, you
    known what to do and if you don't you will known what will happen. I
    know of lots of different tools and solutions to help you. The
    domestics company, mentioned above, are running Microfocus COBOL and
    from what I understand. Microfocus COBOL have one of the better tool
    suites.
    

                         

>    And no amount of testing and code-inspection can guarantee that all
>    problems are found even in professional companies. The reality is that
>    something can be overlooked, perhaps not even tested because noone
>    conceived of the possibility that it might break, and sometime after
>    1-JAN-2000 will start malfunctioning, either subtly or otherwise.


    Let's face it, testing is not only a year 2000 problem it a general
    programming problem. In my opinion the general rule about testing is if
    you do zero tests you have zero confidence fact that the program will
    work. The more tests you run the higher the confidence factor. Is it
    difficult to get to 100% confidence factor? yes. 


    Are there tools to help you test? Yes.


    The are three phase to y2k
    1) find the lines of code you what to change. (Assessment)
    2) change the lines of code                   (Implementation)
    3) test them                                  (Test)

    Actually, I don't under estimate the work involved in testing code
    after you have changed it. There are some good thoughts on testing out
    on the web. The general thought relate to the idea that even though its
    a 10,000 line program you just changed, you have in actuality only
    modified a few line. However, testing is complicated by the choice of
    solution you have decided to implement windowing or field expansion. 

>    Consequently from the point of view of "Western Civilisation", 

    One point about "Western Civilisation" we are great shoppers, if we
    can't get/find we will just phone around to find some one who will
    supply it.


>    we need
>    to focus on the basics, on the crucial, on the life-threatening e.g.
>    energy generation and distribution, other utilities, food distribution,
>    traffic lights, communication systems, medical related things, mass
>    transport, defense systems. That should be enough to keep us out of


    You could have a problem if you have a monopoly of suppliers!!!

    Hence, not unsuprisingly some of the larger companies have been
    checking out their monopoly suppliers (and I known BT telephones in the
    UK have been doing this) and arranging for second sources, just
    because of the Y2k problem. 

    
    But really we should rename "Western Civilisation" as 
    "Western Uncivilisation".