Scarecrow,
I've read Murhpy's Y2k proposal, thanks for posting.
Note that only the OS authors can make this solution work, if at all, and it's such a kludge that I very much doubt they'd be interested. One would imagine IBM et al has already considered and discarded most of this stuff out-of-hand. Or, they may be preparing various similar solutions as last-ditch band-aids for those clients who find themselves up against the wall -- but I wouldn't bet on it. The technical support and liability issues from such an offering would be formidable, even for IBM.
I admire Murphy's effort regarding this particular solution, but there are several additional, serious problems:
1) Data join problems. When these date fields are keys, the altered date data in these files will only be able to correctly join to other files with the same type of data alteration. All 6-digit date fields in all files and databases would have to use this same method to make joining of files feasible.
2) Data export problems. If the altered 6-digit data is passed to other systems, which is increasingly common these days -- e.g., data warehousing -- these other systems will not be able to interpret this data properly. This could be the case even if the target system is on the same machine if that system already has proper 8-digit dates, as the 8-digit programs won't be "identified" as using the proposed solution. Systems on other machines with different operating systems would plainly see this as corrupted data and probably abend. All these dates would have to be expanded on export, which, depending on the export method, may not be possible.
3) System utilities. All data transfer, copy, duplicate, filter, and query OS utilities would have to be "identified" as needing the date conversion or else rewritten to handle the "fix" natively.
4) User problems. Asking the users to remember and deal with the proposed odd character representation of the new decade(s) is something of a stretch. It's almost bizarre. They would likely begin to distrust their database and it's hard enough to instill and maintain that trust in the first place. It is one thing to have a work-around that, though technically marginal, is transparent to the end user. Under this solution, it's blatantly obvious the I/T staff is scrambling. Furthermore, occasional or remote users would have great difficulties. They would see very odd date data displayed. Attempting to enter transaction dates or report selection dates would be a complete mystery to them without full instructions in advance. How would these users know which programs within a system or which systems require the "special" characters to be entered before pressing enter?
5) Data exception "reliance". What if a 6-digit field just happens to have the "special" character in its first position, but it's not actually a date. Though a low probability occurrence, it is possible.
6) Internal date manipulation problems. Adding and subtracting these altered date fields is fraught with peril. What if the date is moved to another "work field" within the program and this work field is not 6-digits? The revised data exception handler would not convert this work field. The program would crash right there, as the "work field" would be defined numeric and would not be able to accept the character data of the altered date. Now we're back to scanning all the source code, if it exists, for these instances, which could be quite common. I've seen programmers do some incredibly convoluted date manipulations over the years. Some of this code would certainly fail under this proposal.
7) Data input hardware problems. Most non-programmable terminals (NPTs) will not cooperate with this solution. The "o" with two dots over it is not a valid character on the keyboard. Most input screens on these systems have the screen's data input area defined numeric. This would require new NPTs, special keystrokes, rewritten I/O controllers, and/or ??? Furthermore, and more seriously, the screen representation is usually NOT YYMMDD (as it is on the database), but rather (though not always!) MMDDYY or DDMMYY. Murphy's solution dies, as the special decade character on input screens is not in position 1 but in position 5!
8) Testing. The testing effort will be hampered by the unusual data presentation more so than it would if the dates were displayed properly.
9) Customers! How would you, as a customer of a company using this solution, like to receive an invoice with these weird characters on it? Would you feel comfortable with that vendor? Would you even known when to pay the invoice?? Would this invoice be a proper tax document??? Would the vendor have to send out "instructions" to its customers explaining how to read the unusual date formatting????
Obviously, this list is far from comprehensive, as I can only point out those areas where I have direct experience or know enough to be at least partially dangerous. Every Y2k "fix" I've seen, so far, short of proper code remediation, has numerous undesirable side effects, some of which, if discovered well after the fact, could be quite disruptive if not disastrous to the budget and/or time-line of a Y2k repair project.
Any "fix" has to be thought through VERY thoroughly and VERY carefully, and then thought through again. Then it has to be given to other technical and user teams for their rigorous inspection and then thought through some more. The relevant vendors should be solicited for opinions as to whether the "fix" is workable and is without side effects.
Part of the problem with Y2k progress and, by extension, its increasing seriousness, is that many companies appear to have waited around for a "magic-bullet" to materialize that will take care of everything. IMO, it's just not going to happen. The only reliable, practical way to fix Y2k on the software end is to just sit down and do it, at the code level, as a regular maintenance project. The sooner it gets re-coded, the sooner it can be thoroughly tested. |
