On Aug 15, 11:11 am, [EMAIL PROTECTED] (daver++) wrote:
"Around 1:30 p.m., the CPB experienced problems accessing its database
containing information on international travelers. Assuming this to be a
wide-area network problem, CBP called Sprint, its carrier, to test the
lines. After three fruitless hours of remote testing, Sprint finally
sent technicians on-site. Another three hours passed before Sprint
finally concluded that transmission lines were not the problem, meaning
the problem was inside the CBP local network. After more hours of
troubleshooting, the issue was finally resolved at 11:45 p.m. The real
culprit: a failed router."http://blogs.zdnet.com/projectfailures/?p=346
20,000 stranded because it took over ten hours to diagnose and replace a
failed router. I used to be a mainframe guy that inherited the network
side, so they cut me some slack. BUT- I can guarantee that there wasn't
anywhere near enough slack for me to get off with taking that long to
replace a router. I would have been tarred, feathered and run out of
town. It seems like basic due diligence wasn't even followed. Yes,
Sprint added to the problem, but Sprint never should have been called.
Why call Sprint before determining that the problem isn't on _your_ end?
It is all a bit silly, and it frightens me a bit that our airlines have
this level of quality.
note that inadequate processes in packet networks contribute significantly to
diagnosing the problems. some of the older protocols were much more
circuit oriented ... and could much more rely on telco circuit diagnostics
to identify problems.
we experience this when we were building reliable network based
infrastructures in the 80s ... and attempting to do some work on
NSFNET infrastructure .... misc. collected old emails
http://www.garlic.com/~lynn/lhwemail.html#nsfnet
and to some extent met with quite a bit of corporate resistance ... somewhat
highlighted in this old email:
http://www.garlic.com/~lynn/2006w.html#email870109
in this post
http://www.garlic.com/~lynn/2006w.html#21
note that while tcp/ip is the technology basis for the modern internet, nsfnet
was the operational basis (interconnections of networks, i.e. internetworking),
and cix was the business basis. in the above reference there is somebody in
corporation proposing that sna could be proposed for basis for nsfnet ...
the main issue was the ability to providing internetworking ... interconnection
of large number of different networks.
we later investigated several of the issues in more detail when we were
doing the ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp
which required a detailed threat and vulnerability study for high availability
environments.
we later got to use some of that experience when we were called in to consult
with a small client/server company that wanted to do payments on their server
http://www.garlic.com/~lynn/subnetwork.html#gateway
they had this technology called SSL and the effort is now frequently referred
to as electronic commerce. the initial simple obvious solution was to
move the payment transaction message formats from their existing circuit-based
environment to a packet-based enviornment. however, that totally ignored much
of the availability, diagnostic, and recovery processews that were available in
the circuit based environment. We eventually developed a set of compensating
processes and procedures attempting to make the availability of the packet-based
environment somewhat compareable to the existing circuit-based environment.
for a little topic drift ... recent comment on availability, diagnosing
and recovery in one of the ATC modernization efforts
http://www.garlic.com/~lynn/2007o.html#18
misc past posts on estimated of 4-10 times the effort to take a well written
application and turn it into an industrial strength service (in the case
of the payment gateway, it was closer to ten times, including inventing
various diagnostic and recovery process to compensate for moving payment
gateway to a packet-based environment)
http://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap
(CS)
http://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... --
Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#15 A Dark Day
http://www.garlic.com/~lynn/2003p.html#37 The BASIC Variations
http://www.garlic.com/~lynn/2004b.html#8 Mars Rover Not Responding
http://www.garlic.com/~lynn/2004b.html#48 Automating secure transactions
http://www.garlic.com/~lynn/2004k.html#20 Vintage computers are better than
modern crap !
http://www.garlic.com/~lynn/2004l.html#49 "Perfect" or "Provable" security both
crypto and non-crypto?
http://www.garlic.com/~lynn/2004m.html#51 stop worrying about it offshoring -
it's doing fine
http://www.garlic.com/~lynn/2004p.html#23 Systems software versus applications
software definitions
http://www.garlic.com/~lynn/2004p.html#63 Systems software versus applications
software definitions
http://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications
software definitions
http://www.garlic.com/~lynn/2005b.html#40 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
http://www.garlic.com/~lynn/2005n.html#26 Data communications over telegraph
circuits
http://www.garlic.com/~lynn/2006n.html#20 The System/360 Model 20 Wasn't As Bad
As All That
http://www.garlic.com/~lynn/2007f.html#37 Is computer history taught now?
http://www.garlic.com/~lynn/2007g.html#51 IBM to the PCM market(the sky is
falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007h.html#78 John W. Backus, 82, Fortran
developer, dies
http://www.garlic.com/~lynn/2007n.html#10 The top 10 dead (or dying) computer
skills
http://www.garlic.com/~lynn/2007n.html#76 PSI MIPS
http://www.garlic.com/~lynn/2007n.html#77 PSI MIPS
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
