Don't take this wrong (well, ok, you can if you want) but... Where in God's Name do people come up with things like this???!!! This is a kind of Chicken Little thing. It really is.
I have been dealing with computerized systems since the 1960s - and yes, I consider myself to be relatively knowledgeable. The short answer is 'no'.
The longer answer is that it doesn't pass any kind of reasonability test. First, there are no database management system or file input/output systems that depend on something like that; because it wouldn't work. Therefore, systemic problems are impossible.
The kind of environment in which it MIGHT occur is in those limited circumstances where, actions such as merging two files together are occurring (this is an example); and the merge was based on dates in the records of the files being merged - nothing else - just dates. Common cobol logic might be something like
READ FILEA AT END MOVE ALLNINES TO INPUT-RECORD-A.
.
.
READ FILEB AT END MOVE ALLNINES TO INPUT-RECORD-A.
There is a whole lot more logic involved, but the relevant point is that this is the only slightly reasonable circumstance I can see to which you allude. (I used to put 'high-values' into the record - a character that was higher in value than any other character - including the number 'nine'. And, I never tested a numeric field. Some others did this; and even others set switches. Some Assembler programmers tested an 'eof bit' {that really takes me back} Back to nines...) Now, If I were matching on the entire date, there would be nines in the month, nines in the year, and nines in the day, wouldn't there? And my end-of job test would be to see if the entire date field (as likely the entire record) were 'allnines'. There is no legitimate date with all nines, is there? So. Even if '99' were in the year, the rest of the test would fail... And, oh by the way, the relevant test would need to be on the year only - no other field in the record - not even the rest of the date...
The only time there might be a problem is if there was a specific test on the year field as a signal for some other special action that was dependent on the number '99' in a year field in end of file processing - but end of file processing can't be gotten to through that path unless the sole test for and end of file as '99' in the year. How likely is that? Not very, I think. Lets even think of how often files are merged or processed with the 'date' as the only criteria... Not too many. Social Security and IRS processing is most likely against social security numbers and taxpayer IDs, correct? Well, ok, nines in a year field wouldn't likely cause problems there. So, what's the problem??
Having said all that, there are millions of computer programs in this universe and I can guarantee that somewhere, there will be a computer program that will have a problem. In the bowels of the government. Maybe in the bowels of private industry. That's what we call a bug... Probably at the same level of severity as the other bugs in all those computer programs out there - and with the same likelihood of occurrence. But a systemic problem? Nope.
Hope this helps. |
