Trouble Report System

Gary Dixon [GCD]

TRs (Trouble Reports) were records of problems encountered by customers using the Multics product in the field. This was a Honeywell process that applied to all of their large-scale operating systems (GCOS, CP6, Multics) and perhaps to the Billerica-produced operating systems as well. These reports were used by management as part of the Multics development process.

Originally, TRs were paper records created when a customer, their Site SA, or their Field Engineer (FE), telephoned the support organization with a problem. Details of the problem, interested contacts at the site, etc. were captured in that paper record. Then the paper was passed by customer service to an appropriate engineering team to correct.

When I joined the development team at PMDC (Phoenix) in 1979, one of my first jobs was to receive hand-written TRs directed to the Multics product, and route them to appropriate people. Management asked that I find some method to move this to an online mechanism. So I wrote the trouble_report command to:

allow updates to be recorded, as more details were learned about the problem.
record assignment of the problem to an individual engineer for resolution.
track Multics Release that contained a repair for the problem.

This command maintained a database of TR reports on System M in Phoenix. The TR database was a large keyed vfile, stored in a multi-segment file. Multics developers, FEs, and customer service people interacting with customers had access to create new TR entries using the command. Eventually, some customers were given System M accounts, so they could login and enter TRs directly.

The TR system was never a bug list system, however. It:

did not attempt to capture all bugs against a particular software subsystem, or source component.
did not track repair of individual bugs through a change control or configuration management process.
was not visible to, searchable by, people trying to investigate problems to determine if their symptoms had been seen before.

In fact, I cannot recall any mechanism used for Multics development that performed the role of a bug list system. If developers encountered problems with software while using Multics themselves, they usually reported such issues to a known developer of the software (or to a past changer of the software, as recorded in source history comments within the code).

Developers tracked such comments using their own methods; and fixed any problems in their own time frame. Or they suggested that the person reporting an issue might correct the issue himself/herself. [For example, that's how I got involved rewriting the convert_date_to_binary_ software, to add features needed by tools I was writing when there was no active developer for the project.]

From a process perspective, it was a good thing that Multics software had such high-quality by the time it was installed. If there had been many bugs in the software, or if Multics had many more customers to encounter/raise issues, such lack of a bug tracking mechanism would have been a fatal flaw for the product.

Several administrative documents were written on Trouble Report processing. MAB-049-1, TR Closure and Resolution (1980-06-11) and MAB-044-1, Revised MAB on TR Goals (1981-02-13).

Some System Release Bulletins contained a list of TRs fixed in the release. In the Multics source archive at MIT, we have such lists for MR12.0, MR12.1, MR12.2, and MR12.3.

In the Multics source archive at MIT, there are Installation Maintained Library info segments from System M describing the trouble reporting commands:

There are also info segments describing the TR system administrative commands:

page created 21 Mar 2016 GCD