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.
"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.
"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
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."
at Florida Technological University (now called UCF). I remember a few instances of seeing people trip or drop stacks or boxes of cards on the floor and then crying when they had try to reorder them to get their program to work.
My working C=64 ain't got nothing on this fine machine.
Yeah, so did I. You were supposed to use the last 6 columns for a number that you could use in sorting the cards. We also used markers so you could line up the cards based on the position of a diagonal stripe on the edge. PL/1 - what a language! I had to write an assembler in PL/1. It was a great way to learn what we used to call "structured programming".
And now long would you have to run it to spend the same amount of money it takes to buy modern equipment and pay for someone to convert your accounting over?
I like "if it ain't broke" in general, but this thing has to be a massive power drain, and when it finally does break, they're likely going to be screwed.
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.
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.
Kind of like mowing the lawn with a pair of scissors. Yeah, I'm sure it could be done.
I thought the Computer History Museum got that IBM 402. There's one in the Computer History Museum now. They may have the machine the company was using for parts.
Here it is running in Conroe, TX in 2011. (Terrible video, though)
And people bitch about XP users hanging onto an old and obsolete system.
That's an 026 keypunch he's leaning on, not a 129.
That's why smart people punched sequence numbers in columns 73-80. It helped if you had access to a card sorter, otherwise you'd incur machine time using the sort program to punch a new deck.
There was a lot of standalone electromechanical hardware (not just punches and sorters) to support punched card data processing - my mother (now 80) worked for a utility company in the 50s and alternated her time between doing data entry (card punch) and data verification - essentially retyping the data on a card verifier with the punched card in place to check the data entry was correct.
Actually, an early version of the IBM FORTRAN compiler (for a real computer) marked the cards according to the statement type on a lexical analysis pass and then sorted the cards by that field so it could load the compiler code that dealt with each particular type of statement in turn (the computer having very little memory). The generated code was then resorted to match the original program card sequence.
...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...
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.
Drawing a diagonal line across the top of the deck is faster and lets you insert cards without having to resequence.,..
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.
seeing people trip or drop stacks or boxes of cards on the floor and then crying
Grab a marker pen and draw some diagonal lines/crosses on the edges of the stack. You can easily see which ones are out of order.
You can also see if anybody has swapped a couple of them around as a "joke".
No sig today...
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.
One critical irreplaceable part breaks, and they can no longer process payroll or inventory.
All because they don't want to hire somebody to spend a week or two to replace the functionality of that obscene waste of energy with a simple spreadsheet. The simple value of data security, not to mention the inter-operability between the data generated and things like, I dunno... check printing and direct deposit, for example, seems obvious.
I'd also guess there would be a lot less work for their accounting department. Either they could save the expense of one or two peoples' salaries, or at least spread the workload savings among the staff. In any event, it simply doesn't make sense not to modernize it.
http://xkcd.com/385/
Trust me on this, wiring skill isn't normally supposed to depend on possession of a pale pink penis. You're totally doing it wrong.
PHB: "I want to fire Wally, but I can't risk it. He says he's the only one who can program the Zeberpupin system." Wally: "The word you're trying to think of is 'indispensable.'"
It BELONGS in a MUSEUM!!!
"When information is power, privacy is freedom" - Jah-Wren Ryel
If It Ain't Broke, Don't Fix It: Ancient Computers in Use Today
Dark Reflection
No offense AC, but there is an element of "stupid" to doing this. How are you going to fix it if it breaks, and more importantly, what will it cost? Also, the same thing could very likely be done with off the shelf commodity hardware and some cheap (or free) accounting software. Accounting productivity would be DRAMATICALLY increased just in the amount of time saved each day. Sounds to me like someone in that company is lacking some serious business sense. Punched cards had their day, but that day is long gone.
This computer only has to be on when it's actually processing/tabulating. It's only getting juice for the 20 or so minutes a day you're processing payroll or the day's invoices. Your office PC never gets turned off.
That's great if you have something they have a plan which it covers.
But I once worked at a place where the mainframe guy had retired, was drawing his pension, and had been hired back as a consultant at 3-4x his previous salary because there wasn't anybody on the planet who could run the old system. Literally, since he'd been the one who maintained it for several decades.
Not all legacy systems are something you can easily move away from, much to the chagrin of the people who own them. I've literally seen systems with 40+ years of history, huge amounts of data, and more than one attempt to replace it costing millions of dollars and then getting scrapped.
Sadly, it's not all that uncommon to realize just how massive of a task it will be to replace these things.
I suspect anybody running museum pieces in production environments have already looked into replacing them, and failed miserably.
Lost at C:>. Found at C.
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.
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.
This company is probably the only one in the area that will still be operational in case of a nuclear war. that type of computing device is pretty much impervious to EMPs.
They are slowly migrating to using PCs according to article. They turned down offers to buy the machine from the Computer History Museum, so they must be using it or else have a lot of nostalgia for it (a perfectly valid reason to keep it).
There's not a lot of details on what exactly they use the machine for. But I suspect they keep it because the current process is working. Punch in numbers, put the cards on file, later gather up groups of cards and run them through the machine to do some simple arithmetic calculation (basically the only thing that machine can do), take the results and use those with a PC accounting package, put cards away until next time.
It's not a big machine if you look at pictures of some of them. My guess is that it really doesn't take more power than those large Xerox style copier/printer/collator/fax machines you see in most corporate offices. Plus they don't run this machine constantly, probably a couple times a week. Unlike a mainframe you can just turn it on when you need it then turn it back off again.
Thanks. That would have been real helpful 40 YEARS AGO!
The key to the whole thing was the rubber banded few cards at the front of the box that ran IEHSORT(?) on the sequence numbers of the rest of the box.
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).
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.
In 1973 a small company could buy a computer to keep books, so well it can still be used today, but just ten years earlier, NASA, with a budget of 6% of the USA's GDP, wasn't able to use computers to help design the F-1 engines?
Amazing what the invention of the microchip brought about, isn't it?
When our name is on the back of your car, we're behind you all the way!
Yes, users always lie. It's not their fault. I used to find little scraps of paper up on walls (if I was lucky), with some corner case that everybody knew about, or nobody knew about but the one user. Of course by now these users have long since departed the planet, so lots of luck... You captured it very well!
I had a very annoying related bug in a mainframe program once that took me forever to get to the bottom of, where a text parser I had written was getting the weirdest errors. Eventually I discovered that somewhere in between the input text file on disk and my program was a virtual card punch and virtual card reader - each line of text went through as a virtual punch card for legacy reasons - and the virtual card punch was being ever-so-helpful and automatically punching sequence numbers in 73-80!
Socialism: a lie told by totalitarians and believed by fools.
and then crying when they had try to reorder them to get their program to work
That was the tears, later came the laughter when CA's mainframe Librarian product would state:
"-END CARD MISSING - MAKE SURE DECK WAS NOT DROPPED"
Even though it was reading from disk or tape...
(This was about 20 years ago, As far as I know it still does this to this day)
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."
It's not even always a lie, which is the most frustrating part of replacing legacy applications.
People often simply don't know, or don't have a complete picture of all of the dark and scary corners that are in there, or don't realize that things even are dark and scary corners. Several decades worth of tweaks and adjustments makes for an almost intractable problem in some cases.
Since those projects, every time I've been near anything which says "we're going to replace this legacy application", I try to back away slowly and not get involved in it.
It will probably hurt, it will likely cost a lot more than you expected, and there's a huge chance you'll go through the whole process for a long time and still have the project fall apart as you discover new things that can't be reconciled.
I was on one project, and this was the 3rd time they'd tried to replace a system started in the 60's and continuously maintained and updated.
After 4 years and enough money to keep me on an island under a palm tree for the rest of my life, eventually this one failed too. I strongly suspect they still use it to this day, because I can't imagine it's something which is ever going to get any easier to fix.
Lost at C:>. Found at C.
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:
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.
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.
I'm imagining a Smartphone app that can pictures of punchcards, then execute them.
(In case I'm actually the first person to think of this, I hereby grant any patent interest to the public domain.)
True. But you have to admit, much COBOL was stored on and run from 80-column or maybe IBM 96-column) cards. Boxes and boxes of them, given the amazingly low code density (i.e., verbosity) of the language.
I would venture here and now in the 21st Century COBOL is safely away from punched cards. However, my Air Force computer programming curriculum 30 years ago was 4 weeks (out of a 6-week class) of COBOL punched onto cards and run in batch mode. Rubber bands and the designated runner of the day to take the decks across the base (6 blocks) to the system room to be compiled and run.
You absolutely DID NOT use the compiler to check your syntax when your code-compile-checkout cycle was measured in hours and you had two days to complete a project. Fanatical desk checking was the rule of the day. And since the instructors were competitive assholes and introduced an under-the-table prize for the first in the class to complete the project, so was sabotage of everyone else's decks. The runner of the day was a hell of a job... wonderful opportunities for bribery and also threats.
Now get off my runway!
Welcome to the Panopticon. Used to be a prison, now it's your home.
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!
But what if you lose that employee due to circumstances that are outside of your control? Now you have to find someone who knows how to operate an antique computer. Not only is it hard to find such a person, but they might cost an absurd amount of money as well.
I have to admit, that actually *is* sorta cool. Imagine, you can probably repair a bit on that computer with a well-bent paperclip. When everything goes down the drain, this thing will still be up and running, maintainable and you will be able to build your own spare parts for it using a regular toolbox and a soldering iron.
Then again, my very first computer, a PC 1402 Sharp Pocket Computer from 1986 with cashstrip printer is probably like a bazillion times faster and more powerfull than that thing. It would probalby take less than two weeks to replace the entire workflow with a single cheap-ass current programmable calculator and you could add some features along the way. That makes it quite strange too. Cool, but very strange.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
It doesn't even have to be as large as a mainframe application.
For my senior thesis for my Bachelor's degree, I took on the task of taking on an old DOS flat file "database" system and creating a modern equivalent. I did the same as a sibling post, asking how they use it, what could be what, etc., and then I started to make the program. As I did so, I started looking at the data it held for myself--the format (which I forget at the moment, but I think it was something from IBM) could designate "columns" with data types, and then completely disregard those data types. So you would have a field like "weight", and then the data could be "X1444RTTJU8" because when they had a an entry related to a problem, they would use that field for notes. And the program had no problem with this, even searched on that.
I only had a short time to work on this, and I got in way over my head. In the end, I had to leave the company before I could complete the project. No one there was disappointed, though, as the only reason they seemed interested in replacing it was due to a corporate mandate about replacing technology no longer supported after X years, and I made the fifth or sixth person to attempt and fail (all of us being interns or otherwise low-level devs) on this very task.
What I took away from the whole project (and what I wrote as the final portion of my thesis) was that I approached it from a completely wrong angle: I was trying to copy the program, when instead I should have been focusing on the task and goals and working from there.[1] Not that you can't miss edge cases in this scenario, but you will be better able to handle them because you won't be trying as stringently to maintain an outdated input system.
[1] Although I likely wouldn't have gotten too far with this, either, as those who actually used it seemed unwilling to help me; they were all folks that seemed very set in their ways, resistant to any change, and I got the feeling that they saw a replacement as a threat to their jobs. In addition, all of them were trained to use a set of instructions that was "Press X, now press T", etc., and not actually describing what they were doing, but just how to do it. If the program suddenly disappeared, I suspect they would have no idea how to do half their jobs.