"I really think most systems will be fixed. I just can't believe they're all going to be fixed. There's just no way. There are just too many systems that need to be fixed, and some systems aren't going to be repaired.

Even if we fixed all of the systems on this planet, we would still have failure because all of the systems have to be tested one against the other. And we basically have glued this global computer network together over a 40-year period, let's say. . . .

So I am an optimist on Y2K. I expect that we will hear good news. But I also think that there will be significant vital systems that will not be operational in time, and I think those will have a domino effect on the rest of us that think that we have fixed our system. And as a result, I think there will be some really significant disruptions on a global basis.

So I am an optimist, but I am also an alarmist on the year 2000 problem. I think that there is at least a 60 percent probability now of a global recession as severe as '73/'74. The reason I use that analogy -- it's really the only one that's available to me that I think makes sense.

In '73/'74, we had the disruption in the supply of oil, and that caused a global recession. Oil is obviously very important for running a global economy.

In the year 2000, I think we're going to have disruptions in the flow of information. And I think information clearly is just as important for running our governments and our businesses as is oil, maybe more so in some ways. And I think that could just as easily cause a global recession as severe as '73/'74.

The analogy is useful, but it's -- actually, there are some differences that should be made. For example, imagine in '73/'74, when you stood -- you know, when you sat in your cars waiting for gasoline at the pump, there were these extremely long lines, very frustrating. I don't think too many people had cell phones back then, so it was a total waste of time. And so your personal GDP just was trashed by sitting around waiting for gasoline. Of course, once you got to the pump you were extremely happy, and you could get on with your life and business and GDP was revived. Even though you might have to spend more for oil, the fact is once it was available, your GDP could recover and, of course, the national GDP and the global GDP could recover.

Now imagine that you were happy as could be, you filled up your tank completely, and within five minutes of driving your engine exploded because that gasoline was contaminated with water. So, now you would have to replace the engine.

And that, obviously, would also be bad news for your personal GDP, while you had to get this thing fixed. And then it's also very expensive to repair something that worked awfully well prior to your filling up with this contaminated gasoline.

This is the likelihood of what will happen in the year 2000. The information may still actually be available, but it will be contaminated. It will be corrupt. I can't tell you how many chief information officers I've spoken to over the past year or so who had this as their number one concern that they will spend hundreds of millions of dollars fixing their own system.

And then come January 1, 2000, some systems 50 degrees of separation away will send some contaminated data that will ultimately wind up passing through their system, and information will be filed in the wrong place because of the lack of coordinating the fix of the year 2000 between the systems, and then you're still going to have one heck of a problem. . . .

What level of business could you do in your own profession if your computer systems were down for two hours? Hey, that's easy. That happens on a good day. Now you get on your cellular phone and make some phone calls. You know, maybe you write a personal note, you know, the old-fashioned way, with a pen. That's no big deal.

What if it's down for two days? Hey, well, all right. Well, you figure out something else to do. Two weeks? Two months? Ask yourself that question. What would happen to your personal GDP? And then add it up and put in the number that you think is the kind of disruption that we're going to have in terms of time. There's no way it's just going to be two hours. No way it's going to be just two days. It's going to be at least two weeks. Two months is kind of reasonable.

Could it be six months of major disruptions to our computer systems? Absolutely. Could it be an entire year? Absolutely. Even if we fix everything in our country, even if we all together get alarmed about it and get the message out and make this the top priority that it needs to be, and freeze all changes, stop, you know, changes of tax laws and stop merger and acquisition activity, just focus on only one thing, even if we did that, the rest of the world would still be in trouble.

Now, I say this recognizing it's a strong statement. But, you know, I think I say it with a certain amount of confidence.

Today, Asia is toast. In the year 2000, Asia will be burnt toast. In Asia, they have a year 1998 problem. Most companies have a 90-day business plan of how they're going to stay in business for the next 90 days. They are doing this month by month over in Asia. They have totally been distracted and resourced away from dealing with the year 2000 problem. . . ."

-- Andy (2000EOD@prodigy.net), May 08, 1999

Answers

. I can't tell you how many chief information officers I've spoken to over the past year or so who had this as their number one concern that they will spend hundreds of millions of dollars fixing their own system.

So Imported Data is a figment of my imagination is it Hoff, Flint at al???

-- Andy (2000EOD@prodigy.net), May 08, 1999.

http://infoseek.go.com/Content?arn=a0643LBY686reulb- 19990505&qt=pakistan&sv=IS&lk=noframes&col=NX&kt=A&ak=news1486 [snip]

INTERVIEW-Pakistan told to reveal more on Y2K

04:24 a.m. May 05, 1999 Eastern

By Ovais Subhani

KARACHI, May 5 (Reuters) - Pakistan needs to make public more information on its Y2K readiness to avoid the risk of being shut out from the rest of the world, an official of leading global chip-maker Intel Corp said on Wednesday.

``There is a potential risk that a lot of countries (and) companies, would refuse to interface with countries that have not brought their year 2000 readiness to the same level as they are,'' Phillip Wong, Intel's year 2000 programme manager for the Asia-Pacific, told Reuters.

``There is very little information'' about Pakistan's readiness ``and it is very important that companies dealing with Pakistan should have the confidence that the whole of Pakistan is year 2000 capable,'' he said.

[snip]

``If you have a system that is so-called non-compliant trying to interface with a system that is compliant, the non-compliant could very well contaminate'' the compliant, Wong said.

``A lot of financial institutions in the world, especially in the West...will have very stiff criteria in terms of banking transactions.

Many of these institutions would question whether Pakistan counterparts' internal systems were compliant and not take a risk that those systems could potentially introduce a bug or erroneous data, he said.

Wong said because there is a general perception a lot of Asian countries lag behind in working on the problem, many companies around the world might avoid them or prefer manual dealing to avoid computer system contamination.

``The general feeling that I got is that a lot of people think, even government officials, that there are very few computers in Pakistan so there may not be any implications,'' said Wong, visiting Pakistan to assess Y2K readiness.

``But a lot of private and government organisations do a lot of their transactions and communications online and there will be implications for them,'' he said.

Wong said overseas companies dealing with Pakistani institutions like banks, airports, airlines and internet users have to have confidence the whole country, including its telecommunication systems, is year 2000 capable.

He said Pakistan has been categorised by researchers as among the countries with the highest risk of being non-compliant.

``Pakistan should start working on contingency plans if they think that they may not be compliant..., but you know this would mean additional costs for private companies, and for that the government should come up with a plan,'' he said.

Wong suggested Pakistan start certififying companies whose systems are compliant and offer tax incentives to encourage companies to meet the standard.

Copyright 1999 Reuters Limited. All rights reserved.

[snip]

-- Kevin (mixesmusic@worldnet.att.net), May 07, 1999

Answers

Obviously, the good news is that, where noncompliance is KNOWN, shutting the door may prevent contamination. The bad news is: .... if countries or banks are misrepresenting compliance, it will be difficult to tell, especially across countries where cross-system testing will most likely be lax.

.... it tends to confirm Andy's contention that the banking system worldwide is subject to data contamination as a REAL threat, not just in theory. Perhaps Hoff can ask Wong for some examples!

-- BigDog (BigDog@duffer.com), May 07, 1999.

-- Andy (2000EOD@prodigy.net), May 08, 1999.

With physical things, it is quite easy to determine where "The Battleship" ends and "The Aircraft Carrier" begins. Not so with software systems.

Software systems have been put into place over long periods of time. While they may have begun life several decades ago as freestanding systems with clearly defined edges, what happens over time is that subsystems are slapped on the periphery. Interfaces are added between previously freestanding systems. Boundaries become blurred.

After an amazingly short period of time, it becomes virtually impossible to know precisely where one system begins and another ends. What is even more difficult to understand is how processing in one system affects processing in another system.

It is entirely probable that due to incomplete historical knowledge, analysts will assume that system A just feeds system B. What is missed is that data that comes from A can pass untouched through B and then trigger something in system C. The connection between A and C can be easily obscured, unless you happen to know about them.

In the real world, of course, it's more likely that data from system A moves passively through systems B through Y and then triggers something in system Z. The chances of the owners of A and Z recognizing their co-dependency is very slim. Now do we understand why testing is expected to consume 50%+ of Y2K project efforts?

Link: http://www.y2ktimebomb.com/Techcorner/DE/de9816.htm

-- Andy (2000EOD@prodigy.net), May 08, 1999.

3. Electronic Data Interchanges (EDI) "The whole world has been running a marathon to seamless integration of all data systems. Now a non-compliant system will become a digital Ebola to any compliant one it contacts. We don't have worldwide standards for either compliance or test strategies."

Another conference participant added: "Even where we are starting to get a handle on internal systems integration testing, no one has even started to think through external testing in our agency."

Link: http://www.y2ktimebomb.com/DSA/VP/vp9821.htm

-- Andy (2000EOD@prodigy.net), May 08, 1999.

The greatest risk for glitches in state computer systems on New Year's Day 2000 could be their connection with outside computers not yet rid of the so-called millennium bug, state officials say.

Most state agencies are expected to eliminate any Y2K compliance problem in their own computer systems by midyear, said Don Mazziotti, the state's chief information officer.

But electronic links with outside computers could cause chaos, he added.

"If we receive a virus through a sneeze, it can affect us," he said Friday at a House committee hearing. "It's the same with data crossing electronic boundaries. If it's not compliant with Y2K, we can inherit the code problem from that system -- and that can corrupt our own system." . . . .

The state's treasury department already has informed outside agencies it won't conduct electronic business with them after Dec. 31 unless they can prove their computers won't infect the state's system. . . . .

Of 76 systems that top officials have defined as critical to state agencies, about half are not yet considered fully compliant, including 16 in human resources and eight at the state police.

Among those considered in good shape are systems that issue checks to state workers and retired public employees.

But as of last week, nine critical systems were listed in the red, including those for drivers' licenses, police access to vehicle titles and registrations, student loans, and computation of inmates' sentences and reductions.

Link: http://flash.oregonlive.com/cgi-bin/or_nview.pl?/home1/...

-- Andy (2000EOD@prodigy.net), May 08, 1999.

Despite achieving a level of Y2K compliance organisations risk exposure to indirect effects. Not every organisation will be Y2K compliant at the turn of the century. Y2K problems in one organisation's computers will almost certainly be reflected in the operations of another. Organisations should be concerned about external links between their systems and others. An organisation may achieve a high level of Y2K compliance but find that its systems are still affected due to corrupted data and information being sent to it by external organisations. This problem could be particularly acute in the retail, banking, manufacturing and finance industries. The difficulties which EDS suffered in 1997, with the inter-bank transaction system, were an example of the impact a computer problem can have on many organisations.

The Government also has exposure to the corruption of its computer systems by others. Many government departments are linked to hundreds if not thousands of external suppliers of data and information. For example, the Inland Revenue Department has links to thousands of employers. The New Zealand Customs Service has links to importers and exporters. Many other government agencies have numerous links with outside organisations. Most government departments have links with other departments. These organisations would be a good place to start in ensuring that linkages are secure. However, it is important for all public sector organisations to assess the compliance levels of those organisations with which they have system linkages.

RECOMMENDATION

That the Government ensure that all critical external linkages and connections between the computer systems of public sector organisations and outside organisations have been identified and assurances of Y2K compliance gained from those outside organisations.

Link: http://www.year2000.co.nz/y2kgov71.htm#Part 1

-- Andy (2000EOD@prodigy.net), May 08, 1999.

Here is what every system, every interconnected company now faces: millions of noncompliant computers that pass along noncompliant data.

There are two choices, and only two, if the vast majority of computers are not made compliant (count on it) and if their individual "fixes" are not recognized, accepted, and correctly integrated by all other computers: (1) the compliant computers are reinfected; (2) the compliant computers lock out the bad data. The first case destroys the repair; the second case destroys the system of systems. This is the problem of interoperability.

A highly critical programmer has argued that programs can be written to screen out bad data. I ask: Can a program screen out ALL bad data? Can it screen out "packed" dates, for example? But no matter. If it screens out bad data, it has screened out the good information attached to that bad data. How will good information be transmitted through the worldwide system of systems, i.e., the information highway?

We are back to the lock-out problem. If the information that was important enough to send and receive by computer cannot be received, it is lost to all those who wanted to receive it. How do these people get access to the valuable information that is trapped inside corrupted data?

How about paper and pen entry? Right: take all the data in all the noncompliant computers in 2000 and hire an army of people fill in entries on paper. Then mail these pieces paper through the noncompliant post offices of the world, where another army of people must re-enter the data into their computers.

Hand entry -- paper and ink management systems -- means the end of the computerized system of systems. It's the end of the world economy. It's the end of the information highway. It's a total collapse.

But programmers don't discuss such matters because programmers do not understand social systems. They understand lines of code. That's what they are paid to understand. If programmer A can design a program that protects computer A from importing bad data, that's all he cares about. That is all he is paid to do. (Managers had better be willing to pay for this service.) The collapse of the system of systems is not his concern -- just as it was not the concern of the programmers a generation ago who created the worldwide self-destruct mechanism.

So, I have come along. I keep asking what are obvious systemic questions that a historian with graduate school-level training in sociology and economics is trained to ask. I ask questions about social systems and institutional survival. And for my trouble, I am dismissed by some programmers as being a mere historian and out of my field.

Maybe so, but one thing is sure: no historian would have recommended dropping two digits in the century's date. Historians deal with dates and sequences of dates. They deal with centuries. They are paid to understand social consequences of individual actions. It was not a priesthood of historians that recommended dropping two digits as a cost-cutting device. It was a priesthood of programmers.

We are now facing disaster because programmers do not think systemically in the area of social theory. They are ignorant, some quite proudly, about social theory. We shall all pay a horrendous price for their intellectual inability to see the systemic social forest for the digital trees. Ones and zeroes do not a society make.

http://www.garynorth.com/y2k/detail_.cfm/1902

-- Andy (2000EOD@prodigy.net), May 08, 1999.

I sincerely do not think the following people understand the implications to all of us of the above pieces.

decker

flint

hoff

poole

rms

y2k prairie dog - and all the rest - you know who you are.

-- Andy (2000EOD@prodigy.net), May 08, 1999.

Andy: thanks for the quotes. I believe you are 1) preaching to the choir to those of us who are GI's. 2) totally unable the convince the DWGI's of the problem. I do not believe it is a matter of information, rather it is the ability to emotionally accept the certainty that our living standards are about to be drastically reduced. The vast majority of folks cannot deal with this issue. Historically, only a few % of folks can react in advance: only a few % of Jews left central Europe, all of them could have read Mein Kampf. In Columbia in the mid 1980's the seismologists warned of an impending volcano event, only a few villagers left, more than 28,000 died in the ensuing mudflow. Only a handful of folks left Pompeii, to the jeers and catcalls of those who stayed behind and died. I have many dear friends and kinfolks who are DWGI. One wrote me the following: "Nothing you can write to me will make me worry about y2k." Another e-mailed me: "I cannot imagine anything that could happen to keep food off the grocery store shelves." This female cousin was telling the literal truth, she indeed cannot imagine it.

Very very sad times indeed...

-- Tennessean (holladayl@aol.com), May 08, 1999.

Andy,

I think it's fine to recap the current thinking and opinions, from time to time, regarding the true seriousness of the Y2k problem. While many of us here are indeed part of the choir, there are also many new people who are just now dropping in to find more information. I recognize every item you posted above because it was part of my basic Y2k education. It isn't pretty but that's the reality. There was even a period where I looked at the Polly side of this issue, since I deeply wished it wasn't going to be so disruptive. However, the Polly side seemed to always ignore the darker predictions and I just couldn't do that.

Tennessean,

I agree with what you say. Perhaps the most frustrating part of this whole mess is that we can't reach so many people, particularly many of those we personally care about. I saw this happen a year ago with some dear friends, and today they are even more deeply entrenched in denial or avoidance. It's that psychological reaction to the information that is so puzzling. I can see that it is alarming and frightening to them to discuss the details. Perhaps psych majors will be talking about this phenonmenon in future years but maybe not. I don't see any definitive reports about the roaring 20s and the crash of that stock market, even tho some noted economists were trying to warn about those dangers.

-- Gordon (gpconnolly@aol.com), May 08, 1999.

Andy, thanks again for all your efforts.

I sincerely believe that we will begin to see an unbelievable amount of effort spent by government and corporations in POSTURING with regard to off loading blame for THEIR FAILURE to correct the y2k problem. Yardeni is setting the groundwork here. The excuses and blame will be laid off on anything and everything in sight.

Ray

-- Ray (ray@totacc.com), May 08, 1999.

Now this is quality work, Andy. Kudos from one who sincerely hopes you keep your eyes focused on the road.

One request: please provide a URL to the Yardeni citation.

-- Bingo1 (howe9@pop.shentel.net), May 08, 1999.

I have been lurking and reading y2k materials for about 5 months. This was a wonderful compilation. I don't have an answer; but I do have a question. Can ANYONE tell me in objective, un-emotional terms why Gary North's systemic theories ARE NOT the closest to the TRUTH of all the expert's educated opinions?

-- Don Forney (talk2don@globalpac.com), May 08, 1999.

Good work, Andy, and valuable. I applaud this, and I'll study it carefully. Definitely deserves attention.

My first reaction is to worry less about 'infection' and more about the rejection rate of invalid transactions. It's one thing to kick out bad data, and quite another to reject an unacceptably high percentage of transactions. If all your food is poisoned, you die just as surely from starvation if you reject it, than by poisoning if you eat it.

I continue to predict economic consequences from grinding inefficiency. And there will be a *lot* of problems of this kind, causing confusion and gumming up the works.

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

Well, Andy, you obviously went to alot of work to compile these links. I will look through them more closely; they deserve more effort than I can give at the moment.

A couple of things, though.

1. Do not attempt to setup a strawman that I've ever said imported data problems do not exist. They do. They do today. I said repeatedly on other threads that was a given. Once again, the two points on the Banking thread were: How will Y2k dramatically increase these, and how do these propogate to other systems. And to date, you haven't been able to give me even one reasonable example.

2. The Oregon quote is a joke. Either the guy was misquoted, or he is totally clueless. You do not "inherit code problems" from other systems by passing data. I actually printed this article off when it was released to show people some of the BS that comes out on Y2k.

3. I've also got some real problems with the David Eddy piece. If I can claim expertise in any area, it is with interfaces. My work involves doing exactly the type of thing David Eddy says is so hard; namely, determining just how systems interact with each other. A typical SAP installation is not a complete, all module, big-bang implementation, but is done piece-meal, system by system. I used the analogy over on c.s.y2k that it is the IS equivalent of a heart transplant. In essence, you take an old, mainframe system, such as AR, and replace it with SAP. In doing so, you have to relink all the systems that interfaced with the old system to SAP. And yes, these interfaces can be found and replaced. It is not magic. I do it on virtually every project.

4. Automated external interfaces, at least in my experience, are just not as prevalent as some seem to think. I've worked with a number of large corporations, and the number of external interfaces, whether EDI or other, is usually very small and controllable. Companies just do not open themselves up to external systems, without rigorous testing and controls in place. What this means is that the number of actual interfaces that need to be tested for Y2k is finite, and mostly manageable. My understanding is that even banking uses a "go-between" for interbank transactions, such as S.W.I.F.T or FedWire. Both, I believe, were requiring testing for institutions using their systems. And it also means a single control point, if an institution is sending corrupt data, to shut down the interface.

-- Hoffmeister (hoff_meister@my-dejanews.com), May 08, 1999.

Hoff,

These are just a FEW pieces on the imported data problem that I cobbled together.

I really do have PLENTY more where these came from. With links, natch.

The problem with this problem though is that it isn't sexy, it will not sell tickets. It's pretty boring really. Not only that, but it's hard to pin down. The quote I bolded above, however, is the most telling. It summs up the fears that any IT manager with half a brain should have uppermosit in their minds - and they do, they do - they just don't want to talk about it publicly, it's a veritable can of worms, it's the BIGGEST SECRET if you like in y2k remediation.

Why? Because essentially the problem is insurmountable, as Gary North's essay above most eloquently points out.

"1. Do not attempt to setup a strawman that I've ever said imported data problems do not exist. They do. They do today. I said repeatedly on other threads that was a given. Once again, the two points on the Banking thread were: How will Y2k dramatically increase these, and how do these propogate to other systems. And to date, you haven't been able to give me even one reasonable example."

I know and accept that you know that this problem is real.

However, in our parryings before, you have come away from our discussions with a puffed up chest, convinced that because I in your eyes could not give you a technical example (which I did but I'm not going THERE again), then you must be correct, and the problem by default is minimised and manageable.

I said above that I believed that several folks, some pretty damn clever in their own area of expertise, either would not or could not grasp the systemic nature of this problem.

I see you are struggling Hoff but I fear that you will prove my assetion essentially correct.

I'm not gonna let this one drop.

As and when I see evidence of this problem surfacing I will be sure to remind everyone of this predator, waiting in the wings.

later,

-- Andy (2000EOD@prodigy.net), May 08, 1999.

The Yardeni link is

http://www.csis.org/html/y2ktran.html#yardeni

-- Andy (2000EOD@prodigy.net), May 08, 1999.

APPRECIATE this posting. It was indeed, even if I sound repetitive, an excellent and thought provoking piece of work. About that thought that most people don't get it. That is so true. It should not change those who are looking. The sad thing is, we are heading down a path we are all unsure of, can do nothing about, and all the preparations will not result in certainties. They may help, but are no guarantees. I personally think, even if Y2K isn't a global disaster, it may certainly be the catalyst. And the fact that we are "ticking to it" is ironic. We know when the bomb will go off, and have no where to hide. Our world will change.....

-- rick shade (Rickoshade@aol.com), May 08, 1999.

Hoff;

regardless of the compliance of SWIFT and FEDWIRE (BOTH of which have been tested and sealed, BTW), the more important problem is the calculations made in the other guy's computer, and passed because it is within expected limits, but VERY WRONG. This will perpetuate bad data every time this datum is accessed and used.

Chuck

-- chuck, a Night Driver (rienzoo@en.com), May 09, 1999.

Thanks Chuck, for pointing out this simple fact, and fact it is.

As for SWIFT and FEDWIRE, correct me if I'm wrong but all data going through the same are carried by satellite links, ground links - communications networks. Which depend on power. And on being compliant. Banks need power - ATM's, POS machines. Routers and hubs and network control centres all need power. And to be compliant. 100% compliant - with each other. EDI/EFT data interchanges internal and external fully tested - 100% - and compliant.

All incoming data to the USA must be 100% compliant from 100% compliant financial institutions. Correct?

40 years worth of layers upon layers of hardware and software need to be essentially 100% compliant with EACH OTHER, WORLDWIDE to contine the seamless (ha!) service we get today.

All evidence says - "ain't gonna happen"...

-- Andy (2000EOD@prodigy.net), May 09, 1999.

This is the likelihood of what will happen in the year 2000. The information may still actually be available, but it will be contaminated. It will be corrupt. I can't tell you how many chief information officers I've spoken to over the past year or so who had this as their number one concern that they will spend hundreds of millions of dollars fixing their own system.

This prophecy was made in 1922 and bears close scrutiny, I think Mr Khan may have been ahead of his time...

"The conveniences and comforts of humanity in general will be linked up by one mechanism, which will produce comforts and conveniences beyond human imagination. But the smallest mistake will bring the whole mechanism to a certain collapse. In this way the end of the world will be brought about."

Pir-o-Murshid Inayat Khan, 1922 (Sufi Prophet)

-- Andy (2000EOD@prodigy.net), May 09, 1999.

No, Andy, the problem is not insurmountable.

As interfaces and systems analysis is my area of expertise, we'll keep going, shall we?

The point of S.W.I.F.T and FedWire was not their internal systems, but the testing being done with the individual institutions. I'll have to dig aroung the S.W.I.F.T site some more, but I believe they opened systems for testing rollover dates last summer, and are requiring institutions to perform tests. Does this prove the indvidual institutions are compliant? No, but it does give an added level of evaluation.

The point here is that, just as they were held up as a possible single point of failure, they also provide a single control point.

The point of asking for an example is simple. Look at this whole "secondary clock" issue in embedded systems. While I know virtually nothing on embedded systems, I've been trying to follow the discussions. In essence, it seems to come down to some theoretical usage, with no examples given, and supposedly no way of testing for the problem. The same is true here. Posting a lot of articles where people are "concerned" is not the same as showing it will collapse the banking system. Far from it.

Yes, imported data can be a problem. Again, no argument. And, as I said on another thread, I can readily come up with example of how Y2k problems could cause errors in autmated issuing of PO's, etc. But I have a hard time coming up with anything in interbank data transfers. The only real cause I could see are residual errors, or errors introduced in the code during Y2k changes, that really have no relationship to Y2k itself. While these could be a problem, they will be spread out, as the systems are reimplemented into production. And to date, you haven't shown any way that these errors could propogate outside of the two entities involved. Again, if this is such a huge problem, one that you claim will collapse the system, I would think that a single example would be a trivial task.

Finally, don't make the erroneous assumption that banks, companies, or anyone, will be treating the rollover and the surrounding weeks as "business as usual". They will not. The controls and processes in place today to catch and handle erroneous data will be doubled and tripled. Banks in particular are doing very rigorous testing with their major trading partners, as are most companies. The ones not tested extensively will be examined closely, to check their actual data.

-- Hoffmeister (hoff_meister@my-dejanews.com), May 09, 1999.