Anyone wonder why we're going to have problems with Y2K? Here's a sample of a fix I just made to our company's product. Because of an error in this obscure logic, many of our clients would have been completely unable to process their time cards (payroll) in 2000. Our software was declared "Y2K Compliant", too! This was one line out of approximately twenty-thousand in a code library that implements our product's business rules. Having done this for 20 years I was able to find and fix this one relatively fast - but I had complete source code and debugging tools with which to find it. Many Y2K problems will take place in systems that no longer have source code, tools or programmers that know how they work.

You will notice that this was far more obscure than just looking for the occurance of a 2-digit year and converting it to 4-digit. It simply wasn't that obvious. Without getting too technical about it, the problem revolved around a miscalculation in a year that resulted in the failure of a subsequent routine to correctly calculate a julian-date value which caused an error in the time-period for which employee punch data was interpreted. The result of this was that the client was unable to see, read, edit or report on timecard data for any dates later than 12/31/99 for a monthly pay cycle.

Anyone who tells you that they have a piece of software that you can run on your computer that will identify and fix Y2K problems is LYING. There is no way *anything* but a programmer who knows how to analyze code and determine intent of same can find, let alone fix obscure Y2K problems.

Here's a picture of the code for you Pollies who think that such problems can just "go away". If you can even understand what is written here, let alone what was wrong with it, I will be completely amazed.

// Compute pay-period end-point.

switch(ic) { case 'M': strcpy(jc,j4dtoc(dait)); i = (int) j4val(j4left(jc,2)); j = (int) j4val(j4right(jc,2)); if(i<12) i += 1; else { i = 1; j += 1; // 12/2/99 - Y2K correction. Year was failing in julian date routine. j %= 100; // 12/2/99 }

sprintf(jc, "%02d/01/%02d", i, j); // Format as mm/dd/yy il = j4ctod(jc); return il;

/************************************/

-- CodeBubba (codebubba@yahoo.com), December 07, 1999

Answers

let's make it a little easier for them, shall we?

// Compute pay-period end-point. switch(ic) {case 'M': strcpy(jc,j4dtoc(dait)); i = (int) j4val(j4left(jc,2)); j = (int) j4val(j4right(jc,2)); if(i<12) i +=1; else { i = 1; j += 1; // 12/2/99 - Y2K correction. Year was failing in julian date routine. j %= 100; //12/2/99 }

sprintf(jc, "%02d/01/%02d", i, j); //Format as mm/dd/yy il = j4ctod(jc); return il;

-- RZN (robinsun@netscape.net), December 07, 1999.

CodeBubba, Try this on for size and test your theory that their is no software out their.

http://www.mfxr.com

Write back with your results..

BLUE

-- BLUE (bluefish@thepond.com), December 07, 1999.

Sorry Codebubba,

the forum software kills all the whitespace. is the answer that the switch statement lacks a right angle-bracket to close it off, or is it more complex than that? without variable defs, it's virtually greek.

-- RZN (robinsun@netscape.net), December 07, 1999.

Thanks CodeBubba, I really needed that today, my energy level is low and I'm wondering just how wrong I am in my thinking and prepping. I know only one other person who is SERIOUSLY prepping and the rest of my friends are wearing me down. You'er little Kernal of Wisdom reaffirmed my life over the past 2 years, Y2K will be a 10!!!!!!!!!!!

-- zeda (rickster@n-jcenter.com), December 07, 1999.

Here's the code with the missing right brace:

switch(ic){
  case 'M':
    strcpy(jc,j4dtoc(dait));
    i = (int) j4val(j4left(jc,2));
    j = (int) j4val(j4right(jc,2));
    if(i<12)
      i += 1;
    else{
      i = 1;
      j += 1; // 12/2/99 - Y2K correction. Year was failing in julian 
date routine.
      j %= 100; // 12/2/99
    } 
}

sprintf(jc, "%02d/01/%02d", i, j); // Format as mm/dd/yy
il = j4ctod(jc);
return il; 

-- Richard Dymond (rjdymond@hotmail.com), December 07, 1999.

Well, the switch block is apparently there to determine the next first day of the month, and then the sprintf () sets the string variable jc equal to this date in "mm/01/yy" format.

It's a bit hard to debug this code, though, because I'm not entirely sure what it's supposed to be doing. I'm also not familiar with the j4* functions--afraid my C's a bit rusty.

Come on CodeBubba, more clues please!

-- Richard Dymond (rjdymond@hotmail.com), December 07, 1999.

Blue,

I just checked that MFXR program. It does exactly what I expected; it scans files and looks for strings of the format "mm/dd/yy" and advises the user of the presence of them. There is NO WAY that software can analyze (particularly at the object level) the code I had to correct, because no character strings are visible in that code - they are contrived at runtime. MFXR would never spot that logic error nor could it be expected to.

-- CodeBubba (codebubba@yahoo.com), December 07, 1999.

Richard,

Nice attempt. The right brace that was missing was simply a typo on my part in the cut-and-paste operation. The problem is more subtle and more complex:

The function j4ctod() is a function written to take a date string of the form "mm/dd/yy" and convert it to a long numeric - I.E. julian date. j4ctod() was already fixed (kludged) to recognize the year "00" as "2000" - the guy fixed it to take years 00-49 and make them 2000-2049 and 50-99 as 1950-1999. (Bad solution, but will work for 50 years).

Anyway, the code immediately preceding it was incrementing "j" which contained the current year, then it was contriving the date string in the "mm/dd/yy" format and passing it to j4ctod(). When j was 99 and being incremented it was, naturally, 100. The routine, however, did not consider this so it contrived a date of "1/1/100" for 1/1/2000. This was passed to j4ctod() which, of course, returned the wrong julian date.

My fix simply made sure that only the modulo 100 result of the incremented value gets passed ... I.E. when j = 99 ... (j % 100) is 99 and when j = 100 (j % 100) = 0. With that correction, the date passed was "1/1/00" which was understood by j4ctod().

Blue ... as I said in my previous message, and I maintain my position; there is NO piece of software that can perform such an analysis on code, particularly COMPILED code. The best that a software audit utility can do is look for character-strings within a file that look like "mm/dd/yy" and warn of them. The above problem would not be detected by such a utility because that would require it to look at the code and figure out how the code WORKS ... literally what was intended by it. That's a little like trying to figure out how the gasoline flows through your car by examining the gasoline. I could chemically examine it for oil or water, but that wouldn't tell me you've got a leak in your exhaust manifold. Does that make it a little clearer?

-- CodeBubba (codebubba@yahoo.com), December 07, 1999.

CodeBubba:

So the code snippet, as you gave it, was already fixed? That's cheating! How were we supposed to be able to work out what the bug had been after you had fixed it? :)

-- Richard Dymond (rjdymond@hotmail.com), December 07, 1999.

"it scans files and looks for strings of the format "mm/dd/yy" and advises the user of the presence of them."

What if the programmer wanted to save a little space, and removed the / characters in a file? Better yet, what if he converted the MMDDYY string to binary, to save a little more space?

If this is the best Y2K tool that the polly camp can come up, we're in deeper stuff than I thought!

To laugh or cry...

Tick... Tock... <:00=

-- Sysman (y2kboard@yahoo.com), December 07, 1999.

Richard,

Aww ... sorry about that, guy! I commented the code that indicated what the correction was, but the whitespace got wiped out of it.

Sysman,

Exactly, you now have a better understanding of the scope of the problem. Dates can be stored in so many different ways that there is no way they could all be ferreted out. Blue's program would find:

"1/1/99"

but it would never understand:

sprintf(buf, "%02d/%02d/%02d", month, day, year);

or

strcpy(buf, 2_digit_monthval); strcat(buf, "/"); strcat(buf, 2_digit_dayval); strcat(buf, "/"); strcat(buf, 2_digit_yearval);

etc. etc.

Date strings and calculations are made (as are any code technique) in so many different ways that to assume that any "scanner" could just go search-and-destroy is simply ignorance of how incredibly complex this problem really is.

-- CodeBubba (codebubba@yahoo.com), December 07, 1999.

So that's your riddle, codebubba? Well, duh, where have you been for the last three years? I can assure you that those working Y2K with any sense figured that one long ago, bubba. Automated tools go only so far and you're the fool for thinking that you could just use a "silver bullet". And also you think you're the only one who can find and fix a problem? What makes you so special? Other people can find and fix problems too, genius.

-- Maria (anon@ymous.com), December 07, 1999.

Maria,

Your response is totally uncalled for, troll. I never said anything about a silver bullet, I was saying there WASN'T one. The only fool in this thread is you.

-- CodeBubba (codebubba@yahoo.com), December 07, 1999.

Another player enters the game in the 4th quarter without knowing the score.

CodeBubba, payroll snafus aren't exactly catastrophic events. A problem such as this is not difficult to find and fix if the program has been tested with a decent data set.

-- Buddy (buddydc@go.com), December 07, 1999.

Buddy,

Heh ... payroll failures aren't catastrophic events unless it happens to be YOUR paycheck that's affected. Hope you don't have a catastrophe if you know what I mean!

I don't know where you get off with this fourth-quarter comment, either. If you had any experience as a developer, you'd understand that I was using the payroll situation as an example. Payrolls certainly aren't the limit to where this problem will take place.

No point in my wasting any more time on that ... catch you later.

-- CodeBubba (codebubba@yahoo.com), December 07, 1999.

As to the challenge of "You think Y2K is gonna fix itself?" the answer is "of course not."

However, a great deal of it has been taken care of by people who have been examining, coding and testing in a manner efficient and professional enough so that they are not "just" making these sort of fixes.

Yes, you have provided an excellent example of why Y2K has presented a very tedious and large problem to fix. And, had you presented it months (or even years) ago when many people were doing this sort of work, it would have been educational. However, it is but one example, fairly easily detected through basic testing and easily repaired once found. Let's not make a mountain out of what fails to even rate as a mole-hill.

-- Paul Neuhardt (neuhardt@ultranet.com), December 07, 1999.

The 4th quarter comment was in reference to the assumptions you make that "pollies" don't believe there is any problem at all and the fact that you have restated the same old tired arguments we've been hearing for a few years now. Of course there are Y2K problems. It's the impact that people disagree on.

-- Buddy (buddydc@go.com), December 07, 1999.

Whatever.

-- CodeBubba (codebubba@yahoo.com), December 07, 1999.

Trolls out for gang-bang

-- 21 days (trolls@begone.soon), December 07, 1999.

Me think's that you'er all missing the point of this, Y2k cannot be fixed, your rearranging deck chairs on the Titanic, get prepping!!!!!!

-- Zeda (rickster@n-jcenter.com), December 07, 1999.

I love it. An troll post from some idiot who then calls me a troll.

What troll means at TB2000 and what it means on the rest of the internet are two different things.

-- Buddy (buddydc@go.com), December 07, 1999.

Buddy, you beat me to it. He trolled the pollies to respond on this thread, we respond, then he calls us trolls. Don't you just love it.

-- Maria (anon@ymous.com), December 07, 1999.

No Zeda, you're missing the point. He found a Y2K problem and fixed it. If Bubba can do it, so can the rest of the world. Now you turn around and say Y2K can't be fixed, in effect, saying that bubba is an idiot.

-- Maria (anon@ymous.com), December 07, 1999.

No, I think that Bubba is a good Fixer, but remember, he had documentation and he knew what he was looking for, and the only reason he found it in the first place was because it was broken, it wouldn't have been noticed until 01/01/00 when all of the other gliches that slipped through the cracks show up. Thats what scares me!!!!!!!

-- Zeda (rickster@n-jcenter.com), December 07, 1999.

I'm not a programmer or in the computer industry whatsoever but what I have derived from this thread is that, There is no silver bullet software for finding the date problems in the code, because the date can take too many forms and it has to be done manually.

CodeBubba - We already have problems cropping up around the world, expensive problems I don't think anybody is disputing that. The Deutsche Bank post was an example. Did I approximately summarize the gist of your post in the paragraph above?

-- Guy Daley (guydaley@bwn.net), December 07, 1999.

Let me see if I can interpret this one:

KISS(ic) { case 'M': strcpyYES THAT IS KISS(jc,j4dtoc(dait)); i = (int) YOUR j4val(j4left(jc,2)); j =A@@ YES THAT IS (Y) //(int) j4val (j4right(jc,2)); if(i<12) i += 1; else GOODBYE{ i = 1; j += 1; PREPARE // 12/2/99 - Y2K correction. Year was failing in julian date routine. j %= 100; // 12/2/99 }

sprintf(jc,PREPARE "%02d/01/%02d", i, j);FOR A 10!!!!//\\!!!! // Format as mm/dd/yy il = j4ctod(jc); return il;

Uh... we have big problems...... Kiss your (Y) goodbye. Prepare for a 10.

Kinda reads like General Custer's Final Message:

"BIG VILLAGE. BRING PACKS. p.s. BRING PACKS!"

-- the Virginian (1@1.com), December 07, 1999.

Guy,

Yep. You pretty much got it. All I was trying to do here is illustrate that there is no "silver bullet" fix for Y2k. As for the guy I called a "troll" it was simply response-in-kind to an uncalled- for comment. (I dunno about anyone else, but calling someone you don't know a "fool", particularly when out-of-context is what I consider bad behaviour). Perhaps I chose badly my title for the thread ... I simply was trying to attract some attention. If anyone was insulted, I apologize; I have no axe to grind with anyone on this thread, including those who felt they had to try and belittle me with their commentary - doesn't bother me; if it made you feel better than go ahead and flame!

To those of you who disagree with the "doomer" position on this thing, go ahead and disagree: it will come out in the wash in about 23 days or so. Even as a developer of 20 years, I don't take the "doomer" position (if you want to call it that) lightly and am willing (actually hoping) that I'll have to declare my position WRONG.

My illustration was intended to show that Y2K problems *are* fixable, but that it takes a great deal of work to do so. The problem with this thing started some 50 years ago, though, and to think that even in the last 10 years we're going to be able to fix it is just plain ludicrous. As to its effects? I wouldn't begin to state that I, or anyone else, know for certain what is going to happen. All I know is that it takes very small errors in large code systems to produce relatively serious problems.

The illustration I provided was intended to demonstrate this. Whether or not a failed payroll run is considered a "disaster" to some (as was alluded in a previous post here), it *IS* a disaster to the company who is experiencing it. Certainly my employer considers such a matter a "disaster" because it wreaks havoc with half the client base; if screwing up the bottom-line of a corporation isn't a disaster, then excuse my terminology.

-- CodeBubba (codebubba@yahoo.com), December 08, 1999.