Significance of States Fiscal Start : LUSENET : TimeBomb 2000 (Y2000) : One Thread

1. How significant is a non-event for one of the proported milestones? i.e. States fiscal year beginning yesterday. (understanding events still potential)

2. If there are not any EVENTS reported due to States fiscal start does or should this temper preparations?

3. Is the one and only Technical Biggy the date of 1-1-2000? (understanding other dates involved-9-9-99 and gps and 10-1)

-- David Butts (, July 02, 1999


Fiscal years are not significant Y2K problems, in general (not saying there aren't any problems). For there to be a problem, you have to exercise logic that adds, subtracts, compares, files, etc by fiscal year and you must have years before and after 2000 involved (e.g. current_fy - previous_fy = age ( 00 - 99 = -99 years old). But, financial systems in general close the books after each FY and start up another FY so you generally don't get the data mixed together. FY logic is usually pretty simple as well.

Lots of organizations had FY glitches 1 Apr 99, but it didn't fit the media, because it was manageable. Forward looking (forecasting) systems that deal with Y2 had the prolem a long time ago. Some fixed the problem when they found it. Some shortened the forecast window.

I expect 3% of the problems to hit before date rollover, 95% at rollover and 2% after. New year will hit like a sledgehammer, because of all the realtime problems.

-- noel (, July 02, 1999.

On the other hand, wasn't it the Gartner Group that has predicted approximately 80% of the computer "problems" will have already taken place before the rollover? [I don't have the link just now] A number of milestone dates which many gloomers hung their hats on have come and gone with little or no noticeable effect. I find this very encouraging.

-- CD (, July 02, 1999.

CD, That number would be approximately right for business system (what Gartner Group studies) logic failures, if you say that a piece of logic that causes one problem befor 2000 and another problem after 2000. Way too high if you count workstation OS and BIOS failures, not to mention embedded systems which are real time failures. noel

-- noel (, July 02, 1999.

I wouldn't expect date-related glitches to be noticeable until they begin to affect systems that deal with manufacturing or distribution. The Jo Anne Effect has to do with accounting software that "keeps score" or makes projections about an organization's activity without directly affecting that activity.

Here's what the GartnerGroup said in April about the timing and distribution of failures: bin/article?thisStory=75682445


Why should Y2K start in 1999 and stretch into 2001? In a recent speech in San Diego, Lou Marcoccio, another research director of Gartner's Y2K practice, said the causes will be forecasting software that looks six months into the future, the beginning of new fiscal years for many corporations and some "date-related anomalies in software code."

The number of Y2K failures will increase further in October as forecasting software that looks three months ahead runs up against the Jan. 1, 2000, date and still more companies begin new fiscal years, Marcoccio said.

In Gartner's view, 25 percent of Y2K computer failures will occur in 1999, 55 percent will occur in 2000 and 15 percent will occur in 2001. The other 5 percent occurred before 1999.


-- Linkmeister (, July 02, 1999.

Other recent threads on this same topic...

"Some thoughts regarding the Joann Effect."

"July Rollover"

"For the record: Your July 1st predictions, please"

"Any knowledge being gained from 1999 failures?"

-- Linkmeister (, July 02, 1999.

Thanks for the link to that Gartner quote Linkmeister. I have no idea where I got that 80% impression from.

-- CD (, July 02, 1999.


Thankyou!! missed those threads! hard to believe since I feel like I'm on this allllllllllll day!!

-- David Butts (, July 02, 1999.

I just found this about two minutes ago... rted_in_major_Y2K_test+.shtml


But exceptions were discovered at a state computing center in Chelsea, Asbedian said. One application used to track legislative action on a mainframe apparently misinterpreted the ''00'' of the new fiscal year as a previous date. In a second case, Asbedian said, a mainframe program wasn't able to allocate costs properly because of the unfamiliar year.

Asbedian said he couldn't provide more specific descriptions of the problems, but said they were quickly spotted and repaired.

The glitches were troublesome because they appeared in large mainframe applications that had already been certified as ''Y2K- compliant,'' meaning they were already thought to be prepared for the date change.


-- Linkmeister (, July 02, 1999.

A good excerpt here on how states use fiscal year dates...,4153,1015372,00.html


Few worries about cut-over

Benzen said there were few problems because the fiscal year date is used in most states' systems only to label data or documents, not as a key computational input. In contrast, the calendar year date is critical for computing and tracking values indicating such things as Medicaid eligibility. For that reason, said Benzen, few state information technology officials were worried about the fiscal year cut-over.

"I forgot we changed the fiscal year until I got in this morning," he said.

Because the fiscal and calendar dates are used so differently, Benzen said, the ease with which states coped with yesterday's change doesn't mean they'll be as successful on Jan. 1, 2000. "This is no predictor of what will happen on January 1," he said. "You can't reach a valid conclusion based on what happened with the fiscal year change."


-- Linkmeister (, July 03, 1999.

Another article with a bit of info on the significance of July 1st:,business/3773a954.702,.h tml


For most of us, however, the July 1 date is no big deal.

That's because most fiscal year dates are not used to calculate the payments that thousands of state residents receive every month. Bills are paid, food stamps are issued, Medicaid payments are made and vouchers are tracked by actual dates.


-- Linkmeister (, July 03, 1999.

Will something really happen or just another April Fool's Day? : LUSENET : TimeBomb 2000 (Y2000) : One Thread

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

Okay, guys, here's the $64 question. We all know April 1 is another drop dead day: fiscal Year rollovers for Japan, Canada and the state of NY (with the UK soon to follow, on April 6). So, what will happen? Will NY state pensioners suddenly not get their checks, etc. etc. Is this something serious or another red herring BS non-event. You folks with experience in programing these systems need to speak up on this. Ed, maybe you could chip in on this one. Thanks, everyone... Sandmann

-- Novacop (, March 28, 1999


Response to Wii something really happen or just another April Fool's Day?

Well, we know that it won't have any impact on embedded systems -- so we're not going to see any failures of process control systems, refineries, utilities, or things of that sort.

It also means that we're not going to see problems in PC BIOS chips or non-compliant PC operating systems.

The problems will exist in application programs that are aware of, and make use of, the end-date of the fiscal year, i.e., March 31, 2000. Thus, we're almost certainly talking about financial systems, tax systems, etc. It's likely to have the greatest impact on report- writing programs that spew out spreadsheet-looking reports with rows and columns of numbers, showing budget figures for all 12 months of the fiscal year.

Several people have argued that we probably won't see any problems in the day-to-day transaction-processing systems, e.g., the systems that process daily receipts and daily disbursements of funds. However, if there are any logic-checks that ask questions like, "Is this disbursement legitimate within the context of a full fiscal year?", THAT could cause problems.

As with most other aspects of Y2K, the bottom line is that we really don't know where and how the problems will hit. What's fairly obvious, given the experience from the Euro rollover, is that any minor or modest problems will be hidden pretty well within the bureaucracy. However, if it causes something comparable to the NJ food-stamp problem (yes, yes, I know that the officials have now described that problem as a non-Y2K problem), then it will be hard to cover up. If a hundred thousand retired civil service workers don't get their monthly pension check, you'll definitely see it on the evening news program.

It will be interesting to see how it turns out...


-- Ed Yourdon (, March 28, 1999.



-- Linkmeister (, July 05, 1999.

Sorry. The thread with Ed Yourdon's quote is at...

-- Linkmeister (, July 05, 1999.

A patch some state unemployment insurance systems needed for proper functioning on January 1, 1999:


In addition, in June 1999, OMB reported that as of March 31, 1999, 27 states' unemployment insurance systems were compliant, 11 planned to be completed between April and June 1999, 10 planned to be completed between July and September, and 5 planned to be completed between October and December.


As an example of the benefits that federal/state partnerships can provide is illustrated by the Department of Labor's unemployment services program. In September 1998, we reported that many State Employment Security Agencies were at risk of failure as early as January 1999 and urged the Department of Labor to initiate the development of realistic contingency plans to ensure continuity of core business processes in the event of Year 2000-induced failures. Just last month, we testified that four state agencies systems could have failed if systems in those states had not been programmed with an emergency patch in December 1998. This patch was developed by several of the state agencies and promoted to other state agencies by the Department of Labor.


-- Linkmeister (, July 20, 1999.

Here's a Washington Post article from December 1998 about state unemployment insurance systems and the "bandage" in January 1999 of using a December '99 end date on benefits rather than January '00.

[Fair Use: For Educational/Research Purposes Only]

13 States, District Face Y2K Problems

Unemployment Checks May be Slowed

By Stephen Barr

Washington Post Staff Writer

Wednesday, December 23, 1998; Page A03

Thirteen states and the District will have to put electronic bandages on their computers next month so they can pay new unemployment insurance claims into the year 2000, Clinton administration officials said yesterday.

The federal-state unemployment program provides one of the first large-scale examples of the problems caused by the "Y2K bug." Computer experts have warned that payments for billions of dollars in Medicaid, food stamps, child welfare and other federal-state benefits could be at risk because surveys have shown that states are moving slowly on the Y2K problem.

Many of the computer systems in the unemployment insurance program, which processes claims, makes payments to the jobless and collects taxes from employers, are more than 30 years old. The systems processed more than $20 billion in state unemployment benefits in fiscal 1998 and provide crucial data on economic trends.

Persons filing claims for jobless benefits are assigned a "benefit year," which means that -- starting Jan. 4, 1999 -- unemployment insurance systems will have to be able to process dates and calculations that extend into 2000. Y2K problems may occur when computers next month try to process a first-time claim with a benefit year that covers both 1999 and 2000, officials said.

Some states that have not solved their Y2K problems will use a simple temporary fix, such as ending all benefit years on Dec. 31, 1999, while other states will use different techniques that essentially trick the computers so they will perform accurate date calculations, officials said.

If the computers are still not ready to operate on Jan. 1, 2000, states then will rely on emergency backup plans, including the writing of benefit checks by hand, officials said.

John A. Koskinen, the president's adviser on Y2K issues, and Deputy Labor Secretary Kathryn Higgins yesterday stressed that the nation's unemployment insurance system would not suffer serious disruptions.

"A year out, we know where our problems are. . . . It's an enormous help to have that information," Higgins said.

Koskinen pointed to the contingency planning for jobless benefits as a clear sign that the government will be able to maintain important services and programs, even if computer systems encounter Y2K problems.

Y2K, the computer industry's shorthand when discussing the year 2000 problem, stems from the use in many automated systems of a two-digit dating system that assumes the first two digits of the year are 1 and 9. Without specialized reprogramming, the systems will recognize "00" not as 2000 but as 1900, causing computers to malfunction or shut down.

Labor Department officials listed Arizona, Connecticut, Delaware, the District, Hawaii, Illinois, Kansas, Louisiana, Massachusetts, Missouri, Montana, New Hampshire, New Mexico and Vermont as lagging on Y2K repairs. Puerto Rico and the Virgin Islands also are running behind schedule, the officials said.

Delaware, according to the Labor Department, will not have all computer systems converted until the last possible moment: Jan. 1, 2000. But state officials said the most critical systems have been fixed and suggested that even experts can disagree on how to assess Y2K readiness.

The District should have its unemployment system fixed by March 31, the Labor Department said.

Overall, the repair bill could run to $490 million for the unemployment insurance systems, according to preliminary estimates.

) Copyright 1998 The Washington Post Company


-- Linkmeister (, July 20, 1999.

This is about vehicle registration renewals in Honolulu:


There are no delays -- in fact, one-day processing is standard -- for mailed vehicle registration renewals, but that is an area where the Y2K bug raised its ugly head. Manual processing has been under way since Jan. 1 because "the system has been rendered unreliable by the Y2K problem."

The staff is working after hours to achieve the one-day processing goal, resulting in unbudgeted overtime costs, the auditor found.


-- Linkmeister (, July 20, 1999.

An example from May of early date related glitches: =y2k


Post gets bitten by the Y2K bug

The Washington Post doesn't want your money. At least not for another few weeks anyway.

Despite spending millions of dollars and four years preparing for the Y2K bug, the city's largest newspaper is unable to accept 52-week subscription renewals because its accounting department is not Y2K compliant yet.

"We are getting all new software and a brand new computer to handle this problem over the next three weeks," said Post spokesperson Linda Erdos.

She said the paper predicts it will solve the problem in time to resume offering 52-week subscriptions in July.

But some readers are frustrated by this bookkeeping dilemma.

"Now I have to call them back in two weeks just to pay my bill," a Post reader said.


-- Linkmeister (, July 21, 1999.

Here's some new information about the status of Washington D.C.'s unemployment insurance system. The Washington Post article from December 23, 1998 mentioned how the system was going to be "bandaged" so it could keep running in January 1999, and had this quote in it:

The District should have its unemployment system fixed by March 31, the Labor Department said.

An October 7, 1999 article in USA Today had this new information about how the District's unemployment insurance system is coming along...

Edward Hugler of the Labor Department said the District of Columbia won't fix its unemployment insurance program until the end of the year, and California still has some work left on its program.

-- Linkmeister (, October 20, 1999.

Moderation questions? read the FAQ