Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security

Computer Error Grounds Japanese Flights 154

zephiros writes "Mainichi Daily News reports that a "computer glitch" in Tokyo air traffic control systems resulted in the cancellation of 203 flights this weekend. At 7am Saturday, the error "caused the names of airlines and flight numbers to disappear from radar screens." A Japan Times article suggests the problem may be related to upgrades on a system which exchanges flight plans with the Defense Agency. Makes one wonder about the integration and maintenance risks of systems like CAPPS II."
This discussion has been archived. No new comments can be posted.

Computer Error Grounds Japanese Flights

Comments Filter:
  • by gostats ( 647325 ) on Sunday March 02, 2003 @05:56PM (#5420469) Homepage
    I've work quite a bit with risk maintenance. Most often situations like these increase the budget for disaster prevetion and other related expenses. This failure *should* make fewer failures in the future and generally a safer airport. But then again that all depends on how much passion they have for their job.

    Maybe I should take a trip to Japan in a few months.
    • Actually, the damage was almost minimal to the Japanese air system. The delay only lasted 50 minutes. Unlike American travellers, Japanese people will quietly and orderly board a fully booked 747 in under 20 minutes. If asked to hurry, they will board it even faster. That combined with Narita and Haneda's ability to handle traffic far above their average had most flights back on time before noon. Only a small handful of international passengers may have had to rebook a connecting flight. Domestic flights are almost always direct.

      As far as risk management, had there actually been a perceived emergency due to the malfunctioning radar display system, the airports would default to an agreement with Yokota and Atsugi US airbases to provide fallback flight control facilities.

      This is really a non news item. The system administrator correctly applied upgrades during non-critical operation time. (i.e. not during the main business week) The problem was identified early on and corrected pretty damned quick. This happens hundreds of times a week all over the world. Had the glitch actually halted the entire Japanese air system for a long period of time, then it would make more sense.
  • Why? (Score:4, Insightful)

    by Cyno01 ( 573917 ) <Cyno01@hotmail.com> on Sunday March 02, 2003 @06:00PM (#5420489) Homepage
    Why even bring up CAPPSII, is has nothing to do with air control, only with passenger data.
    • Re:Why? (Score:4, Funny)

      by abh ( 22332 ) <ahockley@gmail.com> on Sunday March 02, 2003 @06:03PM (#5420507) Homepage
      Because this is Slashdot, where every article must somehow involve a violation of rights by the big bad government.
    • Re:Why? (Score:5, Insightful)

      by 56 ( 527333 ) on Sunday March 02, 2003 @06:55PM (#5420743)
      Because the program that caused the error was similar to CAPPSII.

      To quote the article:

      A Japan Times article suggests the problem may be related to upgrades on a system which exchanges flight plans with the Defense Agency.

    • Re:Why? (Score:3, Interesting)

      by zephiros ( 214088 )
      Because it's a large system that will have to integrate with numerous airline systems from god knows how many vendors. And it will need to be maintained and patched. And it's a potential single point of failure (from a software standpoint; obviously they could stripe it across as much hardware as needed).

      Even if CAPPS is only connected to ticketing and passenger information, a bug could result in a pretty nasty transportation snarl. Suppose airlines are unable to issue boarding passes for an hour, or an unusually large number of people were flagged for screening.

      For any of these total-information-awareness type systems, one has to ask "what happens when some part of the patchwork breaks?" Even the most diehard "I have nothing to hide from my government" type understands that multi-hour flight delays are bad.

  • by revmoo ( 652952 ) <slashdot.meep@ws> on Sunday March 02, 2003 @06:02PM (#5420500) Homepage Journal
    "Makes one wonder about the integration and maintenance risks of systems like CAPPS II."

    Does that seem like flaimbait to anyone else? Computers crash all the time, granted steps can be taken to ensure redundancy, but this is nothing new. This problem has nothing to do with the CAPPS II system other than the fact that they are both computerized systems, I'm not trying to defend CAPPS II, I just don't think that it is any way related to this this tokyo airlines problem. Computers crash, it's a fact of life, the real question here, is why weren't there multiple redundancies in place for such a mission critical application.

    • by Phroggy ( 441 ) <slashdot3@@@phroggy...com> on Sunday March 02, 2003 @06:12PM (#5420558) Homepage
      Computers crash, it's a fact of life...

      Been listening to Microsoft too much lately, eh? It shouldn't be something we take for granted.
      • I take it you've never had a kernel panic then...

        What about hardware failures? Even the best code still has bugs in it, and the potential to fail

        • by Anonymous Coward
          Even the best code still has bugs in it,

          I've never been able to crash helloworld.c.

          • "'Even the best code still has bugs in it' I've never been able to crash helloworld.c."

            Uh, I wouldn't refer to helloworld.c as "best"... I think the grandparent was refering to the fact that larger (that is, more complex) programs are more likely to have more bugs in them.
        • But hardware really shouldn't fail as much as we're used to, and we really shouldn't have to put up with the number of bugs even the `best' code has.

          Seeing as we're still in a young industry, it's nice to think that over the coming years things *should* get better, on the hardware side at least.

          The problem with software development is that it's so damn easy to ship a product, let hundreds (thousands? tens of thousands?) of users test the product for you, then release appropriate bug fixes. People don't design a new bridge and let thousands of people try it out before declaring it safe, nor when building new buildings, and usually not even when designing a new microprocessor, so why are we still getting away with it in software engineering?

          Presumably because Microsoft has let the general public get used to this as "the way it is" ;)
          • The problem with software development is that it's so damn easy to ship a product, let hundreds (thousands? tens of thousands?) of users test the product for you, then release appropriate bug fixes.

            In the case of some proprietary software either charging for the bug fixes or intermingling them with new "features" (which may very well contain their own bugs). That's assuming they don't insist on playing "it's a feature not a bug".

            People don't design a new bridge and let thousands of people try it out before declaring it safe,

            There is a story that in the USSR once a bridge was completed the designers and archiects had to stand underneath whilst the Red Army drove a column of tanks across.
      • by Anonymous Coward
        to the tune of: "Model of a Modern Major General", with apologies to
        Gilbert and Sullivan...

        Model of a Slashdot Personality

        I am the very model of a Slashdot personality.
        I intersperse obscenity with tedious banality.
        Addresses I have plenty of, both genuine and ghosted too,
        On all the countless topics that my drivel is cross-posted to.
        Your bandwidth I will fritter with my whining and my sniveling,
        And you're the one who pays the bill, downloading all my driveling.
        My enemies are numerous, and no-one would be blaming you
        For cracking my head open after I've been rudely flaming you.

        I hate to lose an argument (by now I should be used to it).
        I wouldn't know a valid point if I was introduced to it.
        My learning is extensive but consists of mindless trivia,
        Designed to fan my ego, which is larger than Bolivia.
        The comments that I vomit forth, disguised as jest and drollery,
        Are really just an exercise in unremitting trollery.
        I say I'm frank and forthright, but that's merely lies and vanity,
        The gibberings of one who's at the limits of his sanity.

        If only I could get a life, as many people tell me to;
        If only Mom could find a circus freak-show she could sell me to;
        If I go off to Zanzibar to paint the local scenery;
        If I lose all my fingers in a mishap with machinery;
        If I survive to twenty, which is somewhat problematical;
        If what I post was more mature, or slightly more grammatical;
        If I could learn to spell a bit, and maybe even punctuate;
        Would I still be the loathsome and objectionable punk you hate?

        But while I have this tiresome urge to prance around and show my face,
        It simply isn't safe for normal people here in cyberspace.
        To stick me in Old Sparky and turn on the electricity
        Would be a fitting punishment for my egocentricity.

        I always have the last word; so, with uttermost finality,
        That's all from me, the model of a Slashdot personality.

        THIS IS YOU
      • Exactly, the term "fail safe" doesn't seem to be known by some people.

        Brake systems in cars don't fail safe, yet they do on some trains. This isn't a fault of braking systems, just the application of the system in one vehicle.
      • Everything fails. (Score:3, Insightful)

        by T-Ranger ( 10520 )
        Water mains under the street break. Suspension bridges collapse. Buildings collapse. Ships founder and sink. Breaks on cars fail causing crashes. Trains derail.

        No, computers shouldnt crash. But they will eventualy fail, just like everything else will.

    • Looks like flamebait to me...I don't see how anybody in their right (and even not-so-right) mind would interface CAPPS II with the ATC network. Thus, as such a lunatic concept, I discount the Japan Times comment that the two are somehow related as the words of somebody who "knows not of what they speak."

      Do YOU want the ticket agent behind the counter to have access to a network that is interconnected with air traffic control? Neither do I.
    • Because there is a possibility that the error was caused by a problem in a program similar to CAPPS II.

      To quote the article:

      A Japan Times article suggests the problem may be related to upgrades on a system which exchanges flight plans with the Defense Agency.

      • Yeah, but that is just a cover for this conspiracy. I was on one of these flights, and the captain announced:

        "Uh, folks, we're experiencing some moderate Godzilla-related turbulence at this time, so I'm going to go ahead and ask you to put your seatbelts back on. When we get to 35 thousand feet, he usually does let go, so from there on out, all we have to worry about is Mothra, and, uh, we do have reports he's tied up with Gamera and Rodan at the present time. Thank you very much."

        Don't believe the lies!

    • "It's a computer glitch", "the computer made a mistake" etc.. I hate such lines, computers don't design themselves. Humans design processors, humans write software.

      Such news articles should say "hardware failure" if it is a hardware failure, if a computer crashes due to software it should say a bug in the software caused the problem.
    • Computers crash all the time, granted steps can be taken to ensure redundancy, but this is nothing new.

      Well for one, who said some computer crashed? From what I understood from the story. The system had a glitch after a software upgrade. So it seems the new software is at fault. That's not the same as some hardware failure. How do you fight a sysematic error in software with a redundancy?
      The trick with software upgrades is to do some testing in as-real-as-possible environment before going live.

    • ...Computers crash, it's a fact of life, the real question here, is why weren't there multiple redundancies in place for such a mission critical application.

      I'm guessing that the computers didn't crash. The description sounds more like software bugs. Still... one would think that for a system like this they would have done the upgrades on a duplicate server, and only switched over to them after all checks had been passed.

      (Perhaps the only thing CAPPS II has to do with this is that it takes a currenly extrememly complex system and makes it more complex without sufficient testing. That would be enough similarity, but perhaps the comparison should have been more explicit.)
  • "Computers are just no good," said one 51-year-old company manager leaving for Sapporo. "I'm sure they're helpful, but they're just too fragile."

    Lol. Depends how they're set up. I'd say you can get them fairly robust. Clustered, load balanced, hot-swap, failover, etc.
    • Computers are way to fragile - I just broke my third mice in two years...
    • Clustered, load balanced, hot-swap, failover, etc.
      Yes, but you have to remember: the second most common cause of computer failure -- after hardware -- is operator error.

      From the article:
      The system has a backup, but both systems went down at the same time, according to the ministry.
      Simultaneous fialure of two independent systems that are designed to tolerate failure doesn't sound like a hardware issue to me. I could be wrong, but I'm more than willing to bet it's an "oops!" situation, albiet somewhat more serious than most.
      • --around a year and a half ago a similar situation happened in japan if I am remember correctly. It looked rather like a military test that got out of hand. I am medium suspicious of two separate systems failing at the same time, it reminds me of that other "accident" that was rumored to be some pretty advanced jamming.

        Note to anyone, yes, this is pure speculation, I admit it out loud. My default nature that I am completelycomfortable with is whenever strange occurrences happen with "government"- anyone's government - I am suspicious of it as being more than incompetence or actual random accidents. Too many events over the years that at first looked one way turned out to be completely different, they were either delibarately done, or somehow they were collateral damage from something bigger that needed to occur for some agenda, or allowed to happen, again, for a higher level agenda not readily apparent at the time.
    • I've yet to see a computer go postal without human help.

      trouble is computers are designed by people.

      air traffic control and missile guidance are two systems I'd never ever work on.

      I'd like to program all the missiles to fly to the sun, but the consequences of a bug in the system are just too scary for me to contemplate.

  • 1) How the hell did the flights get DOWN once the radar died? It said they disappeared from radar, and you don't keep radar on the planes that are on the ground, so....?

    2) Whose bright idea was it to do a "systems upgrade" while there were large, flying metal objects carrying many people still in the air?!?! Wouldn't you do a test run, install it on a backup system, or one that's not systems-critical?

    This just makes no sense....someone explain it to me?
    • 1: Because the planes themselves still showed up on radar, air traffic control authorities were able to direct flights after contacting aircraft to determine their flight numbers and other details, but all departing flights were grounded as a precaution.
    • by Anonymous Coward on Sunday March 02, 2003 @06:18PM (#5420573)
      > 1) How the hell did the flights get DOWN once the radar died? It said they disappeared from radar, and you don't keep radar on the planes that are on the ground, so....?

      Read the article. It says that just the airline name and flightnumber tags printed beside the radar blips vanished. The radar worked just fine.

      > 2) Whose bright idea was it to do a "systems upgrade" while there were large, flying metal objects carrying many people still in the air?!?!

      Read the article. The change was made early in the morning on a weekend. When would you suggest?

      > Wouldn't you do a test run, install it on a backup system, or one that's not systems-critical?

      The article (did you read it?) hints that might have been a networking problem when they integrated the military database with the civilian database. A backup system is a good first start, but isn't always the same as the production system. Network problems can't always be perfectly tested or simulated.

      • re: 1) Ok, the airline names and tag numbers are important when bringing them down, so although not impossible, it would have been a bitch to do.

        re: 2) Let's see, early morning on a weekend. Weekends are known to be busy times for airports and morning is when they tend to fly. When would I recommend? Maybe a Thursday? Middle of the night?

        re: 3) Bullshit. The backup system should be IDENTICAL to the production system, otherwise it's a worthless backup. Especially in something as critical as ATC. But I will concede the problems with testing network problems being hard to simulate.
        • "Bullshit. The backup system should be IDENTICAL to the production system, otherwise it's a worthless backup"

          Well, it depends what the purpose of the backup is. If the backup is perfectly identical to the main system, that means when something kills the mainsystem,(say a bad string of data is being passwed around the network) you switch to the backup, and it has the same flaw,so it dies too! Thats why its sometimes nice to have a backup system that uses slightly different code/hardware.
        • Thursday: middle of the business week. Would you want construction on the road you take to work on a work day?

          Midnight: Upgrade to a system that tracks planes in the air. If there are no planes in the air, how can you test it? The upgrade was most likely done around midnight, but didn't see any signifigant use until the heavy part of the travelling day. The article indicated it was due to an interface with a defense system. JIEITAI (Japanese military) usually hit the office between 7 and 8, which was when the delays started. I could be wrong about the work time for the folks in Tokyo, but the two units I've worked with in Okinawa and Hokkaido were usually rolling in to hit their first cup of coffee just after 7.

          Despite the lack of information in the article, passengers were not stranded. If their flight was cancelled, they were re-booked and most likely in the air within the hour of their original scheduled flight. Japanese air systems are extremely efficient, although I have no clue how they could be making any money.
    • "Whose bright idea was it to do a "systems upgrade" while there were large, flying metal objects carrying many people still in the air?!?!"

      Actually, there are planes in the air most hours of the day. There is no time when planes aren't flying.

      The best time (when there are fewest planes) may be at night. But that's just the time when the people actually doing the upgrade are going to be half asleep.

      "Wouldn't you do a test run, install it on a backup system, or one that's not systems-critical?"

      I'm sure they did. But the live system is bound to be different in some small way
      - maybe a different (more powerful) system, which might cause different timing issues;
      - maybe a different disk configuration, perhaps with a file system running out of space (e.g. more online logs);
      - maybe the live database (if any) is different to that on the backup system.

      These things can easily go wrong. In my experience, it's vital to ensure you have a way of getting some sort of system operational if you do screw up. Maybe ensure a backup system is capable of running live first, then attempt the update of the live system, and if it goes wrong, you have a backup system capable of operating until you can correct the screw-up.

      • Actually, there are planes in the air most hours of the day. There is no time when planes aren't flying.

        Except on 9/11. In fact, scientists used this to determine how having no jet contrails in the air affected the daily high temperatures.
    • 1) How the hell did the flights get DOWN once the radar died? It said they disappeared from radar, and you don't keep radar on the planes that are on the ground, so....?

      Big airports DO have ground radar... they like to keep track of everything either in the air or on the ground. I would imagine they use different displays for each radar given the differences of scale, but the data is probably merged. A plane attempted to take off in Taiwan in a storm in low visibility, ended up on the wrong runway and people died. The lack of ASDA radar [channelnewsasia.com] meant the tower couldn't track their ground path and spot the pilot error.

      2) Whose bright idea was it to do a "systems upgrade" while there were large, flying metal objects carrying many people still in the air?!?! Wouldn't you do a test run, install it on a backup system, or one that's not systems-critical?

      I would expect a control tower's computer systems to have the tightest change control procedures possible. Unforeseen situations can occur no matter how careful you are. What matters is what procedures you have in place to deal with it when everything goes pear-shaped. Given no planes fall-down-go-boom I think their procedures worked out quite nicely. There's nothing in the article to say the "glitch" occurred at the time of upgrade or whether the upgrade was done earlier and the computer waited until 7am to stick it's finger in it's ear....

      A Control Tower's ability to identify planes isn't magically connected to their ability to fly... and I think they're fairly good at teaching pilots how not to bump into things...
    • 1) How the hell did the flights get DOWN once the radar died? It said they disappeared from radar, and you don't keep radar on the planes that are on the ground, so....?

      They still had working primary RADAR and radios. Aircraft on the ground are managed by controllers at the airport itself.

      2) Whose bright idea was it to do a "systems upgrade" while there were large, flying metal objects carrying many people still in the air?!?!

      They did it on a Saturday.
  • redundancy (Score:5, Insightful)

    by Brigadier ( 12956 ) on Sunday March 02, 2003 @06:04PM (#5420512)


    Am I the only one wondering why there was no redundancy. As in effective. One would think something as important as airtraffic control should have several layers of complete redundancy. As in if a control tower has say a catastrophic failure there is another a.) civilian b.) military control center able to hand off instructions. which would include all flight information. including passengers, cargo flight log, flight plan everything.
    • Re:redundancy (Score:2, Interesting)

      by Mr Rohan ( 87542 )

      Am I the only one wondering why there was no redundancy.

      Typically there are redundant systems as well as manual processes - in Sydney Australia there's even a redundant tower, which is used if the main tower stops working (e.g. major power problems).

    • Bean Counters (Score:4, Insightful)

      by Jetson ( 176002 ) on Sunday March 02, 2003 @09:22PM (#5421435) Homepage
      Redundancy started to suffer when the bean counters took over. Air Traffic Control is no longer an exercise in absolute safety but one of "risk management". This means that when the system designer says "I want a fully redundant hot standby system in a separate building powered from a different grid feed and on its own battery backup" the bean-counters say "you can have a warm standby (because we wouldn't want to have to pay for two software licenses) in a separate rack in the same computer room (have you looked at the cost of raised flooring lately?)". Instead of asking "what can we do to avoid a failure?" they tend to ask "how long will each failure last and how much will that cost us in lost revenue?"
      • That's actually a somewhat reasonable tradeoff. It's not like this would kill people, the air field just shut down. But you would think that while the system was being upgraded it would be run in parallel with the known working system. That was the standard procedure even for office automation.
        Perhaps in this case the separate building and separate power would be excessive. But ... no redundancy? During an upgrade? If you do that, you should expect failure, and allow for it in advance.

        (Perhaps they did, and figured out that it would cost them more to notify their customers than to risk just suddenly closing the airport.)
        • Even running a "shadow operation" on a second set of computers can be an expensive proposition when you're talking about ATC. It is far more common to do "in place" upgrades by taking the redundant systems off-line and upgrading them while the controllers continue to carry live traffic on the other half of the system. At some quiet period the two systems change roles (usually with data loss) and then the controllers run with the new software for a few hours to see if it breaks. If all is well, then the other side is upgraded and brought back into redundancy.

          The problem with this situation is that there is a significant period of time in which the smallest hiccup can bring the whole aviation system back to the stone age because of the lack of redundancy. There have also been (unfortunately numerous) occasions where latent software defects were not detected until after the second side had been upgraded.

          The need for quality control at the design and coding stages cannot be overstated, as it's almost impossible to do live load testing on these systems before they are shipped to the facilities. Sure, the developers can pipe in recorded radar traffic, etc., but nothing can simulate the pseudo-random reality-based pounding of a hundred controllers on the keyboards.

          From my experience, the biggest bugs to reach the operational systems are generally race conditions that weren't expose in testing due to the different operating conditions and/or the presence of debugging code that were actually masking the condition they were trying to detect.
    • From memory, the backup computer crashed as well.

      From the Australian ABC [abc.net.au]
      Due to a reprogramming hiccup, the main system and its backup went down immediately after being switched on

      I presume they made a change to both systems, or more likely, the backup system was also connected to the military system and also choked on the data is was being fed.
    • From what I heard on NHK news Saturday, there was a redundant system -- but it also received the same system upgrade early Saturday morning. So, two broken systems is really no better than one.
  • by MyNameIsFred ( 543994 ) on Sunday March 02, 2003 @06:05PM (#5420519)
    Obviously upgrades to Air Traffic Control (ATC) systems and communication links to ATC can be cause problems. There is a significant safety of flight issue. Therefore, the FAA maintains strict control of these systems. And in fact, has a dedicated network reserved for ATC. Only "essential" programs and systems are allowed to connect to it.

    Passenger listings, airline booking systems, and related software are NOT connected to the ATC network. Since CAPPS II looks at booking data, credit card info, and related data, it would not be connected to the ATC network.

    • True, but both are, after all, major systems in the air transportation process. A failure in either one has the potential to be catestrophic; if the ATC system screws up, planes could collide, and if security screws up, a dangerous passenger could be let through. The difficulty is in the political nature of the second system; there is no one who disagrees that planes should be kept apart, and no one disagrees that terrorists should be kept off airplanes (well, except the terrorists - they might disagree with both assertions, but that's another matter).

      Anyway, the worst hassles of a functioning ATC system are long delays, holding patterns, etc, while the security system has much more troubling implications - which are obvious to anyone. So I guess, in a way, it's better that the ATC system failed, and no one got hurt, than a security failure ...
  • by NotAnotherReboot ( 262125 ) on Sunday March 02, 2003 @06:07PM (#5420531)
    Out of curiousity, how does one go about testing a system like this? Do they test changes to the code in a live system? (not using the newer version, just looking at it along with the old one). Are there flight emulators that will feed fake data to the software which in turn displays what it is receiving? Do they do extensive testing between new systems that perform different functions yet interface as well? It seems to me a large part of the budget for these projects has to be testing.
    • With new systems, they normally do shadow-mode testing: this means, running the new system with ATC controller behind it in parallel. After a while, the new system will become the default system and the old system is also run in parallel but now as backup system (with real ATC controllers checking if everything goes okay). After a while, the new system is considered O.K. and the backup system is removed.

      I don't think they do this with maintenance updates, but maybe they should consider it. Unfortunately, air traffic controllers are still rare and (not in the least) expensive.

  • by Anonymous Coward
    1. Sir, Is your computer plugged in?
    2. We are going to need some registration information before we get started.
    3. Oh, we don't support that OS
    4. Anything else, have a nice day
  • Anyone see the other news on this site?!

    Police recover rock climber's body after fatal fall
    Motorcyclist dies after being hit by a truck
    61-year-old jobless man fatally abuses senile mother
    Dad dies of shock after son's repeated beatings
    Comic questioned over hitting woman in restaurant
    Death row inmate dies in prison cell

    Can someone in Japan please confirm that this is a freaky, awful day, and that Japan isn't normally this bad?

    Although that last one is quite ironic.
    • Yes, it is that bad (Score:2, Informative)

      by Anonymous Coward
      I've lived here for several years now, and the above stories really are an average selection. On a true freaky, awful day, you would see stories far worse.
    • Looks like a perfectly normal day, pretty much anywhere, to me.

      Yes, I'm serious. Read your own home town newspaper if you don't believe me.

      KFG
      • Here are the first "news" items from Bristol, UK.

        Customs officers stop a 46-year-old woman at Bristol airport and find £96,000 in her hand luggage.
        Operatunity winner 'floating on air'
        Man, 83, charged with murder
        Patients' phrasebook aids 999 crews
        A future for Concorde?
        South Gloucestershire council tax up 6.1%

        How dull is that?
        http://www.bbc.co.uk/bristol/content/news/ [bbc.co.uk]
    • Wild boar attacks 6, leaves 2 seriously injured
      Strong winds strike fatal blow to do-gooder
      Public servant disguised as delivery man rob mother, daughter
      Osaka legislator slurs Asians
      Computer cock-up continues plaguing domestic travelers
      Prison death trial to see violent video images
      Marine steals from cabby
      Man sits by unaware as neighbor plunges to death
      Jilted man busted for forcing woman to wear sailor suit
      Old man slits own throat with paper cutter
      Women call for sex scandal governor's resignation
      Education evolves from coeducation to social equality

      And the rest of the items were similarly strange. The thing is, you know how you watch the local news on television and they only seem to report items involving spectacular suffering or small fluffy animals. I think they get extra points if they can find a small fluffy animal suffering. The news items seem to be the standard fare but without the feel-good pieces that we're (that's the royal we, if you don't agree with me) used to.

    • You missed... Dominatrix whips up donations for refugees [mainichi.co.jp] ... now that's a headline!
  • by anon*127.0.0.1 ( 637224 ) <slashdot@@@baudkarma...com> on Sunday March 02, 2003 @06:19PM (#5420579) Journal
    I think it's obviously Y2K related. Civilization as we know it should be coming to an end in a week or so.

  • "Computers are just no good," said one 51-year-old company manager leaving for Sapporo. "I'm sure they're helpful, but they're just too fragile." Uh, yeah, I also have a feeling they may be a little helpful. Good luck controlling 70 percent of all air traffic in Japan with abacii and the Everyday Memory Builder [amazon.com]...
  • by Alien Being ( 18488 ) on Sunday March 02, 2003 @06:22PM (#5420599)
    Loger Murdock: We have crearance Crarence.
    Captain Oveur: Loger, Loger. What's our vector Victor?
    Tower voice: Tower's ladio crearance, over!
    Captain Oveur: That's Crarence Oveur! Oveur.
    Tower voice: Loger.
    Roger Murdock: Huh?
    Tower voice: Loger, over.
    Roger Murdock: Huh?
    Captain Oveur: Huh?
  • some glitch (Score:5, Interesting)

    by LuxFX ( 220822 ) on Sunday March 02, 2003 @06:25PM (#5420610) Homepage Journal
    If this was an error in the code, then how were they able to repair it in just 54 minutes? That's a pretty narrow window when it comes to rounding up the programmers, searching through the source, then repairing, testing, redistributing to the entire system, and rebooting the whole thing.

    Kind of like how Hugh Jackman can hack into the DoD from a computer he's never touched before in Swordfish.

    I'm tempted to think that this was much more human error than a bonefide "computer glitch". Maybe that 54 minutes was the time it took to call in their expert, have him look at the system, and declare "Why, you must have hit F11, which toggles the flight information. Just hit it again and it comes back."

    • According to the article I read, it took around four hours to fix it. (7 am to 11 am). About 30 minutes after the problme occurred, they began routing flights manually, using 10 minute delays between each aircraft.
    • Kind of like how Hugh Jackman can hack into the DoD from a computer he's never touched before in Swordfish.

      Keep in mind that they had the advantage of not being "serviced orally" while they were at it.

      *ducks*
    • If this was an error in the code, then how were they able to repair it in just 54 minutes? That's a pretty narrow window when it comes to rounding up the programmers, searching through the source...

      If this was the 80's, I could say: "Their programmers are Samari trained, and if they don't work fast and accurate, they have to commit hari kari (disembowelment) in front of their peers.", and everybody would believe me. Guess I'll just have to make up shit about Islam instead.
  • Godzilla of course, obviously he is currently running rampent over Japan!

    You have seen the Simpsons episode where they go to Japan right?!
  • by Technomancer ( 51963 ) on Sunday March 02, 2003 @06:28PM (#5420624)
    Was it computer that failed some operation or lousy programmer who made a mistake in the program?
    I am sick of people complaining abour "computer errors" when they are at fault.
  • by NineNine ( 235196 ) on Sunday March 02, 2003 @06:44PM (#5420699)
    ... or at least upgrade as little as possible. No matter how much planning and testing is done, upgrades can and will screw things up. I'm always reading about , "luckily, you can recompile the new kernel every week or so", or, "a new version is coming out so I have to upgrade" and I'm thinking... yeah, at home, maybe, if you have nothing better to do. But this is an extreme example of why companies that are worth their salt don't upgrade at the drop of a hat.
  • by infonography ( 566403 ) on Sunday March 02, 2003 @06:59PM (#5420757) Homepage
    DATELINE: JAPAN (maybe)

    Computer related story about a programming error halting Air traffic control system in Japan is entered in a pre-posting queue to Slashdot.

    DETAILS: Limited and not noteworthy.

    REAL NEWSWORTHYNESS: Not really. No deaths reported.

    DATELINE: SLASHDOT HQ

    PREPOST WORD SEARCH: code runs check for Important items. - keyword search generate matches for two known hot item words [COMPUTER & JAPAN]

    HENTAI AND GIANT ROBOT FACTOR?: n/a

    CUTE BABE?: n/a

    SEARCH FOR BIG NAMES- JOBS, ELLISON, GATES, TORVALDS, STALLMAN, CowboyNeal?: n/a

    Microsoft Bashing Factor: High

    PRIMARY ACTION TAKEN: Story authorizes posting of story to Slashdot

    SECONDARY ACTION TAKEN: activate Inquisitors of the Holy Order of Linux, First Poster Squad IM'ed, new Sex story featuring Whicky the slashdot cat beta authorized.

    STATUS REPORT: Status Quo Achieved.

    RESOLUTION: Computer error found between keyboard and chair

  • Slashdotted (Score:5, Funny)

    by banzai75 ( 310300 ) on Sunday March 02, 2003 @07:01PM (#5420768)
    At 7am Saturday, the error "caused the names of airlines and flight numbers to disappear from radar screens."

    I'm guessing there was an article posted yesterday on Slashdot that linked directly to their system.
  • Wait a second.. didn't they say that was going to happen when the Y2K bug was supposed to hit? Flights disappearing from radar, etc? Funny, they seem to have handled it fine. =)
  • Someone obviously broke the coffee cup holder right at the time the sysadmin had clicked on the 'uninstall' button of the old version.

    Ah, no, wait...

  • Working in the software industry here in Japan for the last two years I have had my eyes opened to the true state of affairs. Most 'westerners' have an idealogical view of the high-tech world of Japan. This is far from reality. The fact is that software development here is at best poorly done, little design, short timelines (okay that one is universal), and lack of quality assurance. I can't say why this is the case, but shoddy products are in abundance. It may be trying to shove a relatively new industry into an old style organization, or the lack of individualism, I'm guessing at these. This story does not surprise me. All I know is I am looking forward to returning to the industry in Canada.
    • Really. I've been living in Japan (Okinawa) now for close to 3 years, and I never ceased to be amazed at the quality and low cost of all the electronics and software available here. The Japanese are varey subserviant and bend over backwards to please the customer and repair any problems. Hell, my DSL line has gone out 1 time for about 3 hours in the last 14 months, I had a NTT tech over to fix it in about 30 min from calling in, and they gave me one month of free service...
  • by muonzoo ( 106581 ) on Sunday March 02, 2003 @09:13PM (#5421402)
    I think this is one of those rare times where I have an opinion that's actually relevant. :-)
    • I am a pilot.
    • I am a Software Engineer
    • I worked on a large air traffic control system [raytheon.com] for 7.5 years
    • I read the article

    First, people need to understand that no Bad Things will happen if an ATC system goes offline while planes are under it's jurisdiction. ICAO [icao.org] member countries (and most nations for that matter) have strong procedural rules in place that keep planes separated without the help of radar. This is espcially true in the enroute case. (Area control centres handle overflight and enroute traffic. Eveyone is separated by at least 1000' vertical and 3 miles horizontal at all times. The altitude restrictions and clearances that each pilot receives are chosen specifically so that in the even of loss of communications, the pilot can continue to his "clearance limit" without any problem. Well, you ask, what happens when he gets to his clearance limit and still isn't communicating with air traffic control? They hold. This is all laid our quite clearly. These rules have been around since before RADAR because thats the way it was done.
    Just take a look at the RADAR coverage map of Canada (one is visible at the link above). There are lots of places that don't even HAVE radar coverage.
    The old tried and true clearance and time/speed based conflict resolutions works and works well.

    Secondly, and more imporatantly, there really isn't any news in this article. It's scaremongering. This happens all the time. It's an inconvenience, but rarely a saftey concern.

    For those who asked about it; yes, typically a new system is run in parallel with the legacy system for a period of time (sometimes 24 months) before it is used as the primary control. Notice that the old system is live and the new system is shadowing. That way, anomalies that are found do not impact any flights.
    [*flame proof underwear on*]
    Is it just me, or does the press dig around for 'news' in about as diligent a manner as Slashdot?
    • Is it just me, or does the press dig around for 'news' in about as diligent a manner as Slashdot?

      It's just you.

      In related news: Aviation Security Expert Says Outdated Airtraffic Control System Still in Use 24 Months after Better, RADAR-Based System Deployed; Tries to Convince Unaware Public "No Bad Things Will Happen"; Canada Apologizes for Insufficient RADAR Coverage.

    • Mainichi Daily News (daily daily news) is often regarded (especially MDN english) as being a tabloid.

      Generally they go for sensational headlines and stories (their "Wai-Wai" section is the most popular).
    • Does the ICAO [icao.org] have strong procedural rules in place on what to do in the event of a slashdotting?

      Might be time to get out the rulebook...
    • Hmmm. Perhaps I can help with a few misconceptions here, based on over 19 years of air traffic control experience at Atlanta Center.

      First, people need to understand that some bad things might happen if enough ATC systems go offline at once. Bad things are less likely to happen, as the poster states, if the outages occur in the enroute (my) environment, because the planes are generally farther apart than in terminal airspace. (Picky notes: enroute separation is 5 miles (not 3) OR 1000 feet--not AND--but I'm sure that was just a misstatement.) But they're not THAT far apart. This post makes it sound like any time we want to we can drop back to good old non-radar control. Well, standard separation in a non-radar environment is as high as 10 minutes flying time (longitudinally, which is to say along the same route). That's a lot more than the five miles I was using when the radar was working. The transition will be a bit tricky, and if I have to do it for any length of time, traffic will slow to a virtual standstill.

      What's more, it is simply not true that aircraft clearances cover eventualities like lost communications or lost radar. This is a myth, and one that new on-the-job trainees quickly get de-programmed out of their heads. It's not possible to issue clearances that are good all the way to your clearance limit--every aircraft that departs, deviates for weather, changes destination, or even changes altitude (say, for turbulence) has the potential to screw up everybody else's "perfect" clearances. We truly don't even try to come up with such clearances. As for the idea that everybody will get to their clearance limit (actually, it's the published holding pattern for the route they're on to their clearance limit--probably that was simplified for clarity) and hold, that's great until you get the part about "until their estimated time of arrival" (original poster left that part out). Now you have planes dropping out of holding (and BTW, who assigned altitudes to make sure 6 aircraft didn't hold at the same altitude when the radios went out?), not necessarily from the bottom first, and flying to their destination airport. It's a 5-times-a-day event at hubs like Atlanta for 30+ aircraft to be scheduled over one fix in an hour--what are we gonna use for sequencing? TCAS? Common Traffic Advisory freqs? Get serious.

      I'm not trying to scare anybody here. There are redundant systems (and they're pretty well-seasoned at this point anyway, so they almost never break), and ways to get hold of aircraft through company radios, and it really is a big sky. But it doesn't do anybody any good to pretend that it's not dangerous to try to sort out a major arrival rush by looking in your fish-finder and chatting with the other pilots til the controller gets back.

      ATC was invented many decades ago because airplanes flew into each other without it. Those were props, flying to destinations with a tenth the volume of a modern hub. Maybe someday we'll have some cool hive-mind software that will allow the airplanes to sort everything out between themselves, and there won't be anymore ground-based controllers. (I won't see it in my career, cause I retire in less than 6 years.) Until that time, controllers and reliable control equipment will continue to be necessary for safety as well as expediency.

      • Disclaimer - while I have read quite a bit on ATC I won't pretend to be a professional.

        My understanding is that controllers keep manual flight strips handy just in case a computer fails without warning. They are trained in estimating where a plane will be after flying x minutes at y knots. However, this is not meant as a substitute for the full technology provided by modern ATC systems - it is basically designed to minimize the likelihood of a crash while the computer guys run like mad to get things back up.

        Keep in mind that modern ATC systems inflict ulcers and heart attacks on their operators WITH all the fancy technology. Imagine having 100 planes under your control and having to keep calling them all for position updates so you can keep updating their location on a map...

        If something like this happened across the entire US at once, the first thing that would happen is all aircraft on the ground would stay that way - no need to add fuel to the fire. Planes in the air would probably be directed away from busy airports as much as possible based on their fuel loads. It is simply impossible to run the JFK or LAX approach patterns without radar at the same capacity they run with it.

        You could probably handle something like this without a major disaster if everyone stayed alert, but you can bet that the controllers involved are going to want to take a day off after it is all over...
  • Hey, slashdot japan is running this story too:

    here. [slashdot.jp]

  • by art3d ( 219854 )
    I take it they weren't running .Net?
  • Let's do a simple trichotomy of possible Slashdot headlines:

    The Good: "Flight Software Runs Smoothly In Japan"
    The Bad: "Computer Error Grounds 203 Japanese Flights"
    The Ugly: "Computer Error in Flight Software Causes 203 Plane Crashes"

    It could have been a lot, lot worse ...
  • The Real Story??? (Score:2, Interesting)

    From The DrudgeReport [drudgereport.com] on 02MAR2003 @ 2204 PST

    Intelligence reports about the terrorist threat to the Hawaiian harbor bombed by the Japanese in World War II were sent to senior U.S. officials in the past two weeks and coincided with reports of the planning of a major attack by Osama bin Laden's terrorist group.

    GERTZ: Terrorists aim at Pearl Harbor; Plan to hijack airliners, fly them into nuclear subs

  • So when is a problem a 'computer glitch' and when is it a human error? How can you blame something that is entirely of human design for making mistakes on its own? Garbage in, garbage out, surely?

    Seems to me we are good at praising ourselves when machines do what we want, but we are quick to distance ourselves from them when they go wrong.

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Working...