Y2K problem *every* year hence?

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

I was looking into some cobol code fixes the other day and was surprised to find that the examples given aren't really fixes; they are put offs.

One specific method was to create an if/then for the year. If the year was >96 then 1900 was added to it. If the year was =<96 then 2000 was added. Egad! How very expeditious!!

That delays it for 99 years and some would say *that's* far enough in the future. I guess because they'll be dead by then. But, what about data bases where the age of people comes into play? The oldest person would require the pivot be somewhere nearer 25. That's only 26 years away. Isn't that the old same-o same-o?

Other requirements in other situations will require any number of pivot points. That spreads the y2k problem all across the next century raising more havoc at every new year and Joanne's effect becomes a constant migrain.

Tell me this type of thing is being done in just an extreme minority of the cases. If not, then I can can make go out and make lots of money too. :-)

Me.

-- Floyd Baker (fbaker@wzrd.com), January 08, 1999

Answers

Hey, if "pivot dates" are good enough for all the Microsoft crap, it should be good enought for us, right?

Any of you Access and Excel application users -- are you SURE your stuff (programs/data tables) is really fixed?

I wouldn't be.

-- vbProgrammer (vbProg@microsoft.sucks), January 08, 1999.


If the coders are so pathetic as to hard-code 96 as a pivot date instead of a variable, say PIVOT_YEAR = 96, and some documentation to say what it's for: yes, there will be Y2K-like failures every year. I guess that if you pay peanuts.... Also, what I've heard is that start-of-year failures are not uncommon. Trouble with 2000 is that there's a load of century-specific failures inbound, as well as the usual end-year and start-year glitches that get routinely fixed-on- failure. An awful lot of them.

Excel's internal date storage doesn't have a Y2K problem. It does allow dates to be INPUT (and displayed) with two-digit year fields, using a pivot date. This seems fairly safe, at least for things that are guaranteed never to be displaced more than a decade with respect to today. The real nightmares with Y2K will attach to big-computer databases where the data is actually STORED as MMDDYY (or DDMMYY or YYMMDD). You either have to completely reformat the database and rewrite the code to match, or graft windowing into a code that originally didn't have it. Both are likely to be error-prone and in need of the sort of extensive testing for which precious little time is left!

-- Nigel Arnot (nra@maxwell.ph.kcl.ac.uk), January 08, 1999.


"Windowing" is very widely used in the industry. I have been on two projects and I have seldom seen where it is not used. The reason is it is much easier to code a simple IF/THEN statement than it is to reformat all the databases and redefine all the variables. It is actually much easier and quicker and when you are on a strict time schedule, you do what ever it takes to get the job done IF IT WILL WORK.

That is the question, for most internally develop systems, it will work. Obviously, for systems in which birthdates or historic dates are used, a four digit expand is used.

The biggest concern you have is when the pivot years don't match. Consider this, If Mainframe system A has a pivot year of 50 and it puts data into flat file that is downloaded into a text file with two digit years and that file is hense imported into Excel to do some number crunching and then exported into a text file and then into a database, say Oracle, YOU HAVE A MAJOR PROBLEM!!!

The first step of the text file being imported into Excel will mess up with years between 29 and 50. While the mainframe application inturrupted these as 2029-2050, Excel will convert them to 1929 to 1950. You get the same problem when you export it back to a text file and then into a database. Believe it or not, even different versions of Excel and Access have different pivot years.

Is this "BRIDGING" done on a wide scale. One word YES.

MB

-- Matthew Bonner (Bonnermc@hotmail.com), January 08, 1999.


Right on, Matthew, regarding pivot dates not matching. I have seen this first hand. The most commonly used year boundaries are 49/50 or 50/51. In a large company that has lots of internal application interfaces this whole thing can cause serious trouble, mostly due to a lack of communication between staff members as to what specific values they have implemented in pivot logic. IF app A uses a different value than app B or app C, and they share data/feed each other, you have just corrupted the app and reports/queries will run but produce erroneous output. If you are running cross app reports (resulting from multiple feeds from different apps into the same database), this can really get interesting, since you also need to id where the bad data originated before it got loaded into the DB.

The easiest way around this is to at adhere (internally) to a standard, but I probably do not have to tell you that this is sometimes not done, even in large shops. Also, I have seen two cases where "waivers" were requested to use a different pivot date due to the functionality of an app, so even when a standard is being used there may be valid exceptions.

-- Rob Michaels (sonofdust@net.com), January 08, 1999.


This strikes me as a case of people not learning from their mistakes and heading to repeat history before the calamities have even happened. Programers knew 35+ years ago that 00 would be a problem in 1999 but did it anyway, giving reasons such as "these programs will be obsolete and replaced" or "it's far away in the future, we'll be retired or not around".

Now they're delaying the current problem 99 years or less. Probably without leaving comments in the code to help programers at the end of the century. (Yeah I know, COBOL won't be around next century...*snikering*)

-- Chris (catsy@pond.com), January 08, 1999.



And what is particularly sobering with the windowing approach is that, due to all the different choices on pivot points, we are essentially planting little "time bombs" just waiting to go off at various times over the next century. At least Y2K problems are reasonably bounded around the year 2000. This is going to be potentially like Y2K in 3D!

-- Jack (jsprat@eld.net), January 08, 1999.

Jack: "Y2K in 3D" - LOL. You know, we look at Y2K from so many perspectives: the entire globe, individual countries, regions, industry sectors, specific companies, and as in this thread, internal conflicts within the same company. No matter how I look at it, there is one statement that I feel comfortable with, and that is: It's a mess. I have posted this before but will repeat that I think of Y2K as a billion piece jigsaw puzzle without any edges, and with half the pieces missing. Now lets put the puzzle together, one piece at a time.....right, uh huh.

-- Rob Michaels (sonofdust@net.com), January 08, 1999.

And all the pieces of the puzzle are painted black.

Me.

-- Floyd Baker (fbaker@wzrd.com), January 08, 1999.


And half of them are going to be found, one at a time, over a period of years, well past the century rollover. Think I'll take my 'last' vacation with the family this spring.

-- Rob Michaels (sonofdust@net.com), January 08, 1999.

Floyd,

Yes, that type of fix isn't as good as going to all four-digit years. There's a lot of that sort of shortcut work going on in order to get software Y2k-sort-of-ready-for-a-while. And this will indeed mean that such software will have to be fixed yet again sometime next century.

OTOH, for many the situation is that it is now too late to fix all Y2k problems before they will cause trouble. That being the reality, there have to be tradeoffs between amount of software fixed, lifetime of the fixes, magnitude of changes (bigger changes leading to greater test requirements and larger risk of secondary bugs). In some cases, the most efficient decision, _for the purpose of avoiding disaster in the next year or two_, is to insert a simple fix that will have to be revisited a few decades in the future.

All Y2k fixes should be documented such that they can be reexamined in an efficient manner once we're past the imminent mess of the next year.

-- No Spam Please (anon@ymous.com), January 08, 1999.



NSP, that makes very good sense to try to avert the iceburg right now. Will they revisit the temporary fixes though? Are we simply headed for for reduced quality of life due to the "machine" being broken and patched up, braking down often in the future? Wouldn't it still be TEOTWAWKI, according to my definition on another thread?

I like asking questions, my school mates hated me for it though.

-- Chris (catsy@pond.com), January 08, 1999.


Lot of good posts above. What they are saying is that it's gonna be a Y2000, Y2001, Y2002 ... Y2049 ... Y2080 ... problem.

The basic problem is that the complexities of technology have gotten way ahead of the average person's (especially including pointy-haired bosses) ability to understand and deal with. It's even becoming too complicated for even people of above-average intelligence and skills.

The rule in industry has been that there's never enough money to do something right the first time, but always enough money to fix it ... over and over again. Will there be enough money this time?

I'm old enough to evaluate our technology changes since the 1950s. The 1950s and 1960s were VERY comfortable. The only thing I would miss would be air conditioning (rare then). Also vitamins. May not live quite as long, but we all die anyway. And, there was a thing called leisure, then. Didn't have to spend additional hours a day playing "keep-up" in addition to job.



-- vbProgrammer (vbProg@MicrosoftSucks.com), January 09, 1999.


A hard coded pivot year is ludicrous. Any pivot should be gotten from an exterior source. With bookeeping and other look-back applications, it could be as simple as reading the bios and keeping the pivot floating 1 year in advance of the current year. It would have to be kept at the current year until after 2k, then changed with a patch or default field. A provision for the actual four digit year, for future use, should be started at the same time so that there is a method to change to, once all the old incomplete data is used up or the records can be updated. In fact, this new method could be made to integrate itself as time went by. That would be good for 99 years.

Provisions should be made in data bases wherever possible. If not able to actually lengthen records for the century columns then most db's have spare columns or columns in use that should be made usable. It would be fairly easy to decide which data could go for the more important use of y2k compatibility. They would be kept clear of data to represent 19 and a number would represent the century. The number would be input only on records that recorded dates in the 21st century and beyond.

A single column would be all that is needed. It would contain nothing to represent 1900; a 1 for the 21st century; a 2 for the 22nd; 3 for 23rd, etc.

The columns don't need to be next to the existing year either. Just somewhere in the record and relate to a specific existing year field via programming. The program would be able to access those columns just as easily as looking as hard code and of course you would have to find a seperate column for every seperate occurance of a year field within a record.

Now, that's a putoff that would last a thousand years. Me.

-- Floyd Baker (fbaker@wzrd.com), January 09, 1999.


Floyd:

You're suggesting yet a different B.S. patch. It ain't gonna fly. There comes a time when it is necessary to clean house -- throw out the old couch and get a new one, to put it into maybe more familiar terms.

The programming required to look up that table for the century would be just as much hassle as to FIX IT RIGHT!!

-- prog (prog@prog.com), January 10, 1999.


I'm certainly not adverse to fixing it right but a put-off that's good for a thousand years isn't exactly chopped liver either. Especially when everyone is saying there isn't time to do it right and they're throwing hard coded pivot years into programs. No tougher to code either. Just get or put the column value instead of reading the hard code pivot. My solution would be light years ahead of the hard coded Willy Westinghouse approach. In one thousand years, we won't even be using conventional computers with data base records, etc. We'll be growing some kind of organic, biological, silicon, (new material), super intelligent, androids to do our work for us... Right? :-)

With this method the input or read routines would handle the century number and not the operator. The operator would only see/input the normal four digit year the same as with "doing it right". With either inputting or reading, the program then looks at the four digit year as two seperate parts. The left two digits get converted to or from a single digit representing the century. This is not much different than using the concept of a month that is part of the year. Here the year is part of the century. This is not only a relatively quick fix but it saves a column in the process. The only real difference is that the columns would be seperate from each other. No big deal. There is no need to have four columns side by side representing the year and so, in effect, this would be a 99% equivalent to fixing it right.

If we got through to the end of the 1000 year put-off and this program was still in use, it would be a simple matter to convert the reading of the century column to base 16 or even 36, using alpha characters. This would give us another 2600 years.

We're not going to worry about the y5.6k bug.

If we did, there are still a slew of other printable characters available.

Me.

-- Floyd Baker (fbaker@wzrd.com), January 10, 1999.



Most "areas" (text box, inout boxes) for inputing dates and other types of data have coded (or "clicked") "formats" or "templates".

Ditto with displaying non-editable info.

Ditto with printing in reports.

Also -- Spacing in screens and reports has to be modified to get, display, and print four digits for year instead of two.

All this is programming

-- Prog (prog@prog.com), January 12, 1999.


Moderation questions? read the FAQ