* * * 19990525 Tuesday

Subject: HELLO! ... Southwestern Bell ... Shutdown Date of Sept 1, 1999?!?

This received from the offspring of a Southwestern Bell engineer ...

Can anyone--in the telecom industry!--corroborate/"illuminate" this data corruption situation? (I understand the concept; seems to be a reasonable pre-management action.)

Where's the media on these Y2K "bones," folks?!? The "skeletons" will emerge from the closet LONG BEFORE 01/01/00! This one could be THE Y2K wake up call. Nothing like having rationed electricity when a large percentage of the power grid is "shutdown" pricking the DWGI's bubble!

Hmmm... I wonder If __this__ is why the Military has cited September 1, 1999-March 31, 2000 as their chosen Y2K Alert Window?! I thought it curious--that September 1, 1999 date.

Air Force bases in Japan did a "black out" (no electricity!) exercise all day Friday, May 21, 1999. Used "runners"--pre-telephony days style--in lieu of "electrical" communications. Perhaps __they__ DO know something WE DON'T?!

Regards, Bob Mangus

* * *

From: [Sender Info Deleted] To: Subject: Hi Date: Tue, 25 May 1999 16:39:59 -0400

Just wanted to let you know I read some of your emails on Y2K on Millennium Salons.... and I think you are right on.

My dad is an engineer at Southwestern Bell and they have accumulated 2 months worth of fuel already and still getting more. They also have a shutdown date of Sept 1, 99 because the following ninth is going to send them reeling.... So they are shutting anything down that is possible non-compliant, (which is a huge percentage) just to keep from sending misinformation to the new systems.... And they still expect major problems... my dad is in charge of four states including Texas, how is that for utility interruption, (dad is personally prepared for a long time).

Talk to you soon

[Signature Block Deleted]

* * *

-- Robert Mangus (rmangus@hotmail.com), May 25, 1999

Answers

As much as I believe that we are going to have big problems coming up with the Y2K rollover, the September 9, 1999 date -- that is, "9/9/99" (or perhaps "09/09/99") -- has always been more in line with old COBOLesque applications, not the things that are going to cause power outages, etc. Of course, "nobody knows", but if anything I would be a lot more worried about what Aug 22, 1999, is going to do when the GPS system re-sets -- this has not had a whole lot of attention, unlike other Y2K-like problems.

-- King of Spain (madrid@aol.com), May 25, 1999.

* * * 19990525

King of Spain:

Get off the throne... Your "contribution" wastes bandwidth...

... I knew the "9/9/99" concept... stating so to avoid lame "contributions" that add no value to the thread...

That's why I specifically requested and designated soliciting a response from someone "in the telecom industry!" *Sheesh*

BTW: "9/9/99" IS NOT ONLY COBOLESQUE. THIS METHODOLOGY IS LEGACY GARBAGE FROM MACHINE LANGUAGE DAYS, PRE-DATING COBOL--BUT PERPETUATED AD NAUSEA.

Regards, Bob Mangus * * *

-- Robert Mangus (rmangus@hotmail.com), May 25, 1999.

Mr. Mangus,

Do you also read your SPAM? This E-mail came from someone you obviously don't know. As King of Spain suggests, the information included is sketchy at best and irresponsible at worst. It's my opinion that September 9, 1999 will come and go just as April 9, 1999 came and went. If I find my telephone service disconnected, I'll have to assume that it's because I forgot to pay the bill...AGAIN [grin]

Anita

-- Anita Spooner (spoonera@msn.com), May 25, 1999.

* * * 19990525 Tuesday

Anita:

Obviously you have never worked a Y2K project and observed an application fail ( e.g., HALT, KAPUT, FREEZE, ET AL ) processing the April 1, 1999 or September 9, 1999 dates.

I have! These are real timebombs! Victims are undertaking operations in deceipt, at any expense--I've seen _that_ firsthand, too--to avoid public disclosure. Employees know these events have taken place. It's the door if they dare disclose the facts.

Your denial is no reason to stop searching for the Y2K truth.

BTW: That must be a large throne the King of Spain has ... *wink*

Regards, Bob Mangus * * *

-- Robert Mangus (rmangus@hotmail.com), May 25, 1999.

Wow, Bob, finally!

For my edification, could you relay just what caused the application to FREEZE, KAPUT?

Sept 9, 1999 I've seen as a problem with user entered dates, as flags. But yet to see, or for that matter really figure out what type of code could, cause the application to crash. Especially with April 1, but also with Sept 9.

Care to share?

-- Hoffmeister (hoff_meister@my-dejanews.com), May 25, 1999.

* * * 19990525 Tuesday

Short for the Pollys ...

The subject systems ( financial... could be any flavor! ), while undergoing Y2K testing using data date-aging input and/or system date in the transaction dates--contained executable code that processed these transaction/system dates ( of different formats; Julian and US formats ) as EOF [End Of File] triggers; thus, rendering the systems useless for their intended purpose.

Get a grip... You must be of management cloth... They could never grasp the concept until they saw the test regime and RESULTS!!

(Editorial) We all hope Polly-"edification" has been fulfilled and will be appropriately reflected in future Polly-posts... *wink*

Regards, Bob Mangus * * *

-- Robert Mangus (rmangus@hotmail.com), May 25, 1999.

*I*'m not management...are YOU, Hoff? I STILL purport, Mr. Mangus that for this event to occur would require BOTH zero compression in addition to THIS particular field being used as an EOF marker. In my mumble, mumble years of experience with languages going back as far as Assembler, Fortran and COBOL, I've NEVER programmed (nor SEEN programmed) anything like these two circumstances coinciding.

If *YOU* have programmed these two circumstances to coincide, or seen code that DID program these two circumstances to coincide, please fess up to exactly WHERE.

Thanks in advance,

Anita

-- Anita Spooner (spoonera@msn.com), May 26, 1999.

Well, Anita, (mumble) err, Project Management.

Gotta concur. This gibberish about 99099 and 090999 signalling end of file has been around for awhile, but as yet, never seen, or seen posted, an actual example.

Cory tried to make up an example on c.s.y2k, but it was so foolish it had to be a joke.

Could it happen? Heck, anything is possible. Which is why I was so interested to hear of a bona fide example.

Don't happen to have the code, or remember enough to post an example, do you Bob?

-- Hoffmeister (hoff_meister@my-dejanews.com), May 26, 1999.

* * * 19990526 Wednesday

Intimidation by ad hominem and putting words in my mouth does not change a single line of defective code... *SIGH*...

Anita:

I never stated that these trigger events were "circumstances coinciding." _That_ is your fabricated distortion and/or diversion!

The generic events I describe ocurred separately, independently, in different processing modules.

I also never stated that I had personally originated/authored/condoned the offending code. I _have_ provided _MAINTENANCE_ consulting services to clients that had such relics with such coded abominations. Often these applications systems were composed of many different languages, kluged together, using "consistent" control methodologies. The system specifications, in fact, reflected these (common in those days) control conventions.

Hoff-sh-eister:

Your lack of experience has nothing to do with the ugly realities of bad "gibberish" computer date code specifications. You are vindicated! *wink*

The "gibberish" and madness of EOF ( End Of File ) conventions is _NOT_ A "JOKE" and often referred to ( in pajorative terms, measured against today's "higher-ordered" conventions ) as "DATA ELEMENT OVERLOAD." ( I've described it on this forum in the past with no rebuke! ) That is, different classes of data ( a pseudo-date in this scenario ) element/field used for more than one purpose ( e.g., Subscriber Date or EOF [trigger] ). The rationale for this "gibberish" ( aptly named, by the way ) was: 1) saving precious space ( "real estate" ); 2) these dates were "invalid dates" ( FUTURE and "foolproof" ) in the contexts of design and era ( circa 1960's-1990's ). These are "bona fide" example situations!

Today, unfortunately, these legacy systems have ported from platform to innumerable platforms ( sometimes! ) as "SOURCE" ( transliterated and/or cloned ) and/or "OBJECT" ( direct; executable ) code containing the "offending" ( once the actual date has elapsed; e.g., IF SUB-DATE-MO-YR LESS THAN [ "0999" | {ANY ARBITRARY "FUTURE" DATE} ] THEN... ; ). No "foolish" example, this!!

[Note: If Cory Hamasaki was unable to give an example as straight forward and self-explanatory as the above... Well, I'll just say his programming skills must be of recent vintage with little or no maintenance on legacy systems. Perhaps someone will extend the courtesy of sending Cory this example for future clarifications for incurable "Pollyannas."]

It is professionally unethical, sacrilegious, and sacrosanct, not to mention a breach of widely accepted industry non-disclosure standards/agreements, to compromise/divulge proprietary code. ...Even to/for "Pollys." *wink*

... Yo', Ed Yourdon...

A little help ( corroboration ) getting these "Polly"-gnats off my hide? _You've_ written a lot of books over the decades re the good, the bad, and the ugly of systems/code standards and practices.

Anita and Hoff-sh-eister will have to settle for this, for now...

Regards, Bob Mangus * * *

-- Robert Mangus (rmangus@hotmail.com), May 26, 1999.

Bob, Unfortunately, the 5 or so systems (multiple programs within each) that used the all nines in the date field, truly used ALL nines as EOF. NOT 09999 [Julian PIC X(5)], OR 090999 [PIC X(6)]. JUST 99999, or 999999.

Sorry about that, Chief. Just my US$.02.

Chuck CR

-- Chuck, a night driver (rienzoo@en.com), May 26, 1999.

IF SUB-DATE-MO-YR LESS THAN [ "0999" | {ANY ARBITRARY "FUTURE" DATE} ] THEN... ; ). No "foolish" example, this!!

Where does "1098" fall in your GOOD example? Oh, you were writing "pseudo-code". That explains it. You didn't mean to compare the month first. Who needs details when you're trying to make a point?

-- br14 (br14@south.bell), May 26, 1999.

Hoff-sh-eister: Aw, c'mon, at least be original! Your lack of experience has nothing to do with the ugly realities of bad "gibberish" computer date code specifications. You are vindicated! *wink* Whoa there. My lack of experience? Granted, I don't have the collective memories of punchcards and abacus's, but done quite my share of systems coding. Haven't always been managing projects. The "gibberish" and madness of EOF ( End Of File ) conventions is _NOT_ A "JOKE" and often referred to ( in pajorative terms, measured against today's "higher-ordered" conventions ) as "DATA ELEMENT OVERLOAD." ( I've described it on this forum in the past with no rebuke! ) That is, different classes of data ( a pseudo-date in this scenario ) element/field used for more than one purpose ( e.g., Subscriber Date or EOF [trigger] ). The rationale for this "gibberish" ( aptly named, by the way ) was: 1) saving precious space ( "real estate" ); 2) these dates were "invalid dates" ( FUTURE and "foolproof" ) in the contexts of design and era ( circa 1960's-1990's ). These are "bona fide" example situations!

Today, unfortunately, these legacy systems have ported from platform to innumerable platforms ( sometimes! ) as "SOURCE" ( transliterated and/or cloned ) and/or "OBJECT" ( direct; executable ) code containing the "offending" ( once the actual date has elapsed; e.g., IF SUB-DATE-MO-YR LESS THAN [ "0999" | {ANY ARBITRARY "FUTURE" DATE} ] THEN... ; ). No "foolish" example, this!!

Example, "foolish" this is. You are actually claiming to have "seen" production code, that queries a substring of a sub-field of a record, not for a flag such as '9999', but '0999'? And uses this as a flag for EOF? How does this "save real estate"? Methinks you are beginning to confuse some of the Y2k ideas, such as the rationale for using 6-digit dates, with old EOF records containing all '9's.

[Note: If Cory Hamasaki was unable to give an example as straight forward and self-explanatory as the above... Well, I'll just say his programming skills must be of recent vintage with little or no maintenance on legacy systems. Perhaps someone will extend the courtesy of sending Cory this example for future clarifications for incurable "Pollyannas."]

Oh yes. Somebody please send the above paragraph to Cory. Please! Pretty Please!

It is professionally unethical, sacrilegious, and sacrosanct, not to mention a breach of widely accepted industry on-disclosure standards/agreements, to compromise/divulge proprietary code. ...Even to/for "Pollys." *wink*

Naw, Bob. People post snippets of code all the time. Not looking for a full program. But I do understand your dilemna. *wink*

... Yo', Ed Yourdon...

A little help ( corroboration ) getting these "Polly"-gnats off my hide? _You've_ written a lot of books over the decades re the good, the bad, and the ugly of systems/code standards and practices.

Anita and Hoff-sh-eister will have to settle for this, for now...

Yes, I figured as much.

-- Hoffmeister (hoff_meister@my-dejanews.com), May 26, 1999.

I don't think anyone believes that I'm a polly, but this 9/9/99 is ridiculous. And as we've seen with JoAnne effect, fiscal year effects, and the 4/9/99, pointing this out as a "serious problem" only undermines peoples' belief that there really is a Y2K problem.

The other thing that makes no sense about this is that the theoretical 090999 date is a NORMAL event! It's been in the code and used for years! Even if someone could come up with an example, the program would just go to end-of-file early. It might not run correctly, but it's a normal event. Unless it's error handling, and then you'd get a message. Makes no sense at all.

Unless someone can post a snippet of REASONABLE code, we should fight to get this one killed. It's almost as bad as planes falling from the sky.

Now, I have seen code (RPG III) that used the Year (only) = 99 to mean something, but those failed the first of this year. And I'll bet you didn't hear of even one of those...

-- Jim Smith (JDSmith1@hotmail.com), May 26, 1999.

http://datapool.nl/zisisit2.htm

More examples of 2000-related problems

You will recognise it: counting or identifications with 999 or 999999 to mark the end of the file.

Here is a example from a hospital: what might ...., sorry, what happened.

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

From:Bill Donovan]

A couple of hospital clients of ours have noted the following problem on their older, IBM mainframe systems: the code in their order paths automatically subtracts 999 from order start dates, and adds a 999 to order stop dates. The system froze on April 7, because adding 999 yielded 1/1/00 which was less than the order stop date. The systems run purchased code.

Can anybody shed any light on this? Does this sound like a problem with the application code, or is it something in Cobol?

Or might it be in the operating system issue? Thanks ---

Response from Michael Gemer

Sounds to me like a problem in the application. It didn't take great brains on my part to predict that Y2K failures would start to ramp up from April 7th, 1997 - there are so many places in applications (and operating systems) where the 999 days scenario comes up. But it is still scary about seeing it happen in reality.

The more I encounter reality (as opposed to rosy optimism and denial) in this Year 2000 thing the more I am inclined to agree with Gary North.

Our biggest problem to date is awareness (i.e. lack of). Too few systems are falling over with too little publicity to seriously scare people into action.

When the USA entered WWII on the Allies' side in 1941, Winston Churchill recorded in his memoirs that he slept peacefully for the first time since the war started (which, for Great Britain, was 2 years previously). He knew that with the vast industrial resources of the USA awakened to the conflict, that victory was only a matter of time.

I am still waiting for the Year 2000 equivalent of the USA to arrive on the scene. Until then, we struggle on with the best of what we have.

Regards

Michael

< snip >

-- z (zz@zzz.com), May 26, 1999.

OK, I shouldn't get involved in this: I have lunch with my daughter's 2nd grade class (end of school) and I want to be in a good mood, but here we go:

There are applications out there where you DON'T have to type in all the characters of a date, i.e. if it's Sept. 9, 1999, you can enter

(the "/"s would be within the code prompt)

9/9/99 rather than 09/09/99. The code itself will place a 0 before the first nine and a zero before the second nine. I guess this is to cut down on keying time or something. There are lots of date- validation subroutines out there that "fix" entered dates.

Now, if 9999 is hard-coded as end-of-run/file/whatever, it's possible the program will halt (or return from the subroutine) PRIOR to validating the entered date. Had you entered a non-hard-code-trigger date, say 9/8/99, the subroutine would then, (with the date having passed hard-coded edits,) place the 0s in front of the nines before writing to the database 990909, or whatever the date-field format is.

Blast me to hades and back, go 'head. I should mention that I can't imagine 9999 being handed to a piece of code by non-human entry.

-- Lisa (lisa@work.now), May 26, 1999.

Geez, I can't believe that I am actually siding with the pollys here, but there is absolutely no basis on which to generalize the 9/9/99 problem. Its the equivalent of saying that embedded chips will fail due to FISCAL YEAR problems -- its not that it is impossible, but it just unrealistic in any common sense scenario.

And quite frankly, Bob, with all the recent well documented bad news that is coming out (e.g., the 60 Minutes program), offering up these annonymous snips from someone who know someone who is related to someone type posts is almost worthless.

-- King of Spain (madrid@aol.com), May 26, 1999.

Hoff is right about this nines thing.

W h o o s h . . . .

IMO, that will be the sound of September 9, 1999, coming and going without any date-related data-processing problems worth mentioning.

-- Lane Core Jr. (elcore@sgi.net), May 26, 1999.

We've been thru this 9's thing a dozen times here. So far, Chuck is the only tech guy here that has knowledge of systems that use ALL 9's. And again, ALL 9's, not 090999. Anything is possible in this business, but in general I agree, not a problem. <:)=

-- Sysman (y2kboard@yahoo.com), May 26, 1999.

Bob??

Any word from Southwestern Bell??

-- Hoffmeister (hoff_meister@my-deja.com), September 09, 1999.

Just another day in history. Sorry to disappoint you whiners!!

-- (doomersARE@whiners.com), September 09, 1999.