I know that the 9.9.99 date is not getting much play in the media except to say that it is going to be a 'test run' of Y2K glitches. I.E. we can use this thursday as a script to judge the end of the year problems. Besides a UNIX problem, does anyone know specific systems that could be affected by this date/kill code problem? Not just Languages, but actual application/businesses that the code could apply to? Any ideas out there?

-- Billy-Boy (Rakkasn@Yahoo.com), September 07, 1999

Answers

Why UNIX?

-- Lane Core Jr. (elcore@sgi.net), September 07, 1999.

Not a Unix problem. 9/9/99 is a "mainframe" problem. Unix does not have problems until about 2037.

-- Anonymous99 (Anonymous99@Anonymous99.xxx), September 07, 1999.

From my understanding (what I have been told, and I ain't thet shmart when it comes to c'mputers) that UNIX was one of the affected systems..probably wrong, so if so my bad...but the question still stands...

-- Billy-Boy (Rakkasn@Yahoo.com), September 07, 1999.

BB, stay tuned.... :-)

-- Lane Core Jr. (elcore@sgi.net), September 07, 1999.

* * * 19990907 Tuesday

[SET CLARIFICATION ON]

{*sigh*}

The "9-9-99" ( a.k.a., "Nines" ) problem is a _CODE_ problem! If legacy application code is ported ( e.g., transcribed ) from a mainframe and/or coding protocols standards adhered to that mimicked mainframe schemes, the code WILL CREATE PROBLEMS. In most cases that will emerge, the users will be unsuspecting "victims"--surprised when the application goes off into the "Nines" never-never-land.

Unless this CODE is changed in critical mission systems, there will be major disruptions in production environments that will and may be fixed in the ~113 days before the infrastructure implodes.

In my 33+ years of IT experience, I have seen legacy applications that have been ported ( i.e., transferred, translated, moved ) from mainframes to mini-computers and PC platforms without changing a single line of original CODE. This is usually facilitated by using "conversion tools" provided--sometimes free--by the vendor of the target platform as an incentive to move the customer/user quickly and at virtually no expense! Conversion tools can be written to do anything the authors want: convert/translate from COBOL into BASIC into C/C++... ad infinitum.

[SET CLARIFICATION OFF]

The fall-out from "Nines" CODING remains to be seen.

All first Y2K-respondent organizations that I am aware of are prudently "holding" their collective breath and standing at-the-ready for _potential_ September 9, 1999 events!

Regards, Bob Mangus

* * *

-- Robert Mangus (rmangus1@yahoo.com), September 07, 1999.

When talking to our Y2K team I asked if they were testing for the April 9, 1999 problem (this was four days before the date). They said 'no, why should we?' I said to them 'well, its 99 julian date on year 99 which is 9999. Could be a problem'. Boy, did they look annoyed because they hadn't scheduled to test for that (ha, ha). I tried to console them by saying that 'I guess we'll have our test in about four days, huh?'. Serious glances all around. No fallout though. So I guess Y2K can be expected to be a none event then. THAT is a relief!!!

-- ..- (dit@dot.dash), September 07, 1999.

The above "clarification" is almost entirely fantasy. The evidence that all-nines is a code problem is virtually nil.

-- Lane Core Jr. (elcore@sgi.net), September 07, 1999.

My husband witnessed a 9-9-99 "inconvenience" on Saturday. He went to Lowes to buy 1000 fence pickets for his business. The clerk asked when he would like to have them delivered. He said "Anytime next week is fine." She typed in a delivery date of 9/9/99 to the computer and he joked to her "That date will probably shut your computers down." He said she looked at him like he was insane or stupid. Two seconds later he said all the computers in the store went down along with the phones to call in the credit card purchases. The clerk called in a computer guy and in a couple of minutes he restarted the system. She put in 9/9/99 again and the system crashed again. The computer guy restarted the system again. She was about to type in 9/9/99 a third time and my husband said "Why don't you deliver the pickets on Friday?" She put in 9/10/99 and the computers stayed up.

-- kelly (kellyraef@aol.com), September 07, 1999.

* * * 19990908 Wednesday

Beware the Trolls:

'The above "clarification" is almost entirely fantasy. The evidence that all-nines is a code problem is virtually nil.

-- Lane Core Jr. (elcore@sgi.net), September 07, 1999.'

Weasle Words/Phrases:

" ... almost entirely fantasy" " ... virtually nil"

To Lane Core Jr.:

Q.: Which part(s) is/are "entirely fantasy"?

Q.: How do you support your negative--"virtually nil"--re "evidence" of the "Nines" problem?

Personally, I've identified and fixed "Nines" code in COBOL applications for clients. They were happy it was remediated, too!

... TB2K Troll Alert!!

_This_ alleged "Lane Core Jr." smells of Troll ...

Regards, Bob Mangus

* * *

-- Robert Mangus (rmangus1@yahoo.com), September 08, 1999.

Thanks, Mangus. I needed a laugh today. :-)

-- Lane Core Jr. (elcore@sgi.net), September 08, 1999.

I used to work at a crop insurance company that used Cobol and RPG on their AS400. All dates were stored as text not dates, so 9/9/99 (yes they only used 2 digit years as well) was stored as 9999 not 090999 and yes they used code that checked for 9's as end-of-file. When I left they had no plans to remediate because the GOVERNMENT was not going to remediate their side and the file from the insurance company had to match the government's side. My guess is that in their batch processing anything with a date of 9/9/99 or maybe later will not be processed because the computer will think it is done when it hits the first 9/9/99 date. I don't think it will blow up the system, just make a major mess of their data.

Now crop insurance is not life threatening, but this is an example of one company's stupidity and I am very sure there are more out there.

-- Beckie (sunshine_horses@yahoo.com), September 08, 1999.