Okay, you've been back from Christmas hols for two weeks, and started the New Year on a high, content in the knowledge that your Year 2000 compliance programme is going like clockwork. You have already identified the large, mission critical systems which are most at risk from the bug and testing these systems has been underway for months. So now you can sit back and relax. It's a rosy picture and one that goes down well with the board, but sadly there is an awful lot of work left to do. By now, companies should fully appreciate the extent of the Year 2000 computer bug. Thanks largely to the lobbying of TaskForce 2000, the heads of large UK companies at least acknowledge that the Year 2000 poses a serious threat to their businesses. However, the situation on the PC is far from rosy. To start with, PC systems have traditionally flourished as departmental systems. Hence they were not under the direct control of centralised IT. Over time, users have come to rely on these departmental systems to perform their day-to-day work. If such a system fails, it may not bring the business to a standstill, but it will certainly hamper users. A far more serious problem is when dates stored on a non-Year 2000 compliant PC system is uploaded to a compliant mainframe or large centralised server. In this situation, there is a very real risk of corrupting the data residing on the mainframe or centralised server, thus rendering the data non-Year 2000 compliant. So given that PCs can directly affect Year 2000 compliant centralised IT systems, it is particularly important to ensure that any PC system which talks to centralised IT is Year 2000 compliant. There are two possible areas of concern on a PC. First is the hardware, which on older PCs, supported only two-digit years. This type of failure occurs in the ROM BIOS, a chip on the PC's motherboard which controls basic PC functions such as keyboard input, the display and the date and time services. BIOS checking utilities are available which can determine whether a BIOS supports four-digit years, and is thus Year 2000 compliant. The best solution to a non-compliant BIOS is obviously to replace it with a compliant one, although this practice is rife with potential pitfalls. A replacement BIOS may not exist at all. Even if one does, it may not fully support the features on the motherboard. A simpler alternative can be achieved in software. There are a number of software products on the market which provide four-digit years on a non-compliant BIOS. These products do a similar job to device driver software, but rather than support an add-on device, instead they extend the PC's existing date and time functions so that they support four-digit years. A problem with the software approach is that since it is software, the work-around for the bug is not set in concrete. Unlike the BIOS chip replacement, the software approach is volatile. If the program files are deleted or the software fails to run correctly then the PC will no longer be Year 2000 compliant. The BIOS problem mainly affects older PCs as newer machines tend to have Year 2000 compliant BIOSes. The second, and far more threatening problem with PC systems, is the software itself. The situation is compounded by the fact that applications developed on PCs tend to be more free spirited than mainframe applications. The popularity of rapid application development tools like Visual Basic and Delphi has brought down the barriers of complexity prevalent in traditional application development. With these tools, even end users can write applications. In fact, this is the strength of the PC over mainframe developments. For instance, how many companies are being run on a spreadsheet with some clever macros? The PC has made this possible. Increasingly sophisticated tools have allowed end users to write their own applications. In the bad old days, users had to wait for the MIS department to get its finger out. If there is one adage that is clearly evident on the PC today it is that a little knowledge can do a lot of damage. Users with little or no formal programming training, are developing their own applications. While end users have helped lift the burden of work from the MIS department, they have also created new, unforeseen problems. The most obvious of these concerns the Year 2000. Before the soothsayers prophe-sied disaster for IT with the Millennium meltdown, users were largely blissfully ignorant that four digit years mattered. The PC seems totally biased towards two-digit years. For instance, in the Windows 95 Regional settings dialog box, the default date setting is short date format which uses two digits for the year. It is no wonder PC users never have cause to practice using four-digit years. Mike Lunch, general manager of IBM's PC division speaking before Christmas expressed concern over the implications of the Year 2000. "The current generation of PCs have been Year 2000 compliant for some time, but I don't think that's the real issue. The real problem is not the hardware, it's all the problems associated with the application software." He added that users may be running applications that are themselves Year 2000 compliant, working on operating systems and PCs that are Year 2000 compliant, but they still have big problems ahead. Lunch said: "The implications are very deep and I'm very concerned that customers are not taking it seriously." Bearing in mind there is a problem with Year 2000 compliance, the next step on the PC is to find which applications are affected. By and large, off-the-shelf applications should at least support four-digit years, but that's no guarantee that they comply. If an application gives users the freedom to enter two-digit rather than four digit years, then the question of whether the application supports the Year 2000 is irrelevant. The date information, if entered with a two-digit year code, will certainly not be Year 2000 compliant. Microsoft applications and operating systems are enabled for the Year 2000, which basically means they support four-digit year codes. This does not imply that they are compliant. Users can still enter two-digit years instead of four. If a two digit year is entered, Microsoft applications use a formula called a date window to determine which century the date refers to. A date window simply states that if the date falls below a certain value it belongs in the 20th century; if it is above then it's in the 21st century. Visual Basic 5 assumes two-digit dates greater than or equal to the year 30, refer to the 21st century. While those years that are less that the year 30 refer to the 20th century. So, Visual Basic 5 interprets the two digit year 29 as meaning 1929; while 30 refers to 2030. This simple date conversion appears fine in theory, but Peter Morris of software house, The Mandelbrot Set, warns that it is by no means standard. "There is no standard industry wide method to map two-digits to a century using a date window. It is not even standard between Microsoft applications," said Morris. "A very nasty case of incompatibility," he continued, "is the system DLL OLEAUT32.DLL." OLEAUT32 is a Windows service for converting two-digit to four digit years sing the date window formula. "There are eight build of this DLL. Some map all two-digit dates to the current century; others use a different formula." Morris said that the version of OLEAUT32 that shipped with Windows 95, Service Pack Release 1, uses century aligned date windows for two-digit date conversions. However, the version that ships with the FAT32-enabled version of Windows 95 (OSR 2), converts two-digit years greater than or equal to 30 to the 21st century. Years 29 or below are converted to the 20th century. What this means is that two versions of the same date conversion DLL, will treat dates differently. In the earlier builds, all two-digit years will be converted to the 20th century; while later builds determine the century on which side of the year 30, the date falls. This DLL is pretty much the standard for Microsoft applications. Morris points out that an application developer could run into serious problems if they rely on this Microsoft DLL to perform the correct date conversions. If an application has been written with the older version of OLEAUT32 installed, the application logic would take into account century aligned two-digit year conversions. However, if the PC on which the application runs is upgraded, with, say, Office 97, this will replace the old DLL with a later version which supports the Year 30 rule. The date window formula has essentially changed and thus the application is effectively useless in terms of Year 2000 compliance. Morris also warns that the situation can go the other way as well. A program written to use the later version of the DLL could fail inadvertently when a rogue piece of software is installed which simply overwrites OLEAUT32.DLL with an older version. It is not uncommon for Windows install programs to load DLLs onto a PC systems without properly checking whether the DLLs being replaced are actually older versions. Although the Year 2000 is the main focus of this article, it is worth noting that compliance testing could reveal a raft of shortcomings in terms of an application's ability to handle dates correctly. The date and time on a PC is actually stored as a double precision floating point number offset from midnight on 30th December 1899 which has the value zero. The PC operating system provides services which converts this number into a text form of the date, such as the string "January 13th 1998" or "13/01/98". Morris notes that a common programming error is to base date calculations on this text form of the date, rather than the actual numeric value. Morris said that a program may expect to find the year as the last two digits in the text string, "13/01/98", for example, in Windows' short date format - ddmmyy. However, if the user changes the date format in the Control Panel's Regional Settings dialog box, this will alter the way the date is displayed which could potentially cause the program to fail. What's unique about the Year 2000 is that it is both the first time computers will have to cope with a new century and a new Millennium. Some of the things Morris says developers should watch out for are dates like 00/00/00, 11/11/11 and 9/9/99. Traditionally, the date, 9/9/99 was used by data entry staff to mark information which never expires. The date 1/11/11 was often used to label data as incomplete. 00/00/00 is a special case. Dates are often used in certain programming algorithms which require some form of dynamic value. "Computers have never seen the Year 00 yet," said Morris. He explained that there is a risk that certain algorithms could fail because they attempt to perform a division by zero. What matters for any Year 2000 compliance programme is effective testing. However, the PC is handicapped because, unlike the mainframe arena, there are still precious few tools for effective testing of Year 2000 compliance on a PC system. When testing a platform, the first task for a developer is verify its handling of BIOS errors related to the Year 2000. If the BIOS is okay, the next step is to test the way in which the application displays the year in each decade of 2000-2099. If the application knows about time zones, the developer should confirm operation when UTC (Coordinated Universal Time in English) is a different century than local time (both + and - from UTC). Next on the testing checklist is to test an application with 2-digit date entry and 2-digit date display both before 2000 and after. And when the entry/display is a date in the other century, both before and after that. Other aspects of the application to check include verifying entry/display of 4-digit dates and verifying the sorting of dates where some are before 2000, some after. It is also important to check the day-of-week before 2/29/00, on 2/29, and after (on 2/1/01). Some questions to ask when testing for Year 2000 compliance include: - Does your program do any "year ahead" calculations? Testing in 1999 may be critical. - What happens if you are networked to a machine with the wrong year? Or different time zone? - Can you backup before 2000 and restore afterwards? - Do you ever select a date range? Can the range cross 2000? - Did any previous version of the program store data in a file format where 00 or 99 meant something special (for example, never expire?). A developer also needs to find the limits to the date values the program accepts and determine any special test issues for the application. One consideration easily overlooked when testing PC systems for Year 2000 compliance is that simulating a point in the future involves move than just winding the clock forward. Car insurance is a prime example of where a problem will occur if the system date is moved forward for test purposes. If the clock is moved forward, someone with two years' no claims bonus in 1998 will have four years' bonus in 2000. All bonuses will have aged by two years, so it will be impossible to test the application for cases of two or less years' no claims bonus. Thus the application is not testing the same functionality. The data hasn't been synchronised and the test has failed. Tools such as Data-Ager from CompuWare enable data to be aged in specific ways or replaced in order to simulate the Millennium change. Another consideration is testing is hugely time-consuming and budgets or resources rarely stretch to allow for a complete testing scenario which involves testing production data through every conceivable date in 2000. So, organisations must start planning to reduce the test data. CompuWare has listed a number of dates that must be tested. These include 9/99/1999, 31/12/1999, 1/1/2000, 4/1/2000, 29/2/2000, 1/3/2000, monthly payroll, quarter-end, year-end. The average seems to be 8-10, although some organisation have identified in excess of 60. Testing can be very time-consuming but don't despair. It is more than likely that by the Year 2000, the majority of non-Year 2000 compliant PC applications will have reached the end of their useful life. Andrew Hammett, director at IT analyst, Bloor Research said that the life expectancy of most PC systems is very short and they have a high turnover. Many will have been rewritten by the Millennium. For those systems that are likely to remain, Hammett advises developers to determine which systems are mission critical, which ones really matter, and work to make these Year 2000 compliant first.
Apple, Samsung, Google and others rush to go ever-higher upmarket is putting off potential customers
Laser tech can charge mobile phones from across a room
AMD's Zen chip roll-out continues with the focus on high-power embedded applications
And becomes the team's executive chairman to boot