The following was taken off the comp.software.year-2000 ng. I find it interesting because I know that a lot of archaic PDP systems are still being used. I did some work for a steel company involving xray spectroscopy in the early 80's on a very similiar machine. I took off the identity of the originator (although it was publicly posted on the ng) to preserve privacy. Imagine the following story repeated 10k times in America because it will be! RDH

=================================================

I am an analytical chemist specializing in inductively coupled plasma atomic emission spectroscopy (ICP-AES). ICP-AES is a method used to determine trace amounts of metals in solutions in the part per million and part per billion range.

I am responsible for two spectrometers each of which cost approximately $130,000. Both instruments contain embedded microprocessor systems that are in turn controlled by external computers.

The first uses a PDP-11/53 for the external computer. It is running the instrument control software under RT-11 and TSX-Plus. No hardware real time clock exists in the system. This version of RT-11 only accepts 1979 to 1999 as valid years for the system clock. There is no 2000 or 00. If left powered up, the system clock rolls over from 99 to 100. The file system is not designed to handle dates outside of the 79 to 99 range. A compliant version of RT-11 has just become available, but the manufacturer of the instrument says this won't help with problems in the instrument control software. We have been told that the software will "crash and burn" when hit with year 2000.

The instrument was manufactured in 1988 and the software is no longer supported by the company. In fact, the company no longer employs anyone who worked on the Fortran source. The company's solution is to replace the PDP-11 with a PC and purchase a $6000 software package that runs under Windows. If we did this, we would no longer be able to use the quality control and data transfer programs we have written for the current system. We would also have several weeks of down time while entering our current analytical methods into the new system. My experience with a beta version of the PC software leads me to believe productivity would suffer in the end.

The second instrument was controlled with a DEC 466 (486-66) running instrument control software under SCO-UNIX System V/386 Release 3.2. This system became very confused after the real time clock (RTC) was set to 12/31/99.

Allowing the clock to roll over with the power off gave a RTC date of 1900. On boot up, Unix said the system year was 2000. However, the instrument software reported the current date as 01/01/10 and the RTC was reset to 1970.

With the RTC set to 2000, the instrument software still reported the date as 01/01/10, but now the RTC was reset to 2070. On the next boot up, Unix would report the system date as 1970. At any time, typing in 000101 in the yymmdd field on boot up resulted in the RTC being reset to 1970. SCO has a patch for the operating system, but again this would not solve problems in the instrument control software.

In this case, we have replaced the 486 with a Y2k compliant Pentium 300 and installed instrument control software that runs under Windows 95. The manufacturer no longer supports the software that ran under Unix. The instrument is two years old.

Inside the instrument are two embedded 68000 microprocessor systems with real time clocks. Access to the clocks requires a program normally supplied only to service technicians. Execution of that program requires a password. The real time clocks can run without external power for up to ten years on internal lithium batteries.

One function of the clocks is to insure the proper start-up sequence is followed after shutdowns of different lengths (hot or cold start). Extensive damage could be caused by an error in the control of heating, cooling, or gas flow systems. The clocks are also used in the monitoring of safety interlocks and sensors. Both clocks rollover from 1999 to 1900 and can not be set to 2000. The clocks also count off the days of the week. I am reluctant to extensively test the system myself because of the possibility of damage.

When I first talked to technical support about my concerns, the technician pulled out a copy of the year 2000 compliance certificate for the new software and read it over. He then stated: "This certification only covers the software - not the *instrument*." This instrument and software is being sold as the company's year 2000 solution to replace almost all earlier systems.

My next contact was with a different technician who was in the lab to repair an electronic problem in the instrument. He told me: "Don't worry, we use four digit dates." I asked him to demonstrate setting the clocks ahead. He ran the program on the main computer and it allowed him to type the year 2000 on the entry screen. He then executed the command to send the date to the embedded system. There were no error messages. He gave me a look that implied "I told you so". I then asked him to read back the current time from the clock he just set. He was visibly startled when he saw 1900 appear on the screen. He said he would have one of their experts call me.

A few days later I heard from the "expert" who tried to reassure me with phrases like "they're just timers" and "the instrument doesn't _need_ to know what day it is". However, since he didn't seem to have a mastery of what the clocks actually do, I wasn't reassured. For example: I can put the instrument into standby (sleep mode) over the weekend with instructions to be ready to operate at 8:00 AM Monday. This will conserve gases (nitrogen and argon) and reduce power needs. 73 minutes before the assigned ready time, the embedded systems will query the main computer for start-up instructions. If the main system is running, it takes control of the sequence. If the main system is off, the embedded systems will look for it for 10 minutes and then independently begin the start-up sequence in the instrument EPROM. The "expert" didn't seem to have even this depth of knowledge of the system.

Nearly a month after I sent email to two different year 2000 addresses at the company, I received a phone call from the company. The caller described herself as a liaison with technical support and admitted to having no technical knowledge of the instrument. She said that their legal department would only allow verbal communication in this matter. She was prohibited from replying by email or written communication.

She said the embedded systems "could be a problem" if new firmware wasn't installed. When questioned, she admitted that new firmware was not available and she did not know when it would be.

She also said that the clocks were used for the "wake up" procedure and not used for anything else. Since she had no knowledge of the instrument, there was no point in asking about system error (SYSERROR) message 75 described in the appendix of the manual:

75 Real-Time Clock. Call Service.

The real-time clock, used to monitor the status of interlocks (and sensors), is not functioning. This will not shut down the system; however, a XXXXXXXX service engineer should be contacted.

"This will not shut down the system" means I can start up a sustained 10,000 degree plasma in a confined space with uncertainty as to whether the interlocks and sensors will detect a malfunction.

It's my belief that in thinking about embedded systems, this company has been in "sleep mode". I may have been the first to sound a "wake up" alarm about this instrument. Now they have to muster the people and resources to re-write the programs stored in the EPROM's, produce new chips, and install them in hundreds of instruments around the world. I should also mention that this is only one instrument in a large product line that has other Y2k problems. Will they get them all done? On time? I don't think they know.

=======================

Humor? The other day I was shopping in a surplus store and the background music played a Doris Day song with "Call me a Pollyanna!" as part of the refrain.

Disclaimer: The University pays large salaries to people that make official statements. I'm not one of them.

-- R. D..Herring (drherr@erols.com), September 22, 1998

Answers

Out of interest, why does a spectrometer need to know what date it is? It may be a convenience to have the date automatically entered on your data, but surely no more than that.

So why not just set the date back ten years (and correct it every March 1st thereafter for leap years), and tell everyone that for 1988 read 1998. In ten years time repeat.

(If your system could accept 1972 or before as a date, set the clock back 28 years and you don't have to worry about day names or leap years either, for the next 28 years).

This solution works well for systems that don't process or store date data and which are not electronically interconnected to other computer systems. It's not a silver bullet, but it's a quick and cheap and largely non-technical solution for many pieces of equipment. I suspect those described above fall into this category, as (probably) do many production-line systems and medical systems.

It's also something to bear in mind for a post-2000 crisis when upper management are desperate for anything, ANYTHING, that'll get production going again. If there are "upstream" connections of a read- only nature, the date-setback solution may well work at the expense of destroying "beancounter" systems to which lower-management types are so attached (probably because without those systems, they'd be hard-pressed to say what they do for a living!)

-- Nigel Arnot (nra@maxwell.ph.kcl.ac.uk), September 23, 1998.

Oh s**t. Even if they have a Y2K department technical users are getting gibberish and "no written" confirmation.

Folks, it be worse that we think.......

-- Robert A. Cook, P.E. (Kennesaw, GA) (cook.r@csaatl.com), September 23, 1998.

Knowing when and in what order you analyze a sample (be it steel, soil or whatever) is often vital. Lets see... that seamless steel pipe we made last August seems tbe giving the oil drilling people fits, now Dr. X exactly what was the composition of that lot? same example for drugs, etc. You can't just put in any arbitrary date just to get the instrument to run. Further, scientific data is often used for trending which is quality X versus timescale Y.

-- R. D..Herring (drherr@erols.com), September 23, 1998.

Nigel,

Does the date matter to the spectograph? No, but it matters elsewhere.

"I am an analytical chemist specializing in inductively coupled plasma atomic emission spectroscopy (ICP-AES). ICP-AES is a method used to determine trace amounts of metals in solutions in the part per million and part per billion range."

Such testing is highly fraught with regulatory and legal restrictions. The results of these tests --- for example, the lead content of a dust wipe sample --- may impact $million court cases or be used to determine worker or occupant safety. The chain used must be totally verifiable, from the individual who took the field sample, through the lab, and the reporting of the results back to the individual or person requesting the data. If the lab results contain the wrong (or altered) dates, the test is invalid from a legal standpoint.

If the test is invalid, why perform it?

Obviously, it won't be performed......by that company. The company goes out of business because it's unable to use these expensive instruments.

-- rocky knolls (rknolls@hotmail.com), September 24, 1998.