When Fixing Y2K Problems, Don't Forget VB Apps
The same year 2000 date problems that are threatening billions of lines of mission-critical COBOL code may also be lurking in millions of Visual Basic programs, experts say.
"Most apps have at least one aspect of their makeup that is not Y2K compliant, even those that have only been in production for 2 or 3 years," says John Petersen, vice president of information systems for IDT Marketing Systems and Services Inc. (Philadelphia) and co-author of "Hands-on Visual Basic 6 Web Development."
The potential problems fall into two categories: those caused by older versions of Visual Basic, and those introduced by programmers, which could affect applications written in even the most recent version of VB.
On its Year 2000 Resource Center Product Guide, (http://www.microsoft.com/technet/topics/year2k/product/product.htm) Microsoft Corp. presents separate discussions of 16-bit and 32-bit VB compliance. VB 4.0 32-bit and VB 5.0 are considered compliant, with minor issues. Many of those issues stem from the Windows library called OLEAUT32.DLL, which these versions of VB use to interpret dates, according to Mark Mayes, director of Class Solutions Ltd. (Wickford, England, www.class-solutions.com), a British company whose Visual DateScope 2000 toolkit is designed to help developers solve Y2K date problems in VB code.
On systems running older versions of OLEAUT32.DLL, two-digit dates are interpreted relative to the system date. But later versions of the library use what is known as the 100-year window -- two-digit dates between 00 and 29 are considered to fall in the 21st century, while dates between 30 and 99 are assigned to 1900s.
The 100-year window resolves the immediate Y2K problem, but not everyone is satisfied with the solution. "This rollover date is too low in my opinion," IDT’s Petersen says. Nevertheless, it's a better solution than the one used by the 16-bit versions of VB. The Microsoft Year 2000 Resource Center lists VB versions 1.0, 2.0, 3.0 and 4.0 16-bit as noncompliant. While VB 4.0 16-bit interprets two-digit dates on the basis of the current century, all earlier version of VB consider two-digit dates to refer to the 1900s.
"Without a doubt, VB 3.0 has the most Y2K problems," Class Solutions’ Mayes says. And, he adds, "there's an awful lot of systems out there that were developed in VB 3." Mayes estimates that half of the VB applications currently running in corporations are noncompliant. Exact figures aren't available, and Microsoft was unable to respond by press time.
What's worse, some of those noncompliant applications may be running in companies that have upgraded to VB 4.0 32-bit or even VB 5.0. That's because of the other potential source of Y2K problems for VB: programming errors. "Regardless of the VB version, it is also possible to introduce Y2K problems into VB code by writing ‘bad’ code," Mayes explains.
Like most programming details, the problems that can be introduced by programmers are complex and intricate. But basically, it boils down to this: Some programmers choose to store dates in string variables, which would usually be used to store text, instead of in VB's designated date variable. Dates in the date variable are subject to the rules mentioned on the Microsoft Year 2000 Resource Center site. But those two-digit dates stored in strings will never be fixed, even if the application is recompiled under a compliant version of VB.
But why wouldn't all programmers use the date variable? Because many VB programmers originally learned their trade using COBOL and C, languages that don't have a date variable. During a presentation at Microsoft's recent Developer Days conference in New York, Aaron Kornbluth, a consultant with Professional Computer Solutions Inc. (Hackensack, N.J.), acknowledged the problem: "If you're going to take your date data and store it in an 8-bit string in mmddyy format, nothing's going to help."
Of course, some companies may be too bogged down with mainframe applications to worry about their VB apps. Most attention to the Y2K problem has focused on such mission-critical applications. But Mayes says he thinks many companies will alter their conception of a mission-critical application once these other programs begin to fail. "Within the last 18 months, people have been writing VB applications for MIS and they're hooking into legacy data. They are making management decisions using applications that have VB front ends. I think people are going to be surprised what is mission-critical when it comes down to it," Class Solutions’ Mayes says.
Andrew Bochman, a senior analyst for Year 2000 Services at the Aberdeen Group (Boston), agrees with Mayes -- to a point. "A lot of enterprises are putting the distributed systems and their languages on the back burner while they take care of what they consider their mission-critical systems," he says, pointing out that mission critical in this case tends to refer to those applications that can ruin the company if they fail.
However, Bochman admits that he's increasingly hearing from companies who are beginning to pay attention to their other applications, such as management reporting. "The more prepared companies, the ones who started earlier, do have the time and should have the resources to take care of that aspect of their portfolio," Bochman says. "I think it's a real emerging market."