We received the following unsolicited email on 14 May 1999:

To: shimadzu-sux@bigfoot.com
From: identity withheld
Subject: EZChrom software OQ violation

"I remember using EZ-Chrom with the newly presented Shimadzu PDA [photo diode array detector] around 1993 for UDL laboratories [now Mylan Labs] in Florida. I don't remember the actual model numbers [probably SPD-M6A or SPD-M10A] and have lost track with Shimadzu since I haven't purchased any more of their "products." I consider the term product to be quite generous in this case!

EZChrom was designed under Windows 3.1 (sic) to be a "time share" acquisition system. Designing such a system under [Windows] 3.1 tells you how much they understood about their computer platform. During acquisition and conversion of analog data, if a lengthy disk access was being made by another program, EZChrom would miss the signal and a flat line would occur on the chromatogram [and contour plot] during the time of the disk access. I experienced this problem while trying to manually quantitate data [from a previous run] while acquiring [new] data.

Working under strict FDA guidelines, this totally violated the operational qualification [OQ] of the software. Shimadzu denied this problem for 3 months continuously only to claim [that] we were using the system incorrectly. They later said it was a Windows problem! I am curious if the problem has been corrected; especially with the availability of Windows NT and [Windows] 95 versions. Our sales rep was the only person who seemed to care. (He later became a little disturbed; was fired by Shimadzu and somehow managed to set the Shimadzu travel van on fire intentionally - but that's another story!)

I suggest all customers and consumers using any type of data acquisition software to perform their own operational qualifications before you purchase the equipment. Make [the] purchase contingent upon passing your IQ/OQ/PQ specifications; not the manufacturer's. Don't let the manufacturer of the equipment/software do it for you!

To perform the test properly - especially with multiple instruments being configured on a single computer - all instruments should be turned on at the same time and forced to acquire data at their highest [acquisition] rates. Examine the chromatograms/output of each of the instruments for signal drops. If the system can't do this, make sure the manufacturer has told you so before performing the test.

It is a good idea to acquire data on the instrument first with no other background processes or instruments operating. Compare the signals from the multi-operation to the signal of the single instrument operation. Do they look the same? If they don't, you have a problem! Perform the test with a familiar analyte."

Sincerely,

Director of Analytical Services

n.b. To answer the writer's query: "I am curious if the problem has been corrected; especially with the availability of Windows NT and [Windows] 95 versions," one only needs to consider the robust observations that were posted to the sci.chem newsgroup last year and which we highlighted in Shimadzu HPLC Battles & GC-MS Crashes.

n.b. We will state emphatically that there were similar accounts of EZChrom OQ problems (like those disclosed at UDL Laboratories) reported in other labs around the US (and probably around the world) but Shimadzu in-house product managers were perpetually mum. The field personnel at Shimadzu were not even served formal notice of this pervasive chromatography data acquisition problem. What does that tell you?

n.b. It bears repeating that a Director of Analytical Services at a major domestic corporation recounted that "Shimadzu denied this problem for 3 months." And when Shimadzu finally admitted that there was a problem, then they blamed it on Microsoft Windows! How does that grab you? Guess who many times Shimadzu customers were stiffed and told to call Microsoft Corporation instead! (This director has agreed to answer any specific questions regarding his observations if they are forwarded to: shimadzu-sux@bigfoot.com with "EZChrom software OQ violation" in the subject line.)

n.b. Terry L. Adams, who coined the term "Sleazy-Chrom," witnessed nearly identical problems (to those reported at UDL Laboratories in Florida) with a EZChrom/SPD-M6A detector which he sold to A.L. Pharma Labs in Baltimore, MD. How widespread do you think this vexing problem really was? Do you think the problem was ever totally solved? Would you want this "rugged and reliable" rubbish in YOUR lab?

n.b. Shimadzu changed the name of their EZChrom software product to Class VP in 1996. Scientific Software (Pleasanton, CA) writes the source code for Shimadzu's Class VP (aka Class Crap or *Class VD) software and uses the EZChrom Elite name exclusively in it's own marketing campaign of the chromatography software product. (ThermoQuest also uses the data integration source code from EZChrom and then adds their own instrument control code.... the resulting product is privately-labelled as ChromQuest.)

*Class VD is most appropriate since Shimadzu Scientific (Columbia, MD) is right down the road from the veneral disease capital of the US (aka The City That Breeds!)

Questions: What kind of rugged in-depth testing did this combo software (EZChrom)/hardware (PDA) product receive before it was released for sale to the consuming public? Would you be generous enough to call it a product? How many other so-called Shimadzu products (including Class VD) have made their way to market complete with software bugs and/or hardware glitches still intact.... you don't even want to know! Can you say SHIT-MA-ZOO? Why would you trust anyone from Shimadzu to tell you the truth, the whole truth and nothing but the truth?