Will Japan Crash on April 1, 1999?greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
Japan, along with Canada and New York state, will begin its new fiscal year on April Fools Day. Although they will call it fiscal year 1999 instead of 2000, I believe that they will have to advance the fiscal calendars in their databases to encompass April 1, 1999 through March 31, 2000. It also seems reasonable that most of Japan's major banks use the same fiscal year.
Has anyone heard anything authoritative to indicate that there will be massive system crashes in Japan due to this change? I know that they got started very late and all of the Japanese banks combined are planning to spend about as much as Chase Manhattan Bank alone on Y2K. (About $1 billion.)
Also, is there any word on Canada and New York State?
-- Incredulous (firstname.lastname@example.org), March 06, 1999
We shall find out soon enough.
-- Steve Hartsman (email@example.com), March 06, 1999.
"The FSA said that as of December, nearly half of the top 19 Japanese banks had completed needed updates for just a quarter of their main computer systems. Only two banks had updated more than 75% of their systems."
The Japanese could care less about what happens to U.S. money in their banks and markets. They have enough problems of their own.
-- @ (@@@.@), March 06, 1999.
Oh s@#t!! Incredulous has put Apr 1 back on my calendar. For months I've been feeling ok about 1/4 because Japan starts fiscal year '99 then, (not fy 00). But like Inc says Jap fiscal year '99 extends into computer year 2000/actual year 2000. But then I'm left guessing whether this matters or not. Hmmph! Elucidate, clarify, rehash please.
-- humptydumpty (firstname.lastname@example.org), March 06, 1999.
One quarter at a time. That's how they will do it in Japan. If the computers can't handle budget projections into 2000, then it can be handfigured and run thru a word processor. The danger comes when the billing and receipts section rolls--this on 1/1/2000 as those are permanent entries and requires date. I'm sure Sysman, Ed. Hardliner or any of the extremely knowledgeable people on this site can explain. This simplistic view is the way it was explained to me.
-- Lobo (Hiding@woods.com), March 06, 1999.
Thanks for the vote of confidence, but seriously, you've got me mixed up with someone else!
To borrow a phrase from someone who used it previously here (I don't remember who, but thanks!), you could inscribe what I know about Japanese fiscal years and Japanese banking practices on the head of a pin with a ball peen hammer.
The guy that knows all of these answers is PNG.
-- Hardliner (email@example.com), March 06, 1999.
Here's what PNG had to say about fiscal year roll-overs in an article he wrote:
Fiscal years have little to do with company or country operations. Producing products, providing services and distributing them are the elements that create commerce. Looking ahead in projections and deciding where and when you are going to post the results is keeping score...not producing, providing or distributing.
Jo Anne Slaven on the following thread said:
Companies don't always open up a new fiscal year right away. They often wait until all of the year-end entries are posted before they "roll over" to the new year. This could take 3 or 4 weeks. And accounting system problems aren't the type of thing that is immediately obvious to outsiders. I would imagine that most corporations could muddle along quite nicely for several months with a non-functional general ledger.
Also see the thread at this link...
...where I posted part of a Washington Post article on how the states dealt with a related problem in unemployment insurance systems:
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.
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.
In my opinion, the biggest news from Japan in April will be the release of fiscal 1998 corporate profit information showing how much money was made or lost from April 1, 1998 to March 31, 1999.
-- Kevin (firstname.lastname@example.org), March 06, 1999.
PNG is full of crap.
-- @ (@@@.@), March 06, 1999.
I agree with you, Kevin. Very few companies will make money this year. Net profits will 50%-60% less than last year. The bank losses will be staggering because of the write down of 10% of the unrecoverable debt. In addition, the government is forcing banks to reveal more information because of the taxpayer infusion of over 40 trillion yen (~$350 billion).
All banks use the same FY. All companies report to the government using the same FY. Most large international companies use calendar year for planning.
The Japanese bank and company remediation schedules vary sector-by-sector and company-by-company just as anywhere else in the world. Everyone started late. Using money as the measure of progress is not applicable to Japan. Financial reporting rules are not the same. The Moodys report that started this idea and the comparison to Chase Manhattan was sloppy research (one guy talked to one guy at one bank) and Moodys has since backed off the statement.
Many banks did begin in the 1980's to expand mainframe date fields. Good programming practices included not embedding date calculation within the application program. The Japanese programmers were particularly careful with this because of the need to manipulate dates between both calendars used. Dates were external to the application, thus more easily changed. The change from Showa to Heisei era ten years ago was done through the external date routines and some (not all) banks began expanding to 4 digit fields then. Obviously, the cost of this work was not reported as y2k remediation.
Now comes the big "but"... The proliferation of packaged software in the 1990's (which of course came from the U.S.) broke the good programming practice by embedding date calculations and using system dates within the application.
You do realize that there is a lot of grumbling in the international community that the U.S. is to blame for y2k, don't you? You wrote the software and sold it... knowing (or incompetently not knowing) it wouldn't work soon.
So, some of the older mainframe code was already y2k ready. Some is easier to fix because of the external date routines. Most of the newer packaged software is more difficult to fix. And some of the packaged software was localized in Japan and the Japanese, because of license agreements had to wait for the U.S. patches and upgrades to be finished before they could redo the localized version. In some cases, the new U.S. supplied y2k compliant version was localized only to find out the y2k compliant version was not compliant. Remenber...mistakes do happen. It's hard to become compliant when the original vendor doesn't meet their upgrade schedule or releases a buggy upgrade and another localization step is required.
Just like all news. Some is bad and some is good. Some banks are in good shape, some are not. I don't think we'll see massive bank or company system crashes from FY rollover.
I think a lot of IT people will be working late, exhausted and ready to attack the next accountant whining that his critically important"Annualized Bi-Quarterly Seasonally-Adjusted Raw Material Cost -Variance Projection (Trial Run) Report" is late!!! The compounding of errors and slowdown of automated procurement will take months to slowly bubble to the surface.
That's my 2 yen worth...
-- PNG (email@example.com), March 06, 1999.
PNG is not a Pollyanna. Take a look at the titles of the articles he's written. They're at the bottom of the page at this link:
-- Kevin (firstname.lastname@example.org), March 06, 1999.
Confidential to--@: You're right. I know I'm full of crap...Some people haven't caught on as fast as you.
I wrote the piece about FY rollovers in January, 1999. All the large companies with February 1st , 1999 FY rollovers went belly up, didn't they?
The people who said I was full of crap last year were right when I was the first to bring up on this forum the possiblity of Middle East oil production problems.... What a load that was! I haven't heard any news recently that petroleum could be a problem. Have you?
Then there's that pesky thread "PNG, You Were Right!" about the televised reports on the status of Japanese banks reporting the same things I had written about months before. Another load.
Come on @, I've got some of these idiots completely fooled...don't blow my cover.
-- PNG (email@example.com), March 06, 1999.
PNG, Have you written in this forum or elsewhere about how Japan suffers if the mideast can't ship oil? Is there enough nuclear to maintain core infrastructure? Any URLs appreciated.
-- Puddintame (firstname.lastname@example.org), March 06, 1999.
On April 1, 1999, Japan starts fiscal year 1999! NOT fiscal year 2000!!
-- Anonymous99 (Anonymous99@Anonymous.com), March 06, 1999.
Sorry PNG, you may have fooled yourself but not me. No one is saying that a company is immediately going to have to shut down because of a fiscal year rollover. It doesn't matter whether these problems are visible to the public or not, they exist. The difference between a 1998 rollover and a 1999 rollover is that it WILL cause internal problems in virtually every company which is not totally compliant. Sure, they can continue business, and no one will notice that anything is going wrong. But in addition to trying to make their systems compliant, they now need people to go back and straighten out all the errors. "Bandages" are not the same as a FIX. The longer they rely on bandages, the longer the real problem is deferred, and then you've got a situation that is twice as bad as the whole Y2K scenario was to start with. It will cost more money and will ultimately determine whether or not a company survives, unless they plan on conducting all business with pencil and paper. Whether a company has PARTIAL problems due to the 99 fiscal year, or TOTAL problems when ALL transactions are in 2000, IT STILL HAS TO BE FIXED!!
-- @ (@@@.@), March 06, 1999.
I agree that problems will (always have and forever will) exist. Are you looking at this from an applications level? Without too much detail @, are you a programmer?
Don't tell me you've been programming for 20 years and you know everything is going to go to hell next year! What have you been doing for the last twenty years? You idiot! If everything is going to hell, what are you doin' on this forum when you should be at work?!
You guys made this mess. You better get your fat, Dunkin' Donut butt off the couch and haul it on down to your little computer and fix it. Stay there all night, every night if you have to. Poor little old Mary down the street just bought a gun, is stocked up on beans and rice, watchin' the CIA on C-SPAN and scared to death because "Mr. IT Pro-fes-sion-al" here didn't have the sense in twenty years to pull his head out his computer and look up at a damn calendar on the wall.
I know why Cory Kamikaze needs to stock up on ammo. Little old Mary and about 50 million of her friends are gonna be lookin' for him and you. If everything doesn't go to hell, she's still gonna be huntin' you down like a dog for scaring her half to death, making her eat beans and rice for 6 months, cashing out her IRA and spending all her savings on a damn generator and fuel. And now you're going to tell me how to run a business?
[End humor That was fun...]
All-or-nothing is true in a systems or applications level view. Thankfully, people and businesses aren't limited by the operating boundries of all-or-nothing or 0 or 1.
The premise that all systems and all applicationsmust be fixed before next year is not valid. Just as the premise that all data must befixed is not valid. Now that may sound like crap to you, but to strategic planners those words sound like opportunites -- Opportunities to re-evaluate the cost/value of systems, applications and data.
The old 'Quality Movement' people have moved to the indirect side of the house. The statistical methods used to yield production quality and efficiency improvements are yielding less results. It's become difficult to squeeze out more production efficiency. The indirect costs of any company far exceed the direct costs and are being targeted, with quantitative methods, for efficiency improvements...particularly MIS. Rarely is the value of indirect MIS been effectively measured.
Many companies are taking hard looks at the systems, applications and data that were categorized as non-critical for y2k remediation. The ones that aren't will be.
Before I give away the whole book, here's a few bullets: Remember these are non-critical.
--Applications that look ahead are more important than those that look back.
--Not all applications that look back will be remediated. Anticipate application amputation.
--Data that is current and re-current is more important than data that is archival. More archival data exists than current and re- current data. (stay with me here...we're almost done)
--Archival data is used significantly less than current and re-current data. (One reason is the forced reduction in calls for the data...i.e. You better have a killer reason for this data.)
--Time is progressing and compliant re-current and archival data increases. Many companies have very limited use for data greater than 2 years old, and again the forced justification will exist.
I know, that you know, that I know, this doesn't apply to all organizations. Look, the priorities are produce, bill and collect. The data runs for some of the internal reports are just going to fall by the wayside for companies that aren't ready with those applications. If you accept the fate that all errors and all applications will not be fixed, your better able to reason your way through the fog of what's truely important.
Let's pretend for a moment that the infrastructure remains reasonably intact. If you believe that your company will be overwhelmed and eventually crumble if only 33% of their non-mission critical MIS applications are compliant by the end of this year...then either you or your company have a problem. And it has nothing to do with 0's or 1's.
-- PNG (email@example.com), March 07, 1999.
Before you get totally out of control, let's clarify something. The closest I've ever come to programming is basic HTML, and I am not an Information Technology professional. But it doesn't take a rocket scientist to know what is happening. Contrary to what you would like to beleive, many of these problems ARE becoming visible to the public, because of the dramatic increase in their occurrences. Although many companies can continue to operate in a disabled condition, I beleive that correcting the errors which are now being created in their databases could in many ways actually be more time consuming and expensive than the actual Y2K compliance remediation itself. To pretend that it doesn't matter is a joke. I can no longer argue with someone who is simply trying to prove that in some miraculous fashion Japan is going to be less vulnerable to these problems than the U.S.
-- @ (@@@.@), March 07, 1999.
"I can no longer argue with someone who is simply trying to prove that in some miraculous fashion Japan is going to be less vulnerable to these problems than the U.S."
I agree. I wouldn't argue with that guy either.
-- PNG (firstname.lastname@example.org), March 08, 1999.