SI
SI
discoversearch

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 : CSGI ...READY FOR TAKE-OFF! -- Ignore unavailable to you. Want to Upgrade?


To: Tech Master who wrote (2459)2/17/1998 6:22:00 PM
From: tech  Read Replies (1) | Respond to of 3391
 
Read it and weep.

biz.yahoo.com

Ms. Marge Davies, Motorola's project manager for the project, stated: ''I am impressed with the ConSyGen 2000 toolset and its ability to identify and list missing code, to give us complete exception reports, and to make code compliant for the Year 2000 with such SPEED and ACCURACY. To be honest, when ConSyGen said that they could make our system Year 2000 compliant in a very short time, I really didn't believe them. When ConSyGen delivered the compliant code in only eight days, I was amazed. We weren't even ready to start testing.'' Davies continued to say that the first code delivered had only one error; ConSyGen corrected the error in the translator, re-ran the code through the toolset overnight, and returned the corrected code to her the next day.

gee, sounds like they are so worried .... NOT

I wonder if Motorola will now give CSGI a contact ?

your attempts to make such stink about one error is truly hilarious.

You have absolutely nothing to go on, and it's the only thing you have to attack. Who are you trying to fool, yourself or someone else.

Obvoiusly Motorola was very happy with the results and the Project manager said she was "AMAZED" at the accuracy and the speed.



To: Tech Master who wrote (2459)2/18/1998 7:18:00 PM
From: TEDennis  Read Replies (1) | Respond to of 3391
 
Tech Master: Re: why reprocess the whole set of code because of one error?

Since CSGI's tool is driven by a set of "rules", then the entire conversion done with the set of rules that created the error is highly suspect. Note that MOT only found one error. That doesn't mean there was only one error there. This is speculation, for sure, but depending on how severe the error was, MOT might have just stopped testing until the "rule" was fixed and the whole set of code re-converted with the new set of rules.

If the error was found somewhere during the initial setup phase of the processing, then additional testing would have been useless, as it would have been based on an invalid execution environment.

Calling CSGI to clarify what this error was would probably not be worth the time. If it was a severe error, they would soft-pedal it enough to make it sound like a minor annoyance. If it was just a minor annoyance, then it would sound like a minor annoyance. Either way, you get the same answer. The only way to judge the true severity of the error is to talk directly with the programmers responsible for running the tests and see what their opinions are. They'll probably be very negative about the whole thing because it would have impacted their ability to get their jobs done.

Note that I'm not picking on CSGI and how they would most likely respond. Other companies would do the same. They will always position themselves in their own best light. Makes sense to me.

I wish everything involved with the Y2K problem were as simple as black and white, or right and wrong. Unfortunately, there are so many shades of gray and degrees of 'wrongness' involved that just about anything that can be said will be studied and interpreted positively by the CSGI supporters, and negatively by the CSGI detractors. Again, this is not unique to CSGI.

Reality sux, eh?

TED