Out of Time?

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

I don't think we are in as awful a financial situation as some people think, provided we use our heads. (There is no denying Y2K is a hell of a situation.)

I have written a paper "Sort of a Silver Bullet" which is on my Web site http://www.crosslink.net/~erington

E-mail responses are welcome: petere@ricochet.net

I am not trying to sell anything.

-- Peter Errington (petere@ricochet.net), December 30, 1998


Peter there are numerous problems with this. Below are are few.

Birthdate is a problem. 100+ is required.

System date is a problem (CURRENT-DATE).

Financial transactions with a look ahead of 30 years is a problem (mortgages, bonds, etc).

Hard coded dates are a problem (every line in every program must be examined for hard coded dates).

Every date in every file/data base in every system would have to be identified (large task in itself). Conversion programs would have to written to shift the date taking at least 130 years into consideration (leap year, days of the week, etc.) and decoversion programs to convert back to real time. This effort would have to be tested and results verified (huge task also).

Debugging, file dumps, SAS type applications, would be a problem (I wouldn't want to have ONE MORE DAMN CARD to look at when debugging something).

The convert/deconvert would take huge amounts of machine cycles at a considerable cost in dollars and gray hair for capacity planners. (even though the programs are small every record in the corporate cache would have to be passed each time the record is prepared for human consumption). Your nightly batch cycle would be shot to hell. Not enough time.

The last one killed it. I won't go on.

But don't give up. Tell SK to keep working on it.

MoVe Immediate.

-- MVI (vtoc@aol.com), December 30, 1998.

Looks like there is no joy in Mudville.

-- Tom Carey (tomcarey@mindspring.com), December 31, 1998.

Mr Ismay says that all we need to do is to pump the water out of the number 3 cargo hold and then we will be able to save the ship , he is a busness man so i think he must know what he is talking about ...


the time for trying to figure out why it happend has past , the time to try to fugure out how to move on , is now at hand .

-- Ron (mongo@earthling.net), December 31, 1998.

This is a response to the points made by vtoc@aol.com about my paper.

I will respond to the points in order except for the one about hard-coded dates. I will discuss hard-coded dates last because this topic is for me the most complicated.

Some of my arguments will involve comparisons with windowing, which is apparently being implemented in a fair number of cases.

Re: "Birthdate is a problem. 100+ is required."

I have a 100 year span to work with, the same as windowing. Beyond that span, some alternative method must be employed (year field expansion, I suppose). Certainly I don't want to be responsible for upsetting the great-grandmothers of this nation by informing them that they must start attending kindergarten.

Re: "System date is a problem."

I mention this on page 3 of my paper: "Likewise, the current date obtained by the operating system would have to be converted before use in a comparison or calculation."

Re: "Financial transactions with a look ahead of 30 years is a problem."

With my 100 year span to work with, if I temporarily renumber years going back 56 (multiple of 28), I can also do this 44 years into the future.

Re: "Every date in every file/data base in every system would have to be identified (large task in itself)"

Very true. But that's also true of any alternative method, to either change the data (year field expansion) or at least cope with it.

Re: "Conversion programs would have to be written to shift the date taking at least 130 years into consideration (leap years, days of the week, etc.)"

My understanding is that a time shift of 28 years, or some multiple such as 56, will take care of leap year and day-of-week problems. And fortuitously handle the fact that year 2000 is an oddball in being a leap year.

Re: "This effort (conversion and deconversion) would have to be tested and results verified (huge task also)"

Not nearly so huge a task as checking out considerably changed application programs and their interaction with each other. (What about estimates that 7% of application program fixes will introduce errors?)

Re: "Debugging....would be a problem"

We are just going to have to agree to disagree on this.

Re: "The convert/deconvert would take huge amounts of machine cycles.....Your nightly batch cycle would be shot to hell"

Rightly or wrongly, I don't believe the nightly batch cycle would be shot to hell. I have one impressionistic point and one theoretical point.

The impressionistic point can best be illustrated by some work I did in 1971 as a contractor for NASA. I ran jobs on the biggest fastest 360 that IBM had come out with. My impression is that this machine could have executed my additional job steps in the fraction of an eyeblink. OK, that was one of the biggest mainframes on the planet. But also, this was 27 years ago. (Please note my sporting nature in sending this response today. By waiting until tomorrow, I could have strengthened my argument by saying 28 years.)

My theoretical argument has to do with a comparison with windowing, which is a technique in some use for Y2K. I believe that this technique will add as many cycles during program execution as mine will, if not more. Are the windowing people worried about blowing the nightly batch schedule to hell? Should they be?

Finally, I think that enormous amounts of machine time could be saved with my approach because of greatly reduced testing requirements.

Finally we get to the problem of hard-coded dates. My thinking on this will take a bit of explaining.

First, this is a problem that implementors of any approach have to worry about. (I haven't written about some problems that are common to every approach. What if all 9's in the date field don't stand for a date? Well, any approach would just have to cope. What if there is no power? In that case we are all in the soup no matter how hard or intelligently we've worked on fixing our systems.)

On the subject of hard-coded dates, my paper was influenced by Ed Yourdon's TimeBomb 2000 book, although in a way that I'm sure was not intended. At one point, the book discusses a field called GEEZER, which contains a number which is possibly an age or possibly a year value. It is being compared to a hard-coded number. The difficulties of tracing back through the program to find out what GEEZER contains are then illustrated.

I want to emphasize that what follows is not a criticism of the GEEZER example. Ed Yourdon used it to make a particular point and made it well. My reaction, though, was that knowledge of the business rules of the institution would have cleared up that mystery quickly. Hence the reference to business rules on p. 3 of my paper.

To elaborate on all this: If someone wanted to counter my emphasis on business rules with examples much less obvious than GEEZER, I'm sure it would be fairly easy to do. But what if one were to take the business rules, reason from them, and make sure that the hard-coded dates embodying these rules were appropriately adjusted. Needless to say, there should be prioritization here. After all, if GEEZER ceases to get preferential treatment, it won't be the end of the world. He will complain, and the institution will fix the system and presumably make amends to him.

To say that "every line in every program must be examined for hard-coded dates" is the counsel of despair. This will be physically impossible. There are not enough programmers alive to do this.

-- Peter Errington (petere@ricochet.net), December 31, 1998.

To say that "every line in every program must be examined for hard-coded dates" is the counsel of despair. This will be physically impossible. There are not enough programmers alive to do this.

-- Peter Errington (petere@ricochet.net), December 31, 1998

I think you're finally starting to get the picture!!!!!

-- WAAHOO (bobb@mtjeff.com), December 31, 1998.


IMO your time-shifting encapsulation method is workable within a batch processing system that has the necessary spare resources for the before-and-after conversion steps. (Do we have the extra space for the temporary data sets? How long will it take to do two passes?) Given that environment, its difficulties seem no worse than those of other timeshifting or encapsulation methods I've seen or can imagine.

Special date cases will complicate your before-and-after conversion programming. Conceivably, this could push the required effort past the point at which it would be more efficient to use another method.

An early consideration for any time-shifting method: Can the application software properly handle the intended range of time-shifted dates?

I.e., if one shifts all true dates backwards by 28 years, then one needs to know whether the unmodified application software correctly handles dates which are 28 years earlier than the earliest true date present within the data with which it will be presented. If not, then either you can't use a 28-year time shift, or you have to modify the application software.

Also, look out for those tricky leap years: If the earliest true dates in ones data precede March 1, 1928, then a 28-year backward time shift will not preserve day-of-week for those dates. 1900 was not a leap year. Also, for such dates one has to consider possible two-to-one mapping problems from February 28-29, 1928 into February 28, 1900, or else the nonexistent date February 29, 1900.

Re: Birthdates or any other data requiring more than a 100 year span

One has to presume that the existing batch processing programs already have provisions for handling these cases correctly (for dates prior to 2000, anyway) -- such time spans are not being added as part of Y2K remediation.

Then the only impact on your method would be that the new before-and-after conversion steps would have to handle such fields correctly, and the encapsulation time bounds would have to be set appropriately. ISTM that would be true of other time-shifting or encapsulating methods as well.

Re: Financial or any other type of transaction with a look-ahead of N years

Again, such look-ahead function would presumably already be handled correctly (for current-dates prior to 2000, anyway) by the existing batch processing programs, and not be part of Y2K remediation itself. So this seems to have the same impact as above -- handle fields correctly in conversion steps and set encapsulation boundaries appropriately. True of other Y2K remediation methods as well.

Re: Bounds on valid year within data

The before-and-after conversion steps would have to be sensitive to the bounds of valid year representation within the data. Same for other time-shifting methods.

Re: System date (CURRENT-DATE)

AFAIK all time-shifting methods, not just yours, have to cope with this, so this is a systematic disadvantage relative to all methods that preserve true dates.

Re: Debugging and file dumps

Again, a systematic disadvantage, relative to methods that preserve true dates, that is shared by all time-shifting methods AFAIK.

Re: Identification of all date fields

Encapsulation methods have the advantage of having to identify only those date fields which pass across the encapsulating boundary.

-- No Spam Please (anon@ymous.com), December 31, 1998.

This is an answer to anon@ymous.com regarding my Sort of a Silver Bullet paper:

Thanks for the feedback. I agree with you on everything except one point: I have always thought that the disadvantage you refer to wrt debugging and file dumps was small potatos. I could be wrong on this, tho.

-- Peter Errington (petere@ricochet.net), January 04, 1999.

You're the best judge of potato size for your applications, so I make no recommendation. :-)

[Written during Lay's potato chip TV ad.]

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

Moderation questions? read the FAQ