Previous IssueIndexInfoSearchingSubmit ArticleFTPDo not even think about clicking on this button

The Risks Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

 

Volume 18: Issue 96

Monday 31 March 1997

Contents

o END OF VOLUME 18
Peter G. Neumann
o Computer model blamed for $83 Million loss
George C. Kaplan
o Greenwich Mean Time just changed by one hour
Scot E. Wilcoxon
o GPS glider pilot confused
Philip Overy
o Printing with different resolutions in MS Word 7.0
Thiemo Sammern
o Re: Crackers Obtained Gulf War Military Secrets
Gene Schultz
o Millennium Bug: latest sighting
Pete Mellor
o Re: More Y2K Cost Estimations
James Byers
Martin Minow
o Re: Risks Associated with the Year 2000 Problem
Jack K. Horner
o Y2K: the revenge of originality / reserved words in Cobol
Henry G. Baker
o Re: Retiring hardware after Y2K
Barry Brown
o Y2K risks and Cobol
Jason D Lampert
o The unique risks related to Y2K
Peter Wild
o Info on RISKS (comp.risks)
---------------------------------------------

END OF VOLUME 18

"Peter G. Neumann" Mon, 31 Mar 1997 8:31:17 PST
The end-volume issue (RISKS-18.97) is available on the ftp site as
risks-18.00 in the main directory, and is now also in the new subdirectory
18 as both risks-18.00 and risks-18.97 -- along with the rest of volume 18.

---------------------------------------------

Computer model blamed for $83 Million loss

George C. Kaplan Sat, 29 Mar 1997 17:25:35 -0800
The *Wall Street Journal*, 28 March 1997, reports that the derivatives
trading unit of Bank of Tokyo-Mitsubishi Bank Ltd. has incurred an loss of
$83 Million as a result of a computer model that overvalued a portfolio.
The problem came to light last summer, when the model was revised.  Another
model-related loss, $139 Million by National Westminster Bank PLC is also
mentioned.

The article points out the risks of increasingly complicated derivatives
portfolios, which are so complex that traders have no choice but to use
computer-based models to evaluate them.

But other sources point out that the real risks are the old familiar ones of
trusting the computer too much.  Thomas Coleman of TMG Financial Products
Inc. says, "I've never seen an options model which, when used for the things
it was meant to do by people who understood it, has caused a $50 million to
$100 Million problem."

George C. Kaplan  gckaplan@cea.berkeley.edu  510-643-5651

---------------------------------------------

Greenwich Mean Time just changed by one hour

Mon, 31 Mar 1997 08:44:14 -0600 (CST)
On my Linux machines, I keep the hardware clock on Universal time to avoid
time-zone problems.  One machine is used for both Linux and MS Win95, so I
set the Win95 time zone to "Greenwich Mean Time".  At least that's what the
map on the Control Panel called it.  I'm in the U.S.A. Central time zone,
six time zones west of Greenwich.

This morning, Monday 31 March 1997, Win95 reported the time had been changed
due to Daylight Savings Time.  DST doesn't begin in the USA until next
Sunday, and I see that I had left the "Adjust for DST" checkbox set on the
Win95 Control Panel.  I then checked and apparently British Summer Time did
indeed start yesterday in England.
  http://www.greenwich2000.com/timefaqs.htm

But Win95 still labels that time zone as GMT, not BST.  If you're trying to
use Universal time on Win95, check your clocks today.

  [http typo fixed in archive copy.  PGN]

---------------------------------------------

GPS glider pilot confused

Philip Overy Thu, 27 Mar 1997 14:25:15 +0000
Well, our club has now met its first lost pilot who was flying on GPS
"lead and follow" when his box went wrong: At our airfield, GPS needs a "watch
out for parachutists" function too; Although one might argue that this is not
a risk of having the navigational aid, but of using it to the exclusion of all
else, the truth is that at our sort of height none of the navigation methods
are perfect - maps plus turning points are not that easy to cope with - so the
lure of GPS will be hard to resist. When height-capable GPS-based devices
begin to drive map displays and provide warnings, there will be real problems
if such laptop or instrument-panel-mounted "aids" ever fail. I'm sure gliding
clubs will make rules regarding GPS, however will the GPS device manufacturers
consider the uses to which their products are being put?. When you buy quack
medicines in a pharmacy, there is (in the UK at least...) a warning to "consult
your doctor if symptoms get worse" - perhaps there should be a warning on GPS
systems to learn navigation before you depend too much on this aid?.

Phil Overy  Computer security officer RAL, CLRC, UK tel (44) (0)1235 (44) 5834

---------------------------------------------

Printing with different resolutions in MS Word 7.0

Thiemo Sammern Sun, 30 Mar 1997 14:06:44 +0100
This story could be interesting for comp.risks-readers. Please note, that
it isn't a Y2K-problem :-)

I recently installed a new HP LaserJet printer in my father's law office.
As most new laser printers it is capable of printing with a 600dpi
resolution.  One of our secretaries has her own printer connected to her
workstation. This printer is an older LaserJet model and has only 300 dpi
resolution. Sometimes she prints on her small printer and sometimes
(especially longer and double- sided documents) on the new printer. We use
Win95 and Word 7.0.  After about a week she told me, that the printout
sometimes differs a lot between the two printers. It happens quite often
that some lines in our documents contain only a few words and the rest of
the line is filled with dots or dashes. She knows about the possibility to
set tabs with filling characters but doesn't want to use it. So she makes
loads of dots and dashes in these lines manually.  It happened, that these
lines were printed different on the two printers.  The printout on her small
printer was always correct, but when she switched to the other printer the
last dot or dash of the line jumped to the next line and so sometimes
changed the whole page.

I found out, that this behaviour didn't occur when I set the new printer
back to 300dpi resolution (the same resolution the old printer has).  I
think the problem lies in the "GetTextWidth"-function in the Windows API or
the way Microsoft Word uses it. This function returns the number of dots a
character (or textstring) needs as an integer value and therefore is only a
coarse approximation of the correct value. If the function is called for
each character in the line separately a possible rounding error gets
multiplied. And I think this happened in our case. Word calculated different
textlengths for the same text on different printers.

The risks?  Sometimes single pages of the documents are printed selectively
because of typos or new data. The above mentioned error could have lead to a
change in the page layout, maybe moving important parts of the document to
another page not included in the new printout. I don't want to imagine the
effects :-(

I hope this message lets some people take a closer look at their printed
documents.

Thiemo Sammern, St. Lorenz 444, 5310 Mondsee, Austria-Europe
+43/6232/54006  tsamm@ping.at http://members.ping.at/tsamm

---------------------------------------------

Re: Crackers Obtained Gulf War Military Secrets (RISKS-18.94,95)

Gene Schultz Mon, 31 Mar 1997 09:07:00 -0800
The recent set of news articles and net postings are the result of an
interview with BBC late in January 1997 in London.  BBC was trying to do a
story on breakins into banks in London.  They persuaded me to supplement the
content with an example of what could happen if security is lax in another
arena---the military.  I shared with the interviewer, Riccardo Pollack, an
account of breakins into U.S. military computers during Operation Desert
Shield/Desert Storm.  What I told him was that I headed the U.S. Department
of Energy's Computer Incident Advisory Capability (CIAC) (which I founded
and kept going for 3.5 years despite working in an extremely adverse
political and managerial environment that ultimately caused the entire team
with the exception of one part-time person to quit).  The AP news story that
followed somehow distorted this by claiming that I was the head of computer
security for the Department of Energy.  Actually, I had responsibility for
running the CIAC team and for developing the team's procedures and
operations was clearly mine -- as the project manager.

Second, the AP news story quotes me as saying that top-secret information
was stolen.  This assertion is totally inaccurate.  I would say, however,
that a considerable amount of information that was not designated with any
sensitivity labels was stolen from U.S. military computers.  The fact that
so much sensitive/critical information was stored on computers that were so
easy to reach and break into is beyond all comprehension.  What was perhaps
worse, however, was that the U.S. Government didn't really deal with the
incidents very well at all.  Turf wars between agencies (as well as within
LLNL) were a constant problem, for example, and nobody within the Government
really seemed to have jurisdiction over the case.  One of the main FBI
players at one point told all other incident-response teams who were
producing information about the attacks to "butt out" because he wanted to
work only with the one particular response team he favored.  One of the
Government agencies ordered that a computer that was being used very
productively to monitor the intruders be shut down to avoid further trouble,
even though the compromised computer was not a sensitive one.  In short, the
whole situation was a real "three-ring circus."  Some day I hope to document
the whole fiasco.  Meanwhile, I have already provided a lot of details in my
Congressional testimony in November 1991 and also in a paper published in
the Proceedings of the 1993 Department of Energy Computer Security Group
Workshop.

I'd like to help more by providing more information, but I'm off on a
three-week consulting stint overseas.  Again, I'd encourage those who have
so greatly contributed to the confusion surrounding the BBC documentary to
simply purchase the tape (videotapes are now publically available) and find
out what was really said.

Gene Schultz, Program Manager, SRI Consulting

---------------------------------------------

Millennium Bug: latest sighting

Pete Mellor Fri, 28 Mar 1997 11:48:24 GMT
My friend and colleague Norman Fenton 
---------------------------------------------

Re: More Y2K Cost Estimations (Schroeppel, RISKS-18.95)

James Byers Sat, 29 Mar 1997 05:25:53 -0500
I encourage anyone interested in a "serious discussion" of Y2K costs to read
Capers Jones' article "THE GLOBAL ECONOMIC IMPACT OF THE YEAR 2000 SOFTWARE
PROBLEM" in full (http://www.spr.com/library/y2k00.htm).  Indeed, Jones
estimates the long term global economic impact of Y2K fixes, downtime,
litigation, etc. at $1.6E12.  Sound excessive?  Perhaps, but Jones presents
a substantial case based on function point metrics rather than "lines of
code" metrics used in analyses by the Gartner Group and others.

A disturbing feature of Jones' analysis is his casual and frequent
disclaimer about the potential for inaccuracy in many of his assumptions.
He notes that his charts are "rough approximations" and have a "high margin
of error."  Skeptics such as myself do not swallow these statements easily.
While Jones presents a substantial body of evidence, more rigorous surveys
of real data on the Y2K dilemma are sorely needed.  Yet time again seems to
be against us, as surveys with the depth and breadth of information needed
for better Y2K cost approximations would likely not be completed nearly in
time to be beneficial.

We can only hope that Jones grossly overestimates the cost of this whole
affair.  One thing is certain, however: the more informed believers and
skeptics alike can be on the issues surrounding Y2K, the better.  Blind
judgements on the issue will only increase the potential for a catastrophe
on 1/1/2000 and beyond.

James Byers - byers@cornell.edu - http://www.people.cornell.edu/pages/jwb19


Re: More Y2K Cost Estimations (RISKS-18.94,95)

Martin Minow Fri, 28 Mar 1997 14:01:49 -0800
My RISKS article might have been clearer in noting that the total cost
refers to the total global cost, not just the cost in Sweden (see below) I
skimmed the report (and recommend it highly). Jones estimates the total cost
for U.S. software at 70.8 billion dollars (with a "large, but unknown margin
of error").

Capers Jones also describes loss of data center productivity, estimated as
10% (best-case), 25% or higher (most probable), to 35% (worst case).

"Although this data has a high margin of error, it appears that the repair
costs for the year 2000 problem may be one of the largest single technology
expenses in human history."

Jones' article concludes with estimates for thirty countries. Sweden is at
the bottom of the list, with an estimate of 267,188 effort-months, or 2.87%
of the American effort. (Again, with warnings for incorrect assumptions.)
Swedish burdened salary costs are almost 10% higher than America [I ought to
move back] and the Swedish total cost is estimated at $2.4 billion, with the
total for all countries estimated at almost $300 billion.

The Swedish text may (repeat, may) be in error regarding the per-capita
cost. Capers Jones gives the following estimate for Sweden:

Burdened Salary:       $9,200 / month
Total effort months:   267,188
Total repair costs     $2,458,125,000

Estimating 8.5 million citizens, this yields $289 dollars/person for Swedish
costs. However, Freese estimates 240 billion SKR, roughly $34 billion, or
$4000 / citizen. I don't know why Freese's cost estimate is about 6 times
higher than Jones, but suspect that they're measuring different things.

Capers Jones is the author of Applied Software Measurement (McGraw Hill,
1996). What little I've seen of his work, appears to be serious and well
thought out, if perhaps a bit over-precise for my tastes.

Martin

  [Also comments on Capers Jones from Rob Bailey 
---------------------------------------------

Re: Risks Associated with the Year 2000 Problem

"Jack K. Horner 120775" Thu, 27 Mar 1997 11:10:33 -0700
  [This is message sent to Rick Light 
---------------------------------------------

Y2K: the revenge of originality / reserved words in Cobol

Henry G. Baker Mon, 17 Mar 1997 14:02:43 -0800 (PST)
Re: programmers who use random words for identifiers in Cobol:

I have argued [1] against certain features of programming languages
that 'blow up' the number of identifiers that a programmer has to come
up with.  Interestingly, although do-while loops save labels, Dijkstra
[2] leaves it up to Wirth & Hoare to make this point with regard to
the 'case'/'switch' construction: "...it eliminates the need for
introducing a large number of labels in the program".

A previous posting mentioned that Cobol has something like 300
reserved words.  I have argued [3] that languages _not_ use real words
for their reserved words, because
 * unreal words are much easier to spot by both experienced and non-experienced
   programmers;
 * every programmer must learn the reserved words anyway, and using
   real words like 'begin' or 'loop' wastes our visual bandwidth, and
   seduces non-technical types into thinking that they can 'understand'
   the program--a very dangerous situation;
 * by using real words as reserved words, some of the best and most
   mnemonic words have already been stolen by the language.

Of course, PL/I's 'cure' is far worse than the disease; parsing PL/I's
'nonreserved' reserved words is a nightmare for both computers and people.

1.  Baker, H.G.  "A Source of Redundant Identifiers in PASCAL
Programs".  ACM Sigplan Notices 15, 2 (Feb. 1980), 14-16.  Available
on my web page.

2.  Dijkstra, E.W.  "Goto To Statement Considered Harmful".  CACM 11,3
(March 1968), 147-148, reprinted in CACM Oct. 1995.  Available on www.acm.org.

3.  Baker, H.G.  "Strategies for the Lossless Encoding of Strings as
Ada Identifiers".  ACM Ada Letters XIII,5 (Sep/Oct 1993), 43-47.  Available
on my web page.

Henry Baker  ftp://ftp.netcom.com/pub/hb/hbaker/home.html

---------------------------------------------

Re: Retiring hardware after Y2K

Barry Brown Mon, 24 Mar 1997 16:39:01 -0800 (PST)
To what extreme do we have to take this?  The world is spending money now to
update all of the computers to four-digit years.  Who's to say we won't have
to do this all over again with our 8000-year-old programs when the year
10,000 approaches?  Are we being shortsighted by not implementing five- or
six- or more-digit dates right now?

Barry

---------------------------------------------

Y2K risks and Cobol

"LAMPERT, JASON D" Fri, 28 Mar 1997 09:51:40 -0500 (EST)
The following is taken from Monday March 24, 1997 edition of the
*Gainesville Sun* in the Worklife Section:

  A renewed use for COBOL

  Cobol, a programming language created in the '50s and in decline through
  most of the '80s is in the midst of a revival.  Cobol is the language that
  enables old mainframe computers to correctly handle dates after the year
  2000 [!!!].  Consultants SPR Inc. in Oakbrook, Ill has trained over 65
  nonprogrammers in it in the past year, with 15 more now enrolled in the
  two-month Cobol "Boot Camp."

  [Corporation X] drills "newbie" programmers in a one month course.  At
  Columbus State Community College in Ohio, Cobol enrollment has jumped by
  a third.  Even a home-study course has emerged, promising Cobol
  proficiency in three weeks.

Going beyond the error in fact about Cobol in the above article, okay, so we
have the Y2K problem, which involves scanning millions of lines of code, and
rewriting thousands of them, then debugging the new code, then testing it.
And to this very complex and difficult project we're going to assign someone
with a 3 week home study course in cobol.  Not just a little risky.

Jason Lampert, Computer Support Specialist, UF Dept of Plant Pathology
Jdlamp@gnv.ifas.ufl.edu

---------------------------------------------

The unique risks related to the Year 2000

Peter Wild Mon, 31 Mar 1997 02:11:50 +0000
These are some of the RISKS associated with the first real Information
Technology {IT} project that demands fixed functionality to be delivered on
a fixed date. ........

1. Many installations do not contract for their development & testing
capacity to be included in their Disaster Recovery Contracts with
organizations such as Comdisco, Sunguard and IBM.  This must be done now
because, in the event of an outage, there will be an increasing need to test
& develop Y2K solutions.

2. The cost of all resources will increase and they will become more scarce
as more are drawn towards the Y2K work which will increasingly pay more.  We
are already seeing consulting staff leaving engagements (which are not Y2K
related) because they have been hired away by other firms.  Also rates are
beginning to increase.  Even mainframe tape cartridges are beginning to
become more scarce the same will happen to other commodities such as DASD,
computers etc. It will also become increasingly more serious as people begin
to place larger, speculative orders to protect themselves - the siege
mentality.

3. There are attorneys who, today, are employing people to cut out every
reference any company official is making in the press about their corporate
Y2K process and readiness ... so they can be quoted if there is a law suit
because they failed.

[...]

peter.wild@worldnet.att.net

---------------------------------------------

Previous IssueIndexInfoSearchingSubmit ArticleFTPDo not even think about clicking on this button

Report problems with the web pages to the maintainer