• anonym (unregistered)

    wouf wouf

  • (cs)

    That is a thing of beutee

  • (cs)

    IN UR 'PUTER - SAYIN YER COMMETNZ

  • (cs)

    Their record for fixing bugs is patchy at best.

  • blah (unregistered)

    I'm disappointed. I expected a script that would activate a piece of industrial machinery to shake the bloody computation out of the beige box.

  • (cs)

    Apparently Mark Bowytz isn't aware that "beige box" is in fact generally understood to mean "a PC".

  • (cs)

    A light immediately went off in Shawn's head

    Well, there's his problem right there: it's difficult to see a solution in the dark.

  • Ken B (unregistered)

    Three of the most feared words in computerdom: Works as designed.

  • Neil (unregistered) in reply to Zylon
    Zylon:
    Apparently Mark Bowytz isn't aware that "beige box" is in fact generally understood to mean "a PC".
    You clearly don't understand - it wasn't a computer at all, but a Rube Goldberg contraption in a beige box with marble hitting a 286 processor that falls over, sparking a match and lighting a candle.
  • Alin (unregistered)

    C'mon, it's a great solution... all it needs is another patch... woof...reboot...crash

  • Monday (unregistered)

    It should really write a log of each session state crash to the hard drive...just in case.

  • (cs)

    I was expecting the watchdog to pop a CD tray out that pressed the reset button and then the watchdog's watchdog to step in a stop the first watchdog from reseting the beige box by putting something in to block the tray and then the two watchdogs would end up in big fight over pressing or not pressing the reset switch with teeth and fur flying everywhere causing general mayhem and mass panic.

    Skizz

  • Iain Collins (unregistered)

    This sort of thing could easily be avoided if only peopled learned how to use throw/fetch exception handling correctly.

  • Norse (unregistered) in reply to Iain Collins
    Iain Collins:
    This sort of thing could easily be avoided if only peopled learned how to use throw/fetch exception handling correctly.

    So the watch dog has something to do while it waits for the computer to freeze?

  • Joey Stick Eye Smiles (unregistered)

    WTF? Did these people have a 30-year support contract?

  • 30-years-old (unregistered)

    There's nothing uncommon in having a "286 in small box" in an industrial environment because they Just Work and they can be very reliable. I would be crazy to expect the same reliability from your powerful desktop with colorful lights.

    Also, watchdogs are commonly used in industrial environments, automotive and datacenters and they are implemented in hardware since many years.

    I'm not implying that what they did was fine - but certaily Mark Bowytz still has something to learn.

  • (cs)

    Like a cascade failure on a poorly designed cluster. One app picks up data from the shared storage that causes it to crash. The second server realises the first has died, picks up the process and the data, tries to process it, and crashes. The third server realises the second has died, picks up the process and the data, etc.

    A great way to take down your entire cluster, and always face-palmingly funny when it's someone else's cluster, and you get to watch it die. (Of course, it usually happens a lot faster than one failure every 48 minutes, so you usually work out what's happening fairly quickly, though usually too late.)

  • Edinburgh Mike (unregistered) in reply to Iain Collins
    Iain Collins:
    This sort of thing could easily be avoided if only peopled learned how to use throw/fetch exception handling correctly.

    Ah yes, like the below:

    try { // Poor Code catch (Exception e) {}

    But seriously, I doubt you'd like the experience of using most of the languages that support these operations on hardware that old!

  • the man who thought he can (unregistered) in reply to Edinburgh Mike
    Edinburgh Mike:
    Iain Collins:
    This sort of thing could easily be avoided if only peopled learned how to use throw/fetch exception handling correctly.

    Ah yes, like the below:

    try { // Poor Code catch (Exception e) {}

    But seriously, I doubt you'd like the experience of using most of the languages that support these operations on hardware that old!

    whoosh!

  • vtcodger (unregistered)

    You're telling me that these guys were smart enough to cobble together a watchdog device running on a serial port? And smart enough to save and restore the state of their application? But they were too dense to figure out that the saved state might be defective and related to their processing crashes?

    With all due respect, that doesn't seem very likely. There has to be more to the story.

  • Steve (unregistered) in reply to Joey Stick Eye Smiles

    They probably bid on a support contract that included "all IT hardware" and got stuck supporting this piece of equipment. From what I hear in the 'hardware world', this is not uncommon.

  • Steve (unregistered) in reply to Edinburgh Mike
    Edinburgh Mike:
    Iain Collins:
    This sort of thing could easily be avoided if only peopled learned how to use throw/fetch exception handling correctly.

    Ah yes, like the below:

    try { // Poor Code catch (Exception e) {}

    But seriously, I doubt you'd like the experience of using most of the languages that support these operations on hardware that old!

    it is supposed to be like this:

    try {

    // crappy code block

    } catch(Exception ex) { // cut and past of crappy code block }

  • (cs)

    This sounds a bit more like the field of an automation company than an IT company.

    I work for an automation company. I recently repaired a welding machine that failed to boot because the 486 DX2/66 machine controlling it got caked with welding dust (thanks to the cabinet not being closed correctly from 'temporary wiring' that's been there for years) and the hard drive failed.

    It's a lot of fun to try to replace an 800 MB hard drive on a computer with a BIOS that is some custom job and, because of age, doesn't recognize anything greater than 1.97 GiB - the 4096 cylinder limit. To top it all off the software controlling the machine conflicts with those drive overlay programs.

    I eventually pulled a hard drive from some computer scrap place in California, cobbled together the software from four failed-but-semi-recoverable 3.5" floppy disks and a Windows 98SE boot disk, and got them going again.

    My favorite part was the support docs I found for this custom computer enclosure. Their solution to replace the power supply when it failed was to swap it out from an AT to an ATX supply - which also required replacing the "CPU board", effectively upgrading the machine from a 486 DX2/66 with 8 MB of RAM to a 2.4 GHz Pentium 4 with 1 GB of RAM. Hmmmm.

  • (cs) in reply to evilspoons
    evilspoons:
    This sounds a bit more like the field of an automation company than an IT company.

    I work for an automation company. I recently repaired a welding machine that failed to boot because the 486 DX2/66 machine controlling it got caked with welding dust (thanks to the cabinet not being closed correctly from 'temporary wiring' that's been there for years) and the hard drive failed.

    It's a lot of fun to try to replace an 800 MB hard drive on a computer with a BIOS that is some custom job and, because of age, doesn't recognize anything greater than 1.97 GiB - the 4096 cylinder limit. To top it all off the software controlling the machine conflicts with those drive overlay programs.

    I eventually pulled a hard drive from some computer scrap place in California, cobbled together the software from four failed-but-semi-recoverable 3.5" floppy disks and a Windows 98SE boot disk, and got them going again.

    My favorite part was the support docs I found for this custom computer enclosure. Their solution to replace the power supply when it failed was to swap it out from an AT to an ATX supply - which also required replacing the "CPU board", effectively upgrading the machine from a 486 DX2/66 with 8 MB of RAM to a 2.4 GHz Pentium 4 with 1 GB of RAM. Hmmmm.

    Wow, that's actually pretty amazing... and what I used to do a while back. Though I always went with the "cut cable off old AT supply, cut connector off ATX supply, wire the two together and short the green wire (pin 14) to a ground" method rather than replacing the motherboard as well, too much chance of an I/O port changing addresses, IRQs being mismatched, or something else that the ancient embedded software wasn't expecting suddenly changing under it... up to and including requiring "speed-up loops". Easier to just whip out the soldering iron than fight with the software.

    Note: when powering embedded systems, put a fuse at each end of the supply cable... on one project we had the fuse at the embedded system end, and one slip resulted in the -48V feed landing on the ground plane of a board, which backfed it so badly that most of the regulators desoldered themselves from the board and every electrolytic capacitor promptly exploded or caught fire :( $750 of custom hardware gone in under a tenth of a second.

  • big bird (unregistered) in reply to Joey Stick Eye Smiles
    Joey Stick Eye Smiles:
    WTF? Did these people have a 30-year support contract?

    Probably - most sales types don't realise that there comes a time when some contracts are better not renewed. Have you tried buying DOS-compatible PCs recently?

    We had support contracts for a DOS-only app at my last place. They had to use NetBeui and connect to 64-bit Windows Servers. Fun, fun, fun.

  • 5|i(3_x (unregistered) in reply to big bird
    big bird:
    We had support contracts for a DOS-only app at my last place. They had to use NetBeui and connect to 64-bit Windows Servers. Fun, fun, fun.

    It's possible to run TCP/IP on DOS--at least on 6.22.

  • spike (unregistered) in reply to 5|i(3_x
    5|i(3_x:
    big bird:
    We had support contracts for a DOS-only app at my last place. They had to use NetBeui and connect to 64-bit Windows Servers. Fun, fun, fun.

    It's possible to run TCP/IP on DOS--at least on 6.22.

    IIRC the TCP/IP stack used an ungodly amount of memory, which could be a concern under DOS. If for example your main APP was close to the limits already, there wouldn't be any room for the TCP/IP stack. NetBEUI was very small however.

  • willthiswork89 (unregistered)

    Am i the only one who noticed the pit-bulls question is malformed?

  • (cs) in reply to big bird
    big bird:
    Joey Stick Eye Smiles:
    WTF? Did these people have a 30-year support contract?

    Probably - most sales types don't realise that there comes a time when some contracts are better not renewed. Have you tried buying DOS-compatible PCs recently?

    This wasn't a personal computer. It was an industrial appliance.

    And yes, yes I have. It is easy, if you go to industrial supply places. You know, the places that sell raw parts and paint and safety equipment and racks and industrial appliances.

  • MD (unregistered) in reply to 5|i(3_x
    5|i(3_x:
    big bird:
    We had support contracts for a DOS-only app at my last place. They had to use NetBeui and connect to 64-bit Windows Servers. Fun, fun, fun.

    It's possible to run TCP/IP on DOS--at least on 6.22.

    It's possible to run TCP/IP on a friggin' 8-bit microcontroller. DOS is overkill =)

  • IV (unregistered)

    Where did he go to school/intern that he was used to multi-giga RAM? At my schools and internships, 1 GB is pretty much the max unless I get on a research machine or go to my personal computer. Maybe I am in the wrong place.

  • big bird (unregistered) in reply to MD

    The TCP/IP drivers used too much memory. The decision to use DOS was made a decade before by time there...

  • Anon (unregistered) in reply to vtcodger
    vtcodger:
    You're telling me that these guys were smart enough to cobble together a watchdog device running on a serial port? And smart enough to save and restore the state of their application? But they were too dense to figure out that the saved state might be defective and related to their processing crashes?

    With all due respect, that doesn't seem very likely. There has to be more to the story.

    I agree, according to the story the WTF is that they didn't seem to realise that their "fix" increased the problem ten-fold. The actual problem never even got a mention and all the OP did was get them back to square 1.

  • big bird (unregistered) in reply to Captain Oblivious
    Captain Oblivious:
    big bird:
    Joey Stick Eye Smiles:
    WTF? Did these people have a 30-year support contract?

    Probably - most sales types don't realise that there comes a time when some contracts are better not renewed. Have you tried buying DOS-compatible PCs recently?

    This wasn't a personal computer. It was an industrial appliance.

    And yes, yes I have. It is easy, if you go to industrial supply places. You know, the places that sell raw parts and paint and safety equipment and racks and industrial appliances.

    Ouch. We did try and none of them was happy running the software.

    And I admire your pendantry, but I think it's safe to call the device in question a PC - an industrial PC. :)

  • KP (unregistered) in reply to Iain Collins

    Try / catch and exception handling came along several years after the AT (80286) and PC (8086 / 8088) machines. Not one of the commercially available compilers would have supported exception handling, if this system was developed before about 1992. To my recollection just about nobody really coded with exception blocks before 2000

  • Chuckler (unregistered) in reply to MD

    It's possible to run TCP/IP on carrier pigeons. 8-bit microcontrollers are .. well ... check out CPCP :-)

  • (cs) in reply to Chuckler
    Chuckler:
    It's possible to run TCP/IP on carrier pigeons. 8-bit microcontrollers are .. well ... check out CPCP :-)
    Also check out the Con-Tiki project and the uIP network stack... with a crystal tech cs8900a, a few SSI TTL chips, and one floppy disk (the actual floppy kind!) you can get a commodore 64 surfing the net on 48k of RAM used.
  • Dan (unregistered)

    So did they not have the source code of the program? If it took 15 minutes on a 286, the same code should take only a couple seconds on a $300 desktop of today. Plus they could, I don't know... FIX the program?

    Heck, you wouldn't even need the unreliability of Winderz, since DOS still runs on new hardware.

  • danodemano (unregistered) in reply to willthiswork89
    willthiswork89:
    Am i the only one who noticed the pit-bulls question is malformed?
    I noticed it but I thought it was just an ID10T error on my part and didn't say anything.
  • nerfherder (unregistered) in reply to KP
    KP:
    Try / catch and exception handling came along several years after the AT (80286) and PC (8086 / 8088) machines. Not one of the commercially available compilers would have supported exception handling, if this system was developed before about 1992. To my recollection just about nobody really coded with exception blocks before 2000

    Are you kidding? On Error Resume Next was all the rage in 1998. Now that's what I call error handling.

  • nerfherder (unregistered) in reply to Dan
    Dan:
    So did they not have the source code of the program? If it took 15 minutes on a 286, the same code should take only a couple seconds on a $300 desktop of today. Plus they could, I don't know... FIX the program?

    Heck, you wouldn't even need the unreliability of Winderz, since DOS still runs on new hardware.

    How hard do you think it is to add serial ports to a new $300 machine, and get the 16 bit handwritten-in-assembly application to run stably, for that matter? Or I guess they could just reverse engineer the application from the no longer existing design docs?

  • Dan (unregistered) in reply to nerfherder
    nerfherder:
    Dan:
    So did they not have the source code of the program? If it took 15 minutes on a 286, the same code should take only a couple seconds on a $300 desktop of today. Plus they could, I don't know... FIX the program?

    Heck, you wouldn't even need the unreliability of Winderz, since DOS still runs on new hardware.

    How hard do you think it is to add serial ports to a new $300 machine, and get the 16 bit handwritten-in-assembly application to run stably, for that matter? Or I guess they could just reverse engineer the application from the no longer existing design docs?

    According to the article, the serial port was used for the watchdog. And 16-bit code runs on new hardware, so what stability changes are you thinking of? And if they can add state savers and watchdog timers, that's a good sign that they have the source and can also FIX THE PROGRAM while they're at it.

  • anon (unregistered) in reply to vtcodger
    vtcodger:
    You're telling me that these guys were smart enough to cobble together a watchdog device running on a serial port? And smart enough to save and restore the state of their application? But they were too dense to figure out that the saved state might be defective and related to their processing crashes?

    With all due respect, that doesn't seem very likely. There has to be more to the story.

    They probably started with poor assumptions, and never questioned or tested those assumptions. It may never have occurred to them that their data or their app caused the crashes...

  • heretic (unregistered) in reply to Steve
    Steve:
    Edinburgh Mike:
    Iain Collins:
    This sort of thing could easily be avoided if only peopled learned how to use throw/fetch exception handling correctly.

    Ah yes, like the below:

    try { // Poor Code catch (Exception e) {}

    But seriously, I doubt you'd like the experience of using most of the languages that support these operations on hardware that old!

    it is supposed to be like this:

    try {

    // crappy code block

    } catch(Exception ex) { // cut and past of crappy code block }

    You, sir, have obviously never worked in a True Java Environment where there is but one True Way to format the above code:

    1. Thou shalt use four space indents.
    2. Thou shalt put the opening brace of a block on the same line as the token which initiates said block.
    3. Thou shalt cower before the mental supremacy of the Great Sun (for you are too stupid to code your way out of a wet paper bag). ... ad nauseam ...
  • The Oracle (unregistered) in reply to heretic
    heretic:
    3. Thou shalt cower before the mental supremacy of the Great Sun (for you are too stupid to code your way out of a wet paper bag).

    Or the Great Oracle?

  • Anonymous Coward (unregistered) in reply to 30-years-old
    30-years-old:
    There's nothing uncommon in having a "286 in small box" in an industrial environment because they Just Work and they can be very reliable. I would be crazy to expect the same reliability from your powerful desktop with colorful lights.

    Also, watchdogs are commonly used in industrial environments, automotive and datacenters and they are implemented in hardware since many years.

    I'm not implying that what they did was fine - but certaily Mark Bowytz still has something to learn.

    I think you're missing the point. The WTF wasn't the 286 or the watchdog hardware, for the exact reasons you pointed out. The WTF was the 'saved state' crash loop.

    The best part of this WTF was how obvious the problem was.

  • Scott K (unregistered)

    Am I the only one who's going to object to the jab at pit bulls--the actual dog? They're unfairly maligned enough, without throwing a misleading photo and offhand insult on an IT website.

  • Nobody (unregistered) in reply to Ken B
    Ken B:
    Three of the most feared words in computerdom: Works as designed.

    Famous words of a programmer I work with ...

    s/Famous/Irritating

  • (cs) in reply to spike
    spike:
    5|i(3_x:
    big bird:
    We had support contracts for a DOS-only app at my last place. They had to use NetBeui and connect to 64-bit Windows Servers. Fun, fun, fun.

    It's possible to run TCP/IP on DOS--at least on 6.22.

    IIRC the TCP/IP stack used an ungodly amount of memory, which could be a concern under DOS. If for example your main APP was close to the limits already, there wouldn't be any room for the TCP/IP stack. NetBEUI was very small however.

    loadhigh? I remember having over 600k of free conventional memory even with the packet driver loaded, and the sound drivers and everything. It might have been MS-DOS 6.22 or DR-DOS 7.03, can't remember.

  • (cs)

    I was expecting an actual dog.

    I can't help but wonder if the problem was coincidental, and they'd already ruled out that their state saving function was the cause. ....nah.

Leave a comment on “Serial Port Pit Bull”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article