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.

Re:Debugging that...

[greyparrot]

I never actually programmed one, but when I worked at Siemens in Iselin, NJ we had some of these. For physical inventory, we needed it to print the name of the spare part on the card my program punched out of the Spectra 70. So a bunch of old guys from all over the company found themselves poking around on the board. And they were successful too. The inventory cards were beautiful! To take inventory, the warehouse people wrote the count on the card, we had it punched at the end, and fed back into the Spectra. (We ran COBOL on that, 64 K of memory allowed even the SORT to run.) Good old days!

Is this an old story?

[Animats]

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 [youtube.com] in 2011. (Terrible video, though)

026

[Peter Simpson]

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

Re:I used to write programs in PL1/PLC on punch ca

[Peter Simpson]

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

Re:Someone should be fired

[admdrew]

someone protecting their job by never updating technology is just amazing

That may be part of it, but generally an overhaul of an entire system like that, especially something as integral to a business as accounting, isn't a decision any single person can make. Also, it's possible those who would've had job security by maintaining that system have long since retired. Slow-moving business isn't completely built on nefarious intentions.

Even more on the subject

[OakDragon]

If It Ain't Broke, Don't Fix It: Ancient Computers in Use Today [pcworld.com]

Re:So i wonder how this was discovered?

[MikeTheGreat]

Whoops - this was funny but I accidentally mod'd it as "Overrated"

I can't seem to find a way to undo/change my moderation.

So I guess I'll do this, instead :/

Re:If it ain't broke...

[greyparrot]

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.

Re:If it ain't broke...

[greyparrot]

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!

Tabulating machine operations

[Animats]

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.

Re:If it ain't broke...

[bws111]

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.

Re:If it ain't broke...

[greyparrot]

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 [senecac.on.ca]

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!