Preparing for the Year 2000
One of the hottest issues today is preparation for the year 2000 (Y2K). Tremendous resources are being expended to bring old programs into compliance and replace older systems that cannot be upgraded. The Gartner Group has estimated the cost of renovation for the U.S at $300 to $600 billion, with the government alone spending $30 billion. The pending deadline has led to a national shortage of computer programmers along with sharply rising rates. Although a boon to staffing services in the IT arena, many companies are unable to recruit the resources required to update all of their systems and are now having to decide which mission-critical programs will be upgraded before their failure brings business to a halt. Current thinking is that 30% of today's businesses will not survive the year 2000 transition.
So, What's the Big Deal?
The classic explanation of the Year 2000 problem involves the decisions by programmers, many years ago, to express all dates using only two digits for the year. So, for example, the last date of this year would be 12/31/98 and the first date of the year 2000 would be 01/01/00. Unfortunately, that is the same as the first day of the year 1900. The result of entering such a date may lead to various behaviors, ranging from incorrect calculations, such as an accounts receivable aging that is 100 years old, rather than 10 days, to total system failures, such as an assignment that starts mid-year and is expected to last for over six months, resulting in a date that the computer cannot store in the allowed space. Even for newer programs, where the year 2000 was anticipated, there can be other limitations due to the language in which the program was written, or the type of storage used for dates. Some programs store dates as a simple number, with zero being some date (usually chosen by the programmer or defined in the language) in the past. Although the year 2000 will work, once this number gets to a pre-determined size, the computer cannot store it, with the same consequences as the year 2000. For example, if the number field used can store numbers from 0 to 32767, and the number zero represents 12/31/1967, then the last date the program would be able to store would be 9/16/2057. Although this will be sufficient for most applications, a mortgage calculation program using such a language would fail in the year 2027, as the dates could extend out 30 years, surpassing the limits that were built in. Many systems have such built-in limits, as they were designed either with the attitude that they would not be in production that long, they would be upgraded before then, or that the programmer wouldn't be there then and would leave the solution to future employees.
A further problem is that the year 2000 is a leap year. Many people, including programmers that should have known better, are confused about when century years are leap years. Any year that is evenly divisible by four is a leap year, unless it is also evenly divisible by 100, in which case it must also be divisible by 400. Still confused? Essentially, this means that 1900 and 2100 are not leap years, but 2000 is, as it is evenly divisible by 400. Many computer systems, as well as the programs running on them, even new systems, do not properly handle leap year. While this may mean that the computer will simply skip 2/29/2000 and you will have to put up with having 3/1/2000 two days in a row, the programs that you run may encounter more serious problems. These can range from refusing to allow entry of orders or payroll on 2/29/2000, to a refusal to accept valid week-ending dates after 2/29/2000. For example, using Saturday week-ending dates, 2/26/2000 is the end of a week, and 3/4/2000 is the end of the next week. On a system that does not include the year 2000 as a leap year, 3/5/2000 would be incorrectly reported as the next week-ending date, and all weeks thereafter would be off by one day.
What is affected
Mainly linked to computers and the information technologies field, this issue also affects other areas of your operations. Businesses will need to evaluate their fax machines and phone systems, as well as computerized time-clocks and other systems that may use dates, for handling of dates past 12/31/1999. In addition, interfaces between systems, such as general ledger and direct deposit, may need to be updated prior to 1/1/2000.
Typical functions that may be affected in a staffing service are the ability to take an order, properly calculate a payroll, print a check or invoice, calculate aged receivables or determine the interest on a past due account. Other systems that may be affected include any automatic backup programs, your network operating system, such as Novell Netware or Microsoft Window NT, and your desktop operating system. Novell Netware 3.2 and 4.11 are compliant, if the latest patches are installed, but other versions are not and must be upgraded. MS-DOS/PC-DOS, for example, is not fully Y2K compliant, but IBM has issued a patch for PC-DOS 7, with recommendations to upgrade to that version on all machines still running DOS. Windows 95 also has some portions that are not fully able to function in the year 2000, such as the Find utility and the Windows Explorer. Other Microsoft applications have different issues with both the year 2000 and date limits of the software. A web page maintained by the company, located at
http://www.microsoft.com/CIO/articles/Y2K_issues&solutions.htm, summarizes possible problems that may be encountered and how they may be corrected.Testing your existing systems
There are several programs that are available on the Internet to test computer hardware for year 2000 compliance, including leap year handling. For PC-based systems, two such programs may be downloaded from NSTL or the Small Business Help Shop (see search.html for a list of Year 2000 related sites). Be aware, however, that there is some risk involved in testing the hardware, as some older systems will fail in such a way that they will need to have their BIOS replaced if the year exceeds the internal limits.
Testing of software systems, however, is more complex. First, check with your vendor for their level of compliance or their schedule for implementing updates. If this is not possible, or you have been assured the system will handle the year 2000, you are ready to manually test your software. Generally, you will need to create a copy of the system, or do your testing on a weekend after making a good backup and plan on restoring everything after you are done. To perform your testing, set your system date forward and make sure you investigate every portion of your software, from input functions, to payroll, invoicing and reporting. Test for year 2000 handling with your system date set during 1999 and 2000 and for proper handling of leap year (2/29/2000). Double check any date calculations or aging for accuracy, as well as simple input handling. Once you are finished, remember to set the date back on your computer, and restore any critical files. Some systems may crash upon testing and have to be restored in order to function, while others may appear to work, but will not correctly calculate date ranges and aging.
What do I do next?
For existing computer hardware, contact the manufacturer to see if there is an update available that will allow the machine to work after the year 1999. Otherwise, plan on replacing the machines at least six months before they will fail. As the deadline approaches, many businesses are planning year-end purchases in 1999 and supplies will be limited in many categories. With software, again plan on upgrading as soon as possible, where necessary. Not only do you want to avoid any last minute rush, you will want to ensure that your business does not run into problems with orders that extend past the year end during the coming year. Most software upgrades will not be covered by your current contracts, although you may want to check to make sure, and may require upgrades of your system hardware for implementation. Early planning can eliminate the sticker shock, as well as help ensure you do not get charged premium rates, for emergency upgrades that are done at the last minute.
For all new systems purchased, make sure you get assurance of year 2000 compliance and test to make sure that everything will work. The US Air Force recently received an order of hundreds of personal computers that were supposed to be Y2K compliant, but failed upon being tested for handling of leap years. Although the upgrade will be supplied at no charge, every one of the machines will have to be upgraded to the new software level. A minor annoyance on two or three pc's can quickly become a major upgrade project when many machines at many offices are involved.
Karen D. Oland
Staffing Technologies, Inc.
8851 Highland View Road
Knoxville, TN 37938
http://www.staffingtech.com