|
||
 |
||
|
| Can't They All Just Get Along? |
 Email This
 Print ThisView My Personal Library |
|
More Information February 1999 • Vol.7 Issue 2 |
Can't They All Just Get Along? Different Definitions Of Compliance Present Problems | ||
 It seems like another question on an already full checklist: Are your computer and your software Year 2000 compliant? You know, don't you? After all, you did check the side of the packaging, and you surfed the Web for any updates that will make you Y2K compliant. Don't jump the gun, though; what you thought was compliant may turn into a big complaint. Jan. 1, 2000, may roll around and you may be rolling your newly worthless PC (and all of that lost data) out the door. The confusion surfaces because there are many terms floating around that actually indicate different levels of an ability to deal with 21st century dates. There are also many hidden problems that can come into play when you don't know what "compliance," "compatibility," and "readiness" mean. Because many salespeople and even technical support personnel are not well-equipped to deal with the issues, your only defense is to become a well-educated consumer.  Untangling The Mess. The essence of the Year 2000 problem is that computer programmers and designers originally used two digits to indicate the year portion of a date because of the high cost of memory. That approach, which was reinforced by the assumption people would rid themselves of older computers within 10 or 20 years, became a habit. This was the approach used until quite recently, and worked well; that is, until people realized "47" could mean either 1947 or 2047. It may seem that fixing the problem should be easy; just have programmers go in and treat years as a four-digit number. That, unfortunately, is easier said than done. Problem program code, which many different people may have worked on, has often been around for years. Programs can have many date references, both in specialized commands or existing as data. The number of places that must be changed, and the difficulty of finding them, is exacerbated by the fact many programs are not well-documented, so when one programmer leaves to be replaced by another, a lot of knowledge about the program's structure also leaves. At this point, there is no one who knows everything about the programs who could easily go in and make all the necessary changes. Because of the difficulty of identifying all the places that need modification, companies are looking at finding easier ways to update their programs. The result is a potential pain in the RAM for users. A Different Type Of Window. Rather than changing all date references to four-digit numbers, a process technically known as date expansion, many companies are looking at other fixes that find ways of reinterpreting the data without changing the use of two-digit year references. In date windowing, the vendor assumes there are two different data windows, separated by a single year, for example, 1940. Under date windowing, years starting at 40 and running to 99 are assumed to be in the 20 th century. Years from 00 to 39 would be 21st-century dates. With data compression, the two-digit numbers are interpreted in another format, such as a hexadecimal number, where a two-digit number could represent anything from 0 to 255. The thought is that this could offer all the flexibility a company could use in the foreseeable future.
Know What You Are Getting. You may be noticing a pattern in all these approaches to the Y2K problem; they all essentially put it off for a period of time. Date windowing and a 28-year setback provide additional time, but that will eventually run out. Compression allows more time, but is still limited. In all these cases, though, there is a definite date by which either the "fix" will no longer work or will need to be modified to continue being effective. Instead of all products having the same deadline for corrections, the dates will be staggered. Though handling changes over a longer period of time should be easier in theory, tracking and managing the needs for all the different programs will be much more difficult. So, now you may be asking yourself: Just what do Year 2000 compliant, compatibility, and readiness mean? In short, it depends on what the vendor wants it to mean. There are some controls; for example, the federal government can mandate what terms must mean when selling products to the government. There is nothing, however, to force vendors to accept a standard vocabulary. Some people will say pushing the problem off for several decades will be sufficient, ignoring how such an approach has done nothing to solve the problem in the past. Even if you ignore the attitude that aggravated the Y2K problem in the first place, there are good reasons to tread carefully. Think about the number of different software packages you regularly use or the variety of different devices interconnected, for example, an answering machine, a phone, and a computer. When products are not isolated from each other, they can operate quite differently than they would running by themselves. As much as most people hate regulations, they do bring uniformity over areas. Because there is no regulation over solving the Y2K problem, vendors can approach the problem however they want, without considering how other vendors solve the problem. So, the date information stored by one system may be incompatible with the format used in another. The Data Crunch. If applications worked totally on their own, this may not be a problem. But many commercial software packages, such as contact managers, E-mail packages, databases, spreadsheets, and calendar products, are intended, at least in part, to work with other applications. That is where one type of trouble can occur. Look at some of the applications in a popular suite such as Microsoft Office 95. Though it is not the latest version of Office, millions of people are using it. Though Microsoft says the products are Year 2000 compliant with minor issues, those issues can wreck havoc. Let's start with Microsoft Excel 7.0. The product stores dates internally as the number of days past Jan. 1, 1900, so Jan. 1, 2000, is stored as 36526. This is all well and good, but there is a shortcut when users enter a date in a "mm/dd/yy" format. If "yy" is less than 20, Excel assumes the century is 20(yy). When "yy" is equal to or greater than 20, the century is 19(yy). Microsoft Access also stores dates to hold a four-digit year. When someone enters a date as "mm/dd/yy", however, "yy" is assumed to be 20yy if the number is less than 30, but only if a particular version of a certain file used by Access is on the system. If equal to or greater than 30, the program interprets the century as 19(yy). Again, this is all OK, unless you use Access and Excel on the same data. Suddenly you are faced with a situation where, under the right circumstances, a date entered on one system can differ by 100 years from a date entered in the other. So, you can work with both products, both of which can handle four digit years, and still have problems because of assumptions made during order entry. Using Access 95 and Excel 95 with an older version of Microsoft Outlook Express? Outlook Express, with Service Pack 1, stores full dates, but assumes years expressed as 50 to 99 are actually 1950 to 1999 while 00 to 49 are 2000 to 2049. In other words, with three products by the same company, there are three possible interpretations for date information, depending on how you have stored it. If you can have such problems with two-year-old software, all from one vendor, imagine the difficulties that could occur when the applications are coming from different companies, the data from many different sources, and there are no standards on how products and data must work together. More Hidden Problems. Another potential troublemaker is the leap year. Seems easy, right? Just count every four years. Actually, it's a good deal more complex than that. Leap years happen every four years, unless the year is evenly divisible by 100. For example, 1900 was not a leap year. However, 2000 is, owing to even further complications. This is because a year that is divisible evenly both by 100 and 400 is a leap year, so long as it is also divisible by 900 with a remainder of either 200 or 400. Confused? So are some application vendors, who may be miscalculating leap years. When looking at the degree of Y2K compliance offered by a piece of software, it is important to verify the product correctly calculates leap years, not just on the year 2000, but on a number of years after to ensure correct data-handling will continue. As you can see, talking about Year 2000 compliance as a condition that is either present or isn't can be misleading and troublesome. A better approach is to consider your system and all the applications that must run and interact. Set up a chart that shows each product, the approach the vendor takes for Y2K compliance, any relevant specifics (such as the number at which the data windows change centuries), and a list of the data sources that may be used with the product. Group products on the chart so those which interact are grouped together. For more information on preparing your PC for the year 2000, see "Fixing Y2K Problems On Standalone PCs" in this issue. Once this is all set, look to see where interoperability problems and data format differences will occur. No, it's not as easy as relying on a "Year 2000 Compliant" label from a vendor, but in the long run, it will work. by Erik Sherman |
|
Home Copyright & Legal Information Privacy Policy Site Map Contact Us