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.

Microcap & Penny Stocks : TPII - Year 2000 (Y2K); Groupware; Client Server Migration -- Ignore unavailable to you. Want to Upgrade?

To: Pierre Mondieu who wrote (9475)	12/1/1998 5:40:00 PM
From: TEDennis	Read Replies (3) \| Respond to of 10903

Pierre: Re: "phase shift" and "date biasing" solutions: I don't have any experience with them directly, but have discussed them with other technogeeks. Like many other "techie tricks" being used to solve (or, better stated, "to avoid") the Y2K problem, they have a few gotcha's. As long as you're running the environments they support, and you understand their relative strengths and weaknesses, they are an acceptable way to attack the problem. Personally, I'm a "convert everything to 4 digit" bigot, so I wouldn't choose to go that way, or any other "techie trick" way unless I: 1) ran out of time to fix it with code changes (a likely scenario) 2) lost the source code I preach 4-digit conversion for a number of reasons, the least of which is a warm, fuzzy feeling that I get when I can look at code and tell EXACTLY what it's doing, instead of having to make an educated guess about what will really happen during execution time when a "techie trick" takes over behind the scenes and does what somebody in another cubicle told it to. OK, so label me a purist. Other reasons include long term maintenance costs involved with perpetrating the "hoax" (just thought I'd throw in that term to catch the interest of those SEC guys who scan the threads). The concept of intercepting the Input/Output statements is nothing new. We've been doing stuff like that since IBM was a pup. "Front ending" and "Back ending" are common to the "bridging" techniques, and some of the "windowing" techniques. In effect, this is a "windowing" technique in that it slides the window through which the code "sees" dates backwards 28 years. Thus, you have another 28 years to fix the problem the "right" way. 4-digit expansion, of course. As with other techniques, there are source changes that must be made to support the technique in a few instances. The more clever approaches automatically front end the COBOL runtime routines and determine whether or not a particular record type in a particular file needs to be adjusted (phase shifted). For the situations that aren't caught automatically at runtime, you can change the source code to interface directly with the "smarts" of the solution. For the non-COBOL languages, though, it gets a bit messier. To use the capabilities of this approach in one of the non-supported environments/languages, you have to make source changes to invoke the service. Isn't source code changes what we're trying to avoid? But, now instead of making simple logic or data expansion source changes, we're making source changes to give control to another piece of software somewhere else in the overall scheme of things. Kinda' scary. Nobody said this was going to be easy. Except some folks on the "Y2K is a hoax" thread. And they don't know what they're talking about. Regards, TED