Bob - you are obviously fairly intelligent but that does not mean
that you are immune to short sightedness or are wearing blinkers. And
having worked in IT, it seems to me that you are focussing in areas
that you are experienced in, not necessarily the way to approach
looking at the big picture. Throwing in a few straw men of systems
that are wasteful now "hey, we're screwing up now, so 2000, we'll be
able to get by with a few more screw-ups, just like we are now, we'll
muddle through"... this is naive in the extreme (I'm being polite).
We are all worried about the Iron Triangle, if we lose any of these
three we are in deep merde : Banking, Communications, Electricity.
I would put Electricity at the top.
I know about Banking, this is my field, so Bob, consider the
following comments from your peers, (mainly) programmers in at the
deep end, like yourself, but slightly more switched on I would wager.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"how long will it be until they (VISA/MC) notice it is bad data? Not
everything will "look" contminated until each person gets his bill in
early-mid Feb 2000. And even then, many people will probably have
good statements. Or maybe none will.
After how many milion transactions, some of which will be good ones,
of course, some will be mixed up good ones, and some will be
fraudulant "good" ones taking advantage of the confusion.
Adding: Each transaction (worldwide) represents a merchant's and a
supplier's life. Without these legitimate sales, the merchants can't
continue in business. Without real expectation of getting repaid from
VIA/MC/AMEX to their bank account - these guys would be better off
not selling - not accepting any credit, but rather relying only on
cash.
Then you have the run on the bank starting - for those who've not
already pulled their money out."
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"I think you just illustrated the full magnitude of the problem. It's
worldwide, especially in the financial arena, it's highly
computerized, and bad data can get propagated. Firewalls and filters
only work to shut off the sources of bad data. If it's a financial
business you simply can't disconnect the spigot without also shutting
off the flow of money. Oh, my."
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"Ask yourself just *one* crucially important question. Why the hell
did Visa issue x million credit cards (via the issuing banks) to
umpteen banks worldwide with expiry dates of 2000-2001 when the
software, be it at Visa, the Banks or POS (point of sale) terminals
could not handle it?"
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"Somebody also mentioned triage or workarounds (Paul) - i.e. cutting
off mainframe to mainframe discourse from the USA to/from certain
countries...logical idea and valid... but not in this lifetime. Who's
gonna make the decisions, who will be the central point, who will
swallow the legal implications...? Good idea, proposed before, but in
the time frame and with the "leadership" we have now, unworkable. The
very thought of this would collapse the world banking system..."
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"One good reason why bad data *will* be received is that it won't be
bad in the sense you are talking about (scrambled - garbage). It
might just be inflated or deflated numbers, a product of faulty
calculations. No interface program is going to do validity checking
like that. That would presume one knew the range of the numbers
coming in before they came in.
> This is the misguided, unsupported Gary North idea of "corrupt"
data
See, you are calling invalid data corrupt data. Corrupt is corrupt.
Invalid can be either corrupt or deceptively out of range.
Even corruption will be received, though, in some (maybe many) cases.
That is because the interfaces (between bankA and bankB) are going to
be buggy. IMO, the interfaces will be the last piece of the puzzle to
get tested ..... way too late.
I've done interface testing and the number of "surprise" failure
conditions that arise when interfaces change is astounding. There is
no way to quantify it or explain it to somebody that has not done the
testing of interfaces. They are quirky at best - total wild animals
on their worst days. And 00 will bring in their worst days."
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"Date-dependant calculations have nothing to do with data-interchange
validations routines. What Andrew is pointing out is that non-
complient programs will produce data that is wrongly calculated;
these errors will spread magnitudianlly throughout the global
financial system. Validation routines between data interchanges
simply verify that the parameters are correct: not the calculations
forming the data. This is the meaning of corrupt data: bad
information, not bad parameters. Andrew (and Gary North) are
precisely correct. You are espousing the "misguided, unsupported idea
of "corrupt" data " equalling bad parameter transfers. That is
incorrect and a straw dummy. Corrupt data = data correctly
parametered yet wrongly calculated. Wrong calculations beget wrong
calculations ad nauseum. Within 24 hours of the turnover, the Global
Finacial System will either A)be completely corrupt B)be completely
shut down so as to avoid A. The result is the same in either case;
even if we don't go Milne, you are going to see a mess bigger than
you can imagine. Alan Greenspan was entirely correct when he stated
that 99% is not good enough. We will be nowhere close--not even in
the ballpark. The engines have shutdown; the plane is falling--we
simply haven't hit the ground yet. Scoff if you must; as a
professional working with professionals, I know the score. It's going
down. This is why at least 61% of IT professionals are pulling their
money out before it hits--of course, in 10 or 11 months, that number
will rise to 100%; but then, it will be to late. We know for a fact
that that 50% of all businesses in this, the best prepared of
countries, will not perform real-time testing. As a Programmer/Test
Engineer, I can therefore assure you that at least 50% of all
businesses in this, the best prepared of countries, are going to
experience mission-critical failures, Gartners new optimistic spin
not withstanding. Remediation sans testing is not remediation. The
code will still be broken, just in new and unknown ways."
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
">The "amount" of a financial transaction is typically not
"calculated" >- it just "is". If I lay down a charge card for a
$49.95 purchase - >the amount is not "calculated" and then sent to
Visa - it just "is" >$49.95.
Unless you are in Timbuktu.
That's where the interconnecting banks with their currency conversion
programs come into play.
>And to top it all off, the Visa machine has to echo back to me the
>amount that I agree to pay for - if there is some "miscalculation" >
(sic) or mis-transmission of the amount (and what would 1/1/2000 have
>to do with that?), then I will simply not agree to authorize that
>other amount.
Precisely. There will be a magnitude of "declines" in the trillions,
ergo the collapse of the Banking System."
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"I have been a computer programmer since 1961, and programmed in at
least 15 languages for mainframes and personal computers.
Several respondents, including Bill Moquin on July 27, have
challenged your statement that non-compliant data can infect a Y2k
compliant computer. However, their reasoning always seems to be that
the non- compliant data would appear in the form of a date that will
be edited by the receiving computer and found to be erroneous and
thus rejected.
They are failing to consider that the non-compliant data may be in
the form of the result of date arithmetic done on a non-compliant
computer and an erroneous answer that appears to be compliant
transmitted to the compliant computer.
For example, if a non-compliant system determines in error that some
payment should be made or some product should be shipped, and
forwards that information to a Y2k compliant computer system in
error, the receiving system (bank?) may merely edit for accurate
account number, valid amount, valid item number, etc, and perform
debits and credits of the amount or issue a shipping manifest, thus
compounding the error. The compliant receiving system would thus have
participated in an erroneous, non-compliant transaction, and its
accounts would not be correct."
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"On April 16, 1996, the Assistant Secretary of Defense in charge of
y2k testified before a Congressional committee. He offered this
warning:
"The management aspects associated with the Year 2000 are a real
concern. With our global economy and the vast electronic exchange of
information among our systems and databases, the timing of
coordinated changes in date formats is critical. Much dialogue will
need to occur in order to prevent a 'fix' in one system from causing
another system to 'crash.' If a system fails to properly process
information, the result could be the corruption of other databases,
extending perhaps to databases in other government agencies or
countries. Again, inaction is simply unacceptable; coordinated action
is imperative."
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"Here is the assessment of Action 2000, which the British government
has set up to warn businesses about y2k. The problem is not just
software; faulty embedded chips/systems can transmit bad data:
"In the most serious situation, embedded systems can stop working
entirely, sometimes shutting down equipment or making it unsafe or
unreliable. Less obviously, they can produce false information, which
can mislead other systems or human users."
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"A bank that is taken out of the banking system for a month --
possibly a week -- will go bankrupt. But if it imports noncompliant
data, it will go bankrupt. A banking system filled with banks that
lock out each other is no longer a system.
There is no universally agreed-upon y2k compliance standard. There is
also no sovereign authority possessing negative sanctions that can
impose such a standard. Who can oversee the repairs, so that all of
the participants in an interdependent system adopt a technical
solution that is coherent with others in the system?
Corrupt data vs. no system: here is a major dilemma. Anyone who says
that y2k is a solvable problem ought to be able to present a
technically workable solution to this dilemma, as well as a
politically acceptable way to persuade every organization on earth to
adopt it and apply it in the time remaining, including all those that
have started their repairs using conflicting standards and
approaches.
Some people say that y2k is primarily a technical problem. Others say
it is a primarily managerial problem. They are both wrong. It is
primarily a systemic problem. To fix one component of a system is
insufficient. Some agency in authority (none exists) must fix most of
them. Those organizations whose computer systems are repaired must
then avoid bankruptcy when those organizations whose systems are not
compliant get locked out of the compliant system and go bankrupt.
If there is a solution to this dilemma, especially in banking, I do
not see it."
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From Federal Computer Week
"Interface Issues
While most policy-makers have focused on creating awareness and
ensuring compliance, most agencies have not addressed the problem of
interfaces, or how communications with the outside world will affect
compliant systems. What happens when systems are linked and defects
are passed over networks?
"You may have a system in which you address the problem, but that
system also talks to five or six or several hundred systems, and they
may be passing you bad data which you think is good data, and if you
process [that data, it] will give you a bad answer on your machine,''
said Terry Zagar, chief scientist for BDM Federal Inc.
To ensure compliance among systems, the National Institute of
Standards and Technology has instituted a federal information
processing standard change notice that strongly urges all agencies to
use four-digit year elements. OMB has endorsed this standard for
adoption by federal agencies. In addition, the Year 2000 Interagency
Committee decided "early on'' that it would request a four-digit year
on data exchanges.
One hang-up, however, is that the standards are voluntary, and while
they recommend four-digit year elements, they do not specify a
sequence for the day and month elements of an eight-digit date.
Again, time is of the essence.
"I think what is important is the fact that we all are ready, and we
all can recognize which century we're in when we try to do date
calculations,'' SSA's Draper said. "But whether we put the date
before the month or the month before the date I think is immaterial
as long as we know what we're getting and can react to it.''
Most agencies should make an inventory of interfaces when they look
at and analyze their source code and data, said Ken Heitkamp,
technical director of the Air Force's Standard Systems Group, Hanscom
Air Force Base, Mass.
"Certainly if systems aren't going to be brought into compliance at
the same time, then the interface is going to have to be of
concern,'' he said."
Link http://www.fcw.com/pubs/fcw/0819/y2k/main.htm
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From Westergaard's site.
"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
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From Ed Yardeni
"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...."
Link http://www.csis.org/html/y2ktran.html#yardeni
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Bob, I'm really not sure if you are just having a laugh, but this is
a useful exercise anyway.
Cheers, Andy
-- Andy (2000EOD@prodigy.net), December 19, 1998.