MSU EDITOR was a locally-written text editor that was used for nearly all interactive entry of data and program source code.  Though not particularly powerful even by the standards of the day, MSU EDITOR was popular because it was fairly easy to use and surprisingly efficient.


MSU EDITOR (which we'll call "Editor") worked differently than most text editors.  It operated only on files in proprietary "Editor workfile" format.  These files were called EWFILEs because that was their default local filename.  No other programs had the ability to read these files, so when you wanted to actually use the text you had entered, you had to copy it to a normal text file via the SAVE command (or "directive").

EWFILEs were indexed sequential files consisting of lines up to 140 characters in length.  Each line had a fixed line number, though those numbers could be changed via the RESEQ directive.  By default, the SAVE directive appended the line number to the end of each line.  For FORTRAN source code, for instance, the line numbers (or "sequence numbers") were placed on the line starting at column 73.  This allowed you to easily find a given line of code in the EWFILE given a printed listing.  Line numbers looked like floating point numbers, with up to 6 digits before and after the decimal point.  It was typical to use only the integer part, and to increment line numbers by 10.  When you needed to insert a bunch of lines in between two existing lines, you could resort to fractional line numbers.  

EWFILEs had quite a few user-settable attributes.  The LENGTH attribute, for instance, controlled the maximum length of lines and where sequence numbers were placed by the SAVE directive.  For FORTRAN source, then, you'd use a LENGTH of 72.

Using Editor consisted of entering Editor directives to enter and manipulate text, list lines, change settings, and so on.  The syntax of most commands was simply the command name followed by zero or more parameters separated by spaces or commas.  For instance,  LIST 100-200  listed lines with sequence numbers 100 through 200.  These numbers were not ordinals; line 100 would probably not be the 100th line in the file.  In the special case of text entry, the syntax was line_number[=]text; for instance:

420=      DO 160 J=1,10
Entering a line number that was not followed by text deleted that line, so
would delete line number 500.

Editor implemented search strings by literal string only--no regular expressions and, as far as I can remember, no wildcards.  For instance, LIST /FORMAT/

would list all lines containing the string "FORMAT".  The output might be:

250=2000  FORMAT(I5)

Search-and-replace used the syntax /searchstring/=/replacement/ [,lineranges].  For this and other commands, zero or more line ranges could be specified to restrict the command to a subset of lines in the file.  Line range types included:

Because Editor operated only on files in the special EWFILE format, it was necessary to save lines to a normal text files in order for another program to be able to read the text.  This was done by the SAVE directive:


By default, during a SAVE, line numbers were placed starting after the column specified by the LENGTH attribute. The NS (No Sequence) parameter prevented this.

There were special Editor directives that automated a save-and-compile operation.  For instance, the FTN directive did a SAVE and then ran the FORTRAN compiler.  This directive was rarely used by advanced programmers, because there was no way to specify compiler directives.


There were special hooks in SCOPE/Hustler to accommodate Editor.  These hooks allowed both efficient operation and a reasonable user interface (for the time).

Editor directives could be entered via the system command prompt, as if they were operating system level commands.  By contrast, the way other programs worked was that you had to explicitly run the program before you could give it input.

The system control point program MANAGER, which received all text entered at all terminals, knew the syntax of all Editor directives, including the special text entry format.  When a user entered a Editor directive at the command prompt, MANAGER recognized this.  It copied the directive to a temporary file associated with the user's job.  This temporary file had a fixed name, something line ZZZINP.  If the command was line_number=text, MANAGER did nothing further.  You could enter many lines of text, and MANAGER would append them to the temporary file very efficiently, without calling Editor.  However, when you entered some other Editor directive, or an operating system command, MANAGER would run the control card EDITOR.  Editor would load and execute, opening the file EWFILE and the temporary file containing commands.  All directives would be read and processed against EWFILE, which would then be flushed to disk and closed, and the temporary file would be deleted.  Editor would then exit.  

On the surface, this implementation seems wasteful.  Entering two LIST commands in a row, for instance, caused EDITOR to run twice, each time initializing, reading both EWFILE and the command input file, deleting the temporary file, and exiting.  

However, in practice, the design worked efficiently.  All I/O was done by custom code; no system-supplied database package was used.  Editor was heavily overlayed, so it did not require much memory.  The most frequently-used overlays resided in precious ECS memory, so no disk I/O was required to load Editor.  

Adding to the efficiency of the implementation was a MANAGER hook for the special disk file TTYTTY.  Whenever any interactive command terminated, MANAGER would look for a file named TTYTTY.  If it existed, its contents would be sent to the user's terminal, then deleted.  MANAGER would take care of spooling the file if it was larger than the interactive output buffer size.  Editor used TTYTTY to display output.  This was a big win for Editor, since the normal interactive output buffer could store only about 5 lines.  This meant that ordinarily, if an interactive program displayed more than about 5 lines at once, the job would be swapped out, then swapped back in when the buffer had been sent.  With spooling of TTYTTY, Editor rarely had to be swapped out.  It would load and run quickly, usually in a single time slice, and then exit, leaving the output chores to MANAGER.

One disadvantage of this run-quickly-then-exit approach is that no Undo command was available.  When Editor exited, it left no trace of what the last command had been.  Because Editor ran and exited for essentially every command, this meant there was no history available for any sort of Undo.  If you entered DELETE *ALL, you were hosed.  Fortunately, the system was backed up to tape religiously every night.

In addition, the need to SAVE a file every time you needed to compile or otherwise process it certainly worked against Editor's efficiency.

EDITOR is documented in the SCOPE/Hustler Interactive System Users Guide. (This is a PDF file, so you'll probably want to right-click and choose Save Target As or the equivalent.)

Back to CDC 6500 frameset