is discussed in detail by a COBOL progmmer at the Kitco site posted today 6 6 99 at 15:20 at:

notstupid@bbb.gom), June 06, 1999

Answers

What's the url?

-- fben (fben4077@aol.com), June 06, 1999.

---

Kitco http://www.kitcomm.com/cgi-bin/comments/gold/display_short.cgi

-- Daryl (rushmore@dailypost.com), June 06, 1999.

---

Very good and true point. How DO you tell between a value of "12-31-99" that is meant to mean "infinity" (it is the highest date possible with 2 year digits unlike the 9/9/99 baloney) as opposed to a REAL date of "12-31-99"?. Double use of fields has always and will always continue in the art of programming.

-- br14 (br14@good.one), June 06, 1999.

---

http://www.kitcomm.com/comments/gold/1999q2/1999_06/9 90606.152052.silverbea.htm

This is interesting. I'd like to hear the opinions of some programmers on this. Is it an overlooked problem as Silverbear says? Date: Sun Jun 06 1999 15:20 Silverbear (Y2K-2 ) ID#119246: Copyright ) 1999 Silverbear/Kitco Inc. All rights reserved I've been a COBOL programmer for about 15 years. The shop were I work is diligently working on the Y2K problem but no long ago we realized that making the code Y2K compliant is just part of a much larger problem. Like us, many other large corporations are now discovering or soon will discover that much if not all or their corporate data is saved on records which contain an "effective date" and a "termination date" which is tells the computers processing their data when a given record is "effective". The problem is, when these databases were originally built years ago, the programmers knew the systems couldn't handle dates after 12-31- 1999. So what did they do? They put 12-31-1999 or 12-31-99 in the termination date when the databases were built. To make matters worse, users have been keying termination dates of '12-31-99' on records for years because entering 12-31-00 would end up as 12-31-1900. Worse yet, many programs were coded so that if the termination date was left blank when a record was added, the program would plug it with '12-31-99' or '12-31-1999'. No problem, just change all the termination dates to say '01-01- 3000'? You know how long it takes to do this on trillons of records? And what about all the records that have been added this last year with a valid termination date of '12-31-1999'? How do you tell these records from the ones where the termination date should be open ended? What happens if you make a record with a termination date of '12-31-1999' open ended and as a result it overlaps the dates on another record that is not supposed to become effective until say '01-01-2000' but has already been loaded for next years new pricing, etc? Do this and you end up with more than one record with the same key in effect at the same time. I won't even go into what programs do when they encounter this but needless to say it's not good. To sum it up, we can make every program on the planet Y2K compliant and come '12-31-1999' much of the worlds data is going to cease to be "effective". Fixing this data is going to be just as big or a bigger problem than fixing the code. It will require looking at every single record on every database in the world. It will require massive downtime for systems while the databases are off line during the massive updates that will be required. Worse yet, it will require many more programmers as are currently working on the code to fix this the data in time. Where will they come from? There's not enough time to train more now. You know how many companies test for Y2K compliance? They set the system date on a spare machine greater than '12-31-1999' and then run the production data from yesterday against their current production databases. Guess what? The date of service, invoice date, etc on yesterdays data works fine with the bad data because the date of service, invoice date, etc is still less than '12-31- 1999'. In otherwords, most Y2K testing as it's been done to date has not even identified this problem! Do not look for this on 60 minutes anytime soon. Any shops that are now aware of this will be keeping very quiet until they have time to determine how bad the problem is. You have been warned.

-- mb (mdbutler@coastalnet.com), June 06, 1999.

---

Sorry about the formatting. Try the link. It's easier to read.

mb in NC

-- mb (mdbutler@coastalnet.com), June 06, 1999.

---

---

mb in NC: We used FILEAID Dataager to add various aging factors to effective dates, termination dates, and any other that were important. These were windowed as any other. Also did some conversion programming for dates not handled by Dataager. I know this does not handle all of the problem as you state it, because you still have to distinguish between the 2 meanings of 12/31/99 (if that is present), just that not everyone will trip on this.

-- curtis schalek (schale1@ibm.net), June 06, 1999.

---

Welcome to Y2K. Just another story, in a book of ???????'s <:)=

-- Sysman (y2kboard@yahoo.com), June 06, 1999.

---

don't worry, pooleCrETin has a screwdriver...

-- Andy (2000EOD@prodigy.net), June 06, 1999.

---

And Andy has a bunch of loose screws. Sounds like we got the makings of a deal here.

-- Flint (flintc@mindspring.com), June 07, 1999.

---

loose women more like, arf arf!

-- Andy (2000EOD@prodigy.net), June 07, 1999.

---

---

Double use of fields as described above has never been in the art of programming. On the contrary, it's evidence of complete incompetence.

What a true programmer might do is use an "out-of-band" value. In the case of dates, there are plenty, for example any day exceeding 31, any month exceeding 12. (This is if he's not free to add a new field to the database, which is "the right thing" to do)

Mostly, inappropriate use of 31/12/99 crept in via the clerical types using computer systems, as a consequence (probably) of users and programmers being kept apart by managers who know what's best, who never talk to the users about what's actually needed, and never talk or even listen to the programmers because they don't understand anything about computers.

Which is of course how Y2K got to be a problem in the first case.

-- Nigel Arnot (nra@maxwell.ph.kcl.ac.uk), June 07, 1999.

---

Nigel, I disagree. Although not intentional, the double use of values occurs all the time, even by "true programmers" (whoever that is). In this case the programmer wishes to designate a date as "high as possible" that will still pass the edit routines.

Unless a file conversion is in your future (now THAT's fun at 4 in the morning!), i.e. extending the year field(s) from 2 to 4 bytes, "12/31/99" is as high as they go baby. No mas. Now, how do you differentiate between a REAL 12/31/99 value and a HIGHEST value represented by 12/31/99? Sure, you can use windowing but we're talking about large, old systems. On a HUGE Fed Govt mainframe project I worked on we used "40" as the pivot year (anything over was 19xx, under was 20xx. 12/31/39 was NOT used as the highest date...which by our windowing standards it was. Try telling the end-user (I believe you referred to them as "clerks") who is trying to enter data that "Oh, just put in this special date; 12/31/39, it will work).

Don't get me wrong it can be fixed...if you have the time. Just convert all of the files, change all of the programs that use the fields in those files, change all of the screens, change all of the report layouts, change all of the documentation on operating the app. and finally change the habits of all those "clerks". Tough task.

-- br14 (br14@good.one), June 07, 1999.

---

Definitely a problem! We have a few workstations where, over the years, 12/31/99 was used as an actual trigger date on some tasks, but as a dummy date on others - hey, it's a user decision! We had to create a report that scanned ALL dates in the system and reported each 12/31/99 occurrence. The users had to scan these reports and determine which dates were real and which were dummy. With 23 million records and several hundred dates in each record, well, just glad I didn't have to scan those reports! But they are getting fixed......slowly but surely.

Deano

-- Deano (deano@luvthebeach.com), June 07, 1999.

---

"But they are getting fixed......slowly but surely." Deano, I thought I remembered that your company was compliant as of 12/31/98??

-- Brooks (brooksbie@hotmail.com), June 07, 1999.

---

just not fast enough,eh deano?that's why we need to take our money out of the banks and cash out our stocks

-- zoobie (zoobiezoob@yahoo.com), June 07, 1999.

---

---

Brooksie - We are compliant. Our clients have some cleaning up to do now that the entire system can handle 2000 dates. We're a service bureau, not a mortgage company.

This has nothing to do with your money in the bank. But it's definitely the best place for it. Always has been, always will be.

Deano

-- Deano (deano@luvthebeach.com), June 07, 1999.

---

Just a rhetorical question: how about EXPDT=99365 in MVS JCL?

Jerry

-- Jerry B (skeptic76@erols.com), June 07, 1999.

---

br14

You aren't talking about the art of programming. What you're talking about might be called many things: at the risk of offending some, I'd call it the prostitution of programming.

If I saw a specification that called for this abomination, I'd try to get it changed. I'd try very hard. If it wasn't possible, I'd want to detach myself from the project and/or the employer as soon as possible, because it would mean that the folks I was working for were dangerously incompetent (ie thinking that causing a many-to-one mapping could sensibly be unmapped at a later date despite the irrevocable destruction of information that many-to-one involves).

Of course, then end result will be that the incompetent employer will end up paying peanuts for monkeys who just do what they are told and call themselves programmers, and sooner or later TS hits TF in a big way. I'm not doubting that this has happened in plenty of cases, I just objected to it being called art!

-- Nigel Arnot (nra@maxwell.ph.kcl.ac.uk), June 07, 1999.

---

The author of the Kitco article has shown his total lack of understanding of not only programming, but the industry in general.

In my almost 30 years of doing applications design and creation, I have never heard of this. His assertion [come '12-31-1999' much of the worlds data is going to cease to be "effective". ] is totally ludicrous.

In the literally tens of thousands of applications programs that I have either developed or worked with, this type of delimiter has **never** been used. If ever a date delimiter has been required as a "never expire" date, that date was a ficticous one (invalid date) such as 99/99/99 (Gregorian) or 999999 (Julian). Very easy to test for in the code, and very easy to isolate.

Furthermore, the authors assertion that [It will require looking at every single record on every database in the world. It will require massive downtime for systems while the databases are off line during the massive updates that will be required. ] is also absurd. Even *IF* someone was to initiate such a search, it would be a READ-ONLY function which would allow the database or file to be available to it's normal application during the search.

Additionally, the author goes on to say [No problem, just change all the termination dates to say '01-01-3000'? You know how long it takes to do this on trillons of records? ] I must say that the updating of a trillion records would not be a small task, but certainly not a monumental one for a medium/small size mainframe shop with a 100 MIP (Million Instruction Per second) machine. The part of this task that would take the longest would be the backing up of the data prior to the updating of it.

In other words, this article was literally pure BUNK.

Yours in COBOL... Dino!

-- COBOL Dinosaur (COBOL_Dinosaur@yahoo.com), June 07, 1999.

---

I fail to understand why a professional group, such as you programmers, cannot agree on anything!! This is very frustrating...I am certainly glad you are all not Doctors and have to make a life and death decision...the person could die while you were arguing over whether or not the the procedure was correct. Jish!!!! No wonder y2k is so confusing to people!!!!!!!!!!!!!!!!!!!!!!!!!!

-- Moore Dinty moore (not@thistime.com), June 07, 1999.

---

Well folks, for DECADES, the IBM mainframe operating systems, both OS (MVS) and DOS (VSE) used 99/365 to mean KEEP FOREVER on disk and tape file labels. Then, they invented a new day, 99/366, to mean KEEP FOREVER. Yes, this was the pre-compliant days... <:)=

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

---

Moore Dinty:

Actually, you are gaining valuable insight into how programming is really done. Like sausage and law, you don't want to watch it being made.

I start a job with a functional specification -- here is what we want this thing to do, and here are our restrictions (size, cost, weight, form factor, whatever). Pick the cheapest parts that will meet the spec. Write the code to make it work. Do it any way you like, any way you can. We want it tomorrow.

Standards? Hoo Haw! If it's complex, I might start by drawing a block diagram or a rough-and-ready flowchart. Then off into the code, heigh- ho! Got a problem here? Dream up something that'll work and keep going. Oops, that caused problems somewhere else? What time is it? Prety late, I'll kludge around it, a few flags, an exception here or there to register usage protocol that's evolved so far, so what? Comment it later (if I get the chance). Besides, this code is pretty self-documenting. These mnemonics look reasonably descriptive to me. TXA? BST? Obvious, right?

Next day, into test mode. Um, doesn't work. Fire up the old emulator, set some breakpoints, oops, forgot all about this thing here. Good thing I left some patch space. Bang in some code, link it up, much better. A few hours of this, the phone rings. Yes? New feature you want? Uh, OK, when? No schedule change? Uh, OK, right.

Well. The new feature doesn't fit AT ALL with the way this thing ended up working. Can't redesign now, more patching, more kludging, hope I remember why I did this if I ever get to document the damn thing.

A few days of this and voila! A working prototype. And nobody else in the whole world knows what I did or how it works, and nobody cares either. It works, on to the next thing. If anyone ever asks for the documentation, I'll write some. Programming in action.

-- Flint (flintc@mindspring.com), June 07, 1999.

---

Flint,

I think you've got it! Only one question... Why, then, are you such a "polly?" Ever try and fix any of that old "last minute fix" code? You know, that 35 year old stuff, that has been putzed with by countless programmers over the decades! Sorry, two questions... <:)=

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

---

Sysman:

Yes, I've done so many times. That is, I've *tried* to do so. Please understand that I don't work in IT. Typically I have 2-4K of ROM space and 64-128 bytes of RAM. Most code in these parts is completely asynchronous - the main loop does nothing but wait for events. Events trigger state machines, and the states have been massaged beyond recognition, because they can interrupt one another, leading to intricate timing considerations and many undocumented patches to add a clock here or set a mutex there.

So most of the time, I'm lucky enough that it's *much* faster to discard the whole mess, reverse-engineer the functional spec, and start over. Why spend a few weeks studying that mess trying to figure out *precisely* why someone did *this* (to alter the timing maybe? Because of an overloaded RAM location maybe? Who knows?). I can write it from scratch in a week and meet the spec, because I no longer need to deal with the patch history or the modification history.

I think a lot of this has been going on behind the scenes, at least at my level. Where do you think compliant replacements come from?

-- Flint (flintc@mindspring.com), June 07, 1999.

---

Evenin' Flint, just a couple of things first:

"the main loop does nothing but wait for events."

You'ld do pretty good at "Windows" programming.

"Typically I have 2-4K of ROM space and 64-128 bytes of RAM"

If tou were doing "Windows" you'ld need a MEG or so just to get your feet wet.

"Where do you think compliant replacements come from?"

No doubt, hardware and software VENDORS are doing a bunch of work. It's all that CUSTOM WRITTEN code that I'm worried about. Jeez, we have a small mainframe and have over 3,000 programs to deal with. Times 50,000 mainframes, some HUGE! All custom written. Cobol, Fortran, Assembly, PL/1, RPG, CICS!!! ALL had DATE issues until not that long ago. Then there's all those other computers, like PCs, AND mid-range stuff, like the AS/400, and, and, and...

And, not looking for trouble, but the Cobol guys have it pretty easy. Their world revolves around "CURRENT-DATE." Oh sure, you can PACK it, or make it BINARY, or rearrange it to YYMMDD so it sorts nice, but the Cobol crowd doesn't really do anything fancy. Not like the Assembly guys. I worked on a system, very date oriented, that converted each part of YYMMDD to binary, and "packed" the whole thing into two bytes! I wonder how some of the Y2K "tools" deal with this... <:)=

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

---

Sysman:

Sounds like a waste to me. 5 bits for day, 4 for month, hell, you don't need more than 5 bits for year, it won't last 32 years will it? Naw, I *need* those other two bits. Can't be wasteful, now.

-- Flint (flintc@mindspring.com), June 07, 1999.

---

Flint, we used:

YY - 7 bits

MM - 4 bits

DD - 5 bits

Actually, if you start YY with 0 = 1900, this way is good-to-go, 'til 2027. But that's a whole 'nother story, with reports, and screen layouts, and forget about all those hard-coded 19s, and that sorta stuff, but it still "sorts nice" 'til 2027... <:)=

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

---

Flint,

I can understand the creating process just fine..it's the fact you guys can't agree on what is or is not a problem..even the medical profession tries and retries medications when searching for a cure..but one doesn't usually argue over how they function...yes, the heart has to beat, yes, the blood must flow in certain directions...liver must function...etc etc...they have parameters they can follow...lab results/ xrays...all know what is normal or abnormal or functioning etc. You guys on the other hand don't agree on much of anything...one says something and another disagrees with importance of it...But, thanks for answering anyway...I appreciate the response.

-- Moore Dinty moore (not@thistime.com), June 07, 1999.

---

Hi Dinty, long time, no talk.

Programming really is a free-for-all. A programmer can comment only from their own experience. Some haven't seen any real date problems with the projects that they have worked on. Some have. Some can't see beyond their own, tunnel vision, experience. Some can. I don't claim to know any more than the next guy, but I have seen computers do some really funky things with dates. Some haven't. <:)=

-- Sysman (y2kboard@yahoo.com), June 08, 1999.

---

(Miss one little ">", and look what happens ...)

-- - (-@-.-), June 08, 1999.

Moore Dinty:

I guess I didn't make myself clear. There are no standards. Not even 2-digit-years was a standard, and not everyone used them. Some programming practice might cause horrible problems in one shop, but be used nowhere else. As Sysman said, there's no way to tell.

In one area where I work a lot, PC BIOS, the totally different ways of doing exactly the same things were done very deliberately, to avoid copyright restrictions. We speak of NIH - the "Not Invented Here" syndrome. There might be a perfectly workable way to do things, but programmers re-invent it anyway, to make it proprietary or just to prove they can do it better.

It's not that we're disagreeing, really. We agree that in programming, the "no two alike" principle rules. I tried to explain how that principle comes to be.

So programmers tend to extrapolate (incorrectly) based on what they know. Non-programmers extrapolate based on what they *don't* know. Neither method is very informative, the problem is that *no* method is informative. There are no standards.

-- Flint (flintc@mindspring.com), June 08, 1999.

There are as many opinions in IT folks regarding Y2k as there are opinions by any other segment of the population, on ANY topic. If (for whatever reason), one feels that the government has caused them harm in the past, they tend to be less willing to believe remediation reports from the government than someone who has never felt this harm. If one (regardless of race) were attacked and beaten by a group of another race, they tend to be less willing to believe that there are good people amongst this other race.

If a person in IT has worked for one firm all their adult life, and saw that firm remediated, they have no real reason to believe that other firms are in worse shape. If a person in IT has worked for another firm all their adult life, and see that firm unable to be completed in time, they have no real reason to believe that other firms are in BETTER shape.

I've worked on various remediation projects for 15 years (believe it or not some firms WERE on the ball.) At some sites an actual expansion to 4 digit centuries were included as part of another project. I've worked on other remediation projects where sliding windowing was used for remediation and saw the code tested (in phases) and moved back into production, where it failed and was promptly fixed. I've worked on projects that converted entire Assembler systems to COBOL II. This was NOT fun if the system was huge, but was quite rewarding if a project only had a FEW assembler programs to convert. I've worked on projects where complete systems were pitched and a new system developed in its stead. Of course if a firm is going to the trouble of converting a system from one language- set or platform to another, the date issue will be handled at the same time. I've seen conversions to SAP successful and conversions to SAP fail completely. I've seen firms continue to remediate old systems while SAP installations were ongoing (just in case.)

I mention all this only because a fellow contractor recently asked me if I'd been sucked into Y2k remediation. She told me that 90% of their business in FoxPro recently is in Y2k remediation. I work on big iron and she works on small/medium systems. For my locale, the big iron work is complete and many contractors are out of work waiting for firms to lift their freezes. In other areas of the country, there is still work to be had, as Cory mentioned regarding the last-minute project from hell in D.C.

Personal experiences tend to taint our perspectives of outcome, whether we're in IT or not.

Anita

-- Anita Spooner (spoonera@msn.com), June 08, 1999.

And, taking the real overview (that I always try to take here), these guys have just told you why I don't expect total meltdown on 1/1/2000, or any other date.

NOBODY, and I mean NOBODY is writing programs just like anyone else. Thus, many companies NEVER HAD ANY REAL Y2K PROBLEM. For others, the best solution is to START FROM SCRATCH. And, of course, some will wait till the code breaks, and worry about it then. And a great many of them will actually succede in patching things up well enough to get by. Honest, it really is what they are doing to keep running right now.

And now you can see why there are so many filters for bad data in place around the world - and THAT is why the 'crashing dominos' just does not apply to the mainframe world.

Anita, Flint, Sysman - was it really fair to burst people's illusions and let them peek into the real world of programming? Here they have had this ivory tower image - and now you show them the cracks in the tower.

-- Paul Davis (davisp1953@yahoo.com), June 08, 1999.

Flint, Sysman, and Anita...think that was all of you...

Thanks for your time in helping me understand part of the "interpretation" problem. I guess I had pictured a much more precise profession. After all, when one little thing is wrong on my computer it goes nuts...just shuts itself off!:> Seemed reasonable to think that little glitches from y2k would have same effect. Will mull over info and continue to read .....Thanks again

-- Moore Dinty moore (not@thistime.com), June 08, 1999.

Moore Dinty moore:

You wouldn't believe how many things are going wrong inside your computer all the time. Especially if you run Windows. Most of them are benign, many are annoying, and a very few make you reboot. Windows (last I read) has over 5,000 documented errors, which doesn't count any applications you're running. Explorer (last I read) is well over 1,000 known errors.

There's a reason they don't want to ditch those legacy systems -- they've been debugging them for decades. When some IV&V outfit says they found, say, 750 errors per million lines of code, I'm impressed. That's damn near perfect, relatively speaking. It's a small miracle a lot of our software runs at all.

-- Flint (flintc@mindspring.com), June 08, 1999.

Flint,

That is interesting information. Are you implying that errors they are finding will not cause any problems??

-- Moore Dinty moore (not@thistime.com), June 09, 1999.

Moore - it's worse than that (more confusing, that is...)

If enough right things go wrong at the right time, nothing happens (that you notice), therefore everything appears fine.

If one right thing goes wrong at the right time, nothing happens (that you notice), therefore everything appears fine.

If one wrong thing goes wrong at the right time, nothing happens (if the computer the computer freezes), therefore everything appears fine, until you try to do something that won't work, then nothing work right.

We could go on like this ......

-- Robert A. Cook, PE (Kennesaw, GA) (cook.r@csaatl.com), June 09, 1999.

Moore:

What I'm trying to say (and what Robert Cook is saying as well) is that the *impact* of any given bug is contingent on factors beyond comprehension even in theory. You might have an error in your program that will do horrible damage only under highly unusual circumstances, which might never arise. With the possible exception of very tiny programs in closed systems, a great deal of what's going on inside your computer is undefinable. Even then, I'm assuming perfect hardware.

Again I emphasize the importance of testing. Many y2k errors are main- line errors, meaning they'll be encountered by normal processing, handling normal situations. Errors of this type tend to show up immediately, and in obvious ways. This (I believe) is what Gartner was referring to in saying that 70% of the problems would be cleaned up in three days. NOTE that this assumes remediation has been essentially completed, and we're cleaning out the ones we missed. You aren't likely to be able to handle redesigns in three days.

The important thing to remember is that by definition, we can handle (or live with) ANY errors in noncritical systems, and we can handle noncritical errors in critical systems. We can even handle critical errors in critical systems if they're rare enough.

If a practice has been to use 12/31/99 for two different purposes, this is NOT a 3-day fix. This will be a constant nightmare for quite a while, generating problems that will most likely cause a hull breach and have impact outside the organization. Very long hours, and hellacious customer support for a long time.

Everything lies in the details, and the details are for practical purposes unknowable. That's why major meltdowns and no problems remain supportable right up until they either happen or they don't.

-- Flint (flintc@mindspring.com), June 09, 1999.

No, not unknowable.

Y2K from IT perspective = Russian Roulette with five bullets in the gun (the empty chamber is the famous "bump in the road"). We just don't know where in the body we will be hit and whether we will die, be incapacitated or merely wounded.

Lovely.

-- BigDog (BigDog@duffer.com), June 09, 1999.

In the movie contact as Jodie Foster was getting suited up and ready to go on "the trip" she is handed a little vile of poison...to paraphrase the tech guy, "We can think of a thousand reasons why you might need this...but mostly, it's for the ones we can't think of."

Paul, how can you compare a "12-31-99" or a 99999 problem with the 1/1/00 problem? Aren't these two very different fish?

Mike =================================================================

-- Michael Taylor (mtdesign3@aol.com), June 10, 1999.

"You might have an error in your program that will do horrible damage only under highly unusual circumstances, which might never arise."

I think you've almost got it Flint. If we call the error a "design" error, and substitute Y2K for never, which is true since we have never seen Y2K before, I think I agree with you! Another minor miracle! <:)=

-- Sysman (y2kboard@yahoo.com), June 10, 1999.

Yes we had a well-ised database at Commercial Union in the UK which used expiry dates of 12/31/99, it was recognised early on and a work- around produced. (I forget what it was but have some documentation on the subject).

PS if it hadn't have been fixed that single problem alone would have brought all systems crashing down, they would not have found the Reference data needed by many programs.

-- dick of the dale (rdale@coynet.com), June 10, 1999.

The 12/31/99 problem is really the same 1/1/00 problem... just in reverse. If the expiry dates aren't fixed but the 1/1/00 dates are, then what? It all boils down to the same thing, when the rollover happens, TSHTF.

I did work on a system which used this practice. One important thing to note 99/99/99 was an invalid entry for the operating system so 12/31/99 HAD to be used. The system was originally designed back in the '70s. The company had plans underway to change the dates to 4 digit years, and convert the files, and clean up the programs (back in '96). But with 5 million + lines of COBOL to go through, and all the different possibilities of field names...who knows if they will ever fix them all.

Oh...by the way, this company sell it's software to over 200 fortune 500 companies, if the software's not compliant then those companies are not compliant. So when a company says it's not sure about it's vendors... you can bet it's referring to the Software Vendor.

DJ

-- DJ (reality@check.com), June 10, 1999.