Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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.
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
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]
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
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
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
My friend and colleague Norman Fenton <nf@csr.city.ac.uk> seems to attract the Millennium bug. Instances of it follow him around like storm clouds following a rain god. Here is his report of his latest sighting:- I actually witnessed a millennium bug in action last week at a hotel. The receptionist was trying to enter a renewed membership (which had arrived by post) for the health club on the computer system. The member in question had paid for a 3-year membership which was therefore to expire in March 2000. The system used 2-digit years. The year 00 was rejected (it was clearly treating it as 1900 because it came up with an error message something like 'date expired'). The receptionist in the end decided to enter the date 31Mar99 as the expiry date. Hence this unsuspecting member is being cheated out of 3 months membership. I wonder how many similar transactions are taking place all over the world at this moment. Norman [Note added in archive copy: Well, you get the idea. That must be either 31Dec99 or 9 months. PGN]
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
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 <wm8s@pobox.com>. PGN]
[This is message sent to Rick Light <rxl@LANL.GOV> in response to a forwarding of a comment on the appended message from the U.S. House Science Committee, particularly relating to those Y2K problems resulting from the omission of the "19" in the calendar year. It is reproduced with the permission of the author. PGN] The problem is potentially much messier than just the occurrences of the literal value "19" in date types. ANYTHING in software that merely _acts as if_ the first two digits of the date are "19" will have insidious effects. About a year ago, I worked on an analysis of the Global Positioning System (GPS) ground station code to try to characterize the Y2K problem. We found no less than ten types of manifestations of the problem in a survey of a randomly selected sample of 10% of the code. The occurrence of the literal value "19" was only one of these ten types. Other types included type overflow problems at various dates throughout 1999, Y2K arithmetic that implicitly assumed no dates later than 31 Dec 99 were possible, and implicit module-interface date-type conversions. These problems are potentially infinite in their variety, and not all can be detected with tools. Furthermore, in GPS it is not possible to construct good test cases to see what will happen at the millennium start, because the future (time-) states of the system depend on physical values (orbital elements, pole wander, Jovian gravitational force) that can be determined with sufficient accuracy only from the actual operation of the system within about three months of the time of interest. Approximately 1% of the total GPS code is affected by this class of problems, or affected it. The GPS user-equipment code is in even deeper trouble because of the Y2K problem, and the breakage will occur well before Jan 1, 2000. Date, in the GPS signal standard, uses exactly thirteen bits (these bits represent a time-unit offset from a conventional epoch date). This allocation is burned into proms on all existing GPS user equipment. On about August 20, 1999, the actual date value will overflow this 13-bit type, and the equipment will fail to produce correct time or position information. Best estimate is that there are ~10^6 pieces of user equipment that will be immediately affected. Everybody who depends indirectly on those pieces of equipment (meaning all the rest of us) will also be affected. The GPS standards committee is desperately trying to figure out what to do with the problem. Various well-calibrated software estimation models (SLAM, REVIC, PRICE-S) predict that fixing the Y2K problem in systems of about 500,000 lines of code or larger will take more time than is available between now and the year 2000, regardless of how many programmers are thrown at the job. Most of the US's military command-and-control systems contain more than 500,000 lines of code. GPS is now the primary means of distributing time standards throughout the US, and throughout much of the world. (The accuracy of the atomic clocks on board the GPS satellites is second only to those maintained by the primary standards clocks in Washington.) Thousands of large financial computers ultimately take their time calibration from GPS, every day. Interest on overnight multi-billion-dollar short-term electronic-funds transactions is computed at millisecond granularity, derived from the GPS standard. Place your bets. Jack Horner, CIC-8 <>Notice From: <>United States House of Representatives <>Committee on Science <>F. James Sensenbrenner, Jr., Chairman <>George E. Brown, Jr., California, Ranking Democrat > <>CONSUMER RISKS ASSOCIATED WITH YEAR 2000 PROBLEM CITED <> <>Washington, DC — Rep. Constance A. Morella, chair of the Committee on <>Science's Subcommittee on Technology, along with several of her <>colleagues sent a letter today to the Clinton Administration requesting <>information on the Year 2000 problem. <> <>"We initially thought the problem affected just computer software and <>programs, but we are now learning that the magnitude and scope of the <>Year 2000 challenge seems to be growing beyond just computers," Morella <>stated. "If consumer products which contain microchips are affected, we <>need to know whether agencies are addressing this fact and whether the <>American public is being adequately informed." <> <>The Year 2000 problem involves embedded microchips which are present in <>many every day conveniences such as microwaves and elevators. Most of <>these products have internal timers which are programmed with the "19" <>prefix. When the year 2000 is ushered in, computers which are <>programmed with the "19" prefix will interpret the year to be 1900 - <>not year 2000. Some experts are predicting that if corrective actions <>are not taken by the year 2000, businesses and possibly some sectors of <>the government could face operational and fiscal disasters. <> <>"The Year 2000 problem poses a daunting challenge to consumers, <>businesses, and government alike," said Representative Bart Gordon, <>ranking Democrat on the Subcommittee who also signed the letter. "I <>look forward to working with Chairwoman Morella to increase the public's <>awareness of the potentially catastrophic consequences if the Year 2000 <>problem is not addressed." <> <>The letter was drafted after a hearing last week in which several <>witnesses reiterated their concerns about potential serious safety <>consequences associated with the Year 2000 problem. One study discussed <>predicted that more than one-half of all organizations world-wide will <>not fully complete the Year 2000 effort. <> <>"If the long-term forecast for the Year 2000 problem is dismal, there <>must be a realization of failure, and new strategies must emerge from <>this realization," Morella said. She also said the response to the <>inquiry would assist her Subcommittee with identifying Year 2000 <>situations which may affect the health and safety consequences of <>consumers. <> <>In addition to Morella and Gordon, the letter was also signed by <>Representative Stephen Horn, chair of the Government Reform and <>Oversight Committee's Subcommittee on Government Management, <>Information, and Technology and Representative Carolyn Maloney, ranking <>Member on the Subcommittee on Government Management, Information and <>Technology.
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
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
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
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
Please report problems with the web pages to the maintainer