http://flash.oregonlive.com/cgi-bin/or_nview.pl?/home1/... Don Mazziotti, the state's chief information officer:

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." . . . .

Is it possible to explain this process for non-programer types?

Thanks, Les

-- Les (llweil@razorlogic.com), January 28, 1999

Answers

I've worked on a lot of data imports and exports in my time so I'll give it a shot.

First, we have data moving from one computer application to another. Do you download data from your bank in order to balance your checkbook? That data contains the date the bank processed the check.

Second, there are different ways to represent a specific date within the data. Perhaps the date in the bank data is represented in YYMMDD order. Another option is for it to be stored in MMDDYY format. Today's date in YYMMDD format is 990128 and in MMDDYY format it's 012899. So, the same date in each case but 2 different ways to store it.

Now, just so long as the application that is receiving the data is programmed to interpret the date format correctly everything is hunky dory. But now let's say the bank updated their application to include the century in the date but the application receiving the data has not been updated to recognize the banks new format. The bank sends the date in CCYYMMDD format but the application receiving the data is still programmed to process a date in YYMMDD format.

It's hard to say what can happen at that point. Some programs would stop cold, others might pick off the CCYYMM portions of the date and treat it like a date in YYMMDD format. This is a very simple example of how data exchanges could be impacted.

Another data exchange might not include dates at all but still pass bad data that was summarized incorrectly due to a Y2K problem on the system on which the data originated. This is probably the kind of error to which Mr Mazziotti was referring. This is the old Garbage-In-Garbage-Out problem but you can't solve it until you realize the garbage is piling up.

[No true Year 2000 success story can be reported until the year 2000]

-- Bob Benson (appysys@inreach.com), January 28, 1999.

This is oversimplified but here goes anyway.

Computers store information in files (these 'databases' typically containing lists of transactions, customers, and various other records important to the organization).

When two or more computers exchange information, they must first agree on what that infomation will look like (the 'format' of the data). For example, one computer ('A) might pass another computer ('B') the infomation "8190072399012311170512207". Both computers agree that this information represents a transaction on an account and both agree that the data breaks down as follows: "819007" is the account number to which the transaction is applied, "23" is a transaction code (lets say a 'debit' to the account, "9901231117" is understood as a date and time code (Jan 23, 1999 at 11:23am) and "0512207" is the dollar amount, understood to be $5,122.07

Now ignore the date field above because I'm not trying to contrive an example 'Y2K' failure. The real point I'm trying to make is that, in many cases, computer A passes this data to computer B and computer B trusts the data it received from computer A and acts accordingly. It has no real way of knowing whether the data computer A passed it is valid - it simply accepts the data it is passed and processes the transaction accordingly.

Have you ever punched in "300" minutes into your microwave oven when you really meant "30" minutes? Computer A (you) pass the data (300 minutes) to computer B (your microwave) and the microwave didn't question you about it - it happily accepts your command and turns your baked potato into a smoldering cinder.

In reality, transaction records are much more complex and some safeguards are usually, though not always, built in. But the bottom line is that whenever two computers 'trust each other' at some level and one of them begins spewing erroneous data, it can cause problems at the other computer. The nature and consequences of those problems are highly unique to the specific situation. Frequently, just like your baked potato/cinder, you wont know there has been a problem until much later when the smoke alarm goes off.

This is why the people who are in charge of 'fixed' systems are very concerned about the other external systems which 'feed' information to their computer. (i.e. those systems over which they have no direct control)

Computers are not brains, they only blindly follow the commands that are given to them. Like your microwave, they couldn't care less what you really intended. Whether the mistake was made by a 'fat-fingered' clerk or an errant piece of software on a remote computer, the end result is the same - a transaction gets processed which should not have been.

The problem with Y2K is scale. The sheer volume and number of transactions that many computers exchange with each other means that one errant computer can do a lot more damage a lot quicker than one fat fingered clerk.

Hope this helps

-- Arnie Rimmer (Arnie_Rimmer@usa.net), January 29, 1999.

Thanks Arnie, a great explaination to a situation concerning us all. If you were from Hobokin NJ ,they would say "Ya done Good " Thanks again for your info .

-- Newton (newbie@y2kdumb.com), January 29, 1999.

Try this one out, put out to csy2k and not proven wrong, thanks to No Spam please for the legwork on this one... :)

Example -- Bank A (unremediated Bank of Potsylvania) sends Bank B (allegedly compliant ANZ Bank) a funds transfer with the following data:

Date: 2000-01-06 Time: 09:00:00 Type of transaction: Transfer checking-to-checking Source account: Bank A account number 123-456- 789 Destination account: Bank B account number 987-654-321 Amount: $5,435.43

Looks okay. All field data correctly formatted, all numeric fields within bounds. Date is in ISO format with four-digit year. Bank A account 123-456-789 had to have sufficient funds in order for the transfer software to send the transfer request. All fields and parameters pass EDI checks.

Except --- What is not apparent in the transfer data is that Bank A account 123-456-789 was incorrectly credited on 2000-01-06 at 08:31:00 with interest in the amount of $5,555.55 instead of the correct amount, $5.55, because of a Y2k bug. Thus its available balance at 09:00:00 is $5,550.00 larger than it should be. At 08:00:00 the Bank A account's correct balance was $321.00, and at 08:59:59 its balance should have been $326.55, quite insufficient for a transfer of $5,435.43 out of it. But because of that not-yet- detected Y2k bug, that Bank A account's balance appeared to have been $5,876.55 at the time the transfer was requested, and thus was deemed to have had sufficient funds.

Oh, and the Bank A account owner wasn't trying to get away with ill- gotten gains -- she didn't yet know that her account balance was so high, and she was trying to transfer merely $5.43 (an automated request to pay a monthly bill). A Y2k bug related to the other Y2k bug caused her requested transfer amount to be changed from $5.43 to $5,435.43!

To recap the amounts:

Bank A account 123-456-789 balance as of 08:00:00 = $321.00 Correct interest amount to credit at 08:31:00 = $5.55 Correct account balance at 08:59:59 = $326.55 Correct transfer amount at 09:00:00 = $5.43 Correct account balance at 09:00:01 = $321.12

Actual (incorrect) interest amount credited at 08:31:00 = $5,555.55 Actual (incorrect) account balance at 08:59:59 = $5,876.55 Actual (incorrect) transfer amount at 09:00:00 = $5,435.43 Actual (incorrect) account balance at 09:00:01 = $441.12

Bank B account 987-654-321 is credited with $5,430.00 too much as a result of the Y2K bugs. Bank A account 123-456-789 winds up with $120.00 too much as a result of the Y2K bugs. In the given example, Bank A was not Y2K-compliant. Bank B was Y2K- compliant, but now has incorrect data not detectable by edit-checking of the transfer from Bank A.

Bank B's database is now corrupted - yes or no? It has inaccurate data.

Bank A's database is now corrupted - yes or no? It also has inaccurate data.

To further mudddy the waters the account at Bank B has an automatic order to post 20% of incoming funds to charity at unremediated bank C. Obviously the wrong amount gets sent, and who knows what Bank C will do with the data. It will be an almight mess to manually trace back and fix all transaction flows through back office intervention. Multiply this back office intervention at all entities world-wide and you have chaos.

Bank C's database is now corrupted - yes or no? It has inaccurate data.

And so on. Inaccuracies beget inaccuracies.

What does Bank C do with the data? Who knows.

Gives it to the Charity :)

This is the tip of the iceberg.

In many cases transactions will not complete due to, for example, insufficient funds.

If this happens with sufficient magnitude - i.e. mass declines in the credit card world, the inability to trust the validity of data, the banking system will collapse.

More.

The scenario I envision for allegedly compliant bank B (ANZ) at rollover is as follows:-

Bank B will have EDI software in place. This software will allow data into bank B from non-compliant entities word-wide that is correctly formatted and parametered but corrupt. The possibilities are staggering.

Does anyone dispute this - and if so, why?

If this corrupt data can somehow be weeded out then there will be no problem - I accept this.

Can anyone tell me how this can be achieved, at all financial entities, word-wide, in the <180 working days left before rollover (less in most other countries.)???

Now if the type of transaction I described at Bank B runs into serious numbers in terms of quantity of transactions, bank B is in serious trouble. It will process inaccurate data and may fire off this data to umpteen other different financial entities, which will all be facing exactly the same problem, at the same time, world-wide. Databases will be corrupted world-wide. These umpteen other entities may or may not be compliant - they may or may not be processing with faulty date arithmetic - therefore the validity of data throught the world financial system will be suspect.

Result = cross-contamination/infection.

Result = distrust of data accuracy.

Result = Meltdown. Grid-lock. Deadly embrace. No more Banking system.

Andy

Two digits. One mechanism. The smallest mistake.

"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), January 29, 1999.

There was a recent article or thread that discussed the severity of bad data transfers in terms of dollars in stead of just cascading function. For instance, one large non-compliant bank (or securities house?) in Europe could cause $10 billion of damage per day, or something like that. The presumed result was a collapse in confidence in the stock market. Does anyone have the link?

-- Brooks (brooksbie@hotmail.com), January 29, 1999.

Those are great illustrations of the problem on a macro scale; allow me to illustrate the micro-problem.

MS Access and Excel. These databases and spreadsheets are everywhere in a typical organization. The problem? The default settings for date formatting and validation on input forms are not compliant.

In Access 2.0, after entering a birthdate in the most common US format 01/29/23, it puts January 29, 1923 in the database. Do the same thing in Access 97, it puts January 29, 2023 in the database. No error messages (unless custom coded). If your control panel short-date settings are still set to mm/dd/yy, it'll even look right on screen. Essentially the same problem in Excel. Now try to get an average age for your customers, patients or survey respondents. The result is skewed. Maybe not glaringly, because at first, "wrong" birthdates are in only a small number of the averaged records. But after a while, the results are so skewed, they are unusable. Recovery means finding and correcting each "infected" record. (What? You say you threw away the hard copies? And you've been uploading the data to the home office/state agency/federal gov for six months?)

This is one example of how the assumptions built into a system's date-handling can "infect" good, pre-existing data. Fixable? Of course. But it's time consuming, and a medium-sized organization may have hundreds of these puppies. Each one must be looked at.

Admittedly, this is an illustration of the biggest Y2K problem in MS Access (2-year dates prior to 1930 are handled differently in ver. 2.0 , Access 7.0 and Access97), If the system only ever uses dates after 1930, then upgrading to Access97 will probably solve your problems.

Ah but these little spreadsheets and databases aren't "mission critical" you say. Hmmm, well the real problem is; can that homemade application be replaced by a compliant Commercial Off The Shelf (COTS) application? Maybe, but, often these things were written *because* no one made a COTS app to fill the specific need. That's usually why they called me. And, I'm ashamed to say, some of the stuff I built not 3 years ago is not compliant. I'm fixing it, but it's embarassing.

Add in the semi-custom Visual Basic and C apps that use Access databases as "backends", and things can really get hairy.

So les, as someone once said:

"Thanks to the marvel of computers we can now make more mistakes, faster than ever before."

Sleep tight.

-- Lewis (aslanshow@yahoo.com), January 29, 1999.