Need a book? Engineering books recommendations...

Return to index: [Subject] [Thread] [Date] [Author]

RE: Year 2000 computer problem

[Subject Prev][Subject Next][Thread Prev][Thread Next]
Before I start, I want to say this is not directed specifially to the email it is replied to, or to any specific email on this subject. It is rather a general reply to all concerned as I sense that there are those who have formed exact conclusions on a subject they may only have partial knowledge.

I would kindly suggest that a lot of what I have read today indicates a much too focused understanding of the overall Y2K problem. From what I have been reading it would seem to suggest that this is just a simple problem, blown out of proportion by companies/people/programmers/etc. trying to make money. I will add, in part I believe this is somewhat true in a few cases, but very wrong in others.

However, I am concerned with the above, since we as professional engineers often have guiding influence over the companies/clients we work for and advise. If you are just thinking that looking into the source code and making a few fixes, etc., is all there is, and then casually convince your company this is all there is to it, and you just happen to be wrong, please realize what harm you may have done.

Now that has been said, here are just a few examples of what you may be missing:

Just on Process Control Software , as an example:

1.) Process Control Software is receiving lots of information from "embedded" systems. These control equipment that are monitoring equipment temperatures, pressures, flow rates, etc. and their "embedded" (from their integral computer) software itself is kicking out this information typically as files which contain this information as well as dates. And, yes, the dates have often the year, month, and day included on the file records. Why? The answer is that in order to compute the difference in time between two or more such records, the year is involved when passing from one year to the other and when leap years occur, February has a different number of days. Certain smelting processes are producing millions of dollars of material that could be very very costly to recover if the embedded systems were not dealt with. Now an interesting point. We are now finding that a lot of the companies that made the control equipment hired out developing the software and the source code has somehow been lost (see 2 below), or that the company is out of business. Then, it is not so easy to look at source code, is it?

2.) Along with the above, a lot of Process Control S/W relies heavily on database files that reside on the systems with historical data. Failure to fix these databases, or consider them, could lead to the same disaster above. Do you know just how complicated some of these databases are? You don't casually go and change dates from INTEGER*2 to INTEGER*4 of from CHARACTER*8 to something else. (Even if you are able to locate them). Often they are equivalenced in data structures. Here, this might not have been so complicated, but after many companies have re-engineered, re-structured, and globalized (nice words for firing their engineers and technical people amongst others), often no one is around who knows even what these databases are. I have seen programmers, who destroyed files and documentation when they were laid off.

Fortunately, or un-fortunately, most civil or structural engineers rarely have serious date or year dependant problems in their software. But my point is "Please be careful how you advise your clients/companies as you may be casually passing some serious liability related problems off to them that could be disastrous indeed". This CAN be a very serious problem.

Regards: Thomas D. Kohli, P.E.

At 02:07 PM 11/12/98 -0500, you wrote:
>Very impressive description of the problem, Roger. I've never thought
>about it that way (or seen it described as such in the popular press OR
>trade magazines).
>
>Dan
>
>-----Original Message-----
>From: Roger Turk [mailto:73527.1356(--nospam--at)compuserve.com]
>Sent: Thursday, November 12, 1998 1:29 PM
>To: seaint(--nospam--at)seaint.org
>Subject: Year 2000 computer problem
>
>
>R. D. McConnell wrote:
>
>. > It is only necessary to change the 2-digit integer representation of
>the
>. > date to a 4-digit integer to account for the "2000" problem.
>
>I agree with your basic premise that the Y2K problem is a contrived
>problem,
>however for a different reason. I, too, was introduced to computers in
>the
>1950's when the IBM 650 was the greatest and latest.
>
>First, numbers are not stored in computers as "digits," but as
>electrical
>(magnetic) charges. Either it is on or it is off. The largest integer
>that
>can be represented is determined by the number of bits available. As I
>recall, the IBM 650 used 12 bit "words" and allowing 1 bit for the sign,
>the
>maximum integer that can be represented with 11 bits would be 2047.
>Similarly, for 4 bits, the maximum integer would be 15; for 7 bits (8
>bits
>minus 1 for a sign), the maximum integer would be 127; and for 16 bits,
>the
>maximum integer is the recognizable 65,535.
>
>Since the earliest computers (even with the IBM 1401 and IBM 7072, which
>by
>then were using 24 bit "words") did not store dates (the computers had
>to be
>initialized with a card deck and the dates entered manually each time
>the
>computer was started), and that complete "words" had to be used, a
>"date"
>problem would not occur until at least 2047. (Hm-m-m, Mac users, does
>this
>number sound familiar?)
>
>Now, when the BIOS for the PC came into being and stored a date, be it a
>
>2-digit date (80 as 1010000 or 84 as 1010100) [7 bits], or a 4-digit
>date
>(1980 as 11110111100 or 1984 as 11111000000) [11 bits], there should not
>be a
>problem until the year 2007 (for 7 bit numbers) or year 2047 for 11 bit
>numbers. For 16 bits, the problem would not occur until 65535. (I have
>a
>Phoenix BIOS on my old, ca. 1986, Leading Edge Model D [8088 machine]
>and it
>shows the date as 4-digits. I have checked the BIOS out for the year
>2000 by
>setting the date to December 31, 1999, the time to 11:55 p.m., and
>waiting
>for more than 5 minutes, both with the computer on and off, and it
>recorded
>the correct 2000 date. Now I have to check it out to see if there is a
>February 29th in the year 2000.)
>
>Now, when it comes to *programs* using dates, there could be a problem,
>but
>not necessarily at the year 2000. Some programs start with an arbitrary
>date
>and do date and time arithmetic using the number of days, minutes and
>seconds
>from that arbitrary date; others use Julian Dates, which means different
>
>things to different people. (Some Julian calendars count days from year
>1,
>others from the first day of the current year.)
>
>A. Roger Turk, P.E.(Structural)
>Tucson, Arizona
>
>

>* This email was sent to you via Structural Engineers
>* Association of Southern California (SEAOSC) server. To
>* subscribe (no fee) to the list, send email to
>* admin(--nospam--at)seaint.org and in the body of the message type
>* "join seaint" (no quotes). To Unsubscribe, send email
>* to admin(--nospam--at)seaint.org and in the body of the message
>* type "leave seaint" (no quotes). For questions, send
>* email to seaint-ad(--nospam--at)seaint.org. Remember, any email you
>* send to the list is public domain and may be re-posted
>* without your permission. Make sure you visit our web
>* site at: http://www.seaint.org

>
>

>* This email was sent to you via Structural Engineers
>* Association of Southern California (SEAOSC) server. To
>* subscribe (no fee) to the list, send email to
>* admin(--nospam--at)seaint.org and in the body of the message type
>* "join seaint" (no quotes). To Unsubscribe, send email
>* to admin(--nospam--at)seaint.org and in the body of the message
>* type "leave seaint" (no quotes). For questions, send
>* email to seaint-ad(--nospam--at)seaint.org. Remember, any email you
>* send to the list is public domain and may be re-posted
>* without your permission. Make sure you visit our web
>* site at: http://www.seaint.org

>
>


Thomas D. Kohli, P.E.
Manager of Engineering
Costa Del Mar Engineering, Inc.
12 Tall Pine Circle
Augusta, GA 30909

email: tdk(--nospam--at)CostaDelMarEng.com
web site: http://www.CostaDelMarEng.com

(706) 481-0893 (W)
(706) 667-9372 (FAX)