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 : Forecross Corporation : Y/2000 -- Ignore unavailable to you. Want to Upgrade?

To: Ruyi who wrote (1036)	5/25/1998 11:47:00 PM
From: AD	Respond to of 1654

No silver bullet !!!! May 25, 1998, TechWeb News -------------------------------------------------------------------------------- No Silver Bullet For Y2K By Peter De Jager Despite headlines to the contrary, year 2000 is still a problem. Claims of a "silver bullet" finessing the computer in some neat, creative, and unexpected manner are only creating false hope. Some news media report the year 2000 problem is simple: We stored the year as two digits. But that's just the beginning. In addition to two-digit dates, there's also the matter of dates representing "logical flags." The most familiar example is 9/9/99, used as an end-of-file marker. Then there's the problem of "00" instructing us to delete or use a data record. Solving either of these examples would require adding an additional field to the data record or drafting an existing, unused field into use. By itself, that's not a major hurdle. The insurmountable obstacle is this: Where do you set the flag? Or even worse, what if there are multiple values being used? For example, 00 indicates end of file, 01 indicates delete, etc. What if the special values are input by the user? The conversion program would have to modify every input screen that included this particular date field to include the new date field. Also, this conversion utility must somehow communicate this system modification to the users. Then there's the fact that year 2000 is a leap year. How the Gregorian calendar works is not a secret. The three rules are available in any encyclopedia, but it would appear that many programmers were totally unaware of how the calendar operates, as evidenced by indignant letters to the editor received by computer magazines, saying 2000 is not a leap year. No automatic solution will address leap-year issues 100% correctly. Why? Because there are so many wonderfully creative ways in which to calculate or look up leap years or to arrive at "day of the week" information in what many would consider arcane methods. Here's an exercise I'll leave entirely to the reader. What is Zeller's Congruence and why should you care? These are questions you might want to ask your year 2000 vendor. Ignoring embedded systems, we have three components to year 2000: ambiguous date data, special dates, and leap-year considerations. Any silver bullet must address all three. As if this were not complicated enough, we often overlook another aspect of year 2000. We speak about applications or programs as either compliant or noncompliant. This distinction ignores the gray areas. This was brought to my attention several years ago during a demonstration of a vendor's conversion product. I was shown a program chosen at random from a client's portfolio. It was a Cobol program consisting of about 5,000 lines of code. While glancing quickly at the code, I noticed that either the original programmer or some subsequent maintenance programmer had given some thought to year 2000 and was already using a windowing scheme (pivot date of 30) for some-not all-date manipulations. The vendor converted this program and proudly displayed the output. It had done its job, and all date manipulations were converted to the new windowing scheme (pivot date of 50). The existing scheme had been "overlaid" with the new scheme. I spent 20 minutes examining this code and could not determine if conversion had changed functionality. Since I wasn't allowed to take away copies of the original and converted code, I have no idea if the converter created a problem, one that might-or might not-show up in testing. But if the foregoing reasoned argument hasn't swayed you, consider this-No silver bullet can fix the following program: INPUT YEAR: IF YEAR='00, THEN "SHUT DOWN REACTOR-NOW"! Peter de Jager is a noted authority and international speaker on the year 2000 problem. He is also the creator of the year2000.com Web site and is the co-author of Managing 00: Surviving the Year 2000 Computing Crisis (John Wiley & Sons, 1997). He can be reached at pdejager@year2000.com. Copyright r 1998 CMP Media Inc. You can reach this article directly: techweb.com

To: Ruyi who wrote (1036)	5/26/1998 10:05:00 PM
From: Rick Voteau	Read Replies (4) \| Respond to of 1654

A possible Forecross Scenario. GM has publicly stated that they will spend $500 million on Y2K. EDS will of course do that work. Let's assume that Forecross gets 1/5 of that as conversion work or $100 million. They will have about a 85%+ margin or nearly $8/share in NET INCOME. Same Scenario exists for TRW and BDM and I'm not exagerating for effect (although if I was it would be a pretty good effect). $8/share means a $160 stock. I follow many other conversion companies and no others have alliances with the major service companies that Forecross does. Anybody, please show me if I am wrong Some have marketed direct which has produced more [profits up front. Largest dollars are yet to come as the EDS's, BDM's and Keanes of the world find that they have to use Forecross to get completed on time. Other alliances will no doubt come as well. Other companies will jump on board once they realize that the major's have signed up. Patience will pay off. Very soon we will have a listing with contract announcements. I expect it any day now as the information was submitted to NASDAQ and AMEX in January. .