Home Magazines BizTimes Milwaukee Fixing the Y2k problem

Fixing the Y2k problem

Making a company Year 2000-compliant involves auditing each and every computer program used by the company – a labor-intensive process which can take anywhere from six to 18 months. Every line of programming has to be checked. Some of it is written in computer languages no longer used or understood.
How did we get into this mess in the first place?
Back in the 1960s, ’70s and ’80s, storage space on mainframe computers was valuable, and it was cheaper to skip two digits in the standard date field: MM/DD/YY. The date “19” was assumed. Programmers carried the concept over to personal computers, which received a boost in performance by carrying the two-digit date field.
According to Year 2000 guru Peter de Jager, the problem is largely software-related. Current estimates are that as much as 90% of software code is potentially infected by the Year 2000 problem.
Here’s what Jeff Ray, vice president of emerging technologies for Detroit-based Compuware, says businesses need to think about when it comes to a Y2K fix:
Step 1 – Identifying the problem
First of all, assume you have a problem no matter how small your business. Next, develop some kind of strategy for remedying the problem. If you have one, your information technology specialist needs to come up with a plan.
Make a technical case that states how he/she intends to go about finding the problem. There are many products available that scan and look for these infections. One such product is called JumpStart 2000. Keep in mind that you’re going to get a lot of hits for things that won’t fail. These are called “false positives.”
Step 2 – Fixing it
There are three common ways for fixing the Y2K faults.
The most permanent way, and the most expensive, is to turn two digits into four. But once it’s fixed, it’s fixed for good.
Next is the most commonly recommended approach called “windowing.” This method tricks the computer into thinking it’s dealing with the proper century.
“We recommend to our clients that they use windowing because it is reasonable in cost, and manageable,” Ray says. “The only problem, potentially, is that you might have a problem 50-60 years down the road, because you haven’t permanently fixed it. But by then, the odds are that computer language will have changed.”
Windowing is like a sliding window: when you get evidence of infected date, say the number is “90” and the computer doesn’t know if it is 1890, 1990, 2090. So, take a pivot date, such as 1970; this embeds a little bit of logic in the computer. If the two-digit number is greater than 90, it points it toward the proper century.
“We think it is the preferred strategy because it means we don’t have to expand the date fields in our files,” says Jim Bloom of Milwaukee Public Schools.
If you run an insurance company and you are dealing with calculations that span backwards, you could have some problems with the windowing method, Ray says.
The third way is to use a sub-routine.
Another way to fix it is to replace the code.
Step 3 – Testing it
You’ve gone through and identified the bugs and performed your fix. But, you won’t know whether it is fixed until you test it with future dates to see if you get the right answer.
“Companies in our industry have never done a good job of software testing,” Ray says. The challenge with testing is you’re dealing with floating rules; the rules don’t stay constant. It’s very easy to test for getting the same answer, Rays says. You have to be very clever in time-dimensional testing. The hard part is: How do you test when the rules change? The most important part of testing is to involve the end user.
“You have to involve the guy who uses the actual table, the Subject Matter User (SMU),” Ray says. “You cannot test for stuff you don’t know the answers to. Begin the testing discussions before you start altering the code. Capture a snapshot of all the answers the system has today before you mess with your code.”
Anyone who relies on outside suppliers or e-commerce should be concerned with this, Ray adds. About nine months ago, auto companies woke up to that fact because they rely on outside suppliers. It’s not enough to say, OK, fine, we’re sound. You need to validate through your providers and suppliers that they are compliant. The auto industry is going through this process, as is the securities industry.
“The Street Test” is a massive undertaking which will take place on Wall Street this summer.
Finally, don’t let the weeds grow back. Make sure that the outside contractor who comes in to work on your system when the tax code changes must be made is aware that he’s dealing with a Y2K-compliant system. If someone is coming in, make sure that those changes will not corrupt the Year 2000 compliant system.
April 1998 Small Business Times, Milwaukee

Making a company Year 2000-compliant involves auditing each and every computer program used by the company - a labor-intensive process which can take anywhere from six to 18 months. Every line of programming has to be checked. Some of it is written in computer languages no longer used or understood.
How did we get into this mess in the first place?
Back in the 1960s, '70s and '80s, storage space on mainframe computers was valuable, and it was cheaper to skip two digits in the standard date field: MM/DD/YY. The date "19" was assumed. Programmers carried the concept over to personal computers, which received a boost in performance by carrying the two-digit date field.
According to Year 2000 guru Peter de Jager, the problem is largely software-related. Current estimates are that as much as 90% of software code is potentially infected by the Year 2000 problem.
Here's what Jeff Ray, vice president of emerging technologies for Detroit-based Compuware, says businesses need to think about when it comes to a Y2K fix:
Step 1 - Identifying the problem
First of all, assume you have a problem no matter how small your business. Next, develop some kind of strategy for remedying the problem. If you have one, your information technology specialist needs to come up with a plan.
Make a technical case that states how he/she intends to go about finding the problem. There are many products available that scan and look for these infections. One such product is called JumpStart 2000. Keep in mind that you're going to get a lot of hits for things that won't fail. These are called "false positives."
Step 2 - Fixing it
There are three common ways for fixing the Y2K faults.
The most permanent way, and the most expensive, is to turn two digits into four. But once it's fixed, it's fixed for good.
Next is the most commonly recommended approach called "windowing." This method tricks the computer into thinking it's dealing with the proper century.
"We recommend to our clients that they use windowing because it is reasonable in cost, and manageable," Ray says. "The only problem, potentially, is that you might have a problem 50-60 years down the road, because you haven't permanently fixed it. But by then, the odds are that computer language will have changed."
Windowing is like a sliding window: when you get evidence of infected date, say the number is "90" and the computer doesn't know if it is 1890, 1990, 2090. So, take a pivot date, such as 1970; this embeds a little bit of logic in the computer. If the two-digit number is greater than 90, it points it toward the proper century.
"We think it is the preferred strategy because it means we don't have to expand the date fields in our files," says Jim Bloom of Milwaukee Public Schools.
If you run an insurance company and you are dealing with calculations that span backwards, you could have some problems with the windowing method, Ray says.
The third way is to use a sub-routine.
Another way to fix it is to replace the code.
Step 3 - Testing it
You've gone through and identified the bugs and performed your fix. But, you won't know whether it is fixed until you test it with future dates to see if you get the right answer.
"Companies in our industry have never done a good job of software testing," Ray says. The challenge with testing is you're dealing with floating rules; the rules don't stay constant. It's very easy to test for getting the same answer, Rays says. You have to be very clever in time-dimensional testing. The hard part is: How do you test when the rules change? The most important part of testing is to involve the end user.
"You have to involve the guy who uses the actual table, the Subject Matter User (SMU)," Ray says. "You cannot test for stuff you don't know the answers to. Begin the testing discussions before you start altering the code. Capture a snapshot of all the answers the system has today before you mess with your code."
Anyone who relies on outside suppliers or e-commerce should be concerned with this, Ray adds. About nine months ago, auto companies woke up to that fact because they rely on outside suppliers. It's not enough to say, OK, fine, we're sound. You need to validate through your providers and suppliers that they are compliant. The auto industry is going through this process, as is the securities industry.
"The Street Test" is a massive undertaking which will take place on Wall Street this summer.
Finally, don't let the weeds grow back. Make sure that the outside contractor who comes in to work on your system when the tax code changes must be made is aware that he's dealing with a Y2K-compliant system. If someone is coming in, make sure that those changes will not corrupt the Year 2000 compliant system.
April 1998 Small Business Times, Milwaukee

Stay up-to-date with our free email newsletter

Keep up with the issues, companies and people that matter most to business in the Milwaukee metro area.

By subscribing you agree to our privacy policy.

No, thank you.
Exit mobile version