Brian Bretzke has been making multiple postings regarding MFX2000, a "White Paper" on degradation due to "short dates" prodoced by the developers of MFX2000, and the "Rotterdam Report", a set of tests supposedly confirming the White Paper.

I've read through the information, and have some questions. Maybe Brian can enlighten me?

On the White Paper

The "White Paper" is available online as a PDF file:

http://www.mfxr.com/htm/download.htm

Now, there is some questionable material in this "White Paper" regarding the supposed "corruption" of O/S and Applications. In particular:

A date function is recognised by its satisfying certain criteria, that is a day, month and year. Dates like 01/01/02 and 01/01/99 fit within these criteria, and are classified as a date structures even though the century component is not defined. There are multiple date separators including "/", "-" and ".". These identify the break between a day, month or year. However, these three particular separators also carry the mathematical functions of divide, subtract and decimal.

As a result, if an application sends a call and expects the date in the return to be in a string format, if the string return is 01/01/00, the data may be accepted as a date or, due to the format and the possible functionality of the file, it may be interpreted as a 1 divided by 1 divided by 0. A major issue occurs with a month year return, a year return or a string based day, month, year return because these will return a non-date format to the relevant application resulting in an error.

Errors may be trapped or ignored. In either case, part of the functionality of the application will be frozen in memory when the application is closed. This frozen component will be released, if the application is closed correctly. Such an error is unlikely to be trapped and the application will not be closed correctly and a stack freeze will occur resulting in a slight corruption of the relevant file. This will be cumulative and will ultimately affect system files, so that not only the application, but also the system will become corrupted and unstable.

Question #1: What application calls a "date function", then attempts to interpret the result as an arithmetic expression? This idea is almost ludicrous; apparently, the application must be coded to call a function which is expected to return a date, then somehow "forget" that a date is to be returned. Could anyone provide any example of such an application?

Question #2: Do "stack freezes" actually "corrupt" system files? While I've never considered Windows a "stable" system, re-booting has always cleared up the unstable condition.

Going forward:

If a date calculation is hard coded into an application and it is short date based then an error will occur with calculations across the year 2000. If an application passes a date function calculation to a DLL in a long format (so the application is compliant) but the DLL only reads a short date, then a similar error is generated.

Question #3: While I would agree that an error would be generated, why doesn't it generate an error today?

And further:

Data for sales projections could be represented as 07/1999, 08/1999,......, 05/2000 and 06/2000, but read as 07/99, 08/99,....., 01/00, 02/00, 03/00, 04/00, 05/00 and 06/00. In this situation, what does 01/00 mean? What has happened to the bytes passed for the century? Does a query go back to the database for 01/00 returning data from 1900, or 2000? The answer is:

7 The extra bytes dont just disappear, they are "stuck" in memory. A memory stack freeze will occur, and when the application is closed a slight corruption occurs.

7 No application unless specifically programmed can handle a 0 function request. Does the application handle a 01/00 request from the reporting tool as a date or does it actually see it as 1/0 or a divide by zero error? It may be expecting a date format 01/00 as a date format, but it can also be returned as an integer i.e. 1/0. This will not send a return, because it is not the correct data type. The possible errors are: it is the wrong data type or it is a divide by 0 error. There is no error trapping for either of these possibilities, as neither of these errors would be expected when passing date parameters. The net result is file corruption.

Question #4: I have a hard time believing the extra bytes are "stuck" in memory. But beyond that, again, why doesn't this happen today? If the extra bytes are causing the stack freeze and "slight corruption", it shouldn't matter if the "extra bytes" are '19' or '20'.

The last point was addressed above. Why would an application expect a "Date", then interpret the results as an arithmetic expression?

"Rotterdam Report"

The independant test results that supposedly confirm the above is available at:

http://www.y2000c.com/files/RotRepFPS.pdf

In summary, they basically used 4 systems: 2 32bit, and 2 32/16bit systems. All were loaded with vendor compliant software. Then the MFX2000 fix was run on one each.

They then used a benchmarking utility to automate "application runs" in a simulated 5-day, 40 hour week. Measuring the number of "application runs" during each period was meant to determine system performance and availability.

Some of your "statements" regarding this are, umm, certainly questionable. For example:

"Personal computers will cease to operate during first quarter of 2000".

http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001oxf

The test results show nothing of the sort. They show a dropoff from week 1 to week 2 in the number of application runs, which then in essence stabilizes. No PC "ceased to operate".

In fact, the tests in actuality can conclude nothing about running in the year 2000 whatsoever. No control run was performed with non-2000 dates. The intent of the tests was to demonstrate the effectiveness of the MFX2000 Object Code corrections. There is absolutely no evidence that the behaviour of these systems was affected in any way by running in the year 2000.

Also, your statement:

"NATO has confirmed the Rotterdam Group's finding. "

Is at best misleading. NATO has absolutely nothing to say about the "short date" problem, or the results of the Rotterdam tests. NATO recommends using MFX2000, nothing more.

-- Hoffmeister (hoff_meister@my-deja.com), December 01, 1999

Answers

Good questions,Hoffmeister!

Brian please address this. I have requested some comments from a dlient of mine who has dozens of years in the code writing area.

I will post additional information as i get it.

Keep questioning, and the answers will follow.

BLUE :0)

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

Yeah, I know that when I perform a call for a date, I always perform arithmetic calculations based on the separators. You bet! And all those icky bytes gumming up the computer when they're not used -- yecch!

I want some of whatever these people were smoking when they wrote this up.

-- The Whistler (I'm Here, I'm There, I'm Everywhere@so.beware), December 01, 1999.

Hoff,

Good questions, yes.

My choice was not to read the report because at this late date it makes no real difference. To borrow from a dear friend, what will happen will happen, or not and I decided long ago to be prudent and buy a little insurance.

-30 more days and it seems to me that problems are increasing. We'll all know soon enough, one way or the other.

I'm looking forward to maybe a 10 foot hight bump in the road but I'm prepared just in case we actually hit a brick wall. If I can make a suggestion, you should also factor into your Y2k possibilities the outbreak of a few hundred thousand computer viruses (FBI statistic) and the possibility of cyberterrorism (FBI, CIA, NSA)...just in case.

Got preps?

Mike

==============================================================

-- Michael Taylor (mtdesign3@aol.com), December 01, 1999.

Don't sweat it, I had a good read, and IM-professional-O it's a crock of plastic dog turds.

IF you have a system that is using short dates (i.e. it's been windowed, not converted to four digits) AND it has such bizarre and unlikely code that it decides to interpret a date string as an arithmetic expression when the last character becomes zero AND if the divide by zero is handled so badly that the rabid result escapes from the heap or stack and overwrites some executable code on the hard drive THEN you've got Rotterdam therefore give us money.

I'm guessing this applies to, oh, about zero systems worldwide. I would have a hard time writing code to do this deliberately. In the absense of any sample code from a real application (I'd be happy to test it) I'm not losing any sleep over this.

-- Colin MacDonald (roborogerborg@yahoo.com), December 01, 1999.

The report summary says nothing at all about the OS it was tested under. I'd speculate that it was tested in Windows, and that what it measured was a Windows inability to release all resources, just as we've heard of such problems for years. I'd speculate that the Rotterdam tests would show such a degradation in performance on a present dated machine, just as in a future-dated one.

Nowhere in their appendix do they say that their object-level fixer would actually FIX this problem! It feels like the vacuum cleaner salesman who sprinkles his version of dirt and shows how well his cleaner does with it. Doesn't mean it really solves a real-world problem.

Whatcha think?

-- bw (home@puget.sound), December 01, 1999.

I got the impression that the automatic testing did not really support some of the predictions in the white paper. In any event, this is so controversial and so little time is left that it is not going to provide any answers. We have a similar situation with the guy who developed a new method of expressing dates in IBM mainframes. It is much too late to be putting out new ideas to solve the y2k problem.

-- Danny (dcox@ix.netcom.com), December 01, 1999.

Hey guys-

Great discussion and legitmate skepticism..."Plastic dog turds?"

The "OCT Technology"....It takes quite a leap in faith to accept the notion that Y2k problems in personal computers and desktops can be identified and remediated at the object code level. Unless you were programming prior to 1978, you have been using compilers and might have a hard time understanding this "horse and buggy" concept.

The "Smoking Gun".....For a couple of years now, we've been told that nobody knows what's going to happen to personal computers after the rollover...The guys in Rotterdam are providing those answers. (Unfortunately, their simulation (real world) testing won't be complete until 2 weeks before the rollover...Some lead time!) Besides that, these guys want to sell their full report for $5,000!

The "Silver Bullet".....A tiny company in Australia with a minimal marketing budget, claims to have a solution for short date issues in personal computers. They patented the only algorithm that allows you to do this. They also claim short date issues will be the Y2k "achilles heel". These guys are a "for profit" operation. They want to sell their stuff.

I think the guys in Australia and Rotterdam are right...Challenge me. Download a FREE short date audit from Australia at http://www.tir.com/~bretzke/free.html and run it on your own system.

If I'm right, and you have short date issues, we'll all know soon enough.

I have also asked Tom Sirovey to pop into this thread and offer some technical perspective. Tom is the TOP DOG tekkie in Object Code Technology in the U.S.

Lewis has downloaded the FREE audit and seems to be seeing the light: http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001tGA

-- Brian Bretzke (bretzke@tir.com), December 01, 1999.

Brian - http://www.mfxr.com seems to be sleeping today. Be glad to try it when/if it comes up. As an old (1974-5) bit-flipper (assembler coder) this is not unknown territory.

-- bw (home@puget.sound), December 01, 1999.

Brian, the "challenge" isn't regarding MFX2000.

Not necessarily challenging the Object Code technology. Didn't have to be programming prior to 1978; wrote some utilities for the Series/1 EDX operating system that "installed" themselves at the object code level in the OS itself.

No, the "challenge" is regarding these statements on the creeping corruption of PC's in the year 2000.

-- Hoffmeister (hoff_meister@my-deja.com), December 01, 1999.

I have read this report and much of it looks like nonsense to me. I am not saying the product could not have some benefit, who knows, but based on the report I wouldn't buy it. It appears the report was written by someone who either does not know much about software and operating systems, or is deliberately trying to mislead the reader.

1) An application expecting a date in string format will try to interpret it as a string. Not 1 divided by 0.

2) Stack problems and other corruption problems do not corrupt system files.

3) Software designed to use the "short date format" (2-digit years) will not necessarily produce errors because of Y2K. Many applications expect only 2-digit years and work fine that way.

4) Extra bytes from dates getting stuck in memory? This is nonsense.

There are many more examples of things that don't make sense in this report. Again, ANY errors, including date errors, can and do cause instability in PC operating systems. But the corruption exists only until we reboot. Date errors do not somehow accumulate within the operating system and system files.

-- A Programmer (notmy@address.com), December 01, 1999.

BW- The FREE Audit for short date issues download site appears to be working now at http://www.tir.com/~bretzke/free.html

Hoffmeister- The fact that you aren't challenging the "possibility" that Object Code Tecyhnology might have some merit is heartening...I was told by a professor of computer science that any of his students who offered such an "assinine" theory would receive an "F". He then pointed to three different chapters in his text books to confirm it. He advised me it was IMPOSSIBLE to identify and/or fix short date issues at the object code level.

A Programmer- Sorry, reboot won't solve this problem.

My intention wasn't to start a technical debate on this forum, although I welcome it. I was trying to dispel the notion that the Y2k problem will be a one day event. If the guys in Australia are right, and the guys in Rotterdam are right, we'll be seeing some nasty Y2k fallout long after Jan. 1, 2000 from personal computers and desktops.

My interpretation of the Royal Society Report and Rotterdam Test suggests that because of the short date issue, a personal computer being used for some word processing and internet enjoyment will last about six months before the "creeping corruption" (love that description) causes it to be non-functional.

Computers with heavy calculation activity, such as those used in day- to-day business, will become non-functionally corrupted in a much shorter period.

This problem could add to mainframe and embedded system shortfalls and really cause a "snowball effect".

-- Brian Bretzke (bretzke@tir.com), December 01, 1999.

A Programmer wrote: "I have read this report and much of it looks like nonsense to me. I am not saying the product could not have some benefit, who knows, but based on the report I wouldn't buy it. It appears the report was written by someone who either does not know much about software and operating systems, or is deliberately trying to mislead the reader."

Good point programmer.....The MFX product is the ideal "Fix on Failure" product. Don't buy it now.....Wait until there is sure proof of "creeping corruption". It will only take a couple of hours to fix the problem and the corruption signs will be gradual, if the guys in Australia and Rotterdam are right.

Unfortunately, some folks are taking a "Fix on failure" approach to mainframes and embedded systems and these ARE NOT two hour fixes.

-- Brian Bretzke (bretzke@tir.com), December 01, 1999.

Brian, I'm not sure that "seeing the light" accurately describes my comments in the other thread. The FMX audit software certainly found lots of stuff and made a nasty start to my day. But I'm still trying to figure out what that means.

Our colleagues above make many excellent points. (Perhaps colleagues is the wrong term. I am out of my depth in most of this discussion and am learning from them as we go.)

Hoffmeister and A programmer make several excellent points, but the main one to me is: the Rotterdam Report says nothing about the "creeping corruption" problem described in the White Paper. And the lack of a control in the test makes the results suspect.

I dunno. The emergence of new errors caused by date related math or validation *within* compiled libraries and executables previously seen as compliant seems like a plausible idea. That they could cause more (new) system hangs or crashes due to poor error handling also seems plausible. That the aggregate effect of this across thousands of PC's at any one company could be severe seems self-evident. If this much is true, we are facing a new (and as you point out), long-term problem, IMVHO.

But I don't think the Rotterdam Report Public Summary supports the central argument of the White Paper. And there won't be time to independently confirm the results.

You make the point that FMX2000 would be a good FOF tool. That's what NATO's testers concluded as well. That's gonna come in mighty handy, I fear. But will that be before or after the legacy data is corrupted?

Thanks, all. More commentary eagerly anticipated.

-- Lewis (aslanshow@yahoo.com), December 01, 1999.

To all:

The lack of acknowledgement of the posibility of a new "technology" that can address the discussed situation really astounds me.

I have been a systems programmer for over 25 years, DOS, DOS/VSE, MVS, VM, CRAY, VMS, Tandem, Magnusen, Unisys, S32/36/38, AS400, PC's (even when you didn't need a "hard drive" because a "floppy" could hold everything). I could still (probably) run a "card punch", "sorter" as well as a "paper tape" machines (1400 series IBM's - that only provided addition and subtraction (could get division and multiplication for about $5000 per module).

New technologies are always hard to accept (seems to be the way that our society resists "change"). What we have here is a programming concept that "overrides" what we have been never been presented with before.

The NSA has tested this algorithm and has found it to be highly sucessfull. The only drawback was that it was too powerful if in the "wrong hands".

-- Tom Sirovey (tsirovey@blclinks.net), December 01, 1999.

OCT (Object Code Technology) is a new meaning of determination of what is "happening "behind the scenes" within the "wondrous" Windows environments. MVS, VMS, UNIX, VM and many others are no where near complex as the Windows that we now have to deal with.

Many of you have expressed the fact that the "current" Windows environments already have problems (gee'z - we have a VERY stable Windows - right?).

-- Tom Sirovey (tsirovey@blclinks.net), December 01, 1999.

OCT (Object Code Technology) is a new meaning of determination of what is "happening "behind the scenes" within the "wondrous" Windows environments. MVS, VMS, UNIX, VM and many others are no where near complex as the Windows that we now have to deal with.

Many of you have expressed the fact that the "current" Windows environments already have problems (gee'z - we have a VERY stable Windows - right?).

OCT is non-dependant upon any platform nor compiler (unless you have encountered an "OCTAL" system - I haven't since about 1981). Let's face it, everything comes down to "machine level" code. If you really think that programming does not "abuse" standard programming techniques (by todays standards) then you need to go back to school.

Hoff,

-- Tom Sirovey (tsirovey@blclinks.net), December 01, 1999.

OCT (Object Code Technology) is a new meaning of determination of what is "happening "behind the scenes" within the "wondrous" Windows environments. MVS, VMS, UNIX, VM and many others are no where near complex as the Windows that we now have to deal with.

Many of you have expressed the fact that the "current" Windows environments already have problems (gee'z - we have a VERY stable Windows - right?). After "specializing" in "PSP" - Preventative Service Planning and "PSIR" - Problem Source Identification and Resolution for many years, I have become very "stringent" with the methods that I use to procure solutions.

I, too, am a very skeptical person (start out the day with 10 disasters - if only 8 happen, then I had a good day). We need not to be discomforted with the possibility that there is "a better way" nor do we wnat to ignore the fact that possible prevention (or acknowledgement of resolution) is capable.

OCT is non-dependant upon any platform nor compiler (unless you have encountered an "OCTAL" system - I haven't since about 1981). Let's face it, everything comes down to "machine level" code. If you really think that programming does not "abuse" standard programming techniques (by todays standards) then you need to go back to school.

Hoff,

You mentioned in an earlier thread that you have have worked around and with the Y2K issue for 20 years. That is very interesting! I have not been involved with nor worked for nor consulted with any organization nor person that was concerned with the century change before 1997. If you review the APAR's, PTF's, PUT tapes, Microsoft patches and Service Packs, you will see no mention of Y2K "stuff" before this. I have been involved directly with IBM "level 3" support for many years, have been in front of COMPAQ, GATEWAY, Deloit & Tuestch, Lockheed, Unisys, Lucent Technologies, GM, EDS, CISCO, Clover Tehnologies, Chrysler, FMC and many other small, medium and Fortune 500 business entities regarding this issue. Regarding your questions to the "white paper" and the "Rotterdam", you need to read very closely the preceeding and succeding paragraphs (which you failed to include in your response). What you have done has been taken "out of context" without reasonable determination of the remaining text nor evaluation of the overall results.

Simply, please take time to review (without bias), all of the documentation that is available. The decision is only upon you.

Questions you have regarding the "gradual degradation" of the systems (actually denial of the possibility) are not accurately founded nor tested. How many applications (and I will not even go into the processing of the Microsoft Automation or Regional libraries nor the Dynamic Link Libraries that are common to every application that reside within a Windows environment - you can research this yourself). It is not a matter of "interpreting" the date delimiters as an arithmatic function, but that the date presented (and I will use LOCALE.NLS - the "hub" of basic data exchange) that passes back to applications the representation of the "year". If you have ever written a "bubble-up" sort, amortization or any other program that has utilized the date to determine amounts, period or longevity of accounts, possible "future" projections then you will know that I am talking about. If you haven't -= then exit stage left.

As with all of us, we will be the ultimate judge. I would highly suggest that you review (with an open mind) all of the documentation that is available (not just "paper" concerning the MFXR products but all others - I have been doing it for almost 2 years now).

Good Luck in your endeavors...

Mike, Excellent response!

Colin and A Programmer (took that one with a "grain of salt"),

Aparently you have been privy to the millions of lines of code that Microsoft has developed. I am absolutely sure that their programmers have never made a mistake ( I know that I never have - yeah right ). If you have a Windows environment that "locks up" and you have to press the proverbial "fix-it" button, have you never seen the wondrous message "registry corrupt"? If not, you have not worked with Windows very much. Simply run the Audit facility to determine if there are short dates being utilized.

Lewis,

You are on-track. You need to completely evaluate the resulting (and pre-questioned) issues. That is not an easy thing to do. There is so much "what-if" going on that no one can say for sure.

Don't think that the "Legacy" data will be corrupted B4 others, they may be "re-stored" incorrectly due to the "data exchange" capabilities and differences between various Windows and "Office" environments, but then if we can't access the data - where are we?

In summary everyone,

Should you wish to get into a technical discussion regarding the OCT or possibilities of degredation to PC environments (Windows), feel free to "E" me. I will respond as quickly as possible.

AGAIN, the decisions and choices are your's alone. Mine (after many years of preventative service planning) is to do whatever I think is best to prevent possible problems (1st day of college - one of the first lessons - PPPPPP (Prior Proper Planning Prevents Premature Problems)).

Good luck to you all!...Tom

-- Tom Sirovey (tsirovey@blclinks.net), December 01, 1999.

Sorry - Forgot one thing...

Whistler, weren't you supposed to be in school today? (get a life).

-- Tom Sirovey (tsirovey@blclinks.net), December 01, 1999.

OK, I had made a silent vow not to continue this discussion. It's becoming increasingly obvious that Brian is merely shilling for the product, and attempting to stir up attention and interest.

But to answer Tom:

You mentioned in an earlier thread that you have have worked around and with the Y2K issue for 20 years. That is very interesting! I have not been involved with nor worked for nor consulted with any organization nor person that was concerned with the century change before 1997. If you review the APAR's, PTF's, PUT tapes, Microsoft patches and Service Packs, you will see no mention of Y2K "stuff" before this. I have been involved directly with IBM "level 3" support for many years, have been in front of COMPAQ, GATEWAY, Deloit & Tuestch, Lockheed, Unisys, Lucent Technologies, GM, EDS, CISCO, Clover Tehnologies, Chrysler, FMC and many other small, medium and Fortune 500 business entities regarding this issue. Regarding your questions to the "white paper" and the "Rotterdam", you need to read very closely the preceeding and succeding paragraphs (which you failed to include in your response). What you have done has been taken "out of context" without reasonable determination of the remaining text nor evaluation of the overall results.

Please point me to where I've said I've worked on the Y2k issue for 20 years. If anything aggravates me more than people misrepresenting Y2k issues, it's people misrepresenting my statements. I have said I've been in IT for about 20 years.

I don't believe I've taken anything out of context. I took exact quotes and paragraphs from the "White Paper".

Questions you have regarding the "gradual degradation" of the systems (actually denial of the possibility) are not accurately founded nor tested. How many applications (and I will not even go into the processing of the Microsoft Automation or Regional libraries nor the Dynamic Link Libraries that are common to every application that reside within a Windows environment - you can research this yourself). It is not a matter of "interpreting" the date delimiters as an arithmatic function, but that the date presented (and I will use LOCALE.NLS - the "hub" of basic data exchange) that passes back to applications the representation of the "year". If you have ever written a "bubble-up" sort, amortization or any other program that has utilized the date to determine amounts, period or longevity of accounts, possible "future" projections then you will know that I am talking about. If you haven't -= then exit stage left.

The is BS. Of course there are problems in some applications using two-digit dates; kinda the whole reason there is a Y2k issue.

According to the "White Paper", it is an issue of "interpreting the date delimiters as an arithmatic function". The point is made quite clear, in multiple places, and is not taken out of context.

The fact that your only response to this question is to deny it, makes it abundantly clear what the true answer is.

And again, I'm not questioning the product itself, or OCT. It is these claims that PC's will "cease to operate during the first quarter of 2000" that are being challenged. The "Rotterdam" report appears to show that MFX2000 does eliminate some errors; great. The report can conclude nothing about running PC's in the year 2000. No control run was made with current dates, thus no measurement of the effect of running in the year 2000 can be made. Quite honestly, the fact that the author's even attempt to support that conclusion by the test results, in my mind calls the entire report into question.

-- Hoffmeister (hoff_meister@my-deja.com), December 02, 1999.

Hoff,

I SINCERELY apologize - it was an "A Programmer" comment. I "got a litle lost" in the influx of information (after all - you lose 3 things when you get old, 1st is your memory and, and (damn, glad I forgot the other 2).

I have not been employed nor contracted by any organization concerning the software in discussion. I have simply tried to accomodate the requests and concerns of the customer base that I have built within my geographical area. If, in fact, OCT can accomplish at least 50% of the professed "end", they are leaps and bounds above any other remediation package out there. If they accomplish 80%, we should pay homage to the developer. If they accomplish everything that they profess, then we will all be "expert witnesses" in the upcomming litigations that will occur. There are only two "other" products that do any type of "binary" scan - and even at that, they only identify ASCII/ISO type formats and still rely upon Windowing as far as the system date functions are concerned.

It appears that the only country that has it's head "buried in the sand" seems to be ours. This software has been distributed worldwide with excellent results. Keep open to the actual testing that was performed. The NSTL, CSTC, NATO, BSI, NSA, Royal Society and Rotterdam should not "all" simply be "fluffed off" as trying to sell a product. They do have some credence concerning their reports (except the NSA said that the technology was TOO powerfull if in the wrong hands).

As to the "degredation" effect, I also am skeptical. However, if one looks at the "background" processing the occurs within a Windows environment who really knows what is going on? (Don't even think Microsoft does - after all many of the "original coders" have long since disappeared.) If we take, in example, LOCALE.NLS, the "basic" root of all data exchange, automation processing as well as regional processing, you will find over 200 occurances of "short date usage" in that module alone. This can be verified via hex viewers utilizing debug and the good old proverbial "green card" to determine what op codes and links are being referenced. If you take that number of short dates and include the possible combinations of that number there are many potential "cracks" that could appear. Can any of us say exactly what that might cause? I know that I cannot, but I will attempt to prevent situations that could occur with tools that are currently available.

From my time involved with this industry, I have determined my position to be to "fix it before it breaks" rather than "if its not broken don't fix it". That has been my success so far. I really don't care whether anyone utilizes the MFXR products or not, as when (and if) these situations happen, there will only be a limited number of resolution scenarios available.

Again, sorry for the mis-direction of my comment...Tom

-- Tom Sirovey (tsirovey@blclinks.net), December 02, 1999.

Tom;

Thanks, but I've already Got A Life, as it were. 27+ years of it in DP terms, most of it on Big Iron, some of it as a systems programmer, too (believe it or not). I won't bore everyone with the string of acronyms, save to say they're basically the same as yours -- plus a few.

Obviously, I was a little too flippant in my previous response. Allow me to clarify:

I've dealt with stack overflows and the like. I've dealt with memory corruption, I've run out of registers, I've written self-modifying code, I've patched object code in vendor packages (please don't tell them) with a "green card" in one hand and a lot of swearing -- but never have I seen that translate into file corruption on the system level. Not on mainframes. On PC's you usually wind up locking up the system. Either way, though, "stuck bits" are NOT exclusively a Y2k problem. There's no "new technology" here to defend. New techniques, new applications of those techniques, perhaps. Probably.

As far as executing imbedded separators within a date field go -- I stand by my (albeit flippant) comment. Anyone who who writes code (and now I'm speaking from the applications end) who has such a woeful ignorance of the data they're dealing with DESERVES to get burned. (Or probably promoted to "management," where they can do less damage.)

(P.S. I worked with PC's BEFORE there were floppies, and everything was loaded from a cassette tape! Nyaaah!)

Oops. Bell's ringing. Gotta go back to school now.

-- The Whistler (I'm Here, I'm There, I'm Everywhere@so.beware), December 03, 1999.