|
|
 |
|
|
|
|
printf ("%2d", tm->tm_year); |
|
|
|
|
|
|
|
|
which will overflow into three characters. |
|
|
|
|
|
|
|
|
Another C example comes from the library of a major vendor. The code converts the year to string form assuming a range of 00 through 99 for tm_year: |
|
|
|
|
|
|
|
|
*s++ = '0' + tm->tm_year / 10;
*s++ = '0' + tm->tm_year % 10; |
|
|
|
|
|
|
|
|
which produces rather odd years in the output string for input years exceeding 1999. |
|
|
|
|
|
|
|
|
Most of the code affected by Y2K is written in COBOL, simply because many of the affected applications are business oriented and were designed in the 1960s and 1970s when COBOL saw proportionally more use. FORTRAN, PL/1, and assembler round out the top offenders. Not surprisingly, then, Y2K bugs have been found in virtually every programming language. |
|
|
|
|
|
|
|
|
Legacy systems. The impact of Y2K is even greater because it infests the older systems that form the core of many business information systems the old accounting packages, payroll, and so on. These systems are essential work horses that were often written decades ago and have not been seriously maintained based on the theory that "they ain't busted." Because of their age, these systems have some special problems all their own: |
|
|
|
|
|
|
|
|
In many cases, no one now employed, or even living, knows how they work. |
|
|
|
|
|
|
|
|
In some cases, the source code for the systems is nonexistent. |
|
|
|
|
|
|
|
|
In a significant number of cases, the systems exist in digital limbo because the shop runs a language that has been abandoned by the vendor. OS/VS COBOL is, of course, a prime example, having been declared dead for more than ten years by IBM. Some estimates have up to 40% of IBM mainframe shops still running this language. |
|
|
|
|
|
|
|
|
In truly ancient applications, the language of choice was assembler. The sheer variety of hardware-specific flavors, the lack of documentation characteristic of the period and the difficulty of maintenance make these systems very difficult to modify successfully. |
|
|
|
|
|
|
|
|
Emulation. A not uncommon solution to mainframe hardware upgrades in the early days was emulation. Rather than rewrite essential software, shop programmers would write software that "emulated" the old machine on the new, allowing the older software to run unchanged on the new machine. War stories occasionally are told in which the source of unexpectedly slow performance on a new machine is traced to successive shells of several emulators wrapped around the offending software, each emulating an earlier machine. In this environment, it is not clear at all what constitutes a fix. |
|
|
|
|
|