TAVA Technologies (TAVA-NASDAQ) Message Board

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 : TAVA Technologies (TAVA-NASDAQ)

Public Reply Prvt Reply Mark as Last Read File

Previous 10 Next 10 Previous Next

To: Bill Wexler who wrote (22561)	8/23/1998 3:09:00 PM
From: Joe T	Read Replies (1) of 31646

Here is my reply to your Message 5560537. This is possibly boring and long winded. Its at pretty at the level of what you learn in programming 101. But its the only way I knew how to make my point. I am trying to explain why your following assertion is NOT true: "The Y2K problem is a hoax designed to make a millenial crisis out of a relatively straightforward software/hardware upgrade and maintenance issue." Changing one line of code in one program A can create problems for a dozen other programs which read in the data that was updated/created by program A. Lets calls these dozen other programs B1 thru B12. If program A's output file contains some 'bad' data, such as a field that was updated incorrectly (due to faulty Y2K date logic), then B1 thru B12 all have the potential of have problems of their own as a result of the bad data. Programs B1 thru B12 could also each be creating/updating data that is read in by a dozen other programs. Lets call these 144 other programs C1 thru C144. Programs C1 thru C144 each have the potential for having some problems now because they could be now be updating/creating bad data as a result of the bad data being fed into them from the programs B1 thru B12. So in theory you have one bad line of code in program A1 having the potential to cause problems in 156 other programs (B1 thu B12 + C1 thru C144). It is possible that programs B1 thru B12 will not have any problems when the bad data from A1 goes through them. But then one of the C1 thru C144 programs could have a problem. The bad data from A1 passes thru the B1 thru B12 programs without any negative affect but then it does not pass through C1 thru C144 programs without problems. So say you now have a problem in program C120. Where did the problems originate ? You know that B1 thru B12 updated or created the data going into C120 but you can't see any problems with these programs. So then you have to look at A1 and hope you can find the problem there. Figuring out these relationships is tedious and time consuming. Looking for problems in a program is tedious and time consuming. The more changes you make the more potential you have for problems that are 'once removed', 'twice removed' and 'three times removed'. Sometimes you have expert staff who have worked with the system for years and understand all these relationships but more often than not these people left for higher pay. You have tools to help you find these relationships but they don't provide 100% coverage. Normal maintenance might involve changing five or six programs and then testing to make sure everything still works OK. The above scenario is manageable in this situation. Y2K might require that you make changes to 300 out of 1200 programs in a system. As you add more changes the complexity grows exponentially. Im sorry Mr. Wexler but thier is no way I will ever agree with you that what we are talking about here is a relatively straightforward software/hardware upgrade and maintenance issue.

Report TOU Violation

Share This Post

Public Reply Prvt Reply Mark as Last Read File

Previous 10 Next 10 Previous Next