Can anyone tell me why Jan.28th to Feb. 4th are such important dates in reference to the bug?

-- David Whitelaw (Dande53484@aol.com), January 26, 2000

Answers

There's another issue that may or may not be causing problems right now: EOY processing. An overwhelming majority of U.S. firms have a Dec 31 fiscal year, which means that they've got to start running all of the end-of-year stuff, generating reports, filing taxes, sending financials to the SEC and their friendly banker, etc etc etc.

Obviously, the fiscal year involved with all of this is 1999. But if an accounting system tries to open fils for the next year (in order to transfer balances, etc), then it hits Y2K.

A senior banking official sent me a message right after the rollover, expressing great concern that this kind of problem would be especially common in the small-to-medium companies that may be using outdated, non-compliant versions of accounting packages, or using home-grown spreadsheet/VB/dBase-III code, etc.

Ed

-- Ed Yourdon (ed@yourdon.com), January 26, 2000.

This is just my guess, but I would think a lot of activity with regard to running the first month-end reports of 2000 will be going on from Friday 1/28/00 to Friday 2/4/00.

-- Mike Garland (mgarland@pcisys.net), January 26, 2000.

And it's a very rare leap year.

-- RPGman (tripix@olypen.com), January 26, 2000.

My guess would be that the reason is that the first End-of-Month processing will take place during that time frame. (But then, I also predicted mild, spring-like weather for the southeast this week...)

-- I'm Here, I'm There (I'm Everywhere@so.beware), January 26, 2000.

I've mentioned exactly that range when discussing the January EOM (end of month) reports. Company fiscal periods (fiscal years, fiscal months) don't always exactly match the calendar, so some companies will have their January fiscal EOM on the 28th. Retail, for instance, has 4-week and 5-week fiscal months ending on Saturdays. And any batch run like this can usually be delayed for a day or a few days, if they have problems. So we could see companies STARTING to run these all the way through February 4th (or a little later) depending on their fiscal periods, and they may retry and doing emergency patches for a couple weeks after that, if they run into trouble.

The January EOMs are potentially interesting, because this is the first EOMs in the year 2000. Many critical programs will be run in production for the first time. That's when some companies will find out that their databases have been getting corrupted all the way from 1/1/2000. That's when some companies will find out that their accounting systems are not Y2k compliant, etc. In a big batch system, they could be looking at weeks or months of repair work, which essentially means the company is dead.

It will take a couple weeks after the first failures for news to get out, probably. It may take a month for the cash flow to stop, for payroll to be not paid, 401k contributions to not go in, big monthly bills to be left unpaid, etc. So around the end of February we'll start seeing the first bankruptcies, if they happen.

Quartly reports have the same problem - a new slew of programs to run. But these don't usually involve bill-paying. If your monthlies work, you'll probably live. If your quarterlies fail, you'll just have messy reports and be flying blind, management-wise. You can live with that. So monthlies are the next big hurdle.

That's why we tell people to not put their full weight down until about mid-March. We're still hitting the iceberg.

-- bw (home@puget.sound), January 26, 2000.

Now i'm really confused. The leap year comes at the end of Feb. not the 4th.

-- David Whitelaw (Dande53484@aol.com), January 26, 2000.

Last November, I was involved in the testing of several business systems, from a user standpoint. We are using an HP 3000 mainframe and legacy COBOL code, that has been made "Y2K compliant."

The system survived the 1/1/00 rollover just fine. Then, they set the system clock forward to 2/29/00 and several programs crashed.

-- No Polly (nopolly@hotmail.com), January 26, 2000.

I'm here,

LOL Wish you would have been right in that prediction, pretty chhhhhhilly here.

-- Dee (T1Colt556@aol.com), January 26, 2000.

Got nothing to do with leap-year, David, just the first EOM. The leap year problem is the next hurdle AFTER that.

-- bw (home@puget.sound), January 26, 2000.

OK thanks i'm beginning to see the big picture. Actually they are both key dates. Right?

-- David Whitelaw (Dande53484@aol.com), January 26, 2000.

So does any of this mean we are still at risk of losing power etc.?

-- David Whitelaw (Dande53484@aol.com), January 26, 2000.

I thought all the firms hit Fiscal Year 2000 last year. Isn't that what the Jo Anne Effect was all about?

-- (very@confused.here), January 26, 2000.

David - right, there are many key dates, each with their own hazards. No real danger anymore of losing power - that was a risk associated with embedded systems, not mainframe batch stuff like we're talking about here. But (this is a big "but") there is still a danger of mainframe failures like accounting systems, where those machines belong to power companies, and you could then have problems. For instance, if they can't pay the bills, and can't collect from customers, you could have long-term issues to deal with, possibly including losing power. Lots of time to deal with that, though.

Confused - SOME companies did FY 2000 rollover last year, some will do it this year. Companies are all over the map on this. But the fiscal year that you're calculating may have very little to do with the production EOM run, where the machine has to figure out what the date is right now.

-- bw (home@puget.sound), January 26, 2000.

On the losing power issue does anyone know if power companies are still on manual. I live in Washington and it was my understanding that Grand Coulee Dam was on manual for the rollover. Does anyone know if it still is?

-- David Whitelaw (Dande53484@aol.com), January 26, 2000.

David,

You might want to read Tom Atlees Y2K, Experts and Citizens Jan 10, 2000...

http:// www.co-intelligence.org/y2k_experts.html

You may find section d) especially helpful, for further explainations.

Diane

[snip]

d) TECHNICAL EXPERTISE AND THE CURVE OF Y2K:

Finally, can we say anything about the various experts we've had in our "Y2K movement," now that we know that the rollover was basically uneventful (except for all the dancing and fireworks)? Of course, there were people who knew a lot LESS about the problem than we did, who predicted that "nothing would happen." But I'm not about to trade my hard-won knowledge that turned out to be wrong for their ignorant obliviousness that, by chance or grace, turned out to be right. The question is not whose ignorance was right, but who's insight was right.

So, quite specifically, we might ask: Among all those competing experts from before the rollover -- the people who knew A LOT about Y2K -- are there any who have all along promoted well-reasoned, believable rationales for a problem-free rollover? What are they saying now about what lies ahead? (The interesting question "Why didn't we listen to them rather than to all the others?" is a subset of the previous issues a-c. The fact is, we ordinary folks never have dependable means to decide who is right until after the fact -- unless we have something like a citizen's technology panel....)

Now, I openly admit that I don't frequent the technical listserves and websites and chat rooms. So my ability to answer this question is limited. However, my regular email traffic has exposed me to one interesting nominee for "Y2K expert who got it right so far" who we can use, just as a case in point here -- Dale W. Way, Y2K Chair for The Institute of Electrical and Electronics Engineers (IEEE) < d.way@ieee.org>. For months he has been posting long and complicated pieces on various forums that, because they weren't taken up by others on the forums, and because I was always pressed for time and had to struggle to understand, I didn't pay much attention to. But now that some of his well-reasoned predictions have come true, a few people are digging out his old stuff and reposting it and trying to get other Y2K technical experts to address his issues. I've decided to join their ranks. I've appended below one of Way's more novice- readable pieces, which he posted right after the rollover (thanks: terstec1@webtv.net). But first I'm going to try the impossible: to summarize for lay folks some of what I think are his most salient points for the rollover. (I'll probably mess up, and anyone's free to correct me. I am encouraged by a quote from my friend Marianne Morgan: "It is always best to do a thing wrong the first time." So said Sir William Osler.)

Dale Way suggested that most Y2K problems would arise from math calculations that straddled the centuries. This means that programs that looked forward would have problems before the rollover; programs that operated in present time (e.g., clocks) would have problems at the rollover; and programs that looked backwards would have problems after the rollover. Some programs combine these functions, making them vulnerable both before and after rollover.

He also noted that the longer the period of time included in the calculations typical of that system, the more vulnerable it would be to problems. In other words, if a typical calculation involves times that are 10 seconds apart, then the window of vulnerability in a forward-looking system would be from 11:59:50pm until midnight New Years Eve; after that, you'd be home free, because all the dates in later calculations would be on the far side of the rollover. However, if the calculations involved a 30-year period looking both forward and backwards, problems could crop up for years on either side of the rollover.

Way identifies four kinds of system:
1) physical control system infrastructure (power grids, toxics controls, water systems)
2) on-line transaction systems (ATMs, check and credit card processing)
3) support systems (that automatically detect faults, schedule maintenance, order spare parts)
4) administrative and accounting systems (for purchasing, invoicing, personnel, payroll).

He notes that this list is in descending order of vulnerability and ease of fixing. The physical control systems tend to be more integrated, robust software/hardware combinations with coherent tasks; are better engineered and stress-tested, and therefore better understood, and usually have redundancies built in; are so clearly vital that they get lots of management attention; and tend to operate with very tiny (seconds to hours) time-windows. Therefore they are less vulnerable to Y2K glitches which, if they occur, are relatively easy to find and fix.

At the other extreme, the administrative and accounting systems are usually extremely large, complex, repeatedly modified software programs with broad windows of vulnerability (weeks, months or years) -- containing and linked to a vast variety of heterogeneous technologies and data sources which no one really understands, maintains or tests, with little redundancy or management attention -- whose data output is used by other applications all over the enterprise. Therefore, these complex systems are extremely vulnerable to Y2K glitches which, when they occur, will be very messy and iffy to find and fix.

On-line transaction systems and support systems fall in between the other two in vulnerability and fixability.

Given his analysis, he predicted that the rollover was only really special for systems with short time-windows (i.e., real-time systems, such as physical control systems and on-line transactions). Since the vital infrastructure systems were also the most resilient (low vulnerability, easy to fix), he was quite sure they wouldn't go down, at least in any significant way.

His last pre-rollover report on Dec 31, 1999 gave this summary:

"Physical control systems and other primary production systems are not at much risk and not for long, while administrative and accounting systems in all industries are at great risk for a long time. Support systems are in the middle, but closer to production systems at the lower risk end. If we are to have major damage to the economy and system infrastructure it will come from administrative and accounting systems and those dependent on them. This will have long-term impacts on the economy, but the shape of those is hard to decipher at this point. There is still much we can do by way of adaptation to mitigate such failures, but if they persist anyway, we are in serious trouble."

What's next? His January 2 report (below) is entitled: "The Fat Lady Has Not Yet Sung."

For him, it was easier to predict the rollover than what happens next, and for good reason. We've moved from the simpler, easy to remediate systems, to the endlessly complex, vulnerable and difficult to repair systems.

[snip]

-- Diane J. Squire (sacredspaces@yahoo.com), January 26, 2000.

Thanks Diane. I believe i'm starting to get the grasp of the seriousness of this whole Y2K issue.

-- David Whitelaw (Dande53484@aol.com), January 26, 2000.

Prolly better late than never.

by the way, did you get your ticket for this thrilll ride at a discount, since the train had pretty much left the station???

Night train

-- jes a ol footballer (nighttr@in.lane), January 26, 2000.

Hi David,

First, welcome to the forum.

I pretty much agree that this first month-end will be important. See the link in this thread posted today:

Did Y2K consultants cry wolf?

A few snips (sorry regulars, for posting this again):

Back-end systems that handle the processing of financial reports, statements and bills have yet to be fully tested, said Howard Rubin, CEO of Rubin Systems Inc., in Pound Ridge, N.Y. Rubin estimated that by the end of last week, 60 percent to 70 percent of the worlds computer systems would have yet to be fully used since the year switch.

Were not through, said Peter de Jager, a speaker and consultant in Brampton, Ontario, who wrote one of the first articles on the threat of Y2K. Theres a tremendous amount of processing that has not yet occurred. Until then, any judgments about if we succeeded are very premature.

-----

I think the 60-70% number is just about right. Business works on a month-end basis, and this is the first month-end when we will be processing year 2000 dates, in production. I do expect problems, but not "end-of-the-world" problems.

I'm going to do something that I hardly ever do, and that is disagree with Mr. Yourdon. True, many companies are doing year-end processing now, however those that are, are doing so with 1999 data. But I will say that there could be other "bugs" here, introduced by "fixing" the code. There always are. <:)=

-- Sysman (y2kboard@yahoo.com), January 26, 2000.

david welcome but sorry you gotta look at that disgusting picture of bill gates at the bottom

-- sandy (rstyree@overland.net), January 26, 2000.

With any luck at all Bill will disapear from this page this weekend. LOL

-- David Whitelaw (Dande53484@aol.com), January 26, 2000.

So how will the computers that had their dates set back be able to handle the end of the month.

-- David Whitelaw (Dande53484@aol.com), January 26, 2000.

David, Dale Way is absolutely correct in his assertions. Production systems are regularly stress tested and less vunerable or prone to source code error and possible failure. Administrative and accounting systems are rarely stress tested and much more vunerable or prone to source code error and possible failure. Production systems have built in redundancy(thus less prone to failure). A&A systems lack redundancy.

-- NoJo (RSKeiper@aol.com), January 27, 2000.

What is a Polly?

-- David Whitelaw (Dande53484@aol.com), January 27, 2000.

David, A polly is a non-believer of Y2K problems. They believe Y2K is a hoax perpetrated by people in the IT professions.

-- NoJo (RSKeiper@aol.com), January 27, 2000.

Thanks I sure am learning a lot here.

-- David Whitelaw (Dande53484@aol.com), January 27, 2000.

David, A polly is a non-believer of Y2K problems. They believe Y2K is a hoax perpetrated by people in the IT professions.

This statement is false. A polly is one who believes that the impact caused by Y2K problems will be minor due to the fact that the problems will be scattered and varied, and be handled as they encountered. They do not believe that the impact will be in any way large enough to take down an entire industry and plunge the world into chaos.

-- (duh@duh.duh), January 27, 2000.

So where did the word Polly come from?

-- David Whitelaw (Dande53484@aol.com), January 27, 2000.

A word on monthend cutoffs happening for the 1st time this weekend.

Not entirely true. The Federal Home Loan Mortgage Corp (FHLMC) runs their books from the 15th to the 15th. On 1/15/2000 we processed several of our FHLMC clients with no problems. Programs were reporting activity from 12/15/1999 to 1/15/2000.

Worked like a charm. We expect the same for 1/31/2000.

Deano

-- Deano (deano@luvthebeach.com), January 27, 2000.

Polly = Pollyanna. Like the Disney movie, I believe.

(Although *some* have likened it to a pirate's parrot, babbling rude and crude comments... as in "Polly want a cracker..." and more akin to polly/troll behavior).

Good news Deano. One down.

Diane

-- Diane J. Squire (sacredspaces@yahoo.com), January 27, 2000.