25+ Years of SampleManager, 30 Years of You and Me


I ran across a tribute to SampleManager talking about “25 Years in SampleManager” giving a little history. Has it been that long, I wondered? Well, no, it’s actually been longer.

As I was reminiscing and looking at some of the old screens, I realized I’d personally been using SampleManager longer than 25 years, myself, and remembered it being around probably 30 years ago. Even in the release of SampleManager 10.0 in 2011, Thermo Fisher Scientific mentions that it brings more than 25 years of history with it.

Is this good or bad? Neither. Every product has its good and bad. SampleManager certainly looks nothing like it did “back in the day” and the actual executable has been rewritten. With that, the basic features have remained the same but there are a variety of changes around them. That is about par with the other big systems that remain. It has changed over the years but any of the products that have survived this long have done so – it’s part of the survival of any product.

In any case, I’ve now been working with LIMS and a wide variety of them for 30 years. I’m pretty sure SampleManager can beat that number.

Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/


8 responses on “25+ Years of SampleManager, 30 Years of You and Me

  1. We have the source code of the first version of SampleManager here in the office – dated 9th May 1985. SampleManager is 32 years old this year 🙂

  2. You’ve got me wondering when Hewlett-Packard’s LAS and LABSAM packages came out now! They’re definitely not still about, Y2K did for them both (LAS was tweaked to give it one final year of life) but being tied to a 16-bit machine (the HP-1000. running RTE-A or its precursors) was always a death sentence.

    We were writing custom add-ons in FORTRAN back in 1986 on version 2.0 (AFAIR) and were having to dig down into the internals of the linker to get the programs to fit within the system limitations, even overlaid to hell and back as they were. Happy days – six programmers at the project’s peak and our HP-1000 had a grand total of 300 MB of disk space for everything! 🙂

  3. That is one cute video!

    As for Y2K, and this is where you can see me puff out my chest to turn into an incredible snob about this, but one of the advantages of SampleManager was that those of us programming on the DEC/VAX platforms were used to having the luxury of having plenty of space to have four byte integers and dates with a four-digit year. We didn’t have to economize on space the way previous platforms did.

    That’s in contrast to the Beckman LIMS, which had a terrible nightmare Y2K upgrade, from what I hear. Even though we might now think of it as running on DEC/VAX, it began on the HP platform and I no longer remember its OS. But that’s why it had that unique command line: AB:CD:EF
    where “E” and “F” were optional password characters, dependent on the command being performend.

    Strangely, a discussion just yesterday popped-up around a platform where people have restarted using two-digit years, figuring that we’re too far from the next century to care. We all just shook our heads and looked sad.

  4. I never saw Beckman LIMS, but it was regarded as LAS and LABSAM’s direct competitor in the mid-1980s, so I suspect it probably started out life on the HP-1000. If there was any attempt made to port LAS and LABSAM I didn’t hear of it, but I’m still in touch with a former colleague who would have known about it – I will ask, just out of curiosity. As someone who moved from a DEC environment to HP-1000, believe me, there were frustrations to spare for someone who knew enough to be able to compare VAX FORTRAN with the HP-1000 version!

    • The initial conversion from HP-1000 to DEC/VAX was barking slow. Naturally, DEC/VAX users insisted on being able to use their usual 4-byte integers so the programmers took two I*2 integers and glued them together every time you needed an integer. Similar for the strings PLUS the program had to reverse the order of the characters every time they were displayed them then back again when they were saved. You can just imagine how awful performance was.

      Plus, the system had other problems even without that. We found a stack overflow in the system where the final calculation (I don’t remember what it was for) wasn’t a terribly large number but it was something like x*y/z. We owned a source code license where I worked and this is all I did to fix it: x*(y/z)
      Then, I reported it but I don’t think they acted on it. That wasn’t the only bug I fixed for my employer that the vendor ignored.

      Now that I’m have “fond” memories of that system, the instrument integration was even worse. Not only was it even slower than the LIMS, itself, but it was single-threaded – you could only run one instrument parser at a time. With hundreds of numbers probably coming back from just a handful of the elemental analyses, that would hog the entire thread so that no other analyses could run. We tried to do the elemental analyses at night but then had to be careful about running up against our system administration tasks. With that system, you had to run a type of check program every night on it, or something like that. Plus, the usual backup window, too. So, we had limited time to run it. It was possible to have some great programs running but the fact was that they were so slow that we took almost all the “smarts” out of them because we just, even then and just with elemental analysis, had too much data coming through to have the programs doing anything more than the simplest tasks.

  5. Fantastic piece, Gloria. VGL is still working, reporting tools of infomaker are still operable in new releases, and these things increase popularity of Sample Manager, that developers of C# and DevExpress could redesign their custom forms gradually.

Leave a Reply

Your email address will not be published. Required fields are marked *