Here is a little wake-up call for those who think Sept. 9 is just another day. From ABC News.

Worried Up To The Nines

Fair Use

W A S H I N G T O N, Aug. 26  A little-known computer glitch that could cause system failures on Sept. 9  9/9/99  is about to get a lot of attention.

In a kind of dry run for the Year 2000 glitch, authorities and computer scientists worldwide will be scrutinizing networks on that Thursday for any fallout from the so-called Nines Problem.

At issue is the impact of an old programming convention that used four nines in a row  9999  to tell computers to stop processing data or to perform a special task.

In the relatively unlikely case that systems misread Sept. 9 as 9999  without zeros as in 09/09  they might confuse the nines with what programmers call an end of file marker.

Sorting or Totals

Four nines in the date field could also trigger a grand total or a sorting operation, said Jim Kelton, president of Software Unlimited, an Irvine, California, software consulting firm specialized in networks and Y2K.

All nines could be interpreted as almost anything, he said. For instance, the nines might cause computers to disregard data received after Sept. 9, causing a cutoff in the updating of bank records.

The glitch, which the financial industry has been fixing as part of its $9 billion Y2K preparations, could figure in customized applications written in decades-old computer languages such as FORTRAN, COBOL and RPG, experts say.

Robert Banghart, director of development at Unisolve, a Costa Mesa, California, software firm working on the Y2K glitch, said a string of nines long had been used to tell computers to end a routine, or no longer execute certain instructions.

Worst Case: Bad News

In a worst-case scenario, four nines in a date field could spark problems not unlike Y2K, a coding glitch that threatens to keep ill-prepared computers from distinguishing the year 2000 from the year 1900.

The U.N.-backed International Y2K Cooperation Center, a global clearing house for millennium bug data, is using Sept. 9 to rehearse a plan aimed at keeping up-to-the-minute tabs on how the world is faring as it enters 2000.

Its a dry run for the rollover date, said Lisa Pelegrin, spokeswoman for the Washington-based, World Bank-funded center. We will be testing our reporting system.

Y2K Progress on Web Site

That reporting system, to be updated in real time on the centers website, www.iy2kcc.org, ultimately will reflect the input of 170 or more national Y2K coordinators.

On the centers Sept. 9 shakeout run, about 15 countries are expected to take part. For the most part, they are members of its steering committee  Britain, Bulgaria, Chile, Gambia, Iceland, Japan, Mexico, Morocco, Netherlands, Philippines, South Korea and the United States.

New Zealand and Australia, also active backers, are due to report in. Graeme Inchley, Australias Y2K coordinator, told Reuters that he was absolutely convinced Sept. 9 would go by without a hitch.

Y2K Test Center to Debut

Sept. 9 also will mark the first test of a $40 million-dollar U.S. inter-agency Y2K center meant to give U.S. decision makers a round-the-clock view of Y2K problems in their areas of responsibility.

Likewise, on Sept. 8 and 9, the North American Electric Reliability Council, an industry group, will rehearse an emergency scenario to test operating, communications and contingency responses for the Y2K transition.

If all goes well in this drill, the electric utilities can pat themselves on the back; if not, they may be tempted to blame the nines, said Janis Gogan, an information technology expert at Bentley College in Waltham, Mass.

Mitch Ratcliffe, editorial director of publisher Ziff Daviss Y2K website, rated Sept. 9s chance of triggering problems as extremely low because the date would have to be misrepresented  without zeros as in 09/09  in a way that defies logic. The Nines Problem is almost totally a myth, he said.

Copyright 1999 Reuters. All rights reserved.

-- Rockafeller Skank (rocky2k@x-networks.net), August 28, 1999

Bold off.

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

of couse they'll test their bunkers on 9/9, so they can have a scapegoat. BTW, are you really Rockafeller Shank??

-- sarah (qubr@aol.com), August 28, 1999.

I thought Lane Core settled the issue of the "nines" - to the effect that it could not be a problem. Is this current hype resurrection of another straw man that goes down to reinforce the fact that "alleged y2k problems" are all hype?

-- marsh (armstrng@sisqtel.net), August 28, 1999.

Rockafeller(?),

About two weeks ago, Gary North posted a message from Bob Bemer to the effect that 9/9/99 was unlikely to be a serious problem. I sent the following email message to Gary, which he posted on his site (by now, of course, it has scrolled off the listing of "new" messages, and I forgot what category he put it in):

"Gary,

Just saw your posting about Bob Bemer being unconcerned about 9/9/99 problems. I agree with his basic point, but there's a subtle nuance that almost always gets overlooked: the computer system that requires the end-user to enter a date even when the end-user is convinced that the date is irrelevant.

Suppose, for example, that you've filled out an application form to open a new bank account. The account is opened while you're there in the bank, perhaps on a provisional basis, and you give the bank officer an initial deposit of $100. The bank officer gives you some temporary checks, shakes your hand enthusiastically, and tells you how happy he/ she is that you're doing business with them. You take your temporary checks and various other scraps of paper that you've been given, and you go back home, assuming that you'll get your "real" checks in another week or so, at which point you'll start using your account.

A day or two later, the paperwork that you filled out, along with whatever forms were filled out by the bank officer, shows up in the data-entry department of the bank's computer department. There are thousands of such forms waiting to be processed, each one of which has to be entered into a computer system by a thoroughly disinterested, bored, barely-literate 18 year old high school graduate. He/she reads the information from the paper forms, assuming that the information is legible, and enters them into the appropriate fields on the computer screen. In a "modern" system, any errors are flagged as soon as the information is entered, and the data-entry person is required to fix the errors; in an older system, the error messages are not generated until all of the information has been entered and the clerk pushes the "ENTER" key. Thus, if the clerk is using a system that was developed back in the 70s (e.g., a dumb-terminal, character-based terminal system, rather than a more modern "GUI" system running with Microsoft Windows, etc.), he/she might spend 10 minutes entering all of the data about your new bank account, at which point the computer system informs him/her that it has found 19 errors that must be corrected before the account can actually be opened. This puts the clerk into an even worse mood than before, and tends to increase the chances that some or all of the data will be ignored or entered erroneously or maliciously...

Suppose, for example, that one of the required fields is "mother's maiden name" and another one is "mother's birth-date." When you opened the account, you provided the appropriate information about your mother's maiden name, but perhaps you couldn't remember your mother's birthdate. You can't imagine why anyone would need that information anyway, and indeed you're rather annoyed that they should be asking such personal information. So you leave that entry blank on the form, and the bank officer doesn't notice. Thus, when the data-entry clerk starts entering the information into the computer a couple days later, there's a problem: the computer insists on having a date entered, but the information is missing, and the data-entry clerk knows that the information is irrelevant. Or, to say the same thing in a slightly different way: the clerk knows (from trial-and-error experience), and/or from the "tribal folklore" that he/she absorbed during the first few weeks of working in the bank's data entry department) that it doesn't really matter what kind of date you enter into that field. 0/0/00 won't work, because it's a completely illegitimate date, but 1/1/11 will work, as will 2/2/22, or 3/3/33, or 9/9/99 or 12/31/99. Thus, the clerk (and all of his/her fellow clerks in the data entry department) adopts the convenient habit of typing a "phony" date into that field whenever the information is missing on the paper forms. For all we know, the clerk types in a phony date regardless of what's on the paper form, simply because the "tribal folklore" within the organization is that the computer really doesn't care what you've typed.

But the tribal folklore may turn out to be slightly incorrect: it may turn out that some other part of the overall banking system does look at the "mother's birthdate" field, for reasons that may or may not turn out to be important or rational. The significant thing about such entries as 1/1/11 or 2/2/22 or 3/3/33, etc, is that they are dates PRIOR to today's existing date of something/something/99. Maybe the computer has some logic that says "if the mother's birthdate was BEFORE today's current date, then don't do anything at all. But if the mother's birthdate is EQUAL to today's current date, then send her a pre-approved Visa credit card with an approved credit balance of $10,000."

Thus, when September 9, 1999 arrives a little less than a month from now, various computer systems may "wake up" and begin doing all kinds of strange things because the data that had been entered by the disinterested clerk was fundamentally incorrect. It's possible, though pretty unlikely, that the computer system will crash or stop; it's more likely that it will begin doing things that don't make sense, or have embarrassing and costly consequences.

How likely is such a phenomenon? Well, nobody knows ... but the key point is that you won't find such problems by scanning through old legacy code for programming statements that say "If the date-field is equal to 9/9/99, then do X, and Y, and Z ..." instead, you would have to look for situations where the computer logic accepts a date-field entry without doing sufficient error-checking. For example, in the banking situation mentioned above, the clerk may have opened the new account for you on, say, August 14th, 1999 and in the course of doing so, might enter a mother's birth-date of 9/9/99. A computer system with appropriate error-checking logic would notice that your mother has allegedly been born several weeks into the future, and indeed several years after your birthdate; it would thus reject the date as being nonsensical, and would require the clerk to enter a date-value prior to today's date, and prior to the birth-date of the account- holder. But if that kind of error-checking logic has been left out, it might not be noticed until we actually reach the date of 9/9/99.

Given that the computer system has been programmed sloppily without the appropriate error-checking, the interesting question is: what kind of illegal date is the data-entry person most likely to use? As you can imagine, there is no universally-correct answer to this question; it depends on various factors. Here are a few plausible examples:

1. The data-entry person really doesn't care what value he/she types, and is most interested in minimizing the amount of time and effort required to enter the data; this is particularly common in cases where the data-entry person is paid on a "piece-work" basis, which means that he/she wants to enter as many transactions as possible during an 8-hour work-shift. Now, what that really means is that the preferred data- entry values will depend on how the clerk's keyboard is laid out, especially with regard to the numeric keys. On the keyboard I'm using right now, there is a numeric keypad on the right-hand side of the keyboard, and in order to minimize the physical distance that my right hand has to move from the QWERTY portion of the keyboard to the numeric keypad, for entering the "mother's birthdate" field, chances are that I would use 1/1/11 as the preferred value. On the other hand, if the computer system requires me to explicitly type the "/" between the numeric digits, then I would probably use 9/9/99 because it turns out that the "/" character is located immediately above the "9" character on the keyboard. Obviously, different computer terminals have different keyboard designs, so you might see a variety of different choices in this area.

2. The data-entry person doesn't really care what value he/she types, but is convinced that the computer system is idiotic, and that the people who programmed it are consummate idiots. Indeed, he/she feels that every aspect of the computer system is confusing, inconsistent, unfriendly, inefficient, and just downright annoying. As a result, he/ she is happy to take advantage of any opportunity to wreak revenge upon the computer (which he/she views as a living, anthropomorphic entity) and the people who designed it, and the stupid managers who make him/ her use it. Thus, choosing 9/9/99 as a data-entry value is a subtle way for the data entry clerk to say, "Hee hee hee! Look how stupid you are, you idiot computer! I'm typing in a totally nonsensical value, and you didn't even notice it! I hope this throws a real monkey wrench into your processing logic -- it will serve you right for making my life so unpleasant!"

3. The data-entry person is somewhat more aggressively hostile, and thinks that he/she might be able to accomplish an even greater sense of revenge by typing something different into the date-field for every new transaction. Thus, he/she might type "1/1/11" for your bank-account, and "2/3/45" for the next one.

4. The data-entry person is completely computer-illiterate, and has virtually no idea of what's going on "behind the scenes" in the computer. Most of the required procedures, and most of the error messages from the computer, make no sense to him/her, and nobody has ever provided a rational explanation of what's going on. Indeed, nobody provided any adequate training in the normal sense of the word; when initially hired, the new data-entry clerk was told, "Sit by Mabel for a few days, and watch what she does. You don't have to understand what's going on, just do what Mabel does." And if it turns out that Mabel types 9/9/99 for the birthdate of a new account-holder's mother, then that's what the new person will do. Why? Because that's what Mabel did. Why did Mabel do it that way? See explanation #1 or #2 or #3 above, or (recursively) #4.

5. The data-entry person is reasonably intelligent and well-meaning, but does not read or write English. He/she is an illegal alien and works long hours for below-minimum-wage pay. As a result, the data- entry person not only finds himself/herself in situation #4, but is utterly clueless as to what's going on. He/she is not about to complain, or ask annoying questions about the behavior of the computer system, because he/she is terrified of being fired. This may seem bizarre and implausible, but a local merchant here in my town told me of exactly such a situation with his key supplier, whose factory and computer department are based in Southern California. The data- entry people are Mexican immigrants; they're as intelligent as you and me, but they really don't understand what they're doing -- they merely transcribe numbers and characters from a paper form into a computer system whose English-based error messages and displays are unintelligible to them.

Thus, like many other aspects of the Y2K situation, the devil is in the details. It will be interesting to see what really happens on 9/9/99 - - and it's also important to recognize that we may see a rash of similar problems on 12/31/99, since that's likely to be another common choice of "it doesn't really matter what you type into this date-field, so let's just pick an arbitrary date..."

Ed

-- Ed Yourdon (HumptyDumptyY2K@yourdon.com), August 28, 1999.

In case any of you missed this, the name of the game is cred. Credibility. The Kospin'em crowd sets up these big troublesome date challlenges and reports the hell out of them. Then when the non-event passes they herald the successful transition. The sheeple then nod their heads in awed respect of our superhero's the US Gov.

Sheesh. The Sep 9 "problem" promises to get maximum spin as it is the last time they can trot one of these phoney bs tests out. That is why they plan to change the msg. in Oct because by then there will be no denying the problem. The markets should be fully reflecting the liquidity and leper list problems by that time. Got cash?

-- Gordon (g_gecko_69@hotmail.com), August 28, 1999.

This is the biggest crock there is...The reason insurance exclusion begins on 09-09-99 is that ONLY insurance companies have code that OBSOLETE!

I want to see these systems process LIVE Y2k data in PRODUCTION circumstances, where a massive crash stops the show, but doesn't stop the INPUT! In other words, real world!!

-- K. Stevens (kstevens@ It's ALL going away in January.com), August 28, 1999.

Can any one tell me if the date 9/9/99 has been tested for problems by moveing the date on critical computers. Where there any problems detected?

-- R.J. Renolds (time@out.com), August 29, 1999.

* * * 19990829 Sunday

K. Stevens (kstevens@ It's ALL going away in January.com) wrote:

"This is the biggest crock there is...The reason insurance exclusion begins on 09-09-99 is that ONLY insurance companies have code that OBSOLETE!

I want to see these systems process LIVE Y2k data in PRODUCTION circumstances, where a massive crash stops the show, but doesn't stop the INPUT! In other words, real world!!"

...

Insurance companies are _NOT_ the only companies that have "obsolete" {sic} code. Almost any LEGACY IBM MAINFRAME CODE used the "Nines" protocol; there was no alternative. Only the implementation may vary from platform to platform and between the old software "shops."

Some of the old mainframe code has been ported from the older platforms to newer generations of mainframes as well as PCs/Networks maintaining the original functional "integrity" of the code! Sometimes the user/customer isn't aware that their system _is_ a ported legacy mainfram system. Imagine their surprise when they learn?! ;-)

Anyway, the "obsolete" code isn't "broken" yet and still functions just fine. Code is ONLY "OBSOLETE" when IT STOPS DOING WHAT IT WAS DESIGNED TO DO FUNCTIONALLY! _THAT'S_ "obsolete!"

Regards, Bob Mangus

* * *

-- Robert Mangus (rmangus@hotmail.com), August 29, 1999.

The Dreaded Nines: Will They Be so Bad?
More on The Dreaded Nines and Other Proverbial Dates
Unbelievable: Misinformation about The Dreaded Nines

-- Lane Core Jr. (elcore@sgi.net), August 29, 1999.