Slashdot Mirror


Texas Company's Antique Computers Are For Production, Not Display

concealment writes "Sparkler Filters up north in Conroe [Texas] still uses an IBM 402 in conjunction with a Model 129 key punch – with the punch cards and all – to do company accounting work and inventory. The company makes industrial filters for chemical plants and grease traps. Lutricia Wood is the head accountant at Sparkler and the data processing manager. She went to business school over 40 years ago in Houston, and started at Sparkler in 1973. Back then punch cards were still somewhat state of the art." See kottke.org for an eye-popping view of one of the "programs" — imagine debugging that.

28 of 289 comments (clear)

  1. Debugging that... by icebike · · Score: 5, Insightful

    "THAT", (a wired board), is vastly easier to debug than any modern software. In fact a trainee can usually debug it by trial an error in just a few minutes.
    Now get off my digital lawn whipersnapper!

    --
    Sig Battery depleted. Reverting to safe mode.
    1. Re:Debugging that... by Anonymous Coward · · Score: 4, Funny

      It's not old, it's hacker resistant :D

    2. Re:Debugging that... by Dancindan84 · · Score: 4, Funny

      Not if you're hacking with a box cutter.

      --
      "Always forgive your enemies; nothing annoys them so much." - Oscar Wilde
    3. Re:Debugging that... by greyparrot · · Score: 5, Interesting

      I was the only girl in my high school physics class. At some point we had to make 1-tube radios (6J5). This was a way long time ago! Anyway, I was very nervous about cutting my wires too short so I had quite a bit of wire on there. I had an extra "tickler" coil which was patched with nail polish where I had to splice two wires together. The tuning knob was stuck through a piece of a refrigerator dish.
      The day of the trial came. The teacher came in with a big battery and a pair of earphones. First they tested all the techie boys. They had nicely arranged boards. Many of them had actually done some electronics work at home. Some of their kit worked; some didn't. There were only about 7 of them. They drifted out of the room.
      The teacher hooked me up -- and mine actually worked! A surprise to all of us. I had never soldered anything before, and had biked around town assembling the collection of parts that I had looked up in a book somewhere.
      The point of this is that those of us with no engineering background whatever can be relied on to do something weird when first confronted with it. Not that those young women were really qualified; that is another issue. But big loops of wire? I can relate to that!

  2. The manager's moto by Dancindan84 · · Score: 5, Insightful

    "If it ain't broke, don't replace it. Even if replacing it would lead to a 3 fold increase in employee productivity."

    --
    "Always forgive your enemies; nothing annoys them so much." - Oscar Wilde
    1. Re:The manager's moto by plover · · Score: 4, Interesting

      That's because the new system is frequently implemented in the latest version of a one-size-fits-all, Three-Letter-Acronym, popular technology of the day. And that's because the implementers are obsessed with flexing their technological prowess, instead of solving the business problem. I know a guy who would start by insisting this company should replace this thing with a Grails / Hadoop based solution. Why? Because he's a Grails and Hadoop fanboy, not because they have anything to do with this business' needs. When all you have is a hammer, every problem looks like Michaelangelo's Pieta.

      The bigger question is if this could be replaced with a "faster" system. It probably could, but you have to consider the entire manufacturing and accounting processes it handles. Do they punch the cards and include them with the job? Do workers write notes on the punch cards before returning them? How would all those activities be replaced? There are tons of further things to consider, like a shop floor is a notoriously dirty environment. Labels might be tough because adhesives won't stick due to oil on the work products. A beeping scanner might not work if the employees wear hearing protection. And no matter what, if you have to retrain your employees to do a process differently, there will be a temporary slowdown due to the learning curve.

      On the plus side, if you are honestly looking at your business process with an eye to changing the automation, you can probably find places where the new automation would help you to eliminate waste. Do the shop guys measure things with a dial caliper and write them down? Plug in a data collecting caliper and skip the pencils. Do the guys have to move a job sheet from bin to bin as they do their work? RFID tags on the bins could eliminate the handling of the job sheet. Can a new scheduling program help you find the more profitable jobs, or the faster paying customers, and move them to the front of the queue when cashflow is tight?

      There's likely a lot of things they could improve with automation, but any of them would involve a lot of change, and many people are uncomfortable with that much change.

      --
      John
  3. Re:If it ain't broke... by 0racle · · Score: 5, Insightful

    The problem with that can end up being "when it is broke, how are you going to fix it?"

    --
    "I use a Mac because I'm just better than you are."
  4. I still use punch cards ... by perpenso · · Score: 4, Funny

    While in college there was still a working punch card machine on campus. Our intro to computer science professor made us write our first program using punch cards. He said we would get two things out of it. We would understand why some things are the way they are with respect to programming languages and command lines. And we would have book marks for life (the program was short but we had to buy a deck of blanks at the bookstore). I still use these cards for bookmarks.

  5. It's not broken, so let's break it (SAP). by Maxo-Texas · · Score: 4, Interesting

    Company where I worked decided there perfectly fine AS/400 systems were not good enough and would save lots of money replacing the 20 year old system with SAP.

    Hilarity ensued.

    (and lots of 70 hour weeks... only 5% implemented with 15 years worth of projected savings already spent).

    --
    She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
  6. Wow by geek · · Score: 4, Funny

    And people bitch about XP users hanging onto an old and obsolete system.

  7. 026 by Peter+Simpson · · Score: 5, Informative

    That's an 026 keypunch he's leaning on, not a 129.

  8. I've lost track of the software... by satch89450 · · Score: 4, Interesting

    ...that would take documentation of the plugboard wiring of the old 400 series "accounting machines" and produce source that would work exactly the same as the accounting machine, give 80-column card images for the data. It wouldn't emulate any cross-connects to other tab equipment (sorters, punches, interpreters) but it did a wonderful job of moving plug-board programming to the more modern computers (360, in particular). Anyone know where that software might be? As I recall, it was on a micro-spool of magnetic tape originally, purchased at user group meetings. Time to google...nothing so far...

  9. Someone should be fired by frovingslosh · · Score: 4, Insightful

    OK, I get it, Sparkler hates trees. But the insanity of someone protecting their job by never updating technology is just amazing. I would love to see what they have spent on maintenance over the years for that electromechanical junk. And I really wonder where they are getting punch cards. Can you even get them any more, or are they having a printer make custom batches for them? And, of course, there is no really useable backup of all of the company's data for when the inevitable final failure hits. For less than the cost of their next punch card order they could be on a modern system with performance and good data backup. But then I guess that Lutricia Wood might be concerned that others might be able to do thing that only the high priestess of data systems does now. Good thing that she will live forever and never retire, otherwise Sparkler would be in a very bad position.

    --
    I'm an American. I love this country and the freedoms that we used to have.
    1. Re:Someone should be fired by ebno-10db · · Score: 4, Interesting

      I would love to see what they have spent on maintenance over the years for that electromechanical junk.

      I would love to see what they've saved on not having a bunch of programmers wondering why the latest Java update broke everything.

  10. Re:I used to write programs in PL1/PLC on punch ca by Peter+Simpson · · Score: 5, Informative

    Drawing a diagonal line across the top of the deck is faster and lets you insert cards without having to resequence.,..

  11. So i wonder how this was discovered? by nimbius · · Score: 4, Funny

    accounting intern:"damn, looks like the microwave is getting repaired. wanna go out for bbq?"
    accounting director:"we dont have a microwave. you mean the accounting computer down the hall??"
    BOFH:"so heres the dead man that just pushed a hot pocket into the 402 and took down payroll! let me get the punch cards kid, you're in for a fun night."

    --
    Good people go to bed earlier.
    1. Re:So i wonder how this was discovered? by greyparrot · · Score: 5, Funny

      I found one (or two) of these once as part of a study. The old M-- H-- bank was going to replace some important system, and I was on the illustrious crew of analysts documenting all its interfaces. One of them was a deck of cards that was output at the end of the run. So very early one morning I followed it from the output room to the mail room, and then the wagon to an office, where the cards were placed on the desk of the person who ran that machine. She and her young assistant ran them through the machine, which duplicated them and added some columns, probably totals of some kind. Then they took the new deck and loaded it into another of the same sort of machine, programmed differently. It read the cards and printed a report. Then she put a rubber band around the report and cards, and it went back on the mail cart. I followed it down the hall and to another floor, where it arrived on someone's desk.
      And...
      He picked it up and threw it into the trash.
      When I wrote it up, nobody wanted to believe me.

    2. Re:So i wonder how this was discovered? by rgbscan · · Score: 5, Funny

      It's funny how those things persist. Years ago, I took over a mainframe data processing department. Every month I would be sent a fan-fold report on that old school tractor fed paper that took up a whole copy paper box. It literally was a 50 pound report. I had no idea what it was for, nor did anyone else. It went straight into the shredder. Every month a new bundle would show up. I sent it straight to the shredder. Didn't even look at it. The box came interoffice mail with no return address and there wasn't any identifying information on the report for me to figure out where it came from or how to get it shut off. Not even a report identifier I could look for in the mainframe. I can't imagine how much time, paper, and impact printer ribbon went into it. I mean, how would you even look for anything on that report? Kept coming every month for the whole 4 years I managed that department. I hear it finally and mysteriously, stopped showing up a year or two ago. The new manager has no explanation for it's demise but it was a good thing. /Shrug

  12. Re:If it ain't broke... by gstoddart · · Score: 4, Insightful

    The problem with that can end up being "when it is broke, how are you going to fix it?"

    I mostly agree with you, but I've also been on a couple of projects trying to replace 30+ year old custom-built mainframe applications.

    I've seen a couple where people try to replace it with more modern software, but nothing which isn't built from scratch can even come close. It usually lacks 30-40 years of tweaks and fixes to do everything they need, often completely changes the workflow, and opens up vast amounts of data transformation you need to do to pull in all of the legacy data into the new system.

    I've seen several of these projects fail after a significant amount of time and money was sunk into it as people realized it wasn't possible to build something which did all of the same things.

    Sometimes, no matter how hard you try, it can be an exceedingly expensive thing to replace old systems like that. So much so that it isn't feasible for companies to really undertake it.

    However, that just pushes out the problem, and sooner or later, you end up with a defunct system and no replacement.

    --
    Lost at C:>. Found at C.
  13. Re:If it ain't broke... by greyparrot · · Score: 4, Informative

    Yes, the hard part is finding out what the old system actually did, and how much of it was necessary and/or correct. Every miserable data transformation, data structure, business rule, magic number, compiler kludge, and dead end has to be discovered. It is not just a matter of translating the COBOL source either, supposing it is available. The job control and run books have to be examined, and every damn tape or tape emulation has to be dumped.

    Nothing good happens without analysis and specifications up front.

    Frequently the consulting company analysts are more interested in the user interface, where very little happens! But that is the sexy part, of course.

  14. Not a Computer, its a tabulator by GrumpyOldPgmr · · Score: 4, Interesting

    IBM 402, 403 and 407's were tabulators not computers. As an old IBM program support rep., the first time I ran in to an RPG program it made no sense to me till I realized that RPG is nothing more than an emulation of a tabulator control panel.

  15. Re:I used to write programs in PL1/PLC on punch ca by Anonymous Coward · · Score: 4, Funny

    Thanks. That would have been real helpful 40 YEARS AGO!

  16. Re:If it ain't broke... by gstoddart · · Score: 4, Insightful

    Nothing good happens without analysis and specifications up front.

    And, with legacy systems, the problem is you can do a huge amount of analysis and specifications -- and still end up having no idea how the system works for all of those corner cases nobody ever mentioned and which can't be shoe horned into what you've now got.

    On one of the projects I was on, at the beginning we did the analysis, and asked them a bunch of questions on how it worked and what the constraints were. We got told thinks like "This can never happen, this is always true, this is always structured like that".

    So you build a system which takes the concrete assumptions they've given you, and then get farther into the process when it suddenly becomes "well, sometimes they can look like this but not always, sometimes that isn't true either, and in a few cases it's entirely different from everything else".

    Then you can quickly discover what you've spent a year building can't possibly work, because in some cases, 1+1 really does equal sqrt(67.89), and you can't make that fit anything you've built since there wasn't supposed to be any real numbers (or whatever metaphor works for you).

    Frequently the consulting company analysts are more interested in the user interface, where very little happens! But that is the sexy part, of course.

    Often because what the company wants is to start with is screen mock-ups because they're focused on the new UI, and it's not until you get deep into the ugly bits that you realize half of what they told you about the actual process is blatantly wrong.

    Sadly, the complexity of system that old can be beyond anything that can be conveyed, or even fully known by the people who own it. And the more specialized the software domain, the more you're likely to find all sorts of things like that.

    --
    Lost at C:>. Found at C.
  17. One of the biggest problems with IT is by Stone316 · · Score: 4, Insightful

    change for the sake of change. Let me say up front that i've worked in IT for over 15 years. Mostly as a DBA but I did network admin, hardware, development and OS.

    I keep hearing how the next version will do X, save Y amount of time and Z money. Won't require as many people to maintain it, etc. Yet it never seems to be the case. Vendors keep us on a continuous upgrade cycle because bug fixes aren't back ported or to get the latest security patches, etc. Managers, architects seem to focus more on resume building than a stable environment.

    I can't get any commitment for maintaining production but if i'm an hour late on a project task i'll have an army standing in my cubicle harassing me. I constantly hear developers wanting to go back to the basics because the new piece of software that's supposed to make their life easier isn't as stable.

    Yes, I love to play with the latest and greatest features but i'm not sure if from the companies perspective if its always worth the money. I have to say working in IT support can be a very frustrating and stressful job.

    --
    "Thanks to the remote control I have the attention span of a gerbil."
  18. Re:One vacuum tube away from disaster by Stone316 · · Score: 4, Insightful

    A week or two??? How many enterprise systems have you installed? I've been on a couple of these implementations and it just takes a team of people many months of work. The larger the company the longer it takes. One install, for a customer with less than 300 employees took 8 months. Its not as simple as you make it out to be.

    --
    "Thanks to the remote control I have the attention span of a gerbil."
  19. Tabulating machine operations by Animats · · Score: 4, Informative

    I used all that gear in high school and high school summer jobs. I've wired panels for an IBM 402, an IBM 407 (the last of the electromechanical accounting machines and the best one), a 514/519 reproducer (a 519 has a mark sense reader option), and the 77 and 84 collators. And, of course, card sorters and punches. I was able to draw graphs with a 402 and generate poetry with an 84 collator. This is pushing the limits of those machines.

    The normal processing cycle for a sales/billing operation looks like this:

    • Transactions are punched on cards by a keypunch operator in a fixed format, with customer number, item number, quantity, and price each. Date is automatically punched, copied from the previous card.
    • Payments are also punched on cards in a similar way.
    • There's another deck of cards with three lines of address info on 3 cards, kept by customer number and address line number.
    • Finally, there's a deck of cards with the previous month's balance for each customer.
    • End of month processing begins by running the transaction cards through a 602A Calculating Punch, which can multiply. It multiplies quantity by price each and punches that info into the same card.
    • All the transaction cards are then sorted by customer number and date.
    • The decks are merged together with a collator, which has two input hoppers and four output hoppers. This matches numbers and checks sequence between cards. The assembled deck has, for each customer, three address cards, a previous-balance card, and all the transaction cards, payments first. Each block of cards for one customer thus contains the data for one invoice. The collator kicks out anything that doesn't match and stops if a deck is out of sequence.
    • The merged deck then goes to the tabulator, which is filled with preprinted invoice forms, usually multi-part carbons. The tabulator can add, subtract, and print, but not multiply. The invoices are printed. For this operation, a reproducer (a big card punch used to copy card decks) is cabled up to the tabulator with a cable about 2 inches in diameter. At the end of each invoice, the reproducer is triggered to punch a new previous-balance card for that customer, which will be used in the next billing cycle.
    • After a successful tabulator run, the merged deck is sorted in one pass to separate the name and address cards, which will be used again next month. The transaction cards go into storage as backup. The previous-balance deck is stored for use next month.
    • The fan-fold invoices go through a decollator to pull the carbons apart, and a burster to separate the pages for the copy that gets mailed. Then there's folding, inserting into envelopes, a pass through a postage meter, and mailing.
    • Other reports can be produced from the same cards. The previous-balance deck and the address deck are used to produce reports such as who owes how much, and which customers are buying the most.

    The card operations aren't that bad. All this stuff is slow, but automatic. The data entry is the labor-intensive part of the operation.

  20. Re:If it ain't broke... by bws111 · · Score: 4, Informative

    The question which everyone is ignoring is 'why are they still using this'? The speculation is that they are lazy, cheap, protecting jobs, stupid, etc. However, there is a video of the company on YouTube, and if you watch it you can see why they are still using this machine. The whole place is run by punch cards. They use punch cards for inventory control, job time counting, and controlling some of the industrial machinery. This machine is just used to run reports of inventory, etc.

    Could this all be replaced? Of course. Is it as simple as a spreadsheet? Not even close.

    Note that it is not at all uncommon to be in this situation. Industrial equipment lasts far longer than IT. For some reason, companies seem reluctant to spend a few million dollars replacing perfectly functional equipment just because the IT aspects of it are outdated.

  21. Re:If it ain't broke... by greyparrot · · Score: 4, Informative

    And that is why
    "Between 60 and 80 per cent of all business transactions performed worldwide are processed—very effectively and efficiently—by COBOL programs running on mainframes. Within the financial industry (banks and insurance), COBOL is used extensively to process the vast majority of their transactions."
    https://scs.senecac.on.ca/~timothy.mckenna/offline/COBOL_not_dead_yet.htm

    I stopped writing COBOL in about 1985, but we were smart people, and our code was pretty good. It has lived all this time. Most of the new wave crap I have been involved in since has drifted off somewhere. It was relatively easy to create, but the technologies changed so fast that most of it was ephemeral. I bet some of my CICS is still running!