Summary

  • LAP6 let a LINC user see a long manuscript as a movable scroll and change it directly by adding or deleting lines; the display showed the current manuscript state.
  • Filing that manuscript updated a named LINCtape entry, while conversion, loading and program checkout remained later and distinct operations.
  • Wilkes authored the system, but the verified record also credits Mishell J. Stucki and Severo M. Ornstein for the tape-handling editing technique, Wesley Clark and the LINC team for the machine context, and users and Washington University colleagues for requirements and testing.

A line of source code appears on the LINC's scope. The operator moves to it, deletes it and types a replacement. The next lines close up; their numbers change; the correction is visible in context. On a machine with only 2,048 12-bit words of core, this was not a decorative interface. It was the centre of a development system.

Mary Allen Wilkes's 1970 paper, “Conversational Access to a 2048-Word Machine”, describes LAP6 as an online environment for text editing, automatic filing, file maintenance, program preparation and assembly. The achievement was to connect those activities without pretending that they were the same event.

The manuscript was a visible working object

In LAP6, a manuscript could be any useful collection of keyboard characters. Source programs were typical, but the system did not impose a source-code format. The standard scroll held 45 tape blocks, or 23,040 characters. Only a small part had to be in core at once.

The current manuscript moved forward as the user typed. A potentiometer changed how many lines were visible. Line numbers acted as relative “you are here” information; they were resequenced when text changed. Gross positioning could use a line number, while nearby key combinations moved the scroll one frame or one line in either direction. Editing itself required no separate editing language. A line was added or deleted at the current point, and the display integrated the change.

Wilkes's separate IEEE paper on scroll editing explains the storage mechanism. The text remained a continuous string on fixed-address tape. A 512-character “playground” at the break point absorbed insertions and deletions; material was spliced back into the scroll as it moved. The algorithm handled the text directly instead of accumulating a hidden insert buffer that later had to be reconciled.

The visible result proved something specific: the current manuscript had changed. It did not prove that another named tape copy had changed, that the new text could be assembled, or that a resulting program would behave as intended.

Filing created another state—and another failure boundary

LAP6 files were governed by a two-block index. A named entry could be a manuscript or a binary program; those were different entry types and could even share a name without being the same program. A save command moved the current manuscript, or a selected range of it, into a file. Copy commands moved manuscript entries, binary entries or all non-duplicate entries between two tapes.

The filing algorithm chose contiguous free blocks near the index. A replacement did not promise to reuse the old entry's physical blocks. When an entry with the same name existed, LAP6 displayed REPLACE? and required a decision key. The confirmation protected a name; it was not a transaction certificate.

The LAP6 Handbook makes the limitation unusually concrete. It says that once LAP6 has updated the index, interrupting no longer cancels the filing operation. Its recovery notes add that LAP6 writes the index before the corresponding file entry. Tape trouble between those steps can therefore leave an index describing an entry that is not there. The index had no backup.

So a successful save or replace established a stronger fact than an edited display: LAP6 had acted on a named file entry. But reliable use still required the tape, index and entry bytes to remain coherent. The manual's recovery procedures exist because that coherence could fail.

Assembly and runtime were not filing synonyms

For source programs, CONVERT assembled the current manuscript into binary form. LAP6 could display symbol-definition errors with manuscript line numbers, the inclusive memory locations required by the program and the symbol assignment table. If errors appeared, the operator normally returned to the manuscript, corrected it and converted again.

LOAD was another operation. It transferred the current or a filed binary program into memory and started it under the documented convention. The user commonly kept the LAP6 tape mounted so that a return to the manuscript, symbol table, correction and reassembly was quick. This accessibility reduced the need for binary patching; it did not transform a source edit into a runtime result.

The evidence chain was therefore sequential:

  1. the displayed manuscript shows the source state at the current scroll position;
  2. a file operation records a named manuscript or binary entry on tape;
  3. conversion produces a binary and diagnostics from a particular manuscript;
  4. loading places a particular binary in memory;
  5. program checkout observes its execution; and
  6. a laboratory protocol must still establish whether the connected instrument and experiment produced a valid result.

Collapsing those stages would erase the very operational discipline that made LAP6 useful.

The authorship boundary matters too

Wilkes wrote most of LAP6 during 1965 on a LINC installed in her parents' Baltimore living room, according to her Computer History Museum oral history. She recalled using an earlier LAP while writing LAP6 largely from scratch, selecting routines where useful, and sending the LAP5 version to St. Louis for months of use before general release.

That is strong evidence of authorship, not a licence to erase the team around the system. Wesley Clark led the LINC project and coauthored “Programming the LINC” with Wilkes. The Handbook explicitly credits Mishell J. Stucki and Severo M. Ornstein with the tape-handling technique for the editing facility. Washington University colleagues forced flaws to the surface in prerelease versions, and visits to LINC laboratories shaped the specification. MIT Lincoln Laboratory supplied the earlier project and simulator environment.

Some secondary retellings blur names as well as roles. The primary documents reviewed here identify Mishell J. Stucki and Severo M. Ornstein; they do not establish separate LAP6 contributions by people called “Philip Mishell” or “Ted Severo.” Responsible history preserves that uncertainty instead of inventing a merger between names.

Sources