Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Wind River going up, up, up! -- Ignore unavailable to you. Want to Upgrade?

To: Ramsey Su who wrote (3143)	5/6/1998 8:49:00 AM
From: Allen Benn	Read Replies (1) \| Respond to of 10309

I am surprised to find that there may be more problems on the manufacturing side vs the financial side. The Y2K problem can bite any program with dates in which familiar shortcuts were taken. Certainly assembly line or just-in-time part suppliers involve dates as much as accounting transactions, and are equally prone to the problem. My knee-jerk reaction to date problems in embedded process controllers is that they should be much simpler to fix than back-office business systems. Oldfashioned transaction processing systems often grew organically to become hopelessly intertwined, so format repairs have hard-to-determine side-affects downstream. (Modern database systems avoid most of those problems even if date inputs rely on a 2-digit year. This is because database DATE fields are not stored in YYMMDD format, even if the field is inputted that way. Fix the inputs, and the Y2K date problem is solved. Some database vendors made this particularly trivial by providing replacement masks for a YY input field. With RR, say, the database knows to handle the century correctly.) The C language was the first 3rd generation language I recall that comes with a standard time/date library, which most programmers use to handle time and date manipulations. Similar to, but not as robust as, modern databases, this library stores dates in Julian seconds counting from January 1, 1970 - the beginning of time. Most of the other traditional languages, like Fortran and COBOL, did not provide special date and time services. This was never considered much of a burden on the programmer. After all, how much trouble can it be to set up a YYMMDD field and make sure each component satisfies range checks? Before databases, back office processing invariably involved sequential processing steps consisting of a sort and merge followed by transaction processing with errors thrown out, fixed and recycled. Complex systems involved cascading processing steps, involving hundreds of intermediate files, all properly ordered generally on date. The silver lining of Y2K is that much of this trash is getting dumped, which should lead to improved corporate efficiency, and a boon to the economy. Mission critical systems that can't be dumped have to be fixed, and that can be a challenge. Fixing an embedded process controller would seem to be trivial compared to the nightmarish possibilities awaiting the back-office COBOL programmer. On second thought, however, I realize my knee-jerk reaction is wrong. (One shouldn't use ones knees in thinking about computers.) I can see where the embedded processor might be vastly more difficult to fix than back-office programs. Why? Because it may be extremely difficult to resurrect the development environment needed to check out the code, recompile, debug, etc. Since any fix may alter timing behavior of a real-time system, anything less than a full-scale development environment would be inadequate. Probably most embedded process controllers in operation today rely on a variety of home-grown RTOS' and skimpy development tools. Moreover, assembly language is apt to have been a frequent choice for partial or total implementation. I suspect it would be a near impossible task to resurrect everything necessary to fix a heterogeneous mix of embedded process controllers in a timely fashion. (Initial development of many existing embedded controllers no doubt required an inordinate amount of time to compensate for low-level language and poor development tools.)If there was ever a time to upgrade from home-grown, assembly-language goulash, it would be now. If true, wouldn't that open the door for a limitless amount of state of the art embedded applications? Furthermore, if GM has problems of this nature, wouldn't just about anyone else with older automated manufacturing systems have the same problem? You are correct. The Y2K should cause quite a rush to re-implement thousands of embedded process controllers designs, and should speed the conversion to COTS RTOS. WIND should get its share of the expected bulge in business, with the immediate impact mostly in the form of product license fees and services, not royalties. A Y2K-created rush to COTS RTOS is a theme that deserves watching. Allen