Y2K is far a complex problem as to be explained on some few WEB pages, even so it is worth to try. A good way for handling Y2K problem is to divide it into little pieces and letting every user to fit in the puzzle.
There is an important segment in computer industry which will be affected by Y2K problem, even so I prefer not to discuss the matter because lack of experience in the field. This is the case for microprocessors having some kind of assembler date instructions stored into ROM memories. These tiny devices are widely used in most different places, from talking little dolls to multiple war heads nuclear weapons. Sincerely I don't know what would happen whether one of these chips a long ago programmed carrying some wrong instructions into. We can imagine the every possible scenario, and can only hope these professionals who programmed the devices were no angry against boss (or wives/husbands) at the moment of working on.
Just to know what it would happen case some fault, I tell that some UNIX versions will fail at 3:14:08 AM on Jan. 19 2038, coming soon 8:45:52 PM Dec. 13 1901. Why? Because initial date in these systems is referred to Jan. 1st 1970, and internal clock is 32 bit register. Since register uses 1 bit for signal and every "tick" is one second, these systems are time bombs ready to explode at 2^31 = 2147483648 seconds (translating to human language this means 68 years, 0 months, 19 days, 3 hours, 14 minutes and 8 seconds - leap-years included), as you can see here.
When thinking different devices instead UNIX machines could become crazy because having only two places for years, it brings us some idea about the complexity of this problem.
For more common computer systems, problem can be divided into:
A) OPERATING SYSTEMS (OS)
B) MADE IN HOUSE MAINFRAME SYSTEMS
C) PURCHASED/RENTED MAINFRAME SYSTEMS
D) MADE IN HOUSE MICRO SYSTEMS
E) PURCHASED/RENTED MICRO SYSTEMS
For any above related categories, Y2K problems can appear, and probably when older the system better the chances for some problem to appear.
A) OPERATING SYSTEMS (OS)
There is not much to do here when some fault discovered other than preventing the problem and changing the fastest possible way to a new version of OS, like the UNIX 2038 case.
Since Operating Systems are generally developed by specialized companies (sometimes the same hardware builder), user nothing can make to correct the problem using programming tricks because source codes lacking.
How to detect a possible flaw on OS? The most single response is: set machine clock to 11:59:30 PM Dec. 31 1999 and wait 30 seconds (please try with MS-DOS). If clock turns ok to Jan. 1 2000 probably you are safe from THIS problem.
Why a flaw on computer OS could affect business systems? Because most systems take calendar information from machine clock through internal calls. How account payable systems know some credit was performed and registered on cash at 12:23:55 March 5? Because it asked to OS using some internal routine, then it is easy to imagine what would happen if computer clock disrupt on Jan. 1st 2000. From this moment on all transactions (maybe millions) performed in the machine will go with wrong dates, and you can imagine the work later to correct this mistake.
B) MADE IN HOUSE MAINFRAME SYSTEMS
In this case user holds programs source codes and so can detect AND correct errors, although at times this correction being expensive and time consuming. Why and how much this could cost you can see here.
How to detect some possible error hidden under complex systems composed by thousand files and programs?. There is no easy answer for this question. Mainframe systems sometimes execute very few on-line transactions (those where people type intensively on screens), and rather they care of high volume data through batch processing procedures. Most of these systems won't find the classical problem of "extending two places on screens to write 2000" but they will find another kind of problems in the form of hidden routines to date treatment into big public libraries, JOB processing batches long ago programmed with forgotten dates embedded into, maybe date fields where no places to store 4-figures years.
Some basic procedures could help to detect problems:
- Whether Data Processing Center (DPC) has some active Data Dictionary, (where info about data is stored along with places where data is used) your task will become much easier, since it is a matter of asking to Dictionary which files have date fields with only two figures for year and soon which programs access those files. With this report of files and programs to correct (that could be a very big one) it is possible at least to know what you need to modify, how many times it will take and how much it will cost. (sometimes it is cheaper to program entirely a new system).
If your DPC has NOT a Data Dictionary, just to know what should be modified is frightening task. Probably you'll need to make a survey into all DPC verifying which files and programs need to be updated. This is a handled task and possibly exposed to expensive failures.
- After getting these files containing dates, try to verify possibility of rewriting new 4-figures-year dates in same place old dates occupied, avoiding this way data shifts into file. Sometimes old dates are in uncompressed "mm/dd/yy" form (where just one byte is used to store digits 0-9). Verify possibility of storing new dates in the same previous space by using some new compressed form, because this way you will avoid to modify file lay-outs (and related programs).
- Make a research seeking all routines for date treatment into DPC. Normally routines are stored in public global libraries so programs can refer to when compiling and linking. Probably you'll find into this global directory some routines to compute difference between two dates, to calculate day of week, to know holydays by region / country or even routines to sort dates.
- After collecting those routines, write a set of programs to call them repeatedly passing along different dates, verifying on every case if answers are ok. By instance, on those routines that compute difference between dates, make a "tooth-comb" calling for every day of 1999 and verifying the difference with the same day for year 2000 (Jan. 1st 2000 minus Jan. 1st 1999 = 365 days, Jan. 2, Jan. 3... and so). Verify that from March 1st answer should be 366 days instead.
For routines that compute the day of week make several calls using random dates from year 1999, 2000 and 2001, verifying if days of week are always right placed. (For instance August 20 2000 SHOULD be Sunday).
Whether some week day is misplaced, you should verify what the formula used is. If all routines are working properly, then is highly probable all programs calling them also will work properly, although some programs could have mislead rules and programmers used routines from themselves instead public ones.
Try to contact the COBOL compiler seller (or whatever another language) you are using. Sometimes a little modification inside the compiler could save millions headaches (and Dollars) to you. Sometime it is possible to modify the compiler to use signal bits (+/-) normally not used on dates like being a mark for XX or XXI century (for instance -01/01/99 = Jan. 1st 1999, +01/01/99 = Jan. 1st 2099).
- Verify the possibility to program a central "watchdog" routine to smell automatically all ASCII files crossing the environment (generally used to transfer temporary data) and warning whenever some transfer file is going with "mm/dd/yy" format instead "mm/dd/yyyy". A transfer of this type could lead to failures on year 2000 by passing dates "01/01/00" to inattentive systems.
- Build a tiny system to care about "Y2K problem", recording into what problems were detected, where and who solved them and whom to contact for emergency.
C) RENTED/PURCHASED MAINFRAME SYSTEMS
In this case DPC does not hold source codes to correct, and the most could be done is to detect problems in advance, communicate to software vendor and hoping they will correct it at time.
The only way to detect faults here is to running the system on critical dates, creating a special "Y2K" environment into machine, starting clock at Dec. 31 1999 (or whatever earlier date) and executing all possible tasks in this environment, taking care on what happens when clock turns to next millennium. If system shows in some places on screen the day of the week (Monday, Wed. and so) put random dates into machine (for instance Jul. 5 2001, Oct. 14 2000) and verify if days of week are all correct. The right synchronization between days of week and dates is a strong signal that system is consistent with dates and is safe from faults (for instance if you set the clock to Jan. 1st 2001 and verify it is Tuesday then you know the system believes it is Jan. 1st 1901 because the correct day should be MONDAY, and so you know something wrong is going on into the machine).
A good idea is to be in communication with other users of same system through User Groups (probably the same dealer who sold the system to you also sold it for other people), so to be updated about coming problems and solutions. To remain alone in this problem is a high risk business.
D) MADE IN HOUSE "MICRO" ORIENTED SYSTEMS (most IBM-PC compat.)
Most procedures already commented to "mainframes" also apply to "micro" computers, since most of them are linked through networks into the company. This way there are probably public libraries to store routines and those routines can be also checked same way.
The "micro" universe diversifies in the moment that every machine acts also like an independent workstation, executing programs and routines that could be impossible in "mainframe" world, like spreadsheets, Desktop Publishing or CAD stations. These functions expend high volume resources (CPU time, memory and so) and would be difficult to execute in a centralized machine with hundred users sharing resources, because each user should receive a bad average response.
Since each "micro computer" beholds own CPU and memory (which are very powerful today), the intensive use of some number crunching application is almost unnoticed by neighbors, but in other way this raise a wide quantity of interfaces and conduits with other applications in the network.
Think for instance in some workstation executing a spreadsheet and generating a temporary file to food centralized mainframe system. This file could contain dates, and people who created the file in the micro environment could be careless with dates, so this file which will food another centralized files could carry some "03/27/99" or "02/15/00" because user forgot to update date masks.
The danger in these applications is into the great freedom each user has to generate data which will food the network, and this freedom could unleash a chain of faults whenever transfer data masks are not correct.
A reasonable norm is to establish some date limit to use old masks (for example Oct. 1st 1999), and after this date no "mm/dd/yy" masks should be accepted on network for data transfer. It is not impossible to program a watchdog routine hidden into the net to verify all ASCII files with "nn/nn/nn" data into. Think the possibility of substitute the "copy" or "move" commands by more intelligent "copy/move" commands.
For systems built around DBMS (Data Base Management Systems) like Oracle, Access or dBase-like special attention should be pay to relationships established via date fields. Sometime user could correct the date field into main tables but forgetting to correct related tables.
Since "micro computers" are frequently used for on-line data input (that is to say, a person typing all the time onto screens), a great part of effort should be taken to reformat input data screens so to change the "mm/dd/yy" old format to the new "mm/dd/yyyy" one.
Here a little hint for alert: don't go so fast to change ALL screens to new format because some solutions could be a lot better, easier and cheaper, for instance:
a) To let old format untouched, updating only the internal procedures to understand "1900" for numbers above 50 and "2000" to numbers below 50 for incoming dates.
Please note this solution is very interesting because you'll save two characters for every date (a saving that could represent money in massive data input) and your system can perfectly store complete dates into computer using all four places for year.
b) To let old format for all display-only fields (that's to say, those dates that are not entered but just displayed). Here, it is better to let dates in old format because you are going to save two places on screens and reports.
E) PURCHASED/RENTED "MICRO" SYSTEMS
In this case warning for mainframes also apply. Often it is not possible to correct the problem because lacking of source code, but it is possible to PREVENT some problem will occur in advance and inform software vendors to correct the fault.
Micro systems are easier to check because date changes in OS like MS-DOS or UNIX are easy to perform, so it is cheap and easy to let one or two isolated machines running applications with clocks set on critical dates with no disturbance for current applications.
On those systems that work on DBMS like Oracle, Access and so, check if sorting or indexed fields are ok by printing reports with mixed 1999 and 2000 dates (that's to say, first should appear 1999 dates). This could appear to be obvious but remember that not all indexing fields use entire dates for sorting processes. It could happen dates are ok into Data Base but not properly referred into indexes. If you cannot handle indexing procedures to correct the flaw then contact people who developed the system.
If you want to know what will be next millennium computer, I invite you to know The Song of the Swan
