The Risks Digest

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 4 Issue 45

Monday, 2 February 1987

Contents

o DATE-86, or The Ghost of Tinkles Past
Rob Austein
o Computerised Discrimination (an update)
Brian Randell
o Another non-malfunctioning alarm
Jeffrey Thomas
o Re: Engineering models applied to systems, RISKS-4.42
Joseph S. D. Yao
o Re: A scary tale--Sperry avionics module testing bites the dust?
D.W. James
o Info on RISKS (comp.risks)

DATE-86, or The Ghost of Tinkles Past

Rob Austein <SRA@XX.LCS.MIT.EDU>
Fri, 30 Jan 1987 00:48 EST
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


Computerised Discrimination (an update)

Brian Randell <brian%kelpie.newcastle.ac.uk@Cs.Ucl.AC.UK>
Fri, 30 Jan 87 09:57:00 gmt
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


Another non-malfunctioning alarm

Jeffrey Thomas <Ad.JDThomas@CU20B.COLUMBIA.EDU>
Mon 26 Jan 87 17:56:45-EST
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.


Re: Engineering models applied to systems, RISKS-4.42

Joseph S. D. Yao <hadron!jsdy@seismo.CSS.GOV>
31 Jan 87 02:42:57 GMT
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)


Re: A scary tale--Sperry avionics module testing bites the dust?

D. W. James <vnend@ukecc.uky.csnet>
28 Jan 87 00:47:42 GMT
  >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

Top