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…
Extracted from the Arpanet-BBoards archives. --sra [NOTE DATES...] Date: Wednesday, 11 December 1985 09:55-EST From: Dan Hoey <hoey@nrl-aic.ARPA> To: ARPANET-BBOARDS@MIT-MC.ARPA Re: Software alert: DATE-86 ReSent-date: 14 Dec 1985 03:05:52 EST ReSent-from: Arpanet-BBoards-Request@MIT-MC.ARPA Early this year a message appeared on ARPANET-BBOARDS commemorating the ten-year anniversary of DATE-75. A somewhat more ominous anniversary will occur in four weeks, on 9 January 1986. Users of the TOPS-10 operating system should beware of software failures beginning on that date. DATE-75 is the name of a set of program modifications applied to the TOPS-10 operating system, running on DEC PDP-10 computers. Before the modifications, the TOPS-10 system could only represent dates between 1 January 1964 and 4 January 1975. The DATE-75 modifications added three more bits to the representation of dates, so that dates up to 1 February 2052 could be represented. To maximize compatibility with existing software, the three extra bits were taken from several unused positions in existing data structures. The change was announced in mid-1974, and several tens of person-years went into updating software to recognize the new dates. Unfortunately, reassembling these bits into an integer representing the date was somewhat tricky. Also, some programs had already used the spare bits for other purposes. There were a large number of bugs that surfaced on 5 January 1975, the first day whose representation required the DATE-75 modification. Many programs ignored or cleared the new bits, and thought that the date was 1 January 1964. Other programs interpreted the new bits incorrectly, and reported dates in 1986 or later. Date-related program bugs were frequent well into the Spring of 1975. On 9 January 1986, the second bit of the DATE-75 extension will come into use. Users of software developed in the 60's and early 70's on the TOPS-10 operating system should beware of problems with testing and manipulation of dates. Beware especially of programs that were patched after manifesting bugs in 1975, for in the rush to fix the bugs it is possible that some programs were modified to assume that the date was between 1975 and 1986. Any date that is off by a multiple of eleven years and four days is probably caused by this type of bug. Dan Hoey
Since my original posting on this I've received enquiries as to whether there has been any follow up in the UK press. I hadn't seen any until today's Guardian, which carried the following (excerpted) article: MEDICAL SCHOOL FACES RACE INVESTIGATION By Andrew Veitch, Medical Correspondent The Commission on Racial Equality is to launch an investigation into discrimination against blacks at one of Britain's leading medical schools, it was disclosed yesterday. Sir Peter Newsam, the CRE Chairman, is invoking its rarely used legal powers under the Race Relations Act to investigate the way in which St George's in south London selects its students. This means that CRE officers have satisfied the commission that there is prima facie evidence that the Act has been breached. [...] The inquiry follows the Guardian's disclosure last month that the school was using a computer programme which deliberately downgraded non-white applicants. Two of its consultants, Dr. Aggrey Burke and Dr Jo Collier, ran applications through the computer and found that being a non-Caucasian female lowered the applicant's ranking by up to 20 points - probably enough to reject a candidate who would have been accepted on academic performance alone. The programme was designed to mimic the decisions of the selection committee, which it replaced. The academic board scrapped the programme after being given details of the consultants' investigation. ... Brian Randell - Computing Laboratory, University of Newcastle upon Tyne UUCP : <UK>!ukc!cheviot!brian JANET : brian@uk.ac.newcastle.cheviot
Garnered from a report just now heard on NPR's All Things Considered: BBC reporter speaking of the investigation of the crash of the airliner carrying Mozambique President Samora Machel: Based on official transcripts of the cockpit conversation before the crash, when a ground proximity alarm sounded, the (soviet) pilot ignored the alarm, believing it to be malfunctioning. The investigation also noted evidence that some of the instruments appeared to have been tampered with after the crash, fueling speculation by the soviets that the plane had been lured to the site by a false navigational beacon.
I think that the concept of loosely-coupled systems can be very well applied to software engineering, although perhaps not in the way Wexelblat quotes Meldman as saying. There, the model seems to be that computer systems as a whole don't communicate well, and therefore prevent massive "data rot," as it were. That's as may be, and I may be reading it wrong anyway. But I see this as a very good model for the kinds of things we do in modularisation of software, information hiding, defensive programming, and the like. We try to make sure that errors in one part of a system don't propagate to other parts, by building bridgeheads against them (testing for bad data), not tightly coupling data values (controlling import and export), et alii. Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} jsdy@hadron.COM (not yet domainised)
>From: Nancy Leveson <nancy@ICSD.UCI.EDU> > According to my FAA source, the FAA is not >thoroughly comfortable with this, but the autopilot is only flight-crucial >on this aircraft during about 45 seconds of the landing. Also, their tests >have found that pilots can successfully recover from an autopilot failure >during this period (by performing a go-around) about 80% of the time. While not a direct computer risk, is anyone else troubled that the FAA considers a 1 in 5 chance that the pilot WON'T recover acceptable? Or is it just that they believe a failure during these crutial 45 seconds to be of acceptably low probability? UUCP:cbosgd!ukma!ukecc!vnend; or vnend@engr.uky.csnet; orcn0001dj@ukcc.BITNET
Please report problems with the web pages to the maintainer