Sorry if this has been addressed here, but can someone post some links that refute the GN contention that he always makes, and claims that no one answers. That being:

"But if their information containers -- software and hardware -- are bad, they can't use our compliant information, if any, and their systems will re-corrupt ours. "

It is claimed that overseas non-compliant banks, phone companies, businesses, etc. are going to re-corrupt any computer system they exchange data with. North did once list a US Govt document that did indeed look very ominous re: this matter.

Anyway, if this is true, then I better move my estimation up to a 9 or 10 like good ole Gary. Surely with all the polly wisdom on this forum someone can put up the links that explain why this won't happen?

thank you.

-- Walter Skold (wsvnsk2@juno.com), July 16, 1999

Answers

Without specifics of exactly what data is supplied in what circumstances, it's impossible to refute (or confirm).

However, there's a chain of circumstances that seems relatively unlikely. First, data extering organisation A has to be corrupted as a result of a Y2K bug, without the management at A being aware that the corruption is going on. Then, the resulting corrupt data has to become part of a transaction with B, and again fail to be detected as corrupt, in this case by B. It seems to me much more probable that A's system will crash, or A's corrupt data will fail to pass B's data- validation, or that someone at B will notice the problem quite early and "pull the plug" on A until they prove that they've fixed their bugs.

Also it's exceptionally unlikely that a telco problem could corrupt data passed from A to B. In general, bad problems at the telco will be seen by A and B as a complete failure of service, with no data exchange being possible.

These aside, the question is basically "how bad will it be"? I don't think anyone can know until next year.

-- Nigel Arnot (nra@maxwell.ph.kcl.ac.uk), July 16, 1999.

Corruption is essentially a question of computerized trust. Each system might or might not have careful screening of incoming data, called "edit/capture". Typically, once you have data in a system and then pass it from program to program, there is virtually no screening.

For instance, the motor vehicle transaction that takes keyed data (from the person at the front counter) has very careful edits to make sure that all fields are correct, and then inserts a new record into the database. Later that night, the program that prints the new license is not going to have real tough screening - it assumes that the database record is valid. The programmer who wrote the batch print program trusted the person who wrote the transaction. Might be the same person.

Y2k remediation can cause problems in this situation, because the remediation may have been done by outside contractors. The original writer may be long gone. It might be VERY appropriate now to have tougher edits of the data, but that would not normally be part of the contract. In a situation with bad specs and loose control, one contractor may have fixed one program one way, not matching how another was fixed. Could get pretty nasty.

Each system has some degree of this editing when it gets data from outside, as where the motor vehicle system passes some information about new vehicles to the driver licensing system. How much editing goes on depends on who wrote each system, whether the programmers in one thought that the programmers in the other knew how to code, etc. If they had good standards, they'd do good edits. In the real world, you screen what you don't trust.

So you typically do a little editing on data coming from sibling systems - motor vehicle to driver licensing, for instance. And you do tougher edits on files coming from outside your organization, particularly if you've been burned. An example here would be records of vehicle sales coming from a trade group - you'd check that more carefully. Data corruption from Y2k is not as likely as some suggest, because screening is typically fairly good.

Some sloppy shops are going to go right down the tubes on bad data, going to load it directly into databases without so much as an EOJ crossfoot. This is the recorruption scenario. It's gonna happen. Some will reject the input, halt the process, down the feed line, and sail ahead without that data. Some can't live without that data, and will die. Some won't even notice the bad data coming in, until they've been fatally wounded.

Notice the precise terms I've used: "pretty tough", "not as likely", "fairly good". It all depends on the programming standards, on the attitudes of the system designers and programmers, on the atmosphere of the place. Notice particularly the extensive use of the term "some". We have no clue how many will fall into each category.

Gosh, this is a fascinating year.

-- bw (home@puget.sound), July 16, 1999.