10 responses to “Blast from the Past”

  1. Em

    We have machines still operating in the field that are >40 years old (older than almost all of our engineers), and aftermarket upgrades to machines of all ages accounts for about 20% of our business. We’ve used a combination of methods for data archiving. The oldest systems (from hand-drafted drawings) are on microfilm (we do have two magnifying reader stations for them), and when we do an upgrade on a film-only system we send the film out for scanning to PDF (it would be nice if we filtered out the drawings labelled “NFG” when doing the scanning though…). The associated paperwork (product charts and other archival context, which I need to access on a daily basis) are on paper in file folders.

    For middle-aged systems, we have drawings in AutoCAD. We maintain plenty of seats of a compatible program for edits/upgrades for those who need to do so (the entire aftermarket group), and everyone in the company has at least read-only software. Paperwork was in the Lotus suite, and is more or less readable with Office. What’s most time consuming with these jobs is deciphering the filenames – I’m slowly learning the shorthand used, but it was inconsistent at best. These ones usually have lots of context in the paper files as well.

    New systems are currently designed in SolidWorks, with major assembly drawings provided to the customer in AutoCAD-compatible formats. Paperwork is in MS Office, is searchable, and is well organized with descriptive names. We do still archive paper copies in the file room, but it’s much more selective than the middle-aged files.

    I think in the long-term (say, 20 years), models may not always be accessible, but the 2D prints we use for the shop will always be carried forward in some format.

    More of a problem is that we’re switching to a new database (including both front and back end), which means that those of us who work on archival systems have to run both (plus use the paper records), since importing the information from the old system would have to be done manually. It also means that data analysis is going to be harder, since I’ll have to import from two different systems and will have to try to kludge it together. I’m hoping that there will be a clean break and the old system will become static (so that I can just update with the new system as needed), but we’ll see…

  2. Sean Roberts

    Hi Sam,

    Really good post here. It brings back many a memory! Have to agree with the paper lifespan, simple yet transferable through time!

  3. gasstationwithoutpumps

    I’ve heard from librarians that optical media (CD-ROM and the like) have a very short archival life (less than 10 years in some cases), as bad as mag tape. This is hell for music librarians.

    I’ve had information lost because of programs not being available for changes in computer architecture in just that past 10-20 years (PageMaker 4 files, anyone?, what about MaxDraw pictures?)

  4. David Bley

    Most of my work has been electronics design. Over the years, we purchased many different systems for schematic capture, PC board layout, mechanical drafting (2D first and then 3D later), Gerber file viewing and editing and text editors and spreadsheets and circuit simulation.

    The schematic capture and PCB design packages never had any compatibility from manufacturer to manufacturer. Some of them could not even be carried to another computer and many times we dreaded seeing updates because it was like learning a brand new system. Any designs that were still in production and needed a change had to be redrawn in the latest system. We had a number of products that were in production for 20-25 years. In the 2D world, there were many packages that could read and write dxf or dwg files (AutoCad). In the 3D world the compatibility went away. We had difficulty extracting a 2D view from a 3D package in dxf that was usable.

    Anything that was text based, I tried to save an ASCII version to be forward and reverse compatible. We actually had some procedures written on a Commodore 64. They had to be retyped or scanned and OCR’ed.

    We had 180K floppy, 360K floppy, 1.2M floppy, 720K floppy, 1.44M floppy, 100M ZIP, 250M ZIP, CDR, DVDR, and FLASH Drives. As each new storage technology came along, I migrated the files we had upwards. The CD’s and DVD’s did not tend to be readable after being stored for a while. I end up washing them withe dtsh soap and warm water to read them. My latest migration is to flash drives and a 1TB USB Hard Drive.

    I don’t seem to have room for the paper.

  5. Stephen

    It doesn’t even really have to be that old. At my previous job, we had a lab instrument that was run by a Windows 95 PC. The communication went through an ISA card, so pretty much any computer made in the previous 12-15 years wouldn’t work. It was the only non-server on the plant that had a UPS – we were worried that if it ever shut off, it wouldn’t restart.

  6. ferd

    Keeping up old data IS a big problem. Not only the output documents (such as schematics, source codes, drawings, etc.) but also compatible software and hardware used to create and access them. I’ve lost schematics that were produced using the old blueprint method – they’ve faded to almost unreadable, despite being carefully stored. I’ve been able to save some old prints by getting them copied via newer black-and-white copier machines, but it is a matter of time before these too may perish. For electronic data, I try to import older copies into the newer software packages, but as David says compatibility is a major problem.

    I still have an old 8” floppy that I used as a prop when I taught electronics at a business school (could hold it up and even people in the back could see it). It was made by Radio Shack, and has “lifetime warranty” printed on it. So sometimes if I feel like causing trouble I take it to a Radio Shack store and ask for a replacement. Most of their clerks have no idea what it is!

  7. ORCAD

    Technology is changing at such a fast rate that keeping up with the latest and the greatest is challenging. Do you think that there will be a future in cross platform programming?

  8. Hung Kieu

    Hello! I would like to repost this on my blog! May I have your permission? I will add a link to the original post and your name! Please get back to me! Thanks!

  9. David L.

    It seems like this blaggregation has kind-of died. Is anyone planning on making any posts in the future?

  10. Patrick Matherne

    I use to work in IT before I became an engineer. One of my jobs was to find old computers capable of running these ancient programs. Mainly because they paid several thousands of dollars and still wanted to use them instead of repaying for them. Also some of the old programs are easier to use. I know the Carrier Block Load version 3 is easier to input the data than the current version

    On another note I bought a book on using a loom and someone had used a punch card as a bookmark