Das Jahr 2000 Problem - Auszug aus dem Risk-Forum (comp.risks)

Die hier angebotenen Informationen haben wir mit freundlicher Genehmigung aus den Beiträgen im Risk-Forum (comp.risks) zusammengestellt. Vorerst alles in englischer Sprache.
Bitte beachten Sie die Hinweise am Ende dieser Seite.

Pentagon Y2K preparations

DefenseLINK, the Pentagon's main Web site, ws intended to keep the public
assured that Y2K was a nonproblem for DoD.  However, the site was
accidentally disabled on 30 Dec 1999 when other sites were taken off the Net
to guard against cracker activities.  The process of restoring service was
hindered by admins corrupting the domain name server.  [Source: PGN-ed from CNN
http://www.cnn.com/1999/TECH/computing/12/31/y2k.reports.roundup.01/index.html]

Two possibly unaddressed Y2K problems (From Dave Farber's IP)

While performing a Y2K check of a client's computers, I discovered a small
program, written in BASIC, which suggests an entire class of potential Y2K
glitches which has not been publicized and may plague us on or after
January 1, 2000.

In the client's back office was an older PC attached to a modem. Each time
the computer was booted, it ran a simple program which instructed the
internal modem to make a brief telephone call to a telephone number
somewhere in Colorado. Upon connecting, the computer received the date and
time, set its clock accordingly, and then hung up.

Inspection of the program revealed that it received and used only two
digits for the year.

What number was the computer calling? After a bit of snooping on the
Internet, I discovered that the number was that of the Automated Computer
Time Service (ACTS), provided by NIST (the National Institute of Science
and Technology, previously known as the National Bureau of Standards). The
time message received by the program, derived from an atomic clock, looks
like this:
  JJJJJ YRMODA HH:MM:SS TT L DUT1 msADV UTC(NIST) OTM
where
  JJJJJ is the Modified Julian Date (MJD);
  YRMODA is the date (two digits each for year, month, and day); and
  HH:MM:SS is the time in hours, minutes, and seconds.
(The remaining fields are documented online at
http://www.bldrdoc.gov/timefreq/service/acts.htm.)

What is interesting is that the BASIC program provided by the NIST itself
(the same agency, ironically, which distributes the Malcolm Baldridge
quality awards and offers Y2K help to small businesses) ignored the Julian
date and used only the two-digit year to set the computer's clock. This
software was posted on the Internet by the NIST until approximately last
October.

While ACTS can be used in a Y2K-compliant manner, the way to do this is
somewhat arcane (few programmers understand the concept of a Julian date,
and conversion is tedious). Perhaps this is why the NIST's own software --
which was doubtless used verbatim or as the basis for other programs -- cut
corners, as most programmers were likely to do, and used only the two digit
"YR" code for the year.

According to the NIST's ACTS Web page
(http://www.bldrdoc.gov/timefreq/service/acts.htm), more than 10,000
computers call the NIST's number each day. How many are running that old
BASIC program, or similar ones published on computer bulletin boards, in
magazines, or on the Internet, which have the same flaw?

But wait.... It gets worse. Apparently, the time code transmitted by ACTS is
similar to that used by the NIST's radio stations --WWV, WWVH, and WWVB --
to transmit time and date information the entire world. WWV's binary coded
decimal format, described on the Web at
http://www.boulder.nist.gov/timefreq/pubs/sp432/s_appb.htm, also uses only
two digits for the year. Worse still, the Julian date is not present, so
there is no way, using this code, to distinguish between the years 1900 and
2000.

Alas, some digital logic circuits which interpret the codes from WWV, WWVH,
and WWVB are literally hard-wired to the existing format. (According to some
quick research I've done on the Net, these range from an old Heathkit called
"The Most Accurate Clock" to laboratory instruments to traffic signal
controllers.) So, the NIST does not have the option of changing the format
to include a 4-digit year for fear of breaking this
equipment. Unfortunately, it is unclear whether owners of this equipment are
aware of the potential problems in these embedded systems -- some of which,
again, use hard-wired digital logic rather than microprocessors.  Will
traffic signals in Los Angeles and Orange County, which are said to use WWV
as a time standard (http://www.odetics-its.com/showcase/TASK2-2/la.html),
fail? Or will they become confused about the day of the week and snarl
traffic by using "weekend" timings on a weekday, or vice versa? What other
municipal, scientific, or military embedded systems will go awry because
they rely on the NIST's 2-digit time codes?

Ironically, while the NIST Web site contains an article
(http://www.nist.gov/y2k/embeddedarticle.htm) warning users to evaluate
embedded systems for Y2K compliance, I have been unable to find any article
in which the NIST mentions the format of its own time signals as a potential
source of Y2K problems. Today, when I used the "Advanced Search" facility on
the NIST's Web site to search for the call sign "WWV" together with the term
"Y2K" or "2000," it failed to turn up any hits whatsoever.  The NIST's Y2K
compliance page, at http://www.nist.gov/y2k/nistcomp.htm, lists both ACTS
and the agency's "time synchronization" services as Y2K compliant.

Conclusions are left as an exercise for the reader.

--Brett Glass

Low-tech Y2K failure

[Source: Bank blames error on printing vendor, Dee DePass,
*Minneapolis Star Tribune*, 21 Dec 1999; PGN-ed]

Wells Fargo & Co. sends out a batch of renewal notices - dated 1900

Wells Fargo & Co. experienced its first public Y2K glitch last week when it
mailed 13,000 certificate-of-deposit renewal notices with the year 1900 on
them.  The bank said the notices told customers in 10 states that their
certificates would expire in January 1900 instead of January 2000.  It isn't
known if any Minnesota customers received the letters.  Wells spokeswoman
Teresa Morrow said the error was attributable to a statement-printing vendor
who forgot to change the date on its printing machines.  Morrow said Wells
sent statements to the printer that said 1/15/00 and the vendor mistakenly
translated the 00 as the year 1900.  The mistake was discovered Dec.13, and
officials immediately sent out letters apologizing for the error. Customers
were told they would receive revised renewal notices in a few weeks.  Morrow
said, "We asked [the printer] if it was Y2K related and they said, 'It was
just us not setting our date on our printer.'"  Morrow said she didn't know
if the mistake would alter Wells' relationship with the vendor. She added,
"If that is the worst thing that happens to us with Y2K, then we will be set
for life."  Still, observers called the error an embarrassing blow to a
company that just last week declared it and its critical suppliers were
ready for Y2K, after having tested all its computer systems three times.
Federal regulators and the Minnesota Bankers Association have repeatedly
said all banks in Minnesota are ready for Y2K and don't expect any problems.
Even so, Wells Fargo and its competitors are staffing technical command
centers for four or five days after New Year's Eve, just in case a more
serious glitch occurs.  While most banks will be closed for the New Year's
Day holiday, many will have technical staff in the branches checking on
lights, heat and computers.

The risks: not testing the low-tech procedures for updating date
information -- "Well, we never changed that part of the date before."

Risks of expiring digital certificates in older Web browsers

> Millions of people using older versions of Netscape and Microsoft Web
> browsers may not be able to access some personal finance and e-commerce
> sites starting January 1.  It won't be due to the dreaded Y2K
> bug. Instead, it's because electronic credentials embedded in browsers are
> set to expire on Dec. 31 at midnight.

This is the lead of an article in the *San Jose Mercury News* on 29 Dec
1999, which warns that secure transactions may fail or be blocked because of
expiring digital certificates. Many banks are posting warnings to their
customers, warning that they need to update their net browsers, and SOON !!

Microsoft's Internet Explorer for Macintosh only discovered this
problem in the last three weeks and posted a fix on Dec 21.

I especially enjoyed this quote:

> Ben Golub, VeriSign's director of Internet marketing and sales, said the
> Dec. 31 expiration date was chosen about five years ago because at the
> time browsers couldn't accept dates beyond 1999.

> "In retrospect, maybe we should have chosen December 15," he said. "It's
> just an unfortunate timing kind of thing."

Shirley you can't mean this date is bad!

There are multiple risks, apparently, involved with multiple types of dates.
Experts said early efforts focused on checking dates -- typically identified
with a heading "mm-dd-yy" or "date" -- buried within computer code.  But
prankster programmers sometimes used unusual nomenclature that can make
these date variables nearly impossible to find.  Data Integrity said it
found a date field called "Shirley" when it reviewed software at a major
bank in the Northeast, which it declined to identify.  The programmer
responsible, it turned out, was dating a woman named Shirley when he wrote
the software.  [Source: The Year 2000 Challenge, *Wall Street Journal*, 30
Dec 1999]

The risks of last minute Y2K patches

Jane Garvey, the FAA administrator, was quoted that a late software patch
was applied to her agency's critical ``HOCSR'' computers, which process
flight plan and radar data for controllers.  The repair was completed early
on 30 Dec.  Garvey said the minor problem turned up during continued testing
of the agency's systems, which were declared Y2K-ready in June.  ``We're
continuing to test right up to the last moment.  We erred on the side of
caution.  The patch is in.  It's been fixed.  It's a very, very minor
issue.''  ["Last Minute Y2K precautions Taken", *The New York Times*, 31 Dec
1999 <http://www.nytimes.com/aponline/w/AP-Y2K-National.html>]

Assuming the story is accurate, RISKS readers will undoubtedly wonder
whether whatever benefits this fix might convey will be outweighed by the
risks of patching a critical system the day before the very event that will
trigger the execution of the patched code.  Given the combinatorially
explosive number of potential interactions in any complex system, it seems
strange indeed to conclude that *any* change is just a "very, very minor
issue".  Pondering this question will certainly give me something to do on
my Saturday morning flight...  matt

Y2K fear vs. Common sense

> 1) The generator is in a hastily built wooden hut secured with a padlock.
> The hut is located on the outside wall of our data center.  3,500 gallons
> of boom.

Most large generators are diesel.  I don't know if this particular
generator is diesel, but if it is, diesel does not go boom, and it
doesn't burn very well, either.  It's about as stable as cooking oil.

Gasoline, in its liquid state, does not go boom either.  It does burn pretty
well, though.  If you had an almost empty tank of gasoline, you could have
enough vapor that it might go boom.

I'm not a chemical engineer, so check this with other sources if you like.

Scott Nicol <snicol@apk.net>

  [Lots of you commented on this gaffe.  PGN]

Re: Y2K Fear vs. Common Sense

> All of our upper management is absolutely terrified of the end of this
> year.  They are convinced that there is going to be a major disaster
> at the stroke of midnight.

Would it frighten them any more, to know that power companies generally
operate on GMT?

The risks of failing to understand this necessity of managing a power
grid connecting multiple utilities and spanning several time zones, are:

+  presumption of more time for disaster preparation, than actually
   exists, should fears be justified; and

+  hysteria over impending doom, after the possibility of its occurrence
   has passed, should fears be unjustified.

I keep telling people where I live, that they can stop worrying about
their electric power, shortly after 7PM.  West of here, people can stop
worrying even earlier (4PM in California, for example).

Even if a few generating facilities did fail, unless they lost station-
keeping power, those facilities would remove themselves from the grid,
immediately. As far as I know, it's become standard practice to have
battery-backed station-keeping power, since a station without it caused
a major regional blackout in the Northeastern US, some years ago.

(Either their backup generator failed while the others were down for
 maintenance, or vice versa; I don't remember. The story comes second-hand
 from a former colleague, who, at the time, worked at a nearby manufacturing
 plant, whose generators were used to provide the power to bring the station
 back online.)  [...]

Y2K fear vs. Common sense

I work for a large health maintenance organization.  We share our campus
with about a dozen other assorted companies. All of our upper management is
absolutely terrified of the end of this year.  They are convinced that there
is going to be a major disaster at the stroke of midnight.

To deal with a potential loss of power, we have installed a generator
onsite.  A storage tank next to the generator holds 1,500 gallons of fuel.
An additional 2,000 gallons of fuel will be parked next to the generator the
entire weekend of the new year.

The risks?

1) The generator is in a hastily built wooden hut secured with a padlock.
The hut is located on the outside wall of our data center.  3,500 gallons of
boom.

2) One of the other clients on a campus constantly gets bomb threats.
Often the threats are real.  Who needs a Rider Truck?

3) Disaster recovery planning has taken a back seat to Y2k planning.  We
would not survive the loss of our data center.  The disaster plans have not
been updated to reflect our move from VMS to Unix over the last 5 years.

4) People ignore the large "No Smoking" signs posted on the generator
shed.  See #1.  Who needs terrorists?

The Unix team has started parking on the far side of the parking lot
in the 'blast shadow' of another building.

Y2K-related viruses

Y2K seems to be a spawning ground for security attacks.  W95.Babylonia
is a virus masked as a Y2K fix.  It has the ability to update itself
remotely, and spreads through autodownloads in Microsoft chat-room software
or e-mail.  Other viruses posing as Y2K upgrades have also been reported.
[Source: Self-updating virus spreads on Internet, AP item, 8 Dec 1999;
Courtesy of Sam Kasseman]

Power-out in Y2K test

The Berlin newspaper "tageszeitung" from Dec. 11, 1999 reports on a Y2K test
conducted at the federal Department of Justice. The workers had been asked
to not use their computers from 14.00 on Friday. Good thing, since the tests
managed to shut down the power in the building. No one wants to make an
official statement on the subject, since the official German policy is that
"Everything is going to be all right".

http://www.taz.de/tpl/1999/12/11/a0131.fr/text?re=ba for those who read
German "Millennium-Bug im Justizministerium"

Prof. Dr. Debora Weber-Wulff, Technische Fachhochschule Berlin
weberwu@tfh-berlin.de, http://www.tfh-berlin.de/~weberwu/

Risks of Y2K overreaction

The human element of widely published risks like the Y2K problem has seen
some coverage in RISKS, but seems to have been limited to predictions.

The *Philippine Daily Inquirer* and Associated Press report that a 61-year
old retired government engineer, fearing the Y2K bug, withdrew his life
savings of PHP2.8 million (about US$69,000).  Ten days later, four men
slipped into his house and robbed him of his savings, plus some PHP300,000
(about US$7,400) worth of jewelry.  This is a large amount of money in the
Philippines, worth about a decent-sized new house outside the city.

First of all, it appears that the banking industry's assurances were
insufficient to calm this educated man's fears.  Secondly, even if you
don't trust the banks, it's probably sufficient to convert the savings
to cash (or better yet, cashier's check or manager's check) and put it
away in a safe deposit box at your bank.  Was information about the Y2K
bug spread so poorly that an educated grown man was so scared he ignored
a much more conventional Risk?

Steven Huang Hughes Network Systems, 11717 Exploration Lane,
Germantown, MD 20876  MobileSat (240) 453-2357

Oh, no! Y2K virus competitions

>X-Sender: ars@pop.wilsonwhite.co.nz
>To: y2k_group@year2000.co.nz
>
>I don't have a lot of patience nor tolerance for those who use their
>talents to try and stuff up my life nor those of my staff by developing
>ever more sophisticated and warped viruses.  All it does is cause us grief
>and hinders us from finding good jobs for smarter, more honourable and
>usually more intelligent IT professionals.
>
>We have just received a warning from an anti-virus specialist (poacher
>turned gamekeeper ?) about some idiots in Holland who have established a
>competition for the best Y2K virus.  The p[i?]rates involved have set up
>"game rules" with the only requirement being that each entry has to be a
>virus/trojan or backdoor, and preferably related to the Millennium Bug or
>the year 2000.
>
>Quoting (after editing) from the site :
>"The viruses that will be sent for the Y2K infection feast [sic] will be
>sent 4-5 days before the release to AV companies. The one that gets
>detected last will be the winner."
>
>Words fail me.
>
>I'm told there are almost 50,000 viruses floating around the world
>now.  It's a real pain that some stupid ***** ***** is going to further
>waste my time over Y2K, just when I don't need the hassle.  I'm sure you
>don't either.
>
>What to do?
>
>We're disconnecting our e-mail servers from the WWW and setting up an e-mail
>service on a standalone PC.  This standalone machine will do ALL e-mail
>downloads from real soon now until well after New Year.  We'll keep that
>machine loaded to the gunwales with the latest anti-virus software and will
>endeavour to ensure that any virus outbreaks are thus contained.
>
>We strongly suggest you seriously consider doing the same.
>
>We'll pass CVs internally across to other "more sensitive" machines in .rtf
>format (using rtf avoids Word-type macro viruses).
>
>Remember also that the major anti-virus companies have all agreed to
>provide FREE 90-day versions of their software to cover this period.  GET
>SOME !!!  before 31 December via http://www.year2000.co.nz/y2k8.htm#antivirus
>
>Lastly, remember to pull the power cord/s out of the wall socket/s when you
>go home before New Year, a simple method of avoiding any possible surge
>damage to electronic equipment.
>
>Thinks : Wouldn't it be nice if we could have a quiet Y2K period ????
>
> A R (Ross) Stewart, Wilson White Group, Auckland, New Zealand
> ross@year2000.co.nz http://www.year2000.co.nz/  ross@wilsonwhite.co.nz
> ph: +64(9)307-3869 (posted at http://www.year2000.co.nz/y2kema21.htm)

Worm.Mypic: Will Y2K provide cover for worm/viruses?

The upsurge in e-mail-enabled worms and viruses appears to be supporting the
predictions of anti-virus experts who said that the Y2K transition would see
a flurry of new viruses and variants that would contribute to confusion
about the source of software problems following New Year's Day 2000.

Nancy Weil, writing in ComputerWorld
<http://www.computerworld.com/home/news.nsf/all/9912035y2kworm>, suggested
that the Worm.Mypic (aka W32/Mypics.worm) demonstrates the kind of problem
we are going to face in coming weeks.  Worm.Mypic arrives as an executable
attachment (Pics4You.exe with a length of 34,304 b).  If executed, the
program e-mails itself to the usual first 50 names in the MS-Outlook address
list (and continues to try to do so at regular intervals).  As soon as the
date changes to 1 Jan 2000, the resident virus overwrites checksum data for
the computer's BIOS, interfering with the boot sequence.  The virus also
attempts to format C: and D: drives.

As usual, everyone agrees that it is critically important to update
virus-signature files even more frequently than usual as we approach the new
year.

M. E. Kabay, PhD, CISSP / Director of Education
R&D Group, ICSA Labs <http://www.icsa.net>

Y2K compliance

The IEEE created a document (either a standard, a standard practice, or a
guide), I forget which status it achieved in which Y2K compliance was
originally defined, essentially, as "the software will work after the start
of the millennium". It was pointed out that this was ridiculous since the
software might not work beforehand and it shouldn't suddenly work
afterwards. So the definition was changed to, essentially "the software will
work as well after the millennium as it did before".

Increasingly, I am seeing organizations break all kinds of software now, in
their mad scramble to apply Y2K fixes (well, they are called fixes).  If I
apply the definition, it is clear that they are ensuring Y2K compliance by
the following strategy.

Start with a currently operational system that may (or may not) be Y2K
compliant.  Apply Y2K fixes so that the system becomes non-operational and
now, by the IEEE definition they are guaranteed to be Y2K compliant.

The real risk, behind this the above is, of course, that many organizations
(including those that should know better) have left it *far* too late to
apply and test patches and are now scrambling to become Y2K compliant. Who
knows what will be broken next or the vulnerabilities that are being opened
up?

  [Yes, we know, 2000 is not the beginning of the next "millennium".  PGN]

Re: Irish telephone network outage brings Y2K fears (Casey, R-20.66)

It sounds like the problem may have manifested itself only when the system
was under load (if it took from night/morning until midafternoon for it to
really make a mess), in which case having the upgrade done on the weekend
might not have been an improvement.

There is also a practical issue: it is often safer to make such changes at
times when your full staff is at work, so that minor problems can be spotted
and handled quickly.  This inherently conflicts with wanting to keep major
failures out of the way of the customers, so it unfortunately requires
guessing how serious the problems are likely to be.  Sometimes you guess
wrong.

Irish telephone network outage brings Y2K fears

To summarise Eircom Ireland main teleco had a major failure last Friday
afternoon. An upgrade which took place either Thursday night or Friday
morning failed. When they switched to backup systems these also failure due
to some embedded "software bugs" as described on the radio. The collapse of
the first exchange caused a domino effect on exchanges in the centre of
Dublin and businesses were left without a service from about 2.30 p.m to
6.00 p.m. Some 80,000 land-lines were effected initially, but this rose
significantly as other exchanges were hit. People making calls to numbers in
the affected areas were unable to reach them.  To compound the problem
Eircoms Cell phone customers in the same area where left without service due
to an independant problem. The countrys other mobile network Esat was
unaffected.  A few interesting points, why do people insist on upgrading
during the working week when the risks are obvious.  The second is this was
Eircoms first big test for disaster recovery and it didn't come out very
well. The Irish Telecoms Users Group has questioned Eircoms Y2K preparedness
based on this incident. An Eircom spokesperson said that they were Y2K ready
(£ 25 million project, 70 dedicated staff over a number of years) but
admitted there were likely to be "glitches" in the system.  see the Irish
Times Archive for text of a story covering the incident.
http://www.ireland.com/scripts/search/highlight.plx?TextRes=eircom&Path=/new
spaper/finance/1999/1120/fin50.htm

Firestation fire blamed on Y2K computer fix

This past Tuesday's *Montreal Gazette* reports a fire that caused $500,000
damage to a local fire station.  The fire started when one of the firemen
left french fries cooking when responding to an alarm. The breaker system
designed to cut off power to the stove when this occurs had been
disconnected ... because it was incompatible with the new Y2K compatible
computer system recently installed!!!

In addition to the irony of a fire destroying the fire station and a safety
system being disconnected because it's incompatible to the new computer
system, the station had recently been the object of a successful community
effort to save the historic old building from destruction during a
development project.

According to a city official a patch is required to make the power cut off
system compatible with the new system. No details were given regarding the
hardware or software for either the new Y2K system or the power cut off
system.

Ah, the risks of avoiding risks!

Kevin Whelan <kwhelan@mail.aei.ca>

Re: Y2K creates "horseless carriages"

"Horseless carriage" is a legal designation used by some states to indicate

a particular type of automobile registration, usually for early-20th-century

cars.  It's not an issue of a DMV programmer picking an odd-sounding

category.



Of course, this points out a RISK of transient URLs; the San Jose Mercury

usually leaves articles up only for a few days before they move them into

their archive, where you have to pay to retrieve back content.  However, I

was able to find this article by searching on "horseless carriage" in both

the San Jose Mercury News site and the Portland, ME Press-Herald

(http://www.portland.com/) -- which makes it seem much less of an urban

legend.



Adam  [also noted by many other contributors!  Thanks.  PGN]

Microsoft Y2K liability

I didn't know I _was_ a Microsoft (UK) customer. Must be because they

own Apple.  And I refuse to take seriously any Y2K statement ending with:



   MOREOVER, MICROSOFT DOES NOT WARRANT OR MAKE ANY REPRESENTATIONS

   REGARDING THE USE OR THE RESULTS OF THE USE OF ANY MICROSOFT YEAR

   2000 STATEMENT IN TERMS OF ITS CORRECTNESS, ACCURACY, RELIABILITY,

   OR OTHERWISE.



disclaiming everything previously said, and sent by some clueless

organisation that can't wrap to less than 80 chars.



PGP



  [Get the full message from Lloyd if you are curious.  PGN]

Risks of Office 2000

(Pointed out to me by Adam Kirby.) Try this in Office 2000.



Open a new document.

Type 'Hello World'.

Save as HTML.

View source of the saved document.



The length of the resulting document (three pages!) firmly places this

in the 'extend' part of 'embrace and extend'. Risk? We're going to be

drowning networks in even more redundant crud.



PGP

Re: Y2K creates "horseless carriages"

>AP reports that a Y2K glitch has caused 2000 new vehicle registrations in

>the state of Maine to bear the classification "horseless carriage".

>Apparently, the DMV software misread the 2000 model year as 1900, and it is

>hardwired to classify any vehicle with a model year before 1916 as a

>horseless carriage.



This smells like an urban legend.  Can you imagine a programmer at the DMV

titling a category as "horseless carriage", or even a faceless bureaucrat

specifying that name?  It's unlikely that the DMV was computerized earlier

than the 1960s, and that term just doesn't sound likely.



>http://www.mercurynews.com/breaking/docs/024281.htm"



---This link is dead, adding to the suspicion.  I think someone was pulling

their legs (successfully), and they got caught.



- Ted



Ted Doty, Internet Security Systems              | Phone: +1 678 443-6000

6600 Peachtree Dunwoody Road, 300 Embassy Row  | Fax:   +1 678 443-6479

Atlanta, GA 30328  USA                           | Web: http://www.iss.net

Y2K creates "horseless carriages"

AP reports that a Y2K glitch has caused 2000 new vehicle registrations in
the state of Maine to bear the classification "horseless carriage".
Apparently, the DMV software misread the 2000 model year as 1900, and it is
hardwired to classify any vehicle with a model year before 1916 as a
horseless carriage.

http://www.mercurynews.com/breaking/docs/024281.htm

Millennium Bugs?

It is now finally clear to me what all the hysteria about Y2K is really
all about.

It is not about stingy COBOL programmers using two BCD bytes instead of four
in WORKING STORAGE.

It is not about embedded systems collapsing, rendering our traffic
intersections, our satellite systems, and other vital technologies useless.

It is about the latest in a long debilitating line of systemware products
from Redmond, Washington, USA.

This week I received the WinNT Magazine newsletter, with an introduction
from Paul Thurrott, who describes himself as a "recovering Windows 2000
(Win2K) beta tester". Thurrott is largely positive about this monster, but
does add that hardware requirements "have risen from a lowly Pentium to a
300MHz Pentium II with 128MB of RAM" and winds up by saying:

"But I suspect that when the Win2K beta ends, a lot of testers are going to
find themselves balking at the upgrade, at least for the short term.
Suddenly, that wonderful ugly duckling we know as NT 4.0 doesn't look so bad
after all."

It just dawned on me - namely that the great, great majority of PC users
world-wide are home computer enthusiasts, and the great, great majority of
these enthusiasts use their computer primarily - or even exclusively - to
access the Internet, and that they demonstrably do not need anywhere near
the kind of machine necessary to run Win2K to do that, and that they don't
need Win2K at all.

And it dawned on me further that this would hardly change anything. Home
computers running 16 bit operating systems might be perfectly capable of
rendering an enjoyable cyber experience, and I believe Compaq and Netscape
have shown that if one only wants to surf the net that one does not need an
operating system - and one certainly does not need Windows - at all.

But it would be quite unrealistic to assume that the market analysts and
spin doctors in Redmond have suddenly, after decades of incredibly clumsy
successes, suddenly got it all wrong. A gray shadow of unreality creeps
closer, hovering, threatening, foreboding, and I can literally feel it. Here
we have an operating system destined to be one of the greatest and most
bugged monsters of all time offering us literally nothing most of us will
ever need and forcing us, moreover, to upgrade our hardware at a great
expense - and all of this is _for naught_, all of this gives 95%+ of the
world's computer users absolutely _nothing_ - and yet we all know how things
are going to go in the long run anyway, don't we?

The boggle continues. Ballmer insisted Windows 95 would run on a 386 with
4MB RAM. I knew he had to be crossing his fingers behind his back and so I
went out and bought a machine with a Pentium and a walloping 16MB RAM and it
turned out I was right. Yet the quantum leap from a 386 and 4MB to a Pentium
and 16MB is nothing compared to the leap expected now. I have for several
years run courses in NT programming using first the NT 4 Shell Technology
Update and then NT 4 itself, with MSVC running on top, with only 32MB RAM
installed on low-end Pentium machines, and we have never had a hitch. We
have of late attempted to demonstrate Win2K on classroom machines with far
faster processors and many times the RAM and had to abandon our
efforts. Windows 2000 simply peaks the CPU meter even in idle and then
calmly stands still.

I keep thinking about that comment from Microsoft that another RISKS reader
recounted to me: "that's not the way we do things at Microsoft - when it
gets too slow we just throw more hardware at it." And for those of you that
followed the ripples from these forums in the Daily Telegraph's Connect
supplement, yes my company today does have that "Windows Explorer"
replacement mentioned there, and it does not consume a quarter of a megabyte
on disk as its Redmond counterpart, but only 26KB. 26,624 bytes. As one user
wrote to us: "I can finally throw that Microsoft Windows Explorer in the
trash bin where it belongs."

It is important to realize that our conditions were not better than
Redmond's - quite on the contrary. We did not have access to, or ever
consider availing ourselves of a staff several times the size of
Redmond's. We did not work long hours in our offices and sleep on our futons
as one is expected to do in Redmond. We just wrote the program.  Like
anything else we write. And over a time span considerably more realistic
than Redmond used for Windows Explorer.

Bloat is not unavoidable. Bloat is not a necessary evil.

Bloat is always, has always been, and will always be a totally indefensible
blot on computer science.

I fail to see how anyone - even a band of zonked-out Microserfs - can take
what was almost an operating system - NT - almost totally based on, if not
identical with DEC's VMS, and systematically turn it into the biggest, most
bloated bug farm in the history of computer science - and, for every turn in
the road, for every day and week that went by, not _improve_ the code and
make the system run _faster_, but literally _ruin_ the code and make the
system run _slower_, or run not at all. I truly think that the ordinary laws
of logic, of human intelligence, somehow fail to apply in the Pacific
Northwest, and am starting to facetiously wonder if David Lynch wasn't onto
something after all. Is Laura really Melinda French? Doesn't WHG3 have the
faintest resemblance to her father, and SB a bit too much in common with
Kyle's night porter?

For those fanatics who said all along we should leave the big cities, that
people would drop like flies in droves from the hypothermia - I am beginning
to wonder. For the first time I am getting scared of the Millennium - and
not for the COBOL bug, but for the Redmond Millennium Bug. The wife is now
negotiating with the realtors at Prayer Lake to see if they will part with
some of their precious real estate and thereby help save a few more lives.

PS. Anyone who wants a further peek at this "Explorer killer" of ours to see
for themselves that it really can be done is welcome to drop a line at the
address below. We'll send along a complimentary copy.

Rick Downes, Radsoft Laboratories http://www.radsoft.net

GPS rollover *did* cause DoD Problems

Mike Martin reported on the problems with Tokyo taxicabs caused by the
August GPS rollover (Risks-20.55). Aviation Week reports (Oct 4, p32)
that US DoD systems also had problemswith weapons systems, even though the
situation had been anticipated. "...the fault lay in the way the Pentagon's
two primary mission planning systems, the Air Force Mission Support System
AFMSS) and the Navy's Tactical Aircraft Mission Planning System, were
providing the data to weapons systems."

The mission planning tools provide, amongst other things, the approximate
location of the GPS satellites to a weapons system GPS receiver so that the
receiver can  avoid large-sweep searching for the satellites.
Some receivers work with 16-bit week data; the satellites and
mission planners rolled over; and the different formats caused
"conflicting data sets" and thus problems, according to AvWeek.

"Short-term fixes...include editing the missions planning data manually,
having the receivers find the satellites unaided or downloading the
almanac data directly from the satellite, which takes about 13 min.
The likely long-term fix is a software modification to AFMSS and TAMPS,
which is considered cheaper than modifying weapons systems hardware."

Peter Ladkin  		http://www.rvs.uni-bielefeld.de
University of Bielefeld, Germany

NT Stung Again by Y2K Bug

Microsoft's May 1999 Service Pack 5 (SP5) was supposed make Windows NT 4.0
ready for Y2K.  However, so many bugs arose that fixes have been included in
SP6, which has been in beta since July.  There are problems with the Net
User command line security utility for setting log-in times, with real-time
clock dates when not in a daylight-saving time zone, and with multiprocessor
kernels, another problem with Outlook Express, etc.  The problems are
considered minor.  Problems with other systems are also noted.  [Source: NT
Stung Again by Y2K Bug, Joseph McKendrick, 22 Sep 1999
<http://www.entmag.com/displayarticle.asp?ID=9239933447PM>, PGN-ed]

Iraq decides to wait and see on Y2K oil disruption

  [Keith sent in a Reuters item noting that Iraq is has decided to avoid
  the costs of Y2K upgrades, and may have to shut down production for the
  new year instead.  Many of their computers are reportedly old process
  controllers.  Keith comments that with Iraq and Venezuela both lagging in
  Y2K fixes, it could be an expensive millennium for many drivers.  PGN-ed]

FBI warns some Y2K fixes may be suspect

> The Federal Bureau of Investigation says that some of the
> Y2K-related programming fixes that were undertaken by
> foreign contractors may contain malicious code.  [...]
> Such code could contain "time bombs" set to detonate at
> some future date, [...]

And how, exactly, would that be any different from the code that was there
before ?  (-:

JdeBP

FBI warns some Y2K fixes may be suspect

The Federal Bureau of Investigation says that some of the Y2K-related
programming fixes that were undertaken by foreign contractors may contain
malicious code. "We have some indications that this is happening," says
Michael Vatis, head of the inter-agency National Infrastructure Protection
Center. "A tremendous amount of remediation of software has been done
overseas or by foreign companies operating within the United States." A
Central Intelligence Agency officer assigned to the Center said recently
that India and Israel appeared to be the "most likely sources of malicious
remediation" of U.S. software. "India and Israel appear to be the countries
whose governments or industry may most likely use their access to implant
malicious code in light of their assessed motive, opportunity and means,"
CIA officer Terrill Maynard wrote in the June issue of Infrastructure
Protection Digest. Such code could contain "time bombs" set to detonate at
some future date, disrupting service or compromising security and password
protections. The Special Senate Y2K committee, in its final report last
week, called such scenarios "unsettling."  (Reuters/TechWeb 1 Oct 99)
http://www.techweb.com/wire/story/reuters/REU19991001S0001;
NewsScan Daily,  1 October 1999, with permission)
  [See also http://dailynews.yahoo.com/h/nm/19991001/tc/yk_code_2.html . PGN]

9/9/99?

The Wall Street Journal seems to have reported that 9/9/99 was a nonevent.
Yet, a relative of mine was shocked to discover $160K inexplicably credited
to their account. When they went to the bank to get it corrected, they found
a line of people already there waiting to see the bank officers.  The person
in front of them in line had done considerably better: they had received
over 2 million dollars that way. The transactions had occurred on September
8, and the statement with the errors on it was printed September 9.  The
bank (a well known name) "thanked them for their honesty in coming forward",
"apologized for the inconvenience", "had already fixed the problem so it
wouldn't happen again", and "advised all their customers to hold on to all
paper statements". This event (which apparently affected at least several
dozen people in a Dallas suburb) went entirely unreported in the local
media.

Was this the (mythical?) 9/9/99 bug or an unrelated fluke? I certainly never
heard of something like this happening before to anyone I personally knew!

Sweet Y2K angle

I suppose another Risk of the Y2K hysteria is this "sweet" hoax.  I
received this from a cousin, who has now been directed to (a) desist from
sending me spam and chain letters; and (b) an Urban Legends web site.

>Date: Friday, August 06, 1999 12:15 PM
>Subject: FREE M & M's
>
>Have some fun-this is not a hoax.
>
>Hi.  My name is Jeffrey Newieb.  I am a marketing analyst for M & M's
>chocolate candies based in Hershey, Pennsylvania.
>
>As the year 2000 approaches,  we want to be the candy of the millennium -
>As you may already know,  the roman numeral for Y2 is MM.  We are
>asking you to pass on this e-mail to 5 friends. Our tracking device is
>calculating how many e-mails you send out. Everytime it reaches 2000
>people, you will receive a free case (100  individual  55  gram packs) of
>delicious M&M candies.  That means the more people this reaches,
>the more candy you're going to get.
>
>Mmmmmm.. yummy  M & Ms the year 2000!!
>
>Remember, nothing but no M & M's will come your way if you do not
>share this with at least 5 people
>
>Don Fry, CPC,  President
>Dunhill of Corpus Christi, Inc.
>Voice:  (361) 225-2580
>Fax:     (361) 225-3888

Anyone want to call him?  I didn't.

And when I told my cousin there's no such thing as a "tracking device", I
got this reply:

>What do ya mean, they don't have the technology yet to track....???
> I wonder about that...

Sigh.

1 Oct 1999 as a Y2K problem date?

Add 1 Oct 1999 to your list of dangerous dates.  My Visa bill (which just
arrived) is due in early October.  The "payment due date" field is
apparently too small, so the due date is listed as 0/05/1999.  Presumably,
the leading digit "1" was dropped.

Why didn't this occur last year?  They changed from using a 2-digit year to
a 4-digit year in April of this year, and apparently did not realize that
they would have to increase the size of the field.

--David Wittenberg                dkw@cs.brandeis.edu

   [The problem evidently is not at Visa, but rather at David's issuing bank.
   It appears to be a format error in the statement printer rather than a
   Visa programming problem.  PGN]

Indonesian Year 2000 plans

I admit that I haven't been able to verify this report, but if only half true
the risks are obvious...

PLN, Indonesia's national electricity board, was recently asked by an
Indonesian newspaper about its Y2K Preparedness.

The reply is a gem:

  "We can observe what happens (at midnight 1999) in Western Samoa, New
  Zealand and Australia and still have 6 hours to make plans."

Cheers,

Fraser McHarg from the East coast of Australia and contrary to the above report
we have two hours to make plans after observing New Zealand :-)

  Well, the RISKS archives include cases of systems such as ATMs failing in
  New Zealand and the fix being effected before midnight in England.
  HOWEVER, the complexity of fixing dynamically detected Y2K bugs may be
  different from some of the previous clock problems.  PGN]

Yet another date-related problem

I was working on a new script last night, and stopped to consider how many
output columns would be occupied by a Unix timestamp in the semi-standard
decimal representation.  Nine digits, right?  Always has been, always will
be... NOT!

The Unix timestamp first hit 9 decimal digits on March 3, 1973, and it has
been inexorably incrementing ever since.  A quick check with my time
conversion program tells me that at precisely 01:46:40 UTC on Sunday,
September 9, 2001, it will need that 10th digit.

This is a much smaller problem than most other date bugs, of course.  But I
have to suspect that there are a few programs out there that will break, at
least to the extent of causing an 80-character output line to wrap to 81.

Geoff Kuenning   geoff@cs.hmc.edu   http://fmg-www.cs.ucla.edu/geoff/

If it quacks on 1/1/2000, it must be a Y2K duck

I received a notice recently that one of Verisign's root keys expires at the
end of 1999, and users of Netscape browsers (version 4.05 and earlier) need
to get an updated certificate to avoid warnings about expired keys.

This in itself isn't a big problem--we expect certificates to expire,
although it can be rather inconvenient. The problem comes from the timing:
anyone seeing odd behavior (such as an extra dialog box) on or near 1/1/2000
is likely to blame it on a Y2K problem, whether that's appropriate or not.

Apparently this fact has not been lost on Verisign's competitors, at least
according to Verisign's FAQ on the matter, at:
  http://www.verisign.com/server/cus/rootcert/facts.html

Moral of the story: schedule software dates when nothing else important
is known to be happening.

Win Treese, Open Market, Inc.  treese@openmarket.com

Food expiry date misreading risks

[This topic is raised in news:uk.tech.y2k.]
There is a little more in my Web page
        <URL: http://www.merlyn.demon.co.uk/date2k-3.htm#Food>.

Subject : Y2K - User Misinterpretation of Food Expiry Dates

Confusion between two digits meaning Year 20## and meaning Year 19## is well
understood; misidentification of ## fields in dates between Y, M, D has been
discussed in Y2K newsgroups; the food trade will understand the date formats
on their products.

However, one problem is perhaps not well-realised : the use of ## fields in
expiry dates on the packaging of foods, together with the circumstances of
domestic food storage, leads to the probability that many of those who
finally use these packaged foods may misunderstand the dating formats.

For example, an item sold in March 2000 may be marked for use by "OCT 01" -
does it have a six- or an eighteen- month life? If it is discovered in the
back of the cupboard on 2000-09-20, should it be eaten soon, or is there a
safe year left?  Many errors can be expected.

Remember that some food travels, some amateur cooks travel, date formats
vary, ...

If the famed cook, Great-Aunt Philomena o'Kerry, on her first trip ever out
of Erin, visits the kitchen of her Great-Niece in Troy, AL, USA, will she be
safe?

John Stockton, Surrey, UK.  jrs@merlyn.demon.co.uk
<URL: http://www.merlyn.demon.co.uk/>

Local company stung by Y2K bug

Y2K glitches happen to even the most computer savvy folks.  Wayne Moule,
president of Northwest Metrology, a company that calibrates electronic test
equipment for federal agencies and major corporations, is a case in point.
Moule sees the damage every day and still is counting losses - $80,000 and
growing - because software he owns fell victim to a year 2000 problem. ...
[Source: Marc Benjamin, *The Bakersfield Californian*, 24 August 1999;
PGN-ed]

Tokyo traffic chaos in GPS date rollover

The Australian Financial Review's Tokyo correspondent, Andrew Cornell,
reports (AFR Aug 24) that the GPS date rollover, previously discussed at
length in RISKS, occurred at 9 am Sunday Aug 22 in Japan and that "an
estimated 100,000 systems", mainly used by vehicle drivers for navigation
through Tokyo's unnamed streets, "froze or went blank as the system rolled
over into its new time sequence".

Cornell reports that Pioneer, the GPS market leader, had been advertising to
notify customers of the problem, and had adapted or replaced 210,000 of its
270,000 affected systems.

If this incident is typical of consumers' and small businesses' response to
a technology brick wall then it does not bode especially well for January 1
next year.

Mike Martin

  [See also Reuters, *The New York Times*, 23 Aug 1999,
http://www.nytimes.com/library/tech/99/08/biztech/articles/23gps.html/  PGN]

GPS rollover hits yacht

From this evening's RTE news:

The Irish Marine Emergency Service has been dealing with a yacht on route
from the Scilly Isles to Kinsale which ran into fog and heavy weather south
of Ireland this morning. Local reports say that "The Tam-o-Shanter" radioed
for help when its Global Positioning System began to misread the boat's
position.  The crew were further hampered by extremely heavy weather and a
torn sail. With the aid of the IMES and Coast Radio Stations, a position was
given and the yacht is now safely in Kinsale Harbour.

It is believed a millennium style bug caused the "Tam-o-Shanter" to lose its
position today. At midnight GMT (1am Irish time) the GPS "rolled over".
After its launch in 1980 it had a life span of 1,024 weeks, which reached
zero this morning when the system reverted back to its start time.  All
mariners had been warned of this, but GPS units older than five years would
not have been capable of handling the change.

(snipped from http://www.rte.ie/news/1999/0822/boys.html)

9/9/99

According to a report in one of the UK Sunday papers two real occurrences of
the fabled 9/9/99 bug have been found, one in a non-critical medical
application.  It would be interesting to have more information about this as
I have always thought that the 9/9/99 bug sounded like press scaremongering
rather than something that would really arise.

http://catless.ncl.ac.uk/Lindsay

Y2K in China

Date:        Sat, 21 Aug 1999 20:32:39 -0400
Reply-To: H-Net list for Asian History and Culture <H-ASIA@H-NET.MSU.EDU>
From: David Cowhig <dcowhig@public3.bta.net.cn>
Subject: H-ASIA: May 1999 China Y2K National Conference: Guarded Optimism

May 1999 China Y2K National Conference: Guarded Optimism A June 1999 report
from U.S. Embassy Beijing

http://www.usembassy-china.gov/english/sandt/Y2kcnfwb.htm
[see also the recently updated links to Chinese Y2K related websites at
http://www.usembassy-china.gov/english/sandt/y2gov.htm ]

Summary: China Y2K Czar Zhang Qi and other speakers at the Second PRC
National Y2K Conference held on May 6-7 in Beijing expressed greater
confidence in China's electric power grids but greater concerns about the
effect of the Year 2000 computer problem on railroad freight, medical
instrumentation and embedded chips. Zhang Qi said that electric power
companies would be assured funding for Y2K solutions. Some Chinese experts
doubt, however, that Y2K funding will be made available; the August 1998
State Council Y2K order made each unit responsible for funding its own Y2K
solutions. Zhang mentioned the recent Shanghai Y2K Seminar with Secretary of
Commerce Daley and her upcoming August 1999 USIA sponsored trip to the
U.S.A.. Central government speakers discussed the Y2K problem in
telecommunications, electric power, and transportation. Local government and
industry Y2K speakers came from Liaoning Province, Beijing Municipality, the
Beijing Municipal Health Bureau, the Baoshan steel company and Chinese
banks. Two speakers discussed Y2K legal liability issues.  The speakers
agreed that China faces Y2K difficulties in many sectors but no one foresaw
a national cataclysm. The Embassy Beijing view is that Y2K will not put
American citizens in China into danger but will likely affect business and
especially small businesses such as suppliers and small contractors.  These
Y2K problems might affect the overall Chinese economy gradually over weeks
and months.

Y2K upgrade went 'horribly wrong', admits utility giant

London Electricity has admitted its Y2K upgrade for 400,000 prepayment
customers (costing 2 million pounds) went ``horribly wrong'', leaving 2000
customers without power and light for days, and another 2000 having
``difficulties''.  The process of providing new Rechargeable Powerkeys to
customers was in progress, but for a fourth of the clients the payment
credit did not get transferred or their meters were corrupted.  A similar
upgrade in Sussex was done at the same time, which compounded the problems.
[Source: Mike Simons, *Computer Weekly News*, 12 August 1999; PGN-ed]

Y2K test sends sewage flowing in Los Angeles

A supposedly routine test of LA's Y2K readiness of the emergency
preparedness system at the San Fernando Valley sanitation plant caused about
4 million gallons of raw sewage to be dumped into the Sepulveda Dam area.  A
gate to a major sewer pipe closed without warning because of a programming
error.  [Source: article by Miguel Bustillo, Karima A. Haynes, Patrick
Mcgreevy, http://www.latimes.com/HOME/NEWS/FRONT/t000054865.html,
*L.A. Times*, 18 Jun 1999; PGN-ed]

Re: GPS and collision risks (Wood, RISKS-20.44)

> [...] The probability of a collision between aircraft using GPS on
> established air routes is significantly higher than between aircraft
> using conventional navigation aids because of the greater accuracy of
> navigation using a GPS.

Intuitively, I doubt this. Here's the reasoning.

To begin with, let us consider flight along, say, US Federal Airways.

Firstly, (a) separation in instrument meteorological conditions is ensured
by ATC. No change in risk here. Secondly, (b) aircraft flying under
instrument flight rules in visual meteorological conditions are flying in
cruise at different altitudes (thousands of feet) than those flying under
visual rules (thousands + 500 feet). Thirdly, although I cannot find it in
the US Aeronautical Information Manual (AIM), (c) pilots of aircraft flying
visually on designated airways have *always* been advised to keep the airway
centerline/fix to one side of them - yes, the same side (actually, this is
well-known pilot lore all over). This takes care of the climb/descent
problem. US Federal Airways extend horizontally to 4 nautical miles (4.6
statute miles) each side of the centerline.

Federal Airways are defined by VOR transmitters not more than 50nm from any
point on the airway that they are defining. Even though a signal may be
distorted, all receivers will be receiving the same distorted signal, so any
individual variation must be in the individual receivers in the aircraft. I
can see no way of demonstrating either than pilots fly more accurately to
GPS guidance than they do to VOR guidance, or that VOR reception is
generally sloppier than the accuracy to which visual pilots are flying an
airway (my experience, in fact, is quite the opposite, as would be that of
most instrument flight instructors trying to get their proteges to hold a
VOR course, I would suppose!). Unless one or the other of these can be
demonstrated, one could not conclude that flying behavior on airways had
changed significantly with the introduction of GPS.

But suppose that one could demonstrate somehow that people were flying more
accurately with GPS guidance. Then to conclude that the risk of collision
was higher, one would have to show that the protocols (a)-(c) above were not
in general being followed. Since (a) and (b) are enshrined in aviation
regulations, and (c) in good practice/pilot lore, I doubt this would be easy
to demonstrate.

One other way to show that the risk of midair collisions had increased would
be to show that there had been more midair collisions since GPS use became
prevalent, and that this was not just a statistical fluctuation.  Well, I
don't know for sure, but I don't think there have been more.  Even if there
had, the cause of the phenomenon would have to be determined, and for the
above reasons it would be very hard to show that it was due to
suddenly-increased accuracy of flying of VFR pilots.

So much for airways. On to other possibilities. Perhaps Wood was thinking of
pilots wanting to fly to point X and lots of them all getting exactly to
point X. If point X are the published GPS coordinates of an airport, there
exist procedures to follow well before one gets to point X, which have been
designed to alleviate the possibility of midairs in the neighborhood of an
airport. One would have to imagine that somehow pilots are ignoring these
procedures because they have a GPS, and I don't see how one could show any
such thing. If point X is some specific sightseeing point, then I grant that
there may be an increased need for vigilance since now one can navigate
precisely to X. However, I don't know what the proportion of such flights
would be, and I doubt that they are representative of most flights (It would
seem appropriate to reiterate the usual warnings to pilots about increased
traffic density in the vicinity of sightseeing attractions.)

Finally, I should note the article in Risk Analysis 17(2):237-248, 1997, by
Robert Patlovany entitled U.S. Aviation Regulations Increase Probability of
Midair Collisions, brought to my attention by Hal Lewis (who, by the way,
has written a fine, fine book on making decisions called Why Flip a Coin?,
New York: John Wiley & Sons, 1997, which I found very entertaining as well
as enlightening and have promised for two years to review for Risks, but
haven't yet. Hal's got a great writing style. Read it. So there). Patlovany
uses "a purely stochastic Monte Carlo model [..] to compare the relative
midair collision course probabilities and mean closing velocities of four
systems of rules for aircraft cruising altitudes as a function of altitude
error: (1) current U.S. federal rules, (2) random altitudes, and (3)
[etc...] The calculations verify that (1) federal rules increase collision
course probabilities by about four times more than for a chaotic system of
aircraft cruising at randomly selected altitudes, (2) risk is directly
proportional to the level of compliance, and (3) [etc]."

Note that Patlovany is considering cruising flight only, and altitudes, that
is, vertical displacement, not the horizontal displacement which I take to
be the relevant factor for evaluating Wood's GPS vs. VOR contention.

Prof. Peter Ladkin Ph.D., Univ. Bielefeld, Technische Fakultaet, D-33501
Bielefeld (Germany) http://www.rvs.uni-bielefeld.de +49 (0)521 106-5326/5325

GPS kills 8 in air

 [...] The probability of a collision between aircraft using GPS on
 established air routes is significantly higher than between aircraft
 using conventional navigation aids because of the greater accuracy of
 navigation using a GPS.

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

  [Quite old, but not previously covered.  PGN]

Y2K Test Knocks Out Fiji's Telecommunications

Fiji's telecommunications services were completely shut down for several
hours on 24 May 1999 when a Y2K test by Telecom Fiji Ltd. caused the entire
system to crash.  [See http://www.tfl.com.fj/.  Source: Yahoo Asia News -
Technology, Newsbytes item by Adam Creed, Post-Newsweek Business
Information, Inc., 24 May 1999: PGN-ed.]

Y2K testing on weather images

There's a site at Nottingham U., UK, where weather satellite images are
received from a geostationary satellite (Meteosat), timestamped and prepared
in several different formats.  (ftp.ccc.nottingham.ac.uk)

I download some images regularly off this site a few time a day.  One
morning last week, several images were missing; the next image available,
was timestamped "FEB 28 2000, 2330" (though it seemed to be a current one).
The next one was timestamped "FEB 28 2000, 2400".  Oh well, back to the
debuggers...  (the rest of the images on that day had their correct
timestamps).

Amos Shapir, nSOF Parallel Software, Ltd.,Givat-Hashlosha 48800, Israel
Tel: +972 3 9388551   Fax: +972 3 9388552

  [Perhaps they were running a Y2K leap-year experiment.  PGN]

Y1.9K

  [From Mark after forwarding to him from David M. Sherman.  PGN]

> J.J. McVeigh wrote:
> >
> > ]]]]]] EMPEROR HIROHITO'S DEATH CAUSES SOFTWARE PROBLEMS [[[[[[
> > (1/18/1989)
> > [From Pavan Sahgal, ``Automation at the "Big Four" Securities
> > Firms'', Wall Street Computer Review, January 1989, p. 23]
> >
> > [Kindly uploaded by Freeman 10602PANC]
> >
> > Under Japanese custom, when a new emperor is crowned, his
> > reign or era is marked by a title that appears on all records in
> > the country. [Hirohito's era was called Showa, or peace.]
> > [E]xecutives at Tokyo's leading securities firms were
> > chagrined to discover that the computer programmers who wrote
> > accounting, recordkeeping and customer billing systems software
> > in recent years created inflexible systems. They did not
> > envisage that someday Japan would have a new emperor, and his
> > reign would mark the start of a new era requiring records and
> > statements to reflect that.
> > The dilemma is comparable to having a system that won't change
> > from 1988 to 1989. The programmers had overlooked an essential
> > detail that obviously has widespread fundamental implications.
> > Even worse, a new generation was sadly out of touch with custom
> > and the saying, Koin ya no-goto she [acute accent over e] (A
> > lifetime goes like an arrow).
> >
> > * * *
> > http://www.powerup.com.au/~dominion/ff/k14.htm
>
> David M. Sherman, LLB, LLM, Tax Author & Consultant
> ds@davidsherman.ca  http://www.davidsherman.ca

Nuclear plant Y2K: High risk-readiness or high-risk readiness?

I read this last week on Silicon.com's news site (http://www.silicon.com):

  A US nuclear plant has received a warning from the Nuclear Regulatory
  Commission (NCR) after fears were raised over the Y2K readiness of an
  emergency backup generator.  Massachusetts Congressman, Edward Markey,
  said the NRC has written to the Pilgrim nuclear plant expressing concern
  that the generator will not be able to keep the facility safe in the event
  of a Y2K blackout.  The plant's owner said the problem will be solved by
  adjusting the temperature limit for the generator.

Well, that's alright then, I don't suppose that the temperature limiter
serves any valid safety purpose, nor that running it outside the limits
prescribed by the manufacturers carries any RISKs....

Mike Perry  Data General Ltd

REVIEW: "The Y2K Survival Guide", Bruce F. Webster

BKY2KSUG.RVW   990319

"The Y2K Survival Guide", Bruce F. Webster, 1999, 0-13-021496-5,
U$19.99/C$28.95
%A   Bruce F. Webster bwebster@bfwa.com
%C   One Lake St., Upper Saddle River, NJ   07458
%D   1999
%G   0-13-021496-5
%I   Prentice Hall
%O   U$19.99/C$28.95 +1-201-236-7139 fax: +1-201-236-7131
%P   544 p.
%T   "The Y2K Survival Guide"

    "Don't buy guns, cash all your stocks, withdraw your savings,
    and move to South Dakota unless you already had a good reason
    for doing so, and maybe not even then.  It's really cold in
    South Dakota, and the last place you probably want to be is
    out in the countryside with a lot of other folks armed with
    guns and waiting for Armageddon."

While those from South Dakota may bristle a bit at the impugning of
their home state, the rest of us may be glad of a little sanity in the
year 2000 debate.  (On the other hand, maybe the population of South
Dakota will be just as glad that someone is telling the nuts to stay
home while Ed Yourdon [cf. BKTMBM2K.RVW] is yelling that we're all
gonna die.  This is, in fact, the book that Yourdon could have
written, were he not so busy trying to make application to the
Charlton Heston fan club.)  (Also, since Webster's roots go 'way back
in South Dakota, they'll probably forgive him.)  Webster does not so
much occupy the middle ground as look at the entire spectrum of
reactions to the situation, and tries to remain rational throughout.
Whoever did the cover design caught the tone perfectly: an ostrich
with its head in the sand in the foreground, and a mushroom cloud in
the background.  And an awful lot of territory in between.

Part one looks at how we got here.  Chapter one starts with an
overview of the problem and its cause.  Unfortunately, while there are
some very good points (such as the statement that it is a century,
rather than millennial, problem) the basic explanation is somewhat
confused, and doesn't rise above the generally available material on
the topic.  Whatever faults chapter one may have, though, are more
than made up for in chapter two, which gives a clear and almost
lyrical description of why the problem happened.  Starting with
limited hardware, continuing through software bloat, and ending with
the seven deadly sins, the lessons are clear and unflinching.  (I can
even forgive the mention of the scandal du jour, given the deft manner
of its inclusion.)  A number of the myriad barriers to getting the job
done are examined in chapter three.  Chapter four reviews a number of
myths in regard to Y2K.

Part two looks at preparation in this last year before the deadline.
This section is full of suggested actions you can take, to a greater
or lesser extent, to get ready.  Chapter five looks at laying a
foundation: how to plan what to protect.  This may seem facile, but it
has a real purpose.  If you can't do everything, and you probably
can't, make sure you do what is most important.  To you.  Where other
books may have a bibliography, chapter six lays out some guidelines
for actually getting yourself educated for what might come.  The
discussion of health ranges from the possible failure of Medicare to
starting a fitness program (so as to generally improve your health and
avoid the possibility of hospitalization), in chapter seven.  Chapter
eight reviews planning for home needs.  Food concerns, in chapter
nine, tend to be weighted towards flour, dried foods, and other items
that need preparation (and therefore, in most people's minds,
electricity and water) but the exercise and some pointers are quite
helpful.  The "career" plan in chapter ten is probably appropriate to
any situation, quite apart from the possibility of a recession, and
the financial planning in chapter eleven is pretty sound.  Building a
community and support network is possibly the most important thing you
can do to prepare, and is hardly ever mentioned apart from this book's
chapter twelve.

Part three is again preparation, but more of a mental type.  Chapter
thirteen looks at the value (and danger) of trying to see what's
ahead.  A variety of scenarios, ranging in severity, are presented in
chapter fourteen.

Part four talks about getting on with life after Y2K, and whatever it
brings.  Chapter fifteen suggests taking stock and making an
assessment.  The lessons we should learn from the year 2000 fiasco are
reviewed in chapter sixteen.

Two of the appendices are from work the author did with the
Washington, DC Year 2000 Group.  Appendix A contains testimony
presented to Congress, and Appendix B gives the results of two surveys
of the group members.  Appendix C has a very useful set of resources
for further study, heavily weighted to Internet sites.

Like the more sensationally named "Time Bomb 2000" (cf. BKTMBM2K.RVW),
this book is aimed at the general population.  It does a much better
job of presenting the reality, and, at the same time, suggesting
useful ways to address the issue.

I think it's appropriate to close with another quote from the book,
this one only a few sentences after the one that opened this review:

    "Focus on solving as many problems as you can in your own
    circle of influence, starting with your own life and family,
    but including your community.  Build social cohesion.  Do the
    same sensible personal preparation ..."

copyright Robert M. Slade, 1999   BKY2KSUG.RVW   990319
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

REVIEW: "Y2K Risk Management", Goldberg/Davis/Pegalis

BKY2KRSM.RVW   990312

"Y2K Risk Management", Steven H. Goldberg/Steven C. Davis/Andrew M.
Pegalis, 1999, 0-471-33352-2, U$39.99/C$62.50
%A   Steven H. Goldberg www.dr2000.com
%A   Steven C. Davis www.davislogic.com
%A   Andrew M. Pegalis www.consult2000.com
%C   5353 Dundas Street West, 4th Floor, Etobicoke, ON   M9B 6H8
%D   1999
%G   0-471-33352-2
%I   John Wiley & Sons, Inc.
%O   U$39.99/C$62.50 416-236-4433 fax: 416-236-4448 rlangloi@wiley.com
%P   312 p.
%T   "Y2K Risk Management"

Bit late in the day for a Y2K book, wouldn't you say?  Well, as the authors
point out, some action is better than none.  And, as they also point out,
this marks your last chance to take a look at what you are doing, and make
sure you are getting the greatest benefit for your time and effort.

Chapter one is the fairly obligatory "sell or scare" piece.  While similar
to others of the same ilk, it does stress the importance of interconnected
and interoperating systems, as well as emphasizing the business and legal
risks.  On the other hand, it doesn't do a very good job of presenting the
background and technical aspects, for example discussing different types of
computers rather than various data structures or date usage.  In the same
way as many essays on building a Y2K team, chapter two looks at starting a
risk management project directed at Y2K.  The concepts are presented
reasonably, but the details aren't terribly useful.  Starting a project, and
getting it up to speed as quickly as possible, is covered in chapter three.
Unfortunately, the advice consists, as usual, of "get the right people, have
the right plan, do the right things," with the particulars left as an
exercise to the reader.  Chapter four, on legal aspects, is lengthy and
detailed, usually explains the concepts well, occasionally slips into
legalese, sticks primarily to common law, but does sometimes lapse into the
US-centric black hole.  Dealing with suppliers and providers is handled much
better than in most books in chapter five.  One issue hinted at, but not
adequately covered, is the possibility of a single point of failure removed
one or more layers of suppliers from you, such as having multiple grocery
suppliers--all of whose delivery fleets obtain fuel from the same source.

Chapter six, as did chapter three, gives the usual "do the right thing"
counsel for contingency planning.  Large corporate decisions and Y2K are
reviewed in chapter seven, but not really tied together.  "Due diligence"
was a large factor in chapter four: chapter eight looks at proving your
prudence.  Insurance issues are definitely not made clear by chapter nine.
Chapter ten's overview of "alternative dispute resolution" (ADR: for pity's
sake, *everything* has a TLA [Three Letter Acronym]!) will probably have
value for many, although personally I found it rather obvious.  Preparing
for litigation, in chapter eleven, has a lot of very useful background,
although much of it seems to assume you will be the suer instead of the
suee.  Post Y2K planning is brief, but touches on a number of important, and
often unregarded, issues in chapter twelve.

Risk management is not really handled all that well in this book.  A number
of risks are identified, but the control of those hazards is left vague.  On
the other hand, a number of topics dealt with here get short shrift in other
year 2000 guides.  Overall, while I couldn't recommend it as the only
reference for those just starting out, I would say that, for those seriously
into Y2K planning, the book should handily repay the price and time spent on
it.

copyright Robert M. Slade, 1999   BKY2KRSM.RVW   990312
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Calendar problem with old Calvin and Hobbes comics strips

The "Calvin and Hobbes" comic strip web site has a calendar problem!

Universal Press Syndicate is re-running old C&H comic strips.  Each day they
run the strip from that date 11 years ago.

Another example of calendar problems in general, and a pre-Y2K Y2K problem!

The note on the C&H web pages:

  Calvin is back! Each day we are reissuing an original Calvin and Hobbes
  strip, 11 years after it was first published. Start your adventure with
  the first Calvin and Hobbes Strip, published November 18, 1985. Please
  note: 1988 was a leap year, therefore, Sunday comics will appear on
  Saturday through February 2000.

http://www.calvinandhobbes.com/strips/88/04/ch880417.html
  [change date to wherever you want to start. ^^^^^^
  But the 2-digit year field is not a problem here!  PGN]

Outlook '98 not Y4.501K Compatible

Not only does Outlook reschedule holidays (as mentioned in a previous
risks), it also brings the old problem of how to identify data as null.
While in the past 9/9/99 might have been used to identify a 'null' date
(making that date one of our famous y2k warning dates - now we have a new
problem.  In Outlook '98, the default date value is 1/1/4501 8:00 AM.
Obviously Microsoft has not learned he lesson.  While it is not likely that
anyone will be using Outlook '98 in the year 4501, that is not the point.
This is documented in a several books, but no mention is made as to any
potential risks in using arbitrary dates as flags

So can I be the first to coin the Y4.501K Standard?

Eric Zago, Management Information Systems Major
Worcester Polytechnic Institute, Worcester, MA  zippy@wpi.edu

Leap year 2000 and C

I missed the following when it came up in comp.lang.c.moderated three
months ago, but I think it's worth repeating here.  In C, a time and
date represented by a single number (called a time_t) can be split into
components (year, month, day, hour, etc.) by either of a pair of library
functions, gmtime() and localtime(), which differ only as to the time
zone they use (if that information is available).

Two of the components have unusual representations, for convenience in
particular uses.  The month goes from January = 0 to December = 11, which
is handy for indexing an array of month names.  And the year is represented
with 1900 subtracted from it, a system which in pre-Y2K-conscious days
must have seemed as though it gave a convenient way of obtaining a
"printable form" of a year.  Note that it is does NOT simply reduce the
year to two digits: 1999 is 99, but 2000 is 100, not 0.

Okay, now the bug.  Dennis Ritchie posted this:
#  Until some months ago Plan 9 had an amusing bug: its gmtime routine
#  did not believe that 2000 was a leap year.  The code in the routine
#  had the correct test with 4, 100, 400 (we looked very hard at it).
#
#  It turns out that the "year number" being tested was year-1900,
#  not year!

And Peter Seebach added this follow-up:
|  Curiously, BSD/OS had exactly the same problem earlier this year.
|  It's probably going to pop up all over - because no one's Unix-like
|  implementations were adequately tested in 1900, when they would
|  have incorrectly identified the year as a leap year.

Since all C implementations since the standard came out are required
to include gmtime() and localtime(), they could also be subject to the
same bug, whether on UNIX or not.  Note that such a bug could affect
dates for some considerable time after 2000-02-29 itself, depending
on exactly how the functions are implemented.

Of course, if the implementation got it right, this is a non-issue.
But we see above that there are two that didn't...

Mark Brader, Toronto  msbrader@interlog.com

Y10K: not just for April Fools

So maybe I'm an April Fool, but it seems to me that the Y10K issue is worth
a little serious thought.

There are areas of human endeavor in which 8000 years is not an extreme time
span. At present, we deal with these long time spans only in modeling things
like geological and cosmological events. But it is not unreasonable that
within the next century, we may begin to build very high technology systems
with mission durations of thousands of years - for example, a system to
contain radioactive wastes, or a probe to another star system.

Y2K issues have raised our consciousness about timer overflows, but it's
quite possible that this may fade in succeeding generations. There's no
reason not to start setting standards now.

     Perhaps all time counters should be bignums?

== Tom Swiss/tms@infamous.net == http://www.infamous.net

GPS setup error affects dredging in California

The 22 Feb 1999 "Engineering News Record" in an item titled "Dredge
spoil misplaced due to alleged GPS programming error" reports that 600,000
cubic yards of dredged spoil were dumped almost half a mile from an approved
site, off the coast of Orange County, California, due to an error in keying
in co-ordinates into a GPS receiver.

A new GPS unit had been installed on a tug, and apparently the operator
keyed in the co-ordinates in base 60 ( degrees, minutes, seconds) instead of
in base 100 ( degrees, minutes, decimal fraction of a minute) that the new
GPS used.  The error was detected when the crew of the tug noticed another
tug and barge dumping spoil in the approved site.

Misinterpretation of the display units of measurement is a fairly common
problem in user interface design and is probably responsible for no end of
wasted paper, misprogrammed VCRs, and in at least one case ( the 767 "Gimli
Glider" incident) a serious threat to air safety.

W. T. Shymanski <wts@ieee.org>

Re: Apple Y2K (Stringer-Calvert, RISKS-20.28)

>                 "We may not get everything right,
>        but at least we knew the century was going to end."
>    -- Apple Computer, HAL 9000 ad for Macintosh Y2K compliance

To the best of my knowledge, that wasn't used in the Apple's Superbowl
commercial (the commercial is available online for download, but i feel
lazy). On the other hand, the same quote had been circulating, attributed to
Douglas Adams, for at least half a year.

A quick check with a search engine didn't turn up the original context of
the quote, but did find Apple's citing Adams on their own website:
http://www.apple.com/about/year2000/ -- as an introduction to their own Y2K
compliance statement.

Incidentally, Apple's statement that currently-supported hardware and
software are Y2K compatible allows them to make preemptive decisions to
discontinue support for any products they may decide are better dropped than
revised. While they're hardly the only company to do this, they might at
least provide documentation of what has been discontinued and recommend
upgrade paths, to keep their customers from guessing at what they need.

As has already been observed, even if a supported system, as shipped, will
be Y2K-compatible, third-party software may not be. Users may not be willing
to spend money and time and effort replacing working software with other
working software that provides no apparent outward improvements. I have
doubts that the average computer-using consumer has a clear understanding of
the distinctions between disparate applications, utilities, and system
functions, particularly in our current era of 'seamlessly' integrated
software, and will blame all problems at whichever company seems to have
their name most prominently displayed on the package.  The confusion is
probably better left as a subject for another thread.

ajd@boutell.com

  [Also noted by  DeRobertis <derobert@erols.com>.  PGN]

Professor wants Y2K jokes banned on the Net

Insisting that "there's nothing funny about things that aren't funny,"
Professor Wiley T. Langweile of the Palo Alto (CA.)-based Institute of
Internet Reevaluation has written a searing letter to *The New York Times*
(1 Apr 1999) protesting that the American media are so bored with the Year
2000 problem that they're mentioning it only once in every 94.5 sentences
(by the professor's own hand-count).  "Journalists are just not giving
enough publicity to this impending crisis.  They're either ignoring the
problem entirely or making fun of it.  Either way, they're acting
unconscionably.  Y2K irreverence needs to be banned, especially on the
Internet."  Dr. Langweile further charged in his letter that most reporters
fail to include in their stories a detailed explanation of just what exactly
the Y2K problem actually is and what it means to everyday people.  "The low
level of media competence on this issue is just tragic.  Of course, there's
Edupage.  That's the big exception.  Those Gehl and Douglas people really
know how to get to the point of a story, without wasting words.  They're the
only ones I can think of who've successfully explained Y2K in terms of the
big hand and the little hand.  I say God bless them."  (Edupage, 1 Apr 1999)

  [Note to nonGermanophiles: "Langweile" relates to
  Boredom, not Coyotes.  Definitely not the case here.  PGN]

Y2K: Help for the Weary Programmer

While reading several articles on the Y2K problem in the 1 April 1999 issue
of RISKS-20-26, I noticed that none addressed the actual problem facing
working programmers: there isn't enough time to finish the job before
December 31.  As we all know from The Mythical Man Month, we can't add more
people to the project: the project will just take longer. What we need is
another month.

I propose Caligua. To honor Roman tradition, this would be added after
August.  This extra month should give us enough time to fix -- and test --
our changes.  While it will cause minor disruption to calendar makers and
astronomers, they, along with all other citizens, will reap the rewards when
the airplanes keep flying on 1 Jan 2000.

And, if we need more time, we can always declare a Saturnalia.

Martin Minow, minow@pobox.com

  [Martin drives a Saturnalias for Caligula.  PGN]

Y2K alert!

--- Forwarded mail from a colleague at Disney ---
FINALLY! A Programmers Drinking Song! Woo! Hoo!

  PROGRAMMERS DRINKING SONG:

  99 little bugs in the code,
  99 bugs in the code,
  fix one bug, compile it again,
  101 little bugs in the code.
  101 little bugs in the code.....
    (Repeat until BUGS = 0)

  [I think it's appropriate, given the rash of "buggy" animations these days.
  Rebecca.]  [It's nice that Y2K is also brewing lyrics.  PGN]

RFC2550 - Y10K and Beyond

Despite all of the hooplah about Y2K, computer programmers and protocol
designers have not really learned from Y2K.  Just because a problem seems
far off, it should NOT be ignored.  30 years ago, the year 2000 seemed
unimaginably far off and many protocols and programs were not designed
to deal with it.  Now, we see a similar problem on the horizon and we
fear that most computer professionals are again looking the other way.

Starting with the year 10,000, years will have 5 digits.  At least 16
RFCs and one ISO standard specify 4-digit years and countless programs
(including those fixed for Y2K) rely on 4-digit years.  Given civilization's
projected dependence on computers in 8,000 years, the potential for disaster
is nearly unlimited.  Given the possibility that code and protocols developed
today will still be running, we must begin dealing with the Y10K problem
immediately.

We have developed a proposal to solve the Y10K problem and released it
to focus attention on this looming catastrophe.  It is available today
and can be found in any RFC repository.  Its number is RFC2550 and is
titled "Y10K and Beyond".  We strongly encourage all subscribers to the
Risks Digest to read it and heed its message.

Steve Glassman

  [Among other places, this is in the official RFC repository at
  ftp://ftp.isi.edu/in-notes/rfc2550.txt .  PGN]

- = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - =

Network Working Group                                      S. Glassman
Request for Comments: 2550                                  M. Manasse
Category: Stinkards Track                                     J. Mogul
                                           Compaq Computer Corporation
                                                          1 April 1999

                            Y10K and Beyond

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   As we approach the end of the millennium, much attention has been
   paid to the so-called "Y2K" problem.  Nearly everyone now regrets the
   short-sightedness of the programmers of yore who wrote programs
   designed to fail in the year 2000.  Unfortunately, the current fixes
   for Y2K lead inevitably to a crisis in the year 10,000 when the
   programs are again designed to fail.

   This specification provides a solution to the "Y10K" problem which
   has also been called the "YAK" problem (hex) and the "YXK" problem
   (Roman numerals).

1. Introduction, Discussion, and Related Work

   Many programs and standards contain, manipulate and maintain dates.
   Comparing and sorting dates is a common activity.  Many different
   formats and standards for dates have been developed and all have been
   found wanting.

   Early date formats reserved only two digits to represent the year
   portion of a date.  Programs that use this format make mistakes when
   dealing with dates after the year 2000.  This is the so-called Y2K
   problem.

   The most common fix for the Y2K problem has been to switch to 4-digit
   years.  This fix covers roughly the next 8,000 years (until the year
   9999) by which time, everyone seems convinced that all current
   programs will have been retired.  This is exactly the faulty logic
   and lazy programming practice that led to the current Y2K problem!
   Programmers and designers always assume that their code will
   eventually disappear, but history suggests that code and programs are
   often used well past their intended circumstances.

   The 4-digit year leads directly to programs that will fail in the
   year 10,000.  This proposal addresses the Y10K problem in a general
   way that covers the full range of date and time format issues.

1.1 Current approaches

   A large number of approaches exist for formatting dates and times.
   All of them have limitations.  The 2-digit year runs into trouble
   next year.  The 4-digit year hits the wall in the year 10,000.  A
   16-bit year runs out in the year 65,536.  A 32-bit counter for the
   number of seconds since 1970 [UNIX] wraps in 2038.  A 32-bit counter
   for the number of milli-seconds since booting crashes a Windows (TM)
   PC in 49.7 days [Microsoft].

   In this specification, we focus on the Y10K problems since they are
   most common and a large number of existing standards and protocols
   are susceptible to them (section 7).  These standards, and new
   proposals on their way, will lead to a serious world-wide problem
   unless efforts are made now to correct the computing, government, and
   business communities.

   Already, a small cottage industry is popping up to deal with the Y10K
   problem [YUCK].  We encourage these efforts and, in the coming years,
   this effort can only grow in size and importance.

1.2 A Fixed Format Y10K Fix

   At the time of this writing, only one proposal [Wilborne] directly
   deals with the Y10K problem.  In that proposal, dates are represented
   as decimal numbers with the dates compared numerically.  The proposed
   format is simply YYYYYMMDD - i.e. 5-digit years.

   To allow numerical comparison of dates, this representation requires
   a completely fixed representation for the date.  There can be no
   optional fields, the date resolution is limited to the granularity of
   one day, and this solution fails in the year 100,000 (Y100K).

1.2.2 Limitations of Numerical Comparison

   While sufficient for the specific Y10K problem, this solution is
   limited.  Even if extended for 6-digit years, it fails on 32-bit
   systems (and future 32-bit system emulators) after the date
   represented by the number 2147481231 (December 31, 214748) leading to
   a Y214749 problem.  Similarly, 64-bit and 128-bit systems also will
   fail, although somewhat later (after December 31, 922,337,203,685,477
   and December 31, 17,014,118,346,046,923,173,168,730,371,588,410
   respectively).

1.2.3 Granularity Issues

   The granularity problems of a fixed format date can be improved by
   extending the date format to include greater precision in the date.
   However, since numerical comparison of dates requires a fixed
   representation date, an extended format can not provide sufficient
   resolution for all foreseeable needs.

   For instance, if the precision were extended to the femto-second
   range the date format would become YYYYYMMDDHHMMSSmmmuuunnnpppfff
   (year, month, day, hour, minute, second, milli-second, micro-second,
   nano-second, pico-second, and femto-second).  The additional 21
   digits of this format limit the set of representable dates.  Compared
   to 1.2.2, the 32-bit and 64-bit forms of the date are instantly
   exceeded, while the 128-bit version would be viable - expiring on
   December 31, 17,014,118,346,046.

1.2.3.1 Extrapolation of Future Granularity Issues

   However, a simple extrapolation of Moore's law shows that even
   femto-second resolution will soon be inadequate.  Projecting current
   CPU clock speeds forward, a femto-second clock speed will be achieved
   in only 30 years.  And, by the year 10,000 the projected clock speed
   of the Intel Pentium MMDCLXVI (TM) will be approximately 10 ** (-
   1609) seconds.

   This discussion clearly shows that any fixed-format, integer
   representation of a date is likely to be insufficiently precise for
   future uses.

1.2.3.2 Floating Point Is No Solution

   The temptation to use floating point numbers to represent dates
   should be avoided.  Like the longer fixed-format, integer
   representations of the date, floating point representations merely
   delay the inevitable time when their range is exceeded.  In addition,
   the well known problems of real numbers - rounding, de-normalization,
   non-uniform distribution, etc. - just add to the problems of dealing
   with dates.

2 Structure of Y10K Solution

   Any Y10K solution should have the following characteristics.

2.1 Compatibility

   The format must be compatible with existing 4-digit date formats.
   Y2K compliant programs and standards must continue to work with Y10K
   dates before the year 10,000.  Y10K compliant programs can gradually
   be developed over time and coexist with non-Y10K compliant programs.

2.2 Simplicity and Efficiency

   Y10K dates must allow dates after 10,000 to be easily identified.
   Within a program, there must be a simple procedure for recognizing
   the Y10K dates and distinguishing them from legacy dates.

2.3 Lexical Sorting

   Y10K dates must be sortable lexically based on their ASCII
   representation.  The dates must not require specialized libraries or
   procedures.

2.4 Future Extensibility

   Y10K dates must support arbitrary precision dates, and should support
   dates extending arbitrarily far into the future and past.  Y10K dates
   from different eras and with different precisions must be directly
   comparable and sortable.

2.4.1 Environmental Considerations

   The known universe has a finite past and future.  The current age of
   the universe is estimated in [Zebu] as between 10 ** 10 and 2 * 10 **
   10 years.  The death of the universe is estimated in [Nigel] to occur
   in 10 ** 11 - years and in [Drake] as occurring either in 10 ** 12
   years for a closed universe (the big crunch) or 10 ** 14 years for an
   open universe (the heat death of the universe).

   In any case, the prevailing belief is that the life of the universe
   (and thus the range of possible dates) is finite.

2.4.2 Transcending Environmental Considerations

   However, we might get lucky.  So, Y10K dates are able to represent
   any possible time without any limits to their range either in the
   past or future.

   Y10K compliant programs MAY choose to limit the range of dates they
   support to those consistent with the expected life of the universe.
   Y10K compliant systems MUST accept Y10K dates from 10 ** 12 years in
   the past to 10 ** 20 years into the future.  Y10K compliant systems
   SHOULD accept dates for at least 10 ** 29 years in the past and
   future.

3 Syntax Overview

   The syntax of Y10K dates consists of simple, printable ASCII
   characters.  The syntax and the characters are chosen to support a
   simple lexical sort order for dates represented in Y10K format.  All
   Y10K dates MUST conform to these rules.

   Every Y10K date MUST begin with a Y10K year.  Following the year,
   there MAY be an arbitrary sequence of digits.  The digits are
   interpreted as MMDDHHMMSSmmmuuunnnpppfff...  (month, day, hour,
   minute, second, milli-second, micro-second, nano-second pico-second,
   femto-second, etc. - moving left to right in the date, digits always
   decrease in significance).

   All dates and times MUST be relative to International Atomic Time
   (TAI) [NRAO].

   When comparing dates, a date precedes every other date for which it
   is a prefix.  So, the date "19990401000000" precedes the date
   "19990401000000000".  In particular, dates with the format YYYYMMDD
   are interpreted to represent the exact instant that the day begins
   and precede any other date contained in that day.

3.1 Years 1 - 9999

   The current 4-digit year syntax covers all years from 1000 - 9999.
   These years are represented as 4 decimal digits.  Leading 0's MUST be
   added to the years before 1000 to bring the year to 4 digits.  Files
   containing legacy pre-Y1K [Mike] dates will have to be converted.

3.2 Years 10,000 through 99,999

   Four digits are not sufficient to represent dates beyond the year
   9999.  So, all years from 10,000 - 99,999 are represented by 5 digits
   preceded by the letter 'A'.  So, 10,000 becomes "A10000" and 99,999
   dates with 5-digit years will follow all dates with 4-digit years
   (for example, "A10000" will sort after "9999").  This gives us the
   sort and comparison behaviour we want.

3.3 Years 100,000 up to 10 ** 30

   By a simple generalization of 3.2, 6-digit years are preceded by the
   letter 'B', 7-digit years by 'C', etc.  Using just the 26 upper-case
   ASCII characters, we can cover all years up to 10**30 (the last year
   representable is "Z999999999999999999999999999999").  Again, since
   the ASCII characters are sorted alphabetically, all dates sort
   appropriately.

3.4 Years 10 ** 30 and beyond (Y10**30)

   As discussed in 2.4.1, the end of the universe is predicted to occur
   well before the year 10 ** 30.  However, if there is one single
   lesson to be learned from the current Y2K problems, it is that
   specifications and conventions have a way of out living their
   expected environment.  Therefore we feel it is imperative to
   completely solve the date representation problem once and for all.

3.4.1 Naive Approach for Y10**30 Problem

   The naive solution is to prepend a single '^' (caret) - caret sorts
   after all letters in the ASCII order) before all years from 10 ** 30
   to 10 ** 56.  Thus the year "Z999999999999999999999999999999" is
   followed by the year "^A1000000000000000000000000000000".  Similarly,
   all years from 10 ** 56 to 10 ** 82 get one more caret.  So, the year
   "^Z99999999999999999999999999999999999999999999999999999999" is
   followed by the year
   "^^A100000000000000000000000000000000000000000000000000000000".  This
   scheme can be extended indefinitely by prepending one addition caret
   for each additional factor of 10 ** 26 in the range of the year.

   In this approach, the number of digits in a date that are used to
   represent the year is simply:

      26 * <number of '^'> + ASCII(<prefix letter>) - ASCII('A') + 5

   Note: this algorithm is provided for informational purposes only and
   to show the path leading to the true solution.  Y10K dates MUST NOT
   use this format.  They MUST use the format in the next section.

3.4.2 Space Efficient Approach for Y10**30 Problem

   The solution in 3.4.1 is not a space efficient format for giving the
   number of digits in the year.  The length of the prefix grows
   linearly in the length of the year (which, itself, grows
   logarithmically over time).  Therefore, Y10K format dates use an
   improved, more compact encoding of the number of digits in the year.

3.4.2.1 Years 10 ** 30 to 10 ** 56

   As in 3.4.1, a single '^' and letter precede the year.

3.4.2.2 Years 10 ** 56 to 10 ** 732

   The year is preceded by two carets ("^^") and two letters.  The
   letters create a two digit, base 26 number which is the number of
   digits in the year minus 57.  So, the year
   "^Z99999999999999999999999999999999999999999999999999999999" is
   followed by the year
   "^^AA100000000000000000000000000000000000000000000000000000000".  The
   last representable year with two carets is the year (10 ** 732) - 1
   and is "^^ZZ999..999" (i.e. two carets and two Z's, followed by 732
   consecutive 9's).

   The formula for the number of digits in the year is, based on the two
   digit prefix is:

    26 * (ASCII(<prefix letter1>) - ASCII('A')) +
          ASCII(<prefix letter2>) - ASCII('A') + 57

3.4.2.3 Years 10 ** 732 to 10 ** 18308

   The next block of years has the number of digits given by three
   carets ("^^^") followed by three letters forming a three-digit, base
   26 number.  The number of digits in the year is given by the formula:

    676 * (ASCII(<prefix letter1>) - ASCII('A')) +
     26 * (ASCII(<prefix letter2>) - ASCII('A')) +
           ASCII(<prefix letter3>) - ASCII('A') + 733

3.4.2.4 General Format for Y10K Dates

   In general, if there is at least one letter in a Y10K year, the
   number of the digits in the year portion of the date is given by the
   formula:

       base26(fib(n) letters) + y10k(n)

   Where "n" is the number of leading carets and the fig, base26 and
   y10k functions are defined with the following recurrence relations:

      fib(n) is the standard Fibonacci sequence with:

      fib(0) = 1

      fib(1) = 1

      fib(n+2) = fib(n) + fib(n+1)

      base26(m letters) is the base 26 number represented by m letters
      A-Z:

      base26(letter) =  ASCII(<letter>) - ASCII('A')
      base26(string letter) = 26 * base26(string) + base26(letter)

      y10k(n) is the necessary fudge factor to align the sequences

      properly:

      y10k(0) = 5
      y10k(n+1) = 26 ** fib(n) + y10k(n)

   If the year does not have at least one letter in the year, then the
   number of digits in the year is:

       4

   This year format is space-efficient.  The length of the prefix giving
   number of digits in the year only grows logarithmically with the
   number of digits in the year.  And, the number of carets preceding
   the prefix only grows logarithmically with the number of digits in
   the prefix.

3.5 B.C.E. (Before Common Era) Years

   Now that have a format for all of the years in the future, we'll take
   on the "negative" years.  A negative year is represented in "Y10K-
   complement" form.  A Y10K-complement year is computed as follows:

    1) Calculate the non-negative Y10K year string as in 3.4.2.4.
    2) Replace all letters by their base 26 complement.  I.E. A -> Z, B
       -> Y, ... Z -> A.
    3) Replace all digits in the year portion of the date by their base
       10 complement.  I.E. 0 -> 9, 1 -> 8, ... 9 -> 0.
    4) Replace carets by exclamation points ('!').
    5) Four-digit years are pre-pended with a slash ('/')
    6) Years that don't now begin with an exclamation point or slash are
       pre-pended with a star ('*').  (This rule covers the negative 5-
       31 digit years).

   For example, the year 1 BCE is represented by "/9998".  The
   conversion is accomplished by applying rules:

    1) Calculate the non-negative Y10K year ("1" -> "0001")
    2) Complement the digits ("0001" -> "9998")
    3) Four-digit numbers get a leading slash.

   The earliest four-digit BCE year (9999 BCE) becomes "/0000" and the
   year before that (10000 BCE) becomes "*Z89999".  The earliest 5-digit
   BCE year (99999 BCE) is "*Z00000".  And the year before that (100000
   BCE) is "*Y899999".  And so on.

   These rules give the desired sort order for BCE dates.  For example,
   the following dates get translated and sorted as:
     Jun 6, 200 BCE            /97990606
     199 BCE                   /9800
     Jan 1, 199 BCE            /98000101

3.6 Restrictions on Y10K Dates

   There are no restrictions on legal values for Y10K dates.  Y10K
   compliant programs MUST accept any syntactically legal Y10K date as a
   valid date.  A '0' can be appended to the end of any Y10K date,
   yielding an equivalent date that sorts immediately after the original
   date and represents the instant after the original date.

   The following are all valid representations (in sorted order) of the
   first instant of A10000:

     A1
     A10000
     A1000001
     A100000101000000
     A1000001010000000000000000000000

   Similarly, the following are all valid Y10K dates (in sorted order)
   for the time after the last instant of the A99999 and before the
   first instant of B100000:

     A999991231250000
     A999991232
     A999992
     A9999999999
     A99999999990000000000000

4 ABNF

   The following ABNF [Crocker] gives the formal syntax for Y10K years.

   The initial characters definitions are given in their lexical
   collation (ASCII) order.

   exclamation = '!'
   star        = '*'
   slash       = '/'
   digit       =  0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
   letter      =  A | B | C | D | E | F | G | H | I | J | K | L | M |
                  N | O | P | Q | R | S | T | U | V | W | X | Y | Z
   caret       = '^'


   year     = [*(caret | exclamation) | star | slash ] [ *letter ]
             *digit
   month    = 2digit
   day      = 2digit
   hour     = 2digit
   minute   = 2digit
   second   = 2digit
   fraction = *digit
   date     = year [ month [ day [ hour [ minute [ second [ fraction
             ]]]]]]

5 Open Issues

   There are a number date comparison problems that are beyond the scope
   of this specification.

   1) Dates from different calendar systems can not be directly
      compared.  For instance, dates from the Aztec, Bhuddist, Jewish,
      Muslim, and Hittite calendars must be converted to a common
      calendar before comparisons are possible.

   2) Future re-numberings of years are not covered.  If, and when, a
      new "Year 0" occurs and comes into general use, old dates will
      have to be adjusted.

   3) Continued existence of Earth-centric time periods (year, day,
      etc.) are problematical past the up-coming destruction of the
      solar system (5-10 billion years or so).  The use of atomic-time
      helps some since leap seconds are no longer an issue.

   4) Future standards and methods of synchronization for inter-
      planetary and inter-galactic time have not been agreed to.

   5) Survivability of dates past the end of the universe is uncertain.

6 Affected Standards

   A number of standards currently and RFCs use 4-digit years and are
   affected by this proposal:

     rfc2459: Internet X.509 Public Key Infrastructure
              Certificate and CRL Profile
     rfc2326: Real Time Streaming Protocol (RTSP)
     rfc2311: ODETTE File Transfer Protocol
     rfc2280: Routing Policy Specification Language (RPSL)
     rfc2259: Simple Nomenclator Query Protocol (SNQP)
     rfc2244: ACAP -- Application Configuration Access Protocol
     rfc2167: Referral Whois (RWhois) Protocol V1.5
     rfc2065: Domain Name System Security Extensions
     rfc2060: Internet Message Access Protocol - Version 4rev1
     rfc1922: Chinese Character Encoding for Internet Messages
     rfc1912: Common DNS Operational and Configuration Errors
     rfc1903: Textual Conventions for Version 2 of the
              Simple Network Management Protocol (SNMPv2)
     rfc1521: MIME (Multipurpose Internet Mail Extensions) Part One:

     rfc1123: Requirements for Internet hosts - application and support

   The following standards internally represent years as 16-bit numbers
   (0..65536) and are affected by this proposal:

     rfc2021: Remote Network Monitoring Management Information Base
              Version 2 using SMIv2
     rfc1514: Host Resources MIB

   The following ISO standard is affected:
     ISO8601: International Date Format

8 Security Considerations

   Y10K dates will improve the security of all programs where they are
   used.  Many errors in programs have been tracked to overflow while
   parsing illegal input.  Programs allocating fixed size storage for
   dates will exhibit errors when presented with larger dates.  These
   errors can be exploited by wily hackers to compromise the security of
   systems running these programs.  Since Y10K dates are arbitrary
   length strings, there is no way to make them overflow.

   In addition, positive Y10K dates are easy to compare and less error-
   prone for humans.  It is easier to compare the three projected end of
   the universe dates - "H100000000000", "I1000000000000" and
   "K100000000000000" - by looking at the leading letter than by
   counting the 0's.  This will reduce inadvertent errors by people.
   This advantage will become more noticeable when large dates are more
   common.

   Unfortunately, negative Y10K dates are a bit more difficult to
   decipher.  However, by comparing the current age of the universe to
   its projected end, it is obvious that there will be many more
   positive dates than negative dates.  And, while the number of
   negative dates for human history is currently greater than the number
   of positive dates, the number of negative dates is fixed and the
   number of positive dates is unbounded.

9 Conclusion

   It is not too early to aggressively pursue solutions for the Y10K
   problem.  This specification presents a simple, elegant, and
   efficient solution to this problem.

10 References

   [Crocker]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 2234, November 1997.

   [Drake]     Review for the Drake Equation
               http://www.umsl.edu/~bwilking/assign/drake.html

   [Microsoft] SNMP SysUpTime Counter Resets After 49.7 Days
               http://support.microsoft.com/support/kb/articles/Q169/8/47.asp

   [Mike]      Y1K http://lonestar.texas.net/~mdlvas/y1k.htm

   [Nigel]     Nigel's (en)lighening tour of Thermodynamics for
               Economists ;-) http://www.santafe.edu/~nigel/thermo-
               primer.html

   [NRAO]      Astronomical Times
               http://sadira.gb.nrao.edu/~rfisher/Ephemerides/times.html

   [RFC]       Here are all the online RFCs. Note: this is a LONG menu.
               http://info.internet.isi.edu/1s/in-notes/rfc/files

   [UNIX]      Year 2000 Issues http://www.rdrop.com/users/caf/y2k.html

   [Wilborne]  PktCDateLig
               http://www3.gamewood.net/mew3/pilot/pocketc/pktcdate/index.html

   [YUCK]      Y10K Unlimited Consulting Knowledgebase
               http://www.loyd.net/y10k/index.html

   [Zebu]      The Search for H0
               http://zebu.uoregon.edu/1997/ph410/l6.html

11 Authors' Addresses

   Steve Glassman
   Compaq Systems Research Center
   130 Lytton Avenue
   Palo Alto, CA 94301 USA

   Phone: +1 650-853-2166
   EMail: steveg@pa.dec.com


   Mark Manasse
   Compaq Systems Research Center
   130 Lytton Avenue
   Palo Alto, CA 94301 USA

   Phone: +1 650-853-2221
   EMail: msm@pa.dec.com


   Jeff Mogul
   Compaq Western Resarch Lab
   250 University Avenue
   Palo Alto, CA 94301 USA

   Phone: +1 650-617-3300
   EMail: mogul@pa.dec.com

12.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The Y9Z Problem

In my extensive consulting work on the Y2K problem, a new problem has come
to my attention.  One thing all of my clients have in common is that we are
forbidden from touching the database format -- only the source code may be
modified.  Further, we use formal methods for proof of program correctness,
so any change we make actually costs more to verify than to develop the
change itself.

Because of these restrictions, all of my clients have opted to allow the
date field to roll over from 99 to 9A in the year 2000.  But this only buys
another 26 years of service.  What happens in the year 199Z (i.e. 2025 AD)?

Only one client (a company with a strong "do it right the first time"
corporate philosophy) has opted to follow my recommendation, which is that
the year 199Z be followed by the year 19A0.  This buys another 936 years, to
the year 19ZZ (i.e. 2961 AD).

Because of the verification requirement, this is more than twice as
expensive as the 26-year fix.  Rather than doubling the effort required for
the single digit, it's more like the effort squared to apply to two digits.

What year follows 19ZZ?  My recommendation is that the year 19ZZ be followed
by the year represented by "2000".  If we can't fix the problem by then, we
deserve the fate of extinction.  Hopefully, our bones will serve as a source
of calcium for whatever superior species comes along to replace us.

Mark Thorson (eee@netcom.com)

Yet another Y2K debacle

I found this in a respected journal of scientific neatstuff.

                Researchers Find Y2K Bug in Human Brain!
                       by Natalie N. Quirer

Researchers at the Yale Neurological Sciences Department announced today
that they have discovered a millennium bug implanted in the brains of human
beings.  "The brain is just a big computer, like any other," says Dr. Uri
Ignoramus of the Synaptic Research Lab.  "It has to keep track of times and
dates.  Like when you wake up just before your alarm clock or remember your
mother's birthday a day late.  Stuff like that."

According to researchers, when the clock strikes midnight in January 2000,
power outages and planes falling from the sky will be the least of our
worries.  Along with such mundane annoyances like frozen bank accounts and
nuclear detonations, add epileptic like seizures, an uncontrollable desire
to watch the Rosanne Show, and suddenly not being able to remember where
your keys are or why you are living in the same building with that ghastly
person.

"Billions of years of evolution," says noted Nobel laureate Albert
Bearstein.  "You'd think they could have anticipated this sort of thing.
Just how did they manage the year 0 rollover, anyway?"

In anticipation of the impending cranial apocalypse, experts insist that the
population stay calm.  "There is plenty of time for panic later."

In the meantime, stock up on St. John's wort......

Jon Loux, Data Administration, University of Connecticut

Vatican announces all computer systems ready for new millennium

Vatican announces all computer systems ready for new millennium

Rome, Washington, London and Delhi, 1 Apr (Routers) A spokesman for the IT
department of one of the world's smallest states, the Vatican City,
announced yesterday that all computer systems of the Roman Catholic church
world-wide were now ready for the next millennium.

Asked what solution had been used to combat the so-called "Y2K problem", he
said that the solution had been simple. "All we did was to revert to the
Roman numbering system. This makes the current year MCMXCIX. Next year will
be MM. Since this is shorter than the current representations there will not
be a storage problem. Also, since there is no zero in the Roman number
system nothing will reset."

The spokesman also pointed out that the absence of a zero also categorically
proved the new millennium would begin in MMI. He explained that the zero had
been introduced in MCCII by an Italian mathematician called Fibonacci. This
explained why there was no confusion at the start of the current millennium
in MI.

The church is now considering excommunicating Fibonacci for the confusion he
has caused.

Subsequently in Washington, a spokesman for US President Bill Clinton said,
"we think that it is harsh to pin the blame on one poor Italian. After all,
they are Arabic numbers. Clearly we must break all ties with the Arab world
until they hand over those responsible."

"In the past, the number zero was known as a cipher. Clearly this shows that
strong cryptography is harmful and the Government must retain control."

In a separate development, Prime Minister Vajpayee of India pointed out that
"actually, the number zero was invented in India in about 876AD. Clearly the
Arabs and the West have no concept of nothing. Only South Asians can really
understand what it means."

It is unclear whether he was trying to say that only the Indian software
industry could solve Y2K. It is thought that a case may be brought to WIPO
concerning the loss of intellectual property suffered by India for the last
DCCC years. Damages could run to billions of dollars.

Y10K opportunity

Date: 1 April 9990
> From: System Proving Office and Original Fault Finding, MacroHard Corporation
To: Bob Gates-Windows-Doors III, CEO MacroHard Corporation
Subject: Y10K

It would seem that a potentially serious fault exists which will affect all
known computer systems containing a date processor. This fault could have
catastrophic consequences on January 1, 10000. The origin of the fault has
been traced to a programming error which originated in the late years of the
20th century, when computing was in its infancy and had not developed into
the science which it is today.

It seems that before the historic splitting of the parent company of
MacroHard and Microsoft, as ruled by the US Supreme Court, that programmers
around the world all mistakenly wrote software using only 4 digits to
represent the year. Furthermore, this was then built into the hardware of
the time.

Huge amounts of effort were expended in the early days of computing
correcting an even earlier "bug" when only two digits had been used in some
systems to represent the year. Why at that time no-one had the foresight to
properly correct this error no-one can tell, although speculation rests with
some quasi-religious belief that the world would come to an end in the new
millennium, so they only had to get through to 2001.

This error has been built into all processing chips of the MacroHard
Corporation ever since its formation out of the remains of MS-OS, Intel and
AMI following the ruling of the Supreme Court. The effects of this error
could be disastrous. On January 1, 10000 all systems containing a MacroHard
chip will roll-over to 0000. Due to backward compatibility with MS-DOS this
will then be interpreted by the operating system as either January 1, 1980
or January 0, 1900.

Explanation: MS-DOS was the first operating system of the MS organisation
and originally did not recognise dates before 1980; when MS introduced its
Excel spreadsheet program, only dates after 1900 were recognised as valid
dates.

Other problems: Y10K is a leap year, so was 1980, but 1900 wasn’t,
therefore 29 February, 10000 may cease to exist on some
systems. Fortunately, MS foresaw this by including 29 February, 1900 as a
valid date in their MS-Excel package.

Note: a similar problem to this was overcome in 2099 by MacroHard, when all
processors would have reset themselves to 1980 on January 1, 2100. However,
at that time it was still considered adequate to use four digits to
represent the year.

MacroHard chips are now embedded in so many systems that control the day to
day lives of every citizen in the known universe that urgent action is
required. We recommend the establishment of a secret Y10K task force to
consider possible options and defence strategies to protect MacroHard
Corporation from the potential fallout.

Replacing every single MacroHard chip for free is clearly not an option, as
although this would be within the financial means of the company it is
against corporate policy. One possible solution, based on the previous
history of Microsoft with Y2K is to announce the potential problem, but pin
the blame on those who made bad decisions in the past for short-sighted
gain. We can then announce a new generation solution, which will be Y10K
compliant - possible name: System 10000. This solution can then be sold on
the open market. Anyone choosing not to upgrade could be held responsible
for the consequences, since we would have given them both adequate warning
of the impending disaster, and would have provided an alternative. If we fix
the price well in advance we should be able to turn this into a healthy
profit making opportunity.

At the moment we have almost 10 years to take advantage of this opportunity,
so it may still be too early to make an announcement. However, timing is
critical, since we don't want anyone else to realise this is going to happen
beforehand or they might try to pin the blame on us.

Y2K is the least of it

I just got off the phone with support line of the remaining Boston Bank (no
need to name it except for those who don't know about Fleet taking over
BankBoston). Their home banking does not work with Internet Explorer 5. This
would be understandable if they had tested and discovered a new problem with
the retail release or if Microsoft hadn't mentioned that a new release was
coming out.

But, in December, I had a long e-mail exchange when IE5 suddenly stopped
working with their service and the response was that they didn't support
unreleased browsers and weren't even curious about why it might have stopped
working.

Today I had two conversations with their support staff. During the first one
they basically said it was Microsoft's fault because they released a new
browser. I presume they'll blame the Pope for surprising them with the year
2000. They also made up excuses such as IE5 not having 128 bit security,
which was totally bogus.

Even if any of this were true, it is still the bank's fault since if were is
an IE5 problem, they should simply produce a message saying the browser is
not supported instead of simply going mute.

I then looked at the code. If I read it correctly, the progress messages are
completely bogus and are generated by a local timing loop purely to pacifier
the user.  More striking was that the body of the message looked like the
boiler plate for the web page. It seems as if the server explicitly checks
for the browser version and produces browser-specific HTML. For IE5, it
seems to fall through to the template code but there is no error checking. I
called back and spoke to a supervisor who accepted my analysis, but there
wasn't much he could do about it. At least, it reduced my hostility.

This is very disturbing since it is so trivial and obvious and, even more
so, something I had reported in December. Unlike the subtle bugs often
reported here, this is simply stupid and inexcusable. There doesn't seem to
be much connection between the support staff and the backroom. It is very
embarrassing since it is so visible and unnecessary. Even more so since the
IE4 support simply worked in IE5 and someone had to explicitly break the
support on (or about) December 28, 1998.

Sadly, this will soon be the last of the larger banks in Boston ... IE5
does work with BankBoston.

Bob Frankston  http://www.Frankston.com

Sri Lankan Banks to close on 31 Dec 1999 for Y2K tests

Central Bank has decided to close all banks to the public December 31 this
year to do the final assessment on all computer systems compliance to the
Year 2000 (Y2K) problem.  [Beginning of an item in *The Island*, 12 Mar
1999, noting that employees will be at work.  PGN-ed]

Risks:

1. December 31 appears to be a little late for final testing of Y2K
readiness. What if something isn't ready? Oh, well there'll still be the
weekend to fix it I suppose!

2. The contingency plan to close on December 30 as well would seem to be
superfluous. Will the decision to close then be made half way through
testing on 31st when they realise they don't have enough time?

3. Moving the deadline from March 31 to June 30 would also appear to be a
time waster. What will happen if some banks are still lagging behind in
June, will the deadline move again? Will it keep moving until it reaches
December 31? That's one deadline which won't move!

4. That some bankers were not even aware of the Y2K problem is beyond
belief. Which banks? I want my money out now!

5. The CEB is only testing power plants they suspect aren't compliant. What
about the rest?

6. [Power plant] Sapugaskanda was confirmed as compliant, but won't
work after 2001. How many other power plants around the world will fail on
January 1, 2002?

7. The operating system is too advanced for the local staff. What more can I
say?

Banks warn public about Y2K scam

Following up on the recent discussion of Y2K fraud, readers might find this
URL of some interest.

http://www.cba.ca/eng/Media_Centre/Press/990309-a.htm

It describes a telephone scam where the caller identifies himself as a bank
employee, and requests personal account information to help verify their Y2K
testing.

Elliot Silver, ALI Technologies Ltd., 95 - 10551 Shellbridge Way
Richmond, BC, CANADA V6X 2W9  604/279-5422 x376 elliot@alitech.com

Risks of testing a nuclear power plant for Y2K compliance

Pennsylvania's Peach Bottom Atomic Power Station was subjected to detailed
software analyses and simulations to check Y2K compliance, and concluded
that everything would be OK.  However, when the clock was moved ahead, the
primary and backup monitoring systems crashed, every computer screen blanked
out, and forced manual procedures.  The cause was attributed to a technician
improperly setting the test clock.  The systems remained down for seven
hours.  ``Although the cause was human error, technology specialists say the
glitch here illustrates an unanticipated peril of the Year 2000 problem: As
computer systems that have been repaired are now being tested in live
conditions, inadvertent mistakes and undiscovered bugs can bring the
machines -- and the organizations that rely on them -- to a grinding halt.''
[Source: Rajiv Chandrasekaran, Big Glitch at Nuclear Plant Shows Perils of
Y2K Tests, *The Washington Post* A03, 7 Mar 1999.  PGN-ed]

Outlook Express Date: parsing

Given that I typically sort my inbox based on Date Sent, with newer e-mail
at the top, it seemed odd to see messages showing up at the top of my list
with dates such as this:

Fri, Aug 1, 1919, 12:28 PM

Being curious, I took a look at the actual Date: line in the header:

Date: Sun, 4 Jan 2099 18:28:02 -0200

So, one obviously bogus date is somehow parsed to be in the future
(according to how it was sorted in the list), but is then displayed as
being 80 years old.

Sadly, this wasn't the only case I found.  I also had a piece of e-mail
with the following date header:

Date: 6/30/98 11:14:34 PM Pacific Daylight Time

Outlook Express displayed it as:

Mon, Jul 30, 2018, 3:14 AM

Interestingly, it displayed it *above* most of my other mail (which is dated
correctly from 1999), but *below* the bogus mail shown up above.

I suddenly have renewed faith in Microsoft's Y2K efforts.

-Ken

Bringing Y2K fears to a new high -- or low

From this week's *Infoworld*, in an article entitled 'Planning Beyond
Y2K Disruptions':

  "People act on fear a lot, and in fear there may be a
  financial impact.  We don't want people going and buying
  generators when they should be out buying jeans."
     -- Director of the Year-2000 project for Levi Strauss

While this does make some sense from a purely business perspective, that it
nonetheless is reaching anyone's radar screen makes me a lot more nervous
about people reacting to Y2K fears than I am about Y2K itself.

Michael P. Gerlek / mpg@flaxen.com

Limiting liability for Y2K breakdowns

A bipartisan group in the U.S. House of Representatives has introduced
legislation that would limit litigation, lawyers' fees, and damages caused
by Y2K-related computer breakdowns.  Supporters of the bill claim that it
would help avert Year 2000 problems, since the legislation would protect
only those businesses and individuals who take reasonable actions to prevent
them from occurring.  (*The New York Times*, 24 Feb 1999, Edupage, 25
February 1999) [CA, FL, GA, HA, NV, and VA have already passed such laws.
31 other states are considering such legislation.  There are of course also
risks of this making the situation worse as well.  PGN]

CIA predicts serious Y2K problems around the globe

Amidst all the discussion of possible Y2K effects is the issue of foreign
government preparedness.  Air Force Gen. John Gordon, deputy director of the
CIA, appeared at a hearing of the Senate Armed Services Committee and
testified that other countries (including Russia) are far behind in
preparing for possible crises, noting in particular breakdowns in nuclear
reactors and strategic missile systems, midwinter power outages and
disruptions in world trade and oil shipments.  However, he discounted the
possibility of accidentally missile launches due to Y2K.  But he did add
that malfunctions in temperature and humidity monitors could lead to
incorrect information.  He said that China will probably experience failures
in key sectors such as telecommunications, electric power and banking.
[Source: AP item by Jim Abrams, 25 Feb 1999, PGN Abstracting]

Y2K Test Fine Test Data Causes Problem (via Dave Farber)

Last October, PSE&G sent incorrect bills to 61,000 of their customers as a
result of an operator error.  Subsequent to testing their billing system for
Y2K compliance, the residues from the test data were not properly removed,
resulting in erroneous statements of past payments and amount owed.
However, this error was announced only recently.  [Source: New Jersey
Online, *The Times* (Mercer County, NJ); this item has been PGN-ed from
http://www.nj.com/mercer/times/stories/02-27-Q2BBFUMB.html .]

Re: Store Baelt Bridge not Y2K safe (Weber-Wulff, Risks-20.22)

Not quite right.  The west half of the Storebaelt crossing consists of a
side-by-side road and rail bridge, but the east half has a separate road
bridge while the railway uses a tunnel.  It's the east bridge that opened
last year; the railway (which is presumably the part with a Y2K problem)
opened in April 1997 to freight and June 1997 to passenger trains.

See <http://www.railway-technology.com/projects/denmark/> for a description
of the crossing in English.  (However, it never had the world's longest
main span, as claimed; the Akashi-Kaikyo Bridge in Japan is longer and
opened a month or two earlier.)

Mark Brader, Toronto, msbrader@interlog.com

Store Baelt Bridge not Y2K safe

A small article in Syssvenskan from 1999-02-15 notes that the new bridge in
Denmark over the Store Baelt (which was just opened last year) is not Y2K
safe.  Tests have shown that approx. 50% of all the systems involved
(signalling, signs, etc) will have some problem or other on 2000-01-01. But
that is not a problem, it just means that some of the trains will not be
able to cross the bridge.  [I hear PGN already: We'll cross that bridge when
we come to it!]

Debora Weber-Wulff MALMOe HOeGSKOLA  205 06 Malmo SWEDEN
+46-40-6657254  Debora.Weber_Wulff@te.mah.se  http://www.te.mah.se/person/dw/

  [Debora may be growing too big for her bridges by preempting PGN.  PGN]

Re: Computer fraud as another kind of Y2K risk? (Martin, RISKS-20.21)

In RISKS-20.21, Bruce Martin (Bruce_Martin@manulife.com) commented on the
risk that an unscrupulous Y2K consultant might arrange to divert a client's
funds during a period of uncertainty early next year.

The risk is broader than he suggests.  Uncertainty whether systems are
working properly will provide openings for many types of attacks, including
social engineering as well as technical attacks: "We're fixing a critical
problem that showed up when the clock struck midnight; would you relax
security for a while so we can fix it?"

One sobering though is that it may be weeks or months before the victims
are certain that they can distinguish between theft and technical
failure.

Re: Computer fraud as another kind of Y2K risk? (Martin, RISKS-20.21)

In RISKS-20.21, Bruce Martin raised the possibility of a
less-than-scrupulous Y2K consultant slipping in a few lines of code in order
to "redirect a significant fraction of an organization's wealth to a blind
account in the Cayman Islands at the stroke of midnight on 31 Dec 1999."

In June 1998, the *New York Post* ran a story about organized crime setting
up a phony Y2K consulting firm for the purpose of diverting money into
mob-controlled accounts.  Adam Penenberg of Forbes Digital investigated,
however, and found that the story had no substance.  See "Phantom Mobsters":
http://www.forbes.com/tool/html/98/aug/0828/feat.htm.

Dorothy Denning

Re: Computer fraud as another kind of Y2K risk? (Martin, RISKS 20.21)

In RISKS-20.21, Bruce Martin wonders about computer fraud perpetrated
by miscreants among the legions of consultants working to fix Y2K problems.

I've been wondering about a different kind of fraud, which doesn't even require
expertise in computing. On January 1, 2000, withdraw $1000 from an ATM.
When you get the statement, complain to the bank that you didn't make the
withdrawal. When they describe their records, repeat that you never made
the withdrawal and ask "Do you have a Y2K problem here? Maybe I should
call my attorney."

The problem for the bank, of course, is that proving that there wasn't a bug
could be very costly--if not impossible.

Win Treese <treese@acm.org>

State of the states in Y2K readiness

A recent survey by the General Accounting Office shows only a third of the
421 computer systems used by the states to manage seven welfare programs are
Y2K-compliant, with Medicaid the lowest at 16%.  Systems that deal with
child-care and child-welfare are about 50% compliant.  An ongoing survey of
state readiness conducted by the National Association of State Information
Resource Executives (NASIRE) indicates that a narrow majority have completed
repairs on more than half their critical systems and expect to finish the
rest in the next few months.  But the rest of the states are way behind,
with Alaska in last place with only 15% of its computer systems repaired.
"For a state, if you're not ready, you're out of the game," says Steve
Kolodney, director of Washington state's information services and chairman
of NASIRE's year 2000 committee.  It's estimated that states will spend
close to $3.5 billion in bringing their computer systems to compliance, more
than half of the amount spent by the federal government to do the same.
(*Los Angeles Times*, 1 Feb 1999; Edupage, 2 February 1999)

Y2K update turns city into deadbeat

Sydsvenskan, 19. Jan 1999 [paraphrased by dww]

The city of Malmo[e] in the south of Sweden updated its bookkeeping software
in October in order to get ready for the year 2000. The program AdeEko by
Enator takes care of paying the bills for the city.

But since it has been updated, some bills are not being paid. When the
clerks leave their offices in the evening, everything looks great. But
sometime during the night, the system knocks itself out, and forgets to send
the rest of the files with the payments to the banks and the post office.

This has happened every night since the system has been installed, and no
one knows why. Enator is having people babysit the system over night in
attempts to find out what is wrong. It takes a very long time for the bills
to be paid, as the clerks must sort through which ones were paid and which
ones weren't. The babysitters watch for bills which knock out the system,
remove them, and restart the system.

A spokesperson for Enator identified the problem as being simply files that
should be going to the banks and the post office not being accepted there,
but he is not accusing anyone of anything. The search continues...

Debora Weber-Wulff  MALMOe HOeGSKOLA  205 06 Malmo SWEDEN
Tel: +46-40-6657354 (Fax: -031)   Debora.Weber_Wulff@te.mah.se

Y2K in Swiss hospitals

I heard about this from an informant, took quite some searching to find the
little notice hiding on the pages in the NZZ (Neue Zuercher Zeitung, 7 Jan
1999) usually reserved for reporting celebrity divorces, plane crashes and
natural disasters. An on-the-fly translation:

The hospitals in the canton Waadt spent the 1st and 2nd of January 1999
fighting with the computer problems that are expected for the year 2000.
Except for the University Hospital in Lausanne, the computer systems for
admitting patients in all of the hospitals of the canton were down for 36
hours.  Specialists were able to fix the problem, according to a spokeswomen
for the hospitals in the newspaper "24 Heures" (24 hours) on Wednesday.  The
reason for the system crash is the fact that it was programmed to compare
something with the date a year in the future.  This was programmed in 6
digits as "01.01.00".  The system interpreted this as 1 Jan 1900.
Source: Year-2000 computer problem in Waadtlaender hospitals Lausanne,
http://archiv.nzz.ch/books/nzzmonat/0/8466081T.html]

Prof. Dr. Debora Weber-Wulff, Technische Fachhochschule Berlin
FB Informatik, 13353 Berlin, Germany  http://www.tfh-berlin.de/~weberwu/

  [Waadt's New?  PGN]

1 Apr 2001 flaw in Windows

Windows (95,98,NT) systems apparently suffer from an off-by-one-week glitch
on the daylight savings time cutover in 2001, shifting on 1 Apr rather than
8 Apr.  An updated library program will solve the problem.  [Source: John
Markoff, *The New York Times*, 14 Jan 1999; PGN Abstr, via Dave Farber and
others.]

Quicken 1999 bug

Another 1999 bug, Intuit's Quicken'99 fails with a "divide by zero"
message when a transaction dated in January 1999 is recorded in the Auto
category and its "Home and Car Center" is opened.  See
http://www.intuit.com/support/quicken/faqs/win2/1913.html

James S. Vera       |         Internet         | Voice: +1.415.725.0256
Stanford University |  vera@anna.stanford.edu  | FAX:   +1.415.725.7398

A good Y2K bug

> January 1, 2000
> Re:  Vacation Pay

> Dear Valued Employee:

> Our records indicate that you have not used any vacation time over the
> past 100 year(s).  As I'm sure you are aware, employees are granted 3
> weeks of paid leave per year or pay in lieu of time off.  One additional
> week is granted for every 5 years of service.

> Please either take 9,400 days off work or notify our office and your next
> pay cheque will reflect payment of $8,277,432.22 which will include all
> pay and interest for the past 1,200 months.

> Sincerely, Automated Payroll Processing

Utilities and Y2K: not to worry

I quote from a 10 Jan 1999 article in *The Boston Globe* on utilities' Y2K
readiness:

  Typical is one filing from Notheast Utilities: "NU has found nothing
  that cannot be repaired or replaced and be made Year 2000 ready in time,"
  it states.

They don't get it:  the devil is in the gotchas not found.

Y2K testing tools

I am currently involved with doing y2k testing at a client site. I have
spent numerous hours looking for tools which can be used for building test
suites. Unfortunately, I have not been able to find very many tools which
are worthwhile.

A lot of the available tools appear to have been built by individuals who do
not fully grasp the underlying concept of the machines and operating systems
which they are trying to test.

I have written some c code which should cause alerts with testing software
that checks for possible y2k problems. When compiled and checked under
microsoft based platforms, these binaries easily slip by testing
programs. When compiled and checked by Sun's own y2k testing tools, these
binaries also slip by.

Since Sun's tools are based on shell scripts, I was able to go in and find
the problem. The script works fine under the Sparc editions of the operating
system but returns false information when run under the Intel x86
version. This is due to the 'dump' command having differing output between
the OS versions. This slipped by the engineers at Sun.

Out of necessity, a lot of people are now doing system testing for the first
time in their careers. The risks are obvious. How many systems have been
checked and certified with buggy tools? Have individuals involved with
testing first checked that their test suites will actually work? Do they
even know how? We will find out soon enough.

REVIEW: "Year 2000 in a Nutshell", Norman Shakespeare

BKY2KNSH.RVW   981030

"Year 2000 in a Nutshell", Norman Shakespeare, 1998, 1-56592-421-5,
U$19.95/C$29.95
%A   Norman Shakespeare
%C   103 Morris Street, Suite A, Sebastopol, CA   95472
%D   1998
%G   1-56592-421-5
%I   O'Reilly & Associates, Inc.
%O   U$19.95/C$29.95 800-998-9938 707-829-0515 nuts@ora.com
%P   336 p.
%T   "Year 2000 in a Nutshell: A Desktop Quick Reference"

*Can* the Year 2000 problem be put in a nutshell?  (Please?)

And isn't it just a tad late to be starting this?  (On the other hand,
Nutshell books *are* generally worth waiting for.)

Part one is a general overview of the situation.  Chapter one starts with a
rather exaggerated doomsday scenario, including concerns that have already
been seen, and thus have been addressed.  At the same time, it ignores the
"upstream" multiplier effect of supplier and infrastructure failures.
However, it does go on to note needs and concerns for management of the
potential failures.  Management and budgeting considerations are expanded in
chapter two.  Legal questions are addressed in chapter three, in a somewhat
generic fashion.  Some standard planning models and assumptions are given in
chapter four.  A little technical information in chapter five may help with
calculations for dates and windowing or packing solutions.  Chapter six
looks at the desktop PC; which is interesting in view of a very heavy COBOL
and IBM mainframe and mid-range emphasis elsewhere (as well as a few PC
related goofs in the doomsday scenario).  Unfortunately, some of the
information is missing and some is wrong in regard to the desktop.  There is
no mention of a "cold rollover" test for the CMOS/system date, and the
statement about Excel's date interpretation is incorrect.  (I have confirmed
this in my own testing.)  On the other hand, the warning about internally
developed applications is quite important.

Part two provides some forms and checklists to help organize a Year 2000
project, including triage, inventory, and a project template.  There are
about a hundred pages of COBOL references and tutorial in part three.  Date
functions get extensive listings in part four with attention to general
types, COBOL, PL/1, MVS LE, Visual Basic, and C.  There is a conceptual look
at code scanners in chapters eighteen and nineteen.  An appendix lists Web
sites for Y2K vendors, tools, and other resources.

Was it worth waiting for this?  I'm not sure.  There is little wrong with
the information, but neither is this a cut and dried quick fix that you
might expect from the Nutshell series.  An unrealistic expectation in the
case of the disaster of the century, admittedly, but there you are.  Still,
with the big iron emphasis, and the big project orientation, the material is
this work seems to be coming later than it would have been necessary to
start these kinds of projects.  There is relatively little in the volume for
small businesses depending upon desktop machines, and almost nothing on
fallback plans for non-compliance in the supply chain.  The material is fine
as far as it goes, but it doesn't go as far as it needs to at this late
date.

On the other hand, it's no worse than any of the others.

copyright Robert M. Slade, 1998   BKY2KNSH.RVW   981030
rslade@vcn.bc.ca  rslade@sprint.ca  robertslade@usa.net  p1@canada.com
Find virus, book info http://victoria.tc.ca/int-grps/techrev/rms.html

UAL clock wraparound

I don't know about Y2K, but United airlines has a problem with H24.

This is what www.ual.com provided for the flight status of today's UA63
(scheduled to depart San Francisco at 7:15p and arrive Honolulu at 10:46p)

  Flight: UA 0063
  Date:   01/04/99

  Airport                     Time            Status

  San Francisco Intl Arpt   9:10pm Mon    Delayed 1 hr 39 min
  Honolulu Intl            12:01am Tues   Early  22 hr 35 min

Y2K hits Singapore and Swedish taxi meters

Computerized meters in 300 Singapore taxis failed for about two hours at
noon on 1 Jan 1999 in an early Y2K manifestation.  Taxi meters in Sweden
also acted up on the same day, but passengers there hardly complained.  The
meters continued to work but gave riders unexpectedly low fares.
[Source: Associated Press, 3 Jan 1999, *The Sunday Times*, PGN Abstracting]

  [NOTE: I guess free parking is one of the new-year's initiatives that the
  government didn't tell people about. Perhaps we can make certain this
  happens in San Francisco, D.C., and New York. The problem of moving from
  1998 to 1999 has also been found in some of the embedded systems in power
  plants, mostly in graphical counters for trend analysis.  KR]

The Windows April Fools 2001 Bug (from Richard Smith)

This is really a daylight-savings problem in the Visual C++ library -
but the last time it would have happened would have been in 1990...

More on the webpages. Since it's windows *applications* rather than
Windows itself, it can be expected to be widespread.

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

  ---------- Forwarded message ----------
Date: Thu, 07 Jan 1999 00:39:30 -0500
>From: glen mccready <glen@qnx.com>
Subject: The Windows April Fools 2001 Bug [from 0xdeadbeef]

>From: "Richard M. Smith" <rms@pharlap.com>

I thought the deadbeef crowd might be interested in this story.......

I just got confirmation from Microsoft of the "April Fools 2001" bug that I
reported on Monday.  Although not technically a Y2K bug, many Windows
applications are going to break on April 1, 2001 and start giving the wrong
time of day.  The bug lasts for a week.

Technical details of the bug can be found at:

   http://security.pharlap.com/y2k/april1.htm

A live test page for the bug is available at:

  http://security.pharlap.com/y2k/demo1.htm

With this bug, any technical person involved with Y2K testing has a new
date to worry about which April 1, 2001.

Richard

Swedish passport system struck by 99

In Sweden, the first report about a 99-related computer problem appeared
already on 1 Jan 1999.  The Swedish police can normally issue provisional
passports at the three main international airports in Sweden. But on the
first day of 1999, no passports could be issued because the computer system
could not handle 99.  Four people in Stockholm and two in Goteborg had to
cancel their trips because they could not get their passports.  The system
was reported to have been fixed during the afternoon.  [Primary source
*Sveriges Televisions Text-TV*, January 1 1999]

A couple of things to note: Of course it is a risk to try to travel abroad
without having a passport, but there could be good reasons - family
emergencies, for example.  The ordinary Swedish passports where changed in
1998 to conform with European Union regulations, but in this case the system
must be much older or based on old components (if the designers where not
extremely shortsighted).  Most businesses do not open until Monday 4 Jan - we
could expect to hear about more 99-problems then, I guess.

Ulf Lindqvist, Department of Computer Eng., Chalmers University of Technology
SE-412 96  Goteborg, SWEDEN  +46 31 772 17 60   ulfl@ce.chalmers.se

  [Also reported by Martin Minow, and by Debora Weber-Wulff, who notes
  that 99 seems to be used often in Sweden to denote "end-of-file"...  PGN]

Swedish Giroguide also hit by 99

The New Year provided an early taste of Y2K in Sweden. According to the
Stockholm newspaper, *Svenska Dagbladet*, the modem-based "Giroguide"
payment service run by the PostGiro refused to process payments "if the
payer provided a specific date in 1999". (PostGiro is a convenient payment
system run by the Post Office used as widely as checking accounts in the
United States.)

"It was due to a programming error" ... that can depend on the combination
"99" that, in some cases, is used to mark end-of-run.  Since you can enter
payments up to a year in advance, it may also be due to a year-2000 problem,
but Jarl Dahlerus, who is responsible for E-PostGiro, doesn't believe this
is the case.  If any customer is affected by the error, they will be
compensated by PostGiro.

Translated and summarized by Martin Minow, minow@pobox.com

Y1999: Risk of re-using data fields for error signaling

"1999 problems with medical device clocks found"
<http://www.sjmercury.com/business/tech/docs/085460.htm> discusses two
medical devices that the FDA is warning hospitals of non-health
threatening failure in 1999.  The HP defibrillator will print "set clock"
instead of the date on its printed record.  The other, a patient
monitor, will also fail to correctly report the date in it's logs.

Obviously, somebody made "99" mean "clock needs to be reset".  These are
relatively new devices.  We they really so short of memory that they
couldn't find a bit somewhere for this flag?

Daniel A. Graifer, Parker & Company 1-888-426-6548
Andrew Davidson & Company, 588 Broadway, Ste 610, NY 10012 1-212-274-9075

  [Note: relating to Jerry Leichter's Y2K item in RISKS-20.13,
  various folks observed that 9 Apr 99 is the 99th day of 1999, which
  in some programs is represented as 9999, an erstwhile stopcode.  PGN]

99-Year retrospective health insurance - or Y2K problem

Last week I received my Health Insurance renewal notice with the period of
cover listed as "From: 4 January 1999 To: 4 January 1900".  Since I was not
alive for most of the 99-year period I am intending to decline their
generous retrospective insurance offer.

It does not bode well, that in December 1998, HBA, one of the larger Health
Insurance companies in Australia can presumably be so far behind in its
Year 2000 project that they have not tested the production of their primary
revenue collection document.  Many other companies have already finished
their Year 2000 projects.

Now is the time that annual renewals for all sorts of things will be
issuing that should have expiry dates falling in January 2000, it will be
interesting to see how many other 1999 to 1900 renewals appear.

  [Many people are actually expecting some serious problems beginning next
  week for insurance companies and others who have to deal with dates a year
  ahead.  PGN]

British Government admits Y2K missile problem

>From The Times, 9 Dec 1998, p2:

Bug threat to missile

The Ministry of Defense admitted for the first time that the millennium bug
could have left Britain vulnerable to air attack.  It discovered that the
Rapier anti-aircraft missile would have failed to retaliate.  The problem
was identified inside the field equipment which activates the missiles and
it would have made the system inoperable.  The threat to Britain's defenses
posed by the computer bug was outlined by George Robertson, the Defense
Secretary.  [Well, at least the failure mode was to not fire.]

2,000 Texans get false overdraft notes in Y2K test

2,000 Texans get false overdraft notes in Y2K test
Reuters, Detroit News, 12/17/1998

Bank One Texas was testing their Y2K systems to see if they could send out
overdraft notices after "1/1/00".  They were able to print over 2,000
fabricated notices.  But someone forgot to throw away the printouts, which
were mailed out! <http://www.detnews.com/1998/technology/9812/17/12170189.htm>

Y2K expansion

As not-particularly-competent (but professionally paranoid) lawyers have
gotten more and more heavily involved, the range of "Y2K critical" dates has
grown.  A story has made the rounds that some software uses "9999" in the
date field to indicate special processing; hence, software is now supposed
to be tested for proper operation on 9 Sep 99.  (Why operation *on that
date* should be affected is beyond me.  Then again, since a date written
with a two-digit year and no separators necessarily has to be stored in at
least a 7-digit field -- there being at least one month with a month number
larger than 9 containing at least one day with a number larger than 9 -- it's
beyond me why one would expect software to use 9999 as a flag; 9999999 is
much more likely, and completely safe.)

I recently saw proposed language that would require a vendor to certify
proper operation on about 15 dates, starting with 9 Apr 1999 and ending some
time in 2002.  One could make a rough kind of sense of many of the dates --
e.g., they tested proper leap year handling in 2000 and thereafter -- but
some of them are real head-scratchers.  The 9 Apr 1999 date is one of those.
Is it that 4 and 9 look alike, so that 9499 (or is it 4999?) might have been
used as a magic flag?  :-)

I worked with a lawyer doing Y2K requirements for a major corporation, and
convinced them not to put *any* explicit date requirements in.  Rather, the
language is all written in terms of proper operation on any dates, and with
any input date data, that will foreseeably arise in normal system operation
during the expected lifetime of the system.  Not only does this avoid
getting into silly "my list of dates is longer than yours, hence you weren't
exercising due diligence" games, but it also avoids a genuine *bug* in the
way most of these provisions have been written: They focus so closely on
dates around the year 2000 that they ignore the possibility of problems with
dates further away.  For example, a vendor could introduce windowing -
continue to store two-digit years but have 50-99 always represent 1950-1999
while 0-49 represent 2000-2049 - to easily comply with most Y2K requirements
I've seen.  That's fine if the field in question represents order dates, but
not so good if it represents dates of birth.
                                                        -- Jerry

Unexpected date behavior in Windows 95

I came across the following interesting behavior in Windows 95: if you use
the "Date/Time Properties" dialog box to change the month or day of month,
the system clock is actually set to that date, without the user hitting "OK"
or "Apply."

The risk is that the user is changing system properties without really being
aware of it--if the user hasn't pressed "Apply" he or she will figure that
the change hasn't occurred yet.  Although pressing "Cancel" will restore the
date, any applications that check the system clock in the meantime will read
the altered system time.

As a simple example, consider a mail reader that checks for new mail every
five minutes by comparing system times.  If it checks mail during an
interval when the clock is set forward a day and then reset, the mail reader
will not check mail again for 24 hours.

I don't know how many applications expect and rely on the system time
to be monotonically increasing.

I've been told that other Windows dialogs, besides the date/time, also
prematurely change system settings in similar ways, but I'm not sure what
implications other settings may have.

I tested this on an NT machine and on a Windows 98 machine that was said to
have the recent Y2K patch installed, and noticed the same behavior.

Dan Weber, Sandstorm Enterprises, Inc.  http://www.sandstorm.net/
1-617-547-0011  djweber@sandstorm.net

Microsoft Trojan Horse

I am running Win98 with a Microsoft module that automatically notifies me of
"critical updates" and takes me to a Microsoft Updates web site.  The first
item on the list of updates was one that was intended to make Win98 Y2K
compliant.  This module was roughly 1.5MB.  Further down the list was a beta
IE virtual machine (presumably designed to comply with the Sun Java
decision.)  This file was roughly 4MB; I decided to pass on it.  Having
specified what I wanted to download -- and install (it is both or nothing)
-- I noticed that the download was going slowly.  And then I discovered the
reason: the file that I was downloading was over 5MB ... and included the
Virtual Machine Beta that I had not checked!  I cancelled the download and
went back to check whether I had made and error.  I had not.  I repeated the
exercise with the same result.

My conclusion is that in an effort to show 'good faith' compliance with the
Sun Java court order, Microsoft is installing the revised Java engine on the
computers of users who have decided against using it.  The cheese that they
are using to bait their trap is the promise of Y2K compliance.

Does anyone who is using Win 98 and the IE 5.0 beta know how to get only the
Y2K update?

San Francisco power outage and Y2K (RISKS-20.11)

The 8 Dec 1998 SF outage (RISKS-20.11) may be subject to as much scrutiny as
the 10 Aug 1996 western states blackout (RISKS-18.32).  Electric system
deregulation has caused numerous changes in priorities.  This outage is
attributed to human error, a construction crew not knowing a pipe was acting
as a ground.  It could be considered an information error, if no sign, tag
or other label were present and this sort of pipe is not routinely used
(e.g., noted in standards and training manuals) as substation ground.
www.euy2k.com today quotes PGN on this outage as a sample of the type of
scenario problems which might result from Y2K remediation failures.

Is it a Y2K problem if utility executives decide it is preferable to spend
$50-100 million on a new customer billing system rather than spend that
amount on tree-trimming, line-crew training, supervision, buyout of excess
staff, or labeling of equipment in substations?  Study of major outages
suggests among key issues faced in electric system reliability are aging
infrastructure and loss of the knowledge base on details of transmission and
distribution systems when staff retires or is downsized out as part of
deregulation.  Starting a project to catalog and label every wire in every
city has no glitz and few major consulting firm requirements.  Yet this
simple course of action will prevent many problems with the energy
infrastructure, and could be included in the national infrastructure
protection project (http://www.ciao.gov).  The writings on complexity and
system accidents of Charles Perrow are highly recommended.

Cathy Horiuchi, University of Southern California, formerly at the
Sacramento Municipal Utility District, "Your Electric Service"

San Francisco power outage delays this issue (PGN)

At 8:15 this morning, failure of a power substation in San Mateo County
south of San Francisco propagated, knocking two power plants off line, and
affecting about 372,000 customers in San Francisco and some northern
Peninsula cities, some for up to two or three hours.  The blackout took down
the SFO Airport, the Pacific Stock Exchange, rapid transit, and ATMs, as
well as homes, offices, and hospitals.  There were reports of people stuck
in elevators and problems with home medical equipment.  SFO was back up by
9:45 with emergency generators.  The surge was felt in the North Bay and
East Bay as well.  SRI experienced only a power blip, but it was enough to
wipe out a bunch of servers throughout the institute; CSL's computers were
down for more than two hours.  [Sources: patched together from various
early on-line reports...]

  [I look on this as a further reminder of how dependent we are on
  electric power, and how outages tend to propagate.  Y2K-ologists will
  undoubtedly take this as a microcosm of what might happen on 1/1/00.]

Y2K panic could be as disruptive as computer problems

One of the more interesting -- and perhaps serious -- Y2K risks is not
computer snafus, but widespread panic. As Y2K coverage becomes increasingly
mainstream (60 Minutes and CBS News ran pieces this week), stockpiling by
individuals and businesses could lead to a recession or even bank runs. At
least that was the verdict at a Y2K summit on Thursday. --Declan

http://www.wired.com/news/news/business/story/16618.html
Bankers: Prepared for a Panic? 4:50 p.m.  3.Dec.98.PST
by Declan McCullagh (declan@well.com)

Fear of electric-power outages and bank failures could lead to widespread
panic as disruptive as the Y2K glitch itself, Senator Robert Bennett warned
Thursday at the first summit organized by President Clinton's Y2K council.
"Even if the Y2K problem is solved, the panic side of it can end up hurting
us as badly," said Bennett, the Utah Republican who heads the Senate's Year
2000 committee. [remainder snipped]

DoD falsified Y2K data but has "good feeling" about future

A Department of Defense inspector-general report says that the Defense
Special Weapons Agency never conducted required tests on three of five
"mission critical" computer systems it had certified as Y2K-compliant.  The
military officer assigned to correct the agency's Year 2000 problems says he
agrees with the report, but that the systems in question will be "100% in
compliance" by April 1999: "I have a good feeling about Y2K in this agency."
(*USA Today*, 27-29 Nov 1998; Edupage, 29 Nov 1998)

Y2K inflation risk

Here is another unintended consequence of technology. When a local regional
hospital could not get the vendor of an older *analog* nuclear medicine
machine to declare that the machine was Y2K compliant, the hospital decided
to buy a new digital machine at a cost of over $700,000. The older machine
was still useful but the hospital felt it would be liable if it couldn't
state that the machine was compliant. It is doing the same thing with other
less expensive machines also -- discard and replace. The implications for
patients and insurance companies is obvious; no wonder medical cost
inflation is increasing faster the CPI.

Marion Moon

Re: 100-year-old woman "too old to vote" (RISKS-20.09)

Having read the information in my newspaper, it appears that age is *not*
the reason for the removal of the right to vote, but rather a judgement that
the little old lady is no longer completely competent.  Note that three
other residents of the same senior's residence were also denied the right to
vote, and they were not yet 100 years old.  They were interviewed in person,
and apparently her nodding of her head in response to questions was not
deemed sufficient evidence of her competency.  Whether this decision is
correct or not is not subject to correction under the law being used - that
is the real issue. It has nothing to do with computers or the
two-digit/three-digit controversies.

R.S. (Bob) Heuman, Toronto, ON, Canada
<heuman@intria.com> or <rsh@idirect.com>

  [Also noted by quite a few others.  TNX.  PGN]

100-year-old woman "too old to vote"

The Quebec '98 election Website reported on 27 Nov 1998 that several elderly
residents in a Montreal nursing home are ineligible to vote in Monday's
provincial election.  One of these is a 100-year-old woman.  The chief
returning officer for the riding sees no reason why they can't vote, but he
is prevented by law from giving the woman back her right.

http://www.quebec98.cbc.ca/news/fullstory/F04.html (link may go stale)

I would guess the problem is a Misinterpretation of Dates bug in the
Electoral Office software, but there could be other reasons for the
centenarian's plight.  However, what is RISKy about this story is the part
that existing legislation might play in exacerbating the fallout from
MoD/Y2K related failures.  It is one thing for a computer to remove the
right-to-vote from the young at heart aged 100+, but quite another to have
legislation that inadvertently *forbids* a bureaucrat to fix the resulting
mess; a computer system creates a situation for which a piece of legislation
must be applied (e.g., withdrawing a citizen's civil right), but in a
context never envisioned by lawmakers.

Mike Zastre <zastre@csr.uvic.ca>

  [Note added in archive: This is incorrect.  See RISKS-20.10.  PGN]

Some good Y2K news: whisky will be on tap for Hogmanay 1999

http://www.scotsman.com/interactive/it16nips980923.1.html

   Distiller is 100% millennium proof
   Whisky drinkers should be assured of their tipple being on tap for
   Hogmanay 1999, says Alan Crawford

Whisky tipplers can rest easy after the announcement last week that a
technological crisis that had threatened to halt the flow of Scotch has been
narrowly averted. Burn Stewart Distillers, whose brands include Tobermory
Single Malt and Wallace Liqueur, has declared that its computer systems will
be millennium compliant by the end of the year.

Although the whisky industry is steeped in tradition, it relies heavily on
computers to control many aspects of production and marketing. Burn Stewart
alone sells about 18 million bottles a year to 500 major customers. Failure
to deal with the millennium bug - which threatens global computer meltdown
due to an inability to recognise the date change from 1999 to 2000 - could
result in widespread disruption of the distilling, bottling and marketing
processes.  [...]

POLITECH -- the moderated mailing list of politics and technology To
subscribe: send a message to majordomo@vorlon.mit.edu with this text:
subscribe politech
More information is at http://www.well.com/~declan/politech/

Military preparations to mobilize for Y2K

[Declan notes that the Wisconsin National Guard is preparing to mobilize
for Y2K http://www.jsonline.com/news/1007y2k.asp, as are Toronto-area army
reservists, considering stockpiling food and generators.  2000 cyberglitch
the major concern for Canadian forces, By Patrick Cain]

Void where prohibited by date

Yesterday my wife brought home a copy of a letter that her organization had
received from their insurance broker.  As could be expected, this document,
produced by the Insurance Bureau of Canada, warns that insurance is probably
not going to pay out if something happens that is related to a Y2K bug.
(They use more words to say it, of course.)

The pamphlet warns about a number of things that should be checked, and
could be used to generate a reasonable list of items to be confirmed.
Unfortunately, how you might go about checking them isn't covered.  (There
is one sidebar on checking the BIOS clock for a PC.)

However, that wasn't all that came in the mail yesterday.  There was a
catalogue from a company that sells promotional material related
specifically to anniversaries.  With it was a covering letter congratulating
them on their tenth year in business, coming up this spring.

The institution my wife works for was founded in 1889.

rslade@vcn.bc.ca     rslade@sprint.ca     slade@freenet.victoria.bc.ca
virus, book info at http://www.freenet.victoria.bc.ca/techrev/rms.html

Risks of Upgrades: Florida fingerprint system

Computer Glitch Ties Up Crime Probes
from *The Palm Beach Post*, 1 Oct 1998,
Monika Gonzalez, Palm Beach Post Staff Writer

This article reports that "dozens of crimes in Palm Beach County could be
going unsolved because the sheriff's computers can't compare fingerprints
found at crime scenes with those of criminals arrested in other parts of the
state."

The problem is a software compatibility problem that was caused by upgrades
made to the network of state and local fingerprint computers know as AFIS -
Automated Fingerprint Identification System. In 1996, the Palm Beach County
Sheriff's Office and the Florida Department of Law Enforcement both decided
to upgrade. Palm Beach finished their upgrade first, in October, 1996,
expecting to be compatible with the state's system about six months after
that.  However, the state upgraded their system beyond the capabilities of
the county's upgrade, making them incompatible, and they remain so to this
day.  Mark McDonald, Palm Beach County AFIS Supervisor "hopes" the two
systems can be compatible by January, 1999 after upgrading his system
again. (This should give them about a year of full operation before the Y2K
bug hits them!  - but I digress...)

Losses:
Palm Beach County was getting two to three fingerprint matches a month from
the state system. This comes to 48-72 cases that might be closed by now (2
years since October, 1996). Some of these matches may be discovered once the
systems are linked again, but the statute of limitations may have run out on
some of the crimes in question. Also, any belongings or evidence that might
have been recovered because of a timely fingerprint match may be lost. This
is exacerbated by the fact that Palm Beach County estimates it will take
another year to process the fingerprint backlog.

Lessons:
1) Plan and coordinate your upgrades carefully
2) Come to Palm Beach County to commit your crimes before they can trace
your fingerprints!

Charles P. Schultz <ecs013@email.mot.com>

Y2K police planning

The *Ottawa Citizen* (03 Oct 1998) reports that the RCMP has banned
vacations for its 15,000 officers and 2,400 civilian members from Dec., 27,
1999 to March, 1, 2000. According to Dave Morreau, who heads the RCMP's Y2K
project the length of the ban was determined by the need to include " ...
all the dates that computer experts say ill prepared computer systems would
be likely to crash or malfunction."  For its part, "...  the force has
already fixed and tested about 90 per cent of its systems ... "  notes
Morreau. Additionally the article also reports RCMP attempts to create an
accurate picture of any potential Y2K problems are hindered by " ... many
businesses and utilities ... reluctant to discuss whether their systems have
been fixed for fear of facing [customer]lawsuits ..."  In a memo to the
force, Commissioner Murray noted the situation may be like last January's
Ice Storm, which affected Eastern Ontario and Quebec with power outages
etc. Though Murray does not expect problems throughout the whole period but
" ... problems probably of a limited duration may occur." The last time such
such an ban was issued the article notes, was during the Pope's 1984
Canadian visit.  The full text of the article can be found at
http://www.ottawacitizen.com/national/981003/1910271.html

[Though other police forces probably have these contingency plans in
effect, it is interesting to see how the Y2K bug is becoming noticed in
all quarters now.]

Re: Y2K risk in Netscape cookies (Seymour, RISKS-20.01)

> The Netscape cookies specification ...
>     Wdy, DD-Mon-YY HH:MM:SS GMT

Well, in http://home.netscape.com/newsref/std/cookie_spec.html, the
official cookie standard says: Wdy, DD-Mon-YYYY HH:MM:SS GMT.  the url
which you referred is the 'how to implement cookies with java script'
page.  i'll trust the standard.

i trust the standard to all ends, even the examples at the bottom of the
page, with the demo of "09-Nov-99".

consistency.

jay ball  http://www.invengen.com  [one of several contributions...   PGN]

Calling All Traffic Lights in Dublin!

Getting into, or out of, Dublin City Centre by car was much more difficult
than usual yesterday (Sept 28th, 1998). The journey that should have taken
me 25 minutes (long after normal rush-hour at 9.30) took over an hour
instead. During rush hour, one motorist reported taking an hour and a half
to cover a mile and a half. In my case the congestion was so severe in the
inner city that I kept expecting to round a corner and find some major
obstruction such as a collapsed building, or two stalled trucks side by
side.

The answer was much simpler - an incomplete "upgrade" had disconnected the
traffic lights at 140 junctions from the Dublin Corporation control
centre. The lights are normally regulated to cater for traffic conditions,
but without communications they were left to get on with the job
themselves. They ran through preprogrammed sequences without allowing for
traffic conditions, or proper synchronisation between them. Gridlock
resulted.

PS: Yesterday's jams were so bad that traffic today was much *lighter* than
usual. Thousands of people must have taken to public transport.

Full story: http://www.irish-times.com/irish-times/paper/1998/0929/fro2.html

  [Also noted by
    Niall Smart <nialls@euristix.ie>,
    Bernard Lyons <bernardl@indigo.ie>.
  See the next item from Mich Kabay, which provides a Y2K link! PGN]

Y2K "fix" causes Dublin traffic jams

Chris Parkin of *The Press Association News* (UK) reported that the Dublin
traffic snarl on 29 Sep 1998 was due to poor quality assurance in a new
version of the software controlling traffic signals led to fixed cycles with
no allowance for longer cycles at peak traffic times.  Ironically, the
software was installed to prevent Y2K problems.  [PGN edited]

This case illustrates
* the general danger of introducing new bugs in any "fix" if QA
  procedures are inadequate;
* the specific danger of pushing Y2K fixes into production without
  proper QA;
* the vulnerability of electronically-controlled infrastructure to
  interference.

M. E. Kabay, PhD, CISSP / Director of Education
ICSA, Inc. <http://www.icsainc.net>

Y2K risk in Netscape cookies

How did the following happen?

The Netscape cookies specification (url below) states that the expires
field of the cookie string is formatted as:

     Wdy, DD-Mon-YY HH:MM:SS GMT

A 2 digit year! In a specification from circa 1994-95!! What planet am I
on?!!!

More seriously, how many web applications will stop working around the year
2000 because of differing interpretations of what YY means?

http://developer.netscape.com/docs/manuals/communicator/jsguide4/cookies.htm

REVIEW: "Computer Crisis 2000", W. Michael Fletcher

BKCMCR2K.RVW   980619

"Computer Crisis 2000", W. Michael Fletcher, 1998, 1-55180-138-8,
U$12.95/C$15.95
%A   W. Michael Fletcher feedback@highspin.com
%C   1481 Charlotte Road, North Vancouver, BC   V7J 1H1
%D   1998
%G   1-55180-138-8
%I   Self-Counsel Press
%O   U$12.95/C$15.95 604-986-3366 fax: 604-986-3947 selfcoun@pinc.com
%P   232 p.
%T   "Computer Crisis 2000"

The book jacket states that the author has thirty years of experience in
advising businesspeople how to deal with technology.  If so, then he is, of
course, part of the problem, since this problem is not one that wasn't
foreseen.  Indeed, in the preface he admits he came late to the problem, and
certainly a warning book now is just a tad behind the times.  However, the
book is aimed at small and medium sized businesses.  This market has been
neglected in other works on the topic, and may still have room to fix the
situation as far as it can be dealt with internally, since their computing
needs are presumably less monolithic than those of the corporate giants.

Part one is a definition of the problem and how it may affect people and
businesses.  The explanation is split into the first two chapters (the book
chapters are very short).  Generally the exegesis is reasonable, although
not altogether convincing of the seriousness of the situation, but it also
contains some sections detailing accounting functions that have only a
minimal bearing on the issue.  A third chapter lists some excuses for
avoiding the work involved, but adds nothing to the book.  Possible impacts
get sidetracked into the beginnings of an action plan, the action plan is
disorganized, and the section ends with a look at legalities that ends, for
some reason, with some thoughts on tax law.

Part two looks at large institutions.  The review of government says
what the author thinks they should be doing, but gives limited (and
likely incorrect) analysis of what the situation and prognosis
actually is.  Much the same applies to the chapter on infrastructure
and utilities.  (The optimistic view of the Internet in the event of a
communications failure is particularly naive.)  The overview of
finances simply looks at a bleak set of possible problems, most
without solution.

Planning and implementation is addressed in part three.  The initial outline
is quite good, stressing that the time for delay and cheap solutions is
past, but it may not be entirely convincing to managers and business owners
due to the weak opening in part one.  Personnel and inventory get some
detail, but the implementation itself is strung over four chapters with
questionable organization.

The final two parts contain two chapters looking at the possible ancillary
benefits of going through the year 2000 process, and a very terse look at
the international scene.  An appendix lists both print and online resources.

As Fletcher notes in the preface, he could not put absolutely everything
into the book, and polishing and the inclusion of more material would have
delayed a project that is late enough as it is.  The concentration on
personal computers and shrink wrapped software is valid given the target
audience.  However, more detail on certain implementation areas would have
greatly improved the book.  As only one example, getting commitments from
suppliers is lacking in breadth and range, and there should be contingency
plans for the inevitable failures in some part of the infrastructure.  This
book is not alarmist: if anything it does not paint the scene widely enough.

copyright Robert M. Slade, 1998   BKCMCR2K.RVW   980619

Win98 Yx problem, not Y2K?

I'm a Linux user and don't have Win98 around to test this, but I've found
two reports so far today that Win98 has a date problem.

A Y2K test program in the UK reported a Y2K problem, but further testing
revealed that it was not a Y2K problem.  The date was a day or two off
when crossing between any two years.  Because it happens every year and
not only in 2000, it is not a Y2K bug.

You might want to try to mess up the nearest Win98 machine to confirm
this before reporting it...and I don't expect this report to be used
with exactly this phrasing, as I expect you'll find plenty of other sources
with better information.  (OK, so I can even tell an editor that I know
he'll do his job :-)

I saw one report on the BBS web page and now a second related one at
http://www.sunday-times.co.uk/news/pages/sti/98/08/09/stibusnws01022.html
  [Sorry, I cannot include the user code.  PGN]

As these are reports from the UK, I don't know if the problem is sensitive
to the British Isles or GMT time zones or not.  One can hope there is
something more complex than just a date sensitivity, as one's eyebrows tend
to get stuck to the ceiling when a major product has such a problem this
close to Y2K.

Scot E. Wilcoxon        sewilco@fieldday.mn.org

REVIEW: "Time Bomb 2000", Edward Yourdon/Jennifer Yourdon

BKTMBM2K.RVW   980531

"Time Bomb 2000", Edward Yourdon/Jennifer Yourdon, 1998,
0-13-095284-2, U$19.95/C$27.95
%A   Edward Yourdon
%A   Jennifer Yourdon
%C   One Lake St., Upper Saddle River, NJ   07458
%D   1998
%G   0-13-095284-2
%I   Prentice Hall
%O   U$19.95/C$27.95 201-236-7139 fax: 201-236-7131
%P   416 p.
%T   "Time Bomb 2000: What the Year 2000 Computer Crisis Means to You"

It doesn't take long to figure out which Saturday morning is being referred
to in the Preface.  And one of the common failures suggested by pundits
after December 31, 1999, is that of phone service.  As the outage extends to
a decade, however, one begins to wonder how realistic this book is going to
be.  For one thing, loss of dial tone is much less likely than billing
errors, and the most likely errors would be failure to bill for those calls
taking place as midnight (switch time) strikes.  However, the introduction
goes on to point out that the subtitle is much more appropriate to this
book: it is addressed to the non-technical audience, rather than those
charged with fixing the problem.  A bit of overstatement can therefore be
forgiven.  It is odd, though, that so many of the examples used refer to
large infrastructures: what *could* the normal citizen do if faced with a
region wide water outage?

Chapter one introduces the concepts of risk management and planning, and
stresses the relative time elements to plan for.  However, one of the
central statements is that we simply do not know what is going to happen,
and that makes planning rather difficult.  There are some general
suggestions (for example, that most disruptions will be of days, rather than
weeks, duration), but even these are questionable.  One specific
recommendation, for instance, is that stockpiling a month's supply of food
in a city apartment might be difficult, so maybe you should go visit friends
in the country for a month.  I'm not sure what assumption this is based on,
but if food distribution is interrupted, it might be more likely that
emergency food provision would be concentrated in population centres.  The
consequences to employment are reviewed in chapter two, which ultimately
suggests only one course of action: have a nest egg on hand.  The scenario
is alarming, but also possibly unduly optimistic, since it repeatedly
suggests planning for a year out of work.  Using the book's own figures, and
fairly simple arithmetic, the average time out of work would appear to be
four years.  The discussion of utility disruption, in chapter three, is
vague and offers little in the way of practical suggestions.  Interconnected
failures are not emphasized (gas furnaces fail as soon as electrical
thermostats shut down) and food stockpiling is probably not realistic (how
many foods require no refrigeration for storage and no heating for
preparation?)

Given the heavy business emphasis in other areas, it is odd to note that the
concern for transportation is limited to personal travel in chapter four.
While a sudden transition to telecommuting would have a major effect on
business (and be impossible for some), the failure of shipping is much more
serious.  Chapter five's assessment of the banking industry could be
responsible for a run on the banks, itself.  (The advice to keep hardcopy of
all transactions in the months preceding and following December 31, 1999 is
very good.)  The problems of the advice regarding food in chapter six have
already been addressed, since the material basically repeats, in more
detail, what has already been said elsewhere.  Home computer problems are
really only looked at in terms of business use of PCs in chapter seven.  I
am rather interested to note that the Internet does not get a mention either
in regard to personal computers or in relation to news and information in
chapter eight.  The overview of medical care, in chapter nine, is solid,
careful, and useful.

While I agree that government is one of the largest, and most tardy,
potential victims of Y2K, chapter ten is shortsighted in seeing it
only as a provider of cheques.  As with much of the rest of the book,
the information in this section is US-centric, although similar
concepts apply elsewhere.  Chapter eleven reviews embedded computers,
but only broadens the scope of what could happen in other areas.  This
material should probably have been included earlier in the general
discussion of the problem.  Education, as all too often, seems to be a
bit of an afterthought, but some important points are made in the
relatively short chapter twelve.  Chapter thirteen notes that
communication is an obvious target, and so most likely to be
adequately addressed by the deadline.  That is good, since the book
gives no realistic advice for fallback positions.  (A cell phone will
be just as dead as a land line if all the switches are down, and is
much more likely to have problems in the handset.)

Despite the many shortcomings of the book, I do feel that it should be read
and considered by a good many people.  The books and articles currently
extent concentrate on the problem and necessary solutions from a systems and
technical perspective.  There is a need for some consideration about
personal actions that can be taken to ameliorate potential problems.
Hopefully this discussion can have some rationality behind it: producing a
run on the banks or dry soup mix in December '99 will help nobody.

copyright Robert M. Slade, 1998   BKTMBM2K.RVW   980531

New Jersey Y2K car inspection stickers

On the lighter side of the Y2K problem, I recently received the following
letter from the New Jersey Division of Motor Vehicles:

  Dear Motorist:

  Due to law enforcement concerns over the similarity of the green, year
  2000 inspection stickers with the recently expired green stickers
  issued in 1997, the Division has discontinued use of the green sticker
  and is replacing it with a new orange, year 2000 sticker.

  Our records indicate that a year 2000 sticker was issued for your
  vehicle earlier this year ... We will replace your present sticker
  with a new orange one.

At least we have the New Jersey government sticking it to us on year 2000
compliance.  Still, even with a new orange Y2K sticker, I wonder if my car
will be truly Y2K compliant.

Dan Wallach                  Princeton University, CS Department
dwallach@cs.princeton.edu    http://www.cs.princeton.edu/~dwallach/

  [Crockwork Orange?  PGN]

Bug-free millennium for Railtrack

According to *The Guardian* (30 Jul 1998), Railtrack which was formed out of
the old British Rail has no safety critical computer systems that need to be
debugged.  This is a legacy of underfunding over the past 20 years before it
was privatized.  The article quotes Railtrack as having 750 manual level
signal boxes, 250 power boxes introduced in the 1980's and 9 electronically
controlled boxes.  It has therefore decided to downgrade it's preparation
for the year 2000 as it rushes forward; out of the steam age.

Mike Ellims, Pi Technology, mike@pires.co.uk www.pi-group.com +44(0)1223441256

White House Calm, DoD Nervous About Y2K

http://cgi.pathfinder.com/netly/0,2326,201980729-14220,00.html
TIME.com / The Netly News, 29 Jul 1998

White House Calm, DoD Nervous About Y2K
By Declan McCullagh (declan@well.com)

Few were surprised when John Koskinen, the White House's Y2K czar, said
yesterday that "it's too early to say that in fact there are going to be
major disruptions" due to the Year 2000 problem.  Koskinen's
work-hard-and-don't-be-scared advice is what the Clinton administration has
been saying all along.

But some of the Y2K experts Koskinen brought with him to a National Press
Club briefing yesterday offered some dismaying details. Usually if, say, a
4,000-megawatt power plant gives up the ghost, it's no big deal. The
electric industry is pretty good at planning for these sorts of
breakdowns. But if dozens crash within a few hours on 1-1-00? "It's a very
complex system," admitted Michael Gent, president of the North American
Electric Reliability Council. "It's probably the most complex system every
invented by man, more complicated than a moon shot." Gent nevertheless
predicted that even if today were December 31, 1999, "the lights would stay
on in most places."

If they go out, it'll be the fault of the private sector, not the feds,
Koskinen said.  Contradicting the now-popular belief that the federal
government's computers are in the worst shape, he predicted that "the
threats to the economy and the public are not going to be federal systems."
[...]

Already prepared to accept his part is John Hamre, deputy secretary of
defense. "I think we're probably going to be the poster child for failure,"
he said last week during a speech to Fortune 500 executives.  "Nobody cares
if the Park Services computers don't come on. OK? But what's going to happen
if some do[n't] in the DoD?"

Y2K OK on Wall Street

A ten-day-long test by the Securities Industry Association's Year 2000 project found no problems during a simulation involving 29 brokerage firms, all major stock exchanges, and the corporations that conduct trades for them. Project manager Leslie Tortora hopes that the success of the project will encourage a similar effort by telephone companies, and says: "People are feeling good. An enormous amount of energy and preparation has gone into making this successful." (*The New York Times*, 23 Jul 1998; Edupage, 23 July 1998)

[Excuse my using Edupage so extensively in this issue. John Gehl & Suzanne Douglas do a marvelous job of summarizing many topics, and their last two issues just happen to hit RISKS paydirt. To subscribe to Edupage: send mail listproc@educause.unc.edu with the message:

subscribe edupage <your name>.

If you have subscription problems, send mail to manager@educause.unc.edu. PGN]

No Y2K insurance for household electrical items

I just heard on the radio that all UK insurance companies have decided not to pay out any household claims arising from y2k issues affecting household items. Considering a lot of people own TV, Video, Hi-Fi all of which have date sensitive internals it seems as though a lot of people may be out of pocket come 1/1/2000. I'm not an expert on the internal systems of household appliances, but I would have thought particularly videos will encounter problems due to their reliance on clocks for recording programs. There is also an increasing trend towards integrating TV/Video functions and on screen menu functions rather than the older analogue (Y2K compliant!) switches.

The risks? Integrating date dependent functions (video programming) with other things (tuning via menu systems) just to get it all on the same remote control. Also a risk is expecting companies / insurance agents to honour claims for "malfunctioning" equipment.

Re: Y2K contingency plans (RISKS-19.88)

Rob Bailey in RISKS-19.88 adds hard data to Frankston's observation that preparations are not being made to handle unexpected problems on 00-01-01. (Apparently, what few bureaucrats admit the problem are not willing to say it can't be completely solved in advance.)

My counter-argument (to the bureaucrats, not my esteemed fellow Risks-contributors) is as follows:

1. No release of a new version of software has ever gone completely smoothly. Even if no new internal bugs are introduced (ha!), unexpected external conflicts will arise (incompatibility with other software, incorrect user responses to interface changes, etc.)

2. The more changes are made (between previous versions & a new release), no matter how small, the more unexpected problems there will be, and the harder they will be to find.

   (These are from experiences at a critical site running 24/7. After too many call-outs on weekends to fix bugs in new releases, we implemented a policy that production releases ready after twelve noon on Thursday must be delayed until the following Monday.)

3. 00-01-01:00:00 will be the equivalent of the world's biggest release of new software in history. *Every piece of code* will be run for the first time under real-world y2k conditions *simultaneously*.

4. Even if every application tested perfectly individually under y2k conditions (ha!), unexpected slight changes of operation would cause major, perhaps massive, disruption.

The solution? Continue finding and fixing as many y2k problems as possible, but be sure to have extra (massive?) support available on 00-01-01:00:00 to fix critical problems.

Re: Y2K contingency plans needed (Frankston, RISKS-19.85)

That's what I thought, too. The point was raised over on the Emergency Management Net distribution list that lots of talk about identifying and fixing the problem had taken place, but that the emergency management community as a whole had been pretty much ignoring the problem of response and damage mitigation to a problem that is 18 months off (and, unlike all other disasters, can be timed quite accurately on any calendar).

In response, <VanceB4660@AOL.COM> wrote that "[t]he Y2K bug seems to mostly lurk in old COBOL code." So I decided to offer a couple of examples that had been brought up here in Risks and some pointers in the Web to embedded systems that might / will fail on Y-day. I was pounded with criticism. The most poignant attack came from <stevew@ENG.ADAPTEC.COM>, who opined that I was promulgating unfounded "Fear, Uncertainty and Doubt". Steve went on to add that "[a]ll in all, [he's] not really that concerned about Y2K."

With that attitude, it's no wonder that little if anything has been planned by the emergency management community in response to the 01-01-01. For example, FEMA has implied that few or no Y2K-*specific* preparations have been made; instead, FEMA will rely on the national response plan to deal with the (alleged) emergency like any other emergency. I hope it works; unlike others, all in all, I *am* really concerned about Y2K.

Y2K dig-gerel

Millennium Panic
Michael H. Brill, 5 June 1998

The Bug hangs off in distant skies
And stares with double-O for eyes,
Between my digits now. But soon,
It hides itself behind the moon.
Emerging on the other side--
New-grown, and much too large to hide--
It grows again. I see it nears,
Igniting all my primal fears.
(But no-one else sees this display;
They're deep into their business day.)

With jaws agape and wings unfurled,
This Bug's about to eat the world!
Now sages see the ghastly form,
And mumble that it's just the norm:
"The 'Bug' is just a trick of lights,
A cloud of dust, or must--or mites."

As evening comes, arachnid pall,
It scarcely dims the sun at all.
Though jaws envelop all the sky,
I see through them the planets fly.
Orion studs the frigid night.
I feel no heat; I find no light.
Our world, the lifeblood that we've prized
With digitalis paralyzed.
The ichor from the jaws has spread
In smaller things beside my bed.
Outside, crowds mad with fear and pain,
For lack of power their kin have slain.
As gun-filled hands my door break through,
The sages' echoes all ring true.

"They're right," I sigh with my last breath.
"A cloud of 'mights' has brought my death."

Y2K as a necessary event: Contingency plans needed

In my ongoing role of being the naive* contrarian ....

I'm concerned about all the Y2K discussion that focuses on prevention and
little, if any, discussions of contingency plans. This represents a basic
misunderstanding of how to deal effectively technology. I use the term
"ballistic automation" for the clockwork-like model of automation in which
one sets up all the rules and the system just runs without ongoing
intervention and tweaking.

In any system, there will be surprises and failures. While prevention is
great, it is never complete. Instead one must prepare for failures. We must
assume that there will be pervasive Y2K failures. The question is how do we
survive and recover from them. Such planning has a higher value than Y2K
prevention in that they basis for resilience that can deal with failures in
general and, as a side benefit, provides better security since security
breaches are simply failures.

And Y2K is only one of many problems. There are many limited-size fields
including other clocks (like the Unix one due to expire in 2037?)

Systems do not deal with events that are unanticipated and have difficulty
with those anticipated but not experienced.

One simple example the response zip code changes. Read
http://www.boston.com/dailyglobe/globehtml/193/
Post_office_delivers_new_codes.htm
for more on the zip code changes in the Boston area.

It took years for phone systems to learn to deal with area code changes and
generalized area codes. But no one has heard of a zip code change. When I
provide my new zip code on e-forms, it gets rejected by systems that do
checking. Even mail from the Post Office itself uses the old zip code. Not
only is the zip code changing but it will be recycled within a year or so!
Hopefully, unlike the phone network, I'll still be able to get mail in the
future since the Post Office does have some resilience in that it tries to
handle failures with manual intervention (for now). But the more general
principles of systems design need to percolate from what we've learned in
designing systems into more the more general awareness of design issues. The
zip code system, for example, was designed without leaving extra zip codes
for future growth!

While on the topic of the Post Office, there was another article
<http://www.globe.com/dailyglobe/globehtml/193/
Errant_mail_delivery_brings_bagful_.htm>
about the consequences of unreliable delivery. The concept of end to end vs
link level reliability is something we've learned in the design of computer
systems <http://www.reed.com/Papers/EndtoEnd.html>. Again, this experience
needs to feed back into low tech systems.

There are indeed risks of technology. But there are also risks of
nontechnology. We must understand the risks but shouldn't be naive to assume
that we can choose a risk-free path. And we must learn that we only anticipate
some changes and need to "shake out" systems periodically. Just like we've
learned that value of forest fires, Y2K might help in clearing out the
underbrush.

* I'm not really that naive, but a nonnaive discussion that goes into all the
issues would be too long and boring for this forum.

Y2K problem worries CIA

Central Intelligence Agency director George Tennant is warning that the Year
2000 computer bug (found when programs are unable to correctly interpret
dates past 1999) "provides all kinds of opportunities for someone with
hostile intent" to gain information or plant viruses.  "We are building an
information infrastructure, the most complex the world has ever known, on an
insecure foundation."  (*USA Today*, 25 Jun 1998; Edupage, 25 June 1998)

Galaxy IV, 600 days and Y2K

The following item is from Dennis Elenburg, "The Y2K Weatherman",
delenburg@y2kwatch.com, http://y2kwatch.com/, 1 July 1998,
re: the Galaxy IV failure, RISKS-19.75-77]

"Well, yesterday in talking to an engineer, I heard that the source of the
problem was a 600-day date window.  Bottom line, according to this
particular engineer, is that Galaxy IV was taken out by a Y2k-like glitch.
The recovery from the loss of this (single) satellite was pretty impressive,
but what happens when we lose several satellites at the same time?  Will we
be able to recover communications then?"

[The list he refers to is his own Y2K Weatherman Report.  I imagine that
readers of RISKS would also be very interested in more information on this.
Ben Torrey, rgtorrey@connix.com]

No manual switching for railroads; result, famine

This is an excerpt from the CSIS Y2K conference.

Gary North's Y2K Links and Forums   Summary and Comments
Category:         Shipping_and_Transportation
Date:         1998-06-24 19:34:02
Subject:         No Manual Switching for Railroads; Result, Famine
Link:        http://www.csis.org/html/y2ktran.html#simpson

At a June 2 conference on y2k sponsored by the Center for Strategic and
International Studies, Alan Simpson confirmed what I have been saying for
over a year: the trains will go down. He said that the railroads have
abandoned manual controls.  "Going back to the rail system, they've taken
out manual points. I talked to some of the major rail companies a few days
back and said, 'Go to manual.' And they said, 'All our manual points are in
the warehouse up in New York State waiting to be disposed of. We cannot
switch manually anymore. We have taken out manual reversion systems on most
of our key communication, power, and switching systems.' " Conclusion: * * *
* * * * * * * And a few weeks ago he started looking at this, and it was
Bruce Webster here who mentioned about, in one of his presentations, the
could-be famine in the United States in 2000. And like most of you here I
thought rubbish, rubbish, until we started looking at the infrastructure and
started the wildfire scenarios on what if.  And looking at New York and
California, I walk into a supermarket and I get lettuce, fresh vegetables,
any day of the year. Seven days ago they were in a field in California. Now
they're in a supermarket just outside New York. We know the switches on the
railroads are faulty. We know because of mergers, even today, many of the
major corporations in the railroad business don't know where the railway
stop is.  When you move this way through, come 2000 you could have a
scenario -- and when you look at this, it's the Soviet Union in the '80s --
where there's plentiful supply of food in the fields, but you can't get it
from the fields to the towns to feed the population. This is not a way-out,
whacko scenario. This is for real.

REVIEW: "The Year 2000 Software Problem", Capers Jones

BKY2KSWP.RVW   980410

"The Year 2000 Software Problem", Capers Jones, 1998, 0-201-30964-5,
U$29.95/C$41.95
%A   Capers Jones
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D   1998
%G   0-201-30964-5
%I   Addison-Wesley Publishing Co.
%O   U$29.95/C$41.95 416-447-5101 fax: 416-443-0948 bkexpress@aw.com
%P   335 p.
%T   "The Year 2000 Software Problem: Quantifying the Costs and
       Assessing the Consequences"

    "When the twentieth century ends, many software applications
    will either stop working or produce erroneous results since
    their logic cannot accept the transition from 1999 to 2000,
    when the dates change from 99 to 00 ... The costs of defending
    against litigation and lawsuits can approximate half a year's
    software budget, but damages and penalties from suits that are
    lost can reach multiples of annual software budgets and lead
    to bankruptcy ... Unfortunately, current data indicates that
    at least 15% or software applications will not be repaired in
    time."  - from the Introduction

This book is a warning.  By its own admission, however, it comes too
late.  Is this book simply an insightful and focused locking of the
barn door after the horse has left the building?

Chapter one provides an executive overview of the situation.  It shows that
year 2000 repairs should have started some time ago.  However, it does also
demonstrate that it is barely possible to start such repairs now, provided
heroic measures are undertaken.  It also proves that such repairs then would
have been much less costly than the same repairs now, and furnishes rough,
but well supported, estimates of costs for the repair of applications, and
for the failure to repair.  A historical review in chapter two also notes
that there is a benefit to the year 2000 problem: it will force companies to
pay attention to their software inventory.  Chapter three is rather odd,
defining a handful of terms associated with applications development.  The
common metric for year 2000 work is the number of lines of code to be
checked.  Jones prefers the function point, and chapter four looks at
conversion factors plus a glance at the size of the problem as a whole.
However, it also starts to deal with direct and indirect costs, particularly
in regard to litigation, and loses some focus thereby.  Chapter five is a
very thorough (perhaps at times overly thorough) assessment of the total
impact of the Y2K problem on the United States, looking at the total cost,
and cost by state, industry, programming language, and so forth.

Advice on the actual fixing of the problem starts with program testing
in chapter six.  Chapter seven looks very briefly at database repair.
Litigation and liability is reviewed in chapter eight.  The analysis
of business failure risks, in chapter nine, seems to lean heavily on
litigation as well.  Chapter ten discusses the rise of the year 2000
repair industry.  Retrofitting applications by the use of masking or
windowing is mentioned in chapter eleven.  The heavy United States
emphasis of the book is partially rectified in chapter twelve.  The
analysis of the scope of the project by country is somewhat flawed by
assumptions that figures per line of code can be directly converted
from US surveys.  However, the chapter also looks at the impact of
conversion to the Euro (the new European currency) and the diverse
impact this may have on the problem as a whole.  Chapter thirteen
looks at factors that modify costs for various industries.

Chapter fourteen examines a number of problems that may arise in
various sectors if the problem is not fixed in time.  A review of
general defensive tactics is contained in chapter fifteen.  Appendices
B, C, and E contain additional sources of information.

In general terms, the book does not give much in the way of advice for
dealing with the crisis except for the suggestion to use masking in
preference to date field expansion.  However, it does provide you with
some lovely frightening figures to use next time the CEO asks you if
this Y2K thing is really of any importance.

copyright Robert M. Slade, 1998   BKY2KSWP.RVW   980410

Shuttle imaging Y2K problem? (O'Leary via Wood, RISKS-19.81)

>There is a Year 2000 problem with the SIR-C processor ...

Once in a while, economics has something to contribute to RISKS issues.  It
sounds like the SIR-C processor is functioning as what economists call a
"public good".  If the manager of the SIR-C processor doesn't have the
resources to contemplate a fix, perhaps the user community does.  The
problem is determining how much the user community would be willing to pay.

Academic economics has pretty much solved the problem of obtaining accurate
bids for a public good.  This is generally done with a "Groves Mechanism"
(see Groves, T. and J. Ledyard, 1977, "Optimal allocation of public goods: a
solution to the `free rider' problem", Econometrica 45, 783-811.)  This is a
bidding scheme where it can be proved that the optimal strategy for the
bidders for the maintenance of a public good is a truthful assessment of
what the good is worth to each bidder (which economists equate with the most
the bidder would pay).  If the sum of the bids exceeds the cost of the
public good, each bidder is asked to pay an amount less than or equal to
their bid.  But the mechanism rigs the game so that bidding more than it's
true value is likely to result in bill for more than it's worth to you,
while bidding less will not change the amount you are billed, but may cause
the entire project to be scrapped for insufficient community interest.

Daniel A. Graifer <dgraifer@cais.com>

World shipping full-speed ahead to beat Y2K torpedo

Reuters reports that world shipping is at risk from the Y2K problem, with
much work yet to be done.  Many aspects of merchant shipping are now highly
dependent on computers, many of which are not yet Y2K compliant.  The
increased computerization has resulted in sharp cutbacks in crew sizes, but
also leaves a shortage of people familiar with old-style backups (sextants,
Morse code, etc.).  Malcolm Gosling, who heads Electrical Services at Royal
Dutch's Shell Trading and Shipping Company, said that Shell had tested
systems on Very Large Crude Carriers, and found Y2K-related failures in
seven areas including radar system mapping, ballast monitoring, and ships
performance monitoring.  Gas carrier computer systems had also tested badly.
At airports where Shell delivered supplies, failures due to Year 2000
problems included flow metering, fire alarms, and climate control.  [Source:
Reuters News Service, 16 June 1998; PGN Stark Abstracting]

Will we have power on Jan. 1, 2000?

A Senate Y2K committee (whose chairman believes that if today were 1 Jan
2000, the nation's power grid would collapse) heard testimony from utility
experts who were not able to promise that power would remain available in
the U.S. when the Y2K date rolls around.  [Source: MSNBC, 12 June 1998, PGN
Abstracting.  Incidentally, a House hearing on 16 June 1998 considered the
Y2K threats to the telecommunications networks.]

Re: 15th century time machine and Y2K (RISKS-19.79,81)

The London Times of Monday June 15 1998 has further details of this device,
including a picture. Archive copy available at http://www.the-times.co.uk/ .

Steve King, Dept of Computer Science, University of York, Heslington,
York YO10 5DD UK   king@cs.york.ac.uk   phone 01904 433068

  [Original URL not valid.  Changed in archive copy.  PGN]

Shuttle imaging Y2K problem?

  ---------- Forwarded message ----------
   [Multiple (at least 5) forwardings deleted.  PGN]

[[ The "SIR-C processor" is big wad of custom hardware.  SIR-C was the
   3rd Shuttle Imaging Radar mission -- the premiere unclassified
   spaceborne imaging radar dataset.  Looks like it's about to go
   write-only ...  /Frew ]]

>From: Ellen O'Leary [mailto:ellen.oleary@jpl.nasa.gov]

There is a Year 2000 problem with the SIR-C processor and it is unlikely
that there will be funds available to fix it.  The purpose of this e-mail
is to let you know this so, that you can request SIR-C data processing
before this problem shuts the processor down.

You can request SIR-C data processing over the World Wide Web at:

http://edcwww.cr.usgs.gov/landdaac/sir-c

Please try to space your requests out over the next year or so in order
not to overload the processing team at EROS.  Please pass this along to
others who might like to know.

Ellen O'Leary, Jet Propulsion Laboratory, 4800 Oak Grove Drive
Pasadena, CA 91109   1-818-354-7250 ellen@kahn.jpl.nasa.gov

Re: 15th century time machine and y2k (RISKS-19.79)

Are they trolling?

(a) if it was a 15th-century invention, it would have been built in the
1400s, not in 1600

(b) how did it handle September 1752?

(c) a report from an unnamed "Japanese press" outlet describing a similarly
unnamed museum in Liverpool, England?

  [On (a), Off-by-one errors are very common in naming centuries.  And this
  is only an off-by-one rather than off-by-two.  Ignoring us computer folks
  who like to count from 0, 1600 was the last year of the 16th century.
  On (b), Obviously it didn't.  but that was only a slip of a bunch of
  days and  one doubts that this thing was accurate enough to worry
  about that -- not to mention leap-second corrections.
  On (c), Apparently nando.net's logo confused our contributor?
  And then there is (d), This whole item was rather whimsical anyway.  PGN]

Hinweise