Location
General Motors Corporation, Detroit MI.
Multics was operated by GMISCA (General Motors Information Systems and Communications Activity), initially led by Ashby Woolf.
Original location: B152 GM Bldg, May 1974
Move: GM Technical Center, Warren MI Winter 1977/Spring 1978
Move: GM Argonaut Bldg, behind world headquarters, Detroit MI 1984?
First Installed
[Bob Fetter] Original location: basement, General Motors Building, in the facility called "Detroit Data Center". The original installation was on a raised floor that suspended the entire system and operations area over a closed Executive Swimming Pool. Operations staff could rummage around below the room in the cavernous spaces available, causing certain degrees of consternation and confusion for some GM late night security personnel. Oddly enough, it was during this time that 'Zork' and 'adventure' gained the greatest popularity...
[Fred Zemmin] Original Location: B(basement)152 as Fetter states. It was spring (May) 1974. The original Honeywell installation team was Vern Scheske, Frank Nestor and John Waclawski, Helen Wright was the GM person. Harry Quackenboss and Fred Zemmin had just returned from the Reston, VA Multics classes some of which were taught by Patty Lyon who was recruited to come to Detroit to lead the support team. Honeywell had committed about 24 man years of support. We delivered about 12 man years in a 12 month period. I don't recall the first release but it might have been before MR1.0 because we were using MIT numbers.
Final Shutdown
October 20, 1998
Configuration
[Michael Finn] At peak (1983-1985) GM/EDS had 3 systems configured as follows:
| System | CPUs | SCUs | FNPs |
|---|---|---|---|
| M1 | 4 | 4 | 4 |
| M2 | 4 | 4 | 4 |
| M3 | 3 | 3 | 2 |
17000+ registered users
At final shutdown, the configuration was:
| M1 | 6 CPU | 4 SCU | 2 IOM | 6 FNP |
The final configuration had 6 FNPs (although we probably needed only one). The large configuration allowed for spare parts and testing of parts if needed. We were actually running on 5 CPUs (one was being used to test boards) and 5 FNPs (one was being used for testing and spare parts).
Application areas
A few major applications were:
ORAS - Operations Reporting and Analysis System
[THVV] Done for GM by SofTech in the early 70s. This application was a monster spreadsheet, done before the invention of VisiCalc. It combined the financial operations of all 13 GM divisions into a single database and allowed interactive calculations and exploration.
[HVQ] The GM ORAS implementation also included a relational database named DMF that was developed by GM, with another outside consultant, separate from the work done by SofTech. ORAS and DMF was originally developed on GM Research's IBM TSS system, but the linear virtual memory address space of TSS was deemed not big enough. This preceded my involvement but my understanding is that this was the original reason that GM looked at Multics, and became, along with the issue about outside time sharing expenses, the two-pronged justification for them buying Multics. Delving more into the history, GM hired a guy named Ashby Woolf, who had gotten his PhD from the University of Michigan. There were interesting ties between U of M and MIT, since UofM had developed its own time sharing system, MTS (Michigan Terminal System) on IBM 360/67 hardware. Also, one of the pillars of U of M's computing activities, Bob Graham, left the group at UofM for MIT. My recollection of the story is that Ashby was pretty key to them looking at Multics in the first place.
[HVQ] With respect to DMF, the consultant they used who helped with architecture and implementation was Frank Westervelt. Westervelt's consulting business was called, I think, Set-Theoretic Data Services. DMF was developed in the same time frame that Ed Codd's team was working on System R at IBM. Although Westervelt had left UofM for a position as head of Wayne State's computer center in 1971, if one didn't influence the other. How much was one-way versus bidirectional, I have no idea. Nonetheless, DMF was a significant piece of software, and in another universe, could have been a product in its own right to rival INGRES and Oracle early on.
CRIS - Corporate Recall Information System (native mmap files)
[Brian Henk] Dealers and customers called in, to verify that a Vehicle Identification Number (VIN) was in a recall program. Used double word to encode/hash VIN, used 1000s of native Multics memory mapped files. Supported 10,000+ calls / day at peak.
CERS - Corporate Energy Reporting System (MRDS)
[Brian Henk] Supported GM Energy groups at all GM locations for US government Dept of Energy reporting requirements.
TARGET Build (MRDS)
[Brian Henk] Loaded a MRDS DB with all production volumes and matched to targeted volumes.
CAPAPP (MRDS)
[Brian Henk] Maintained GM's capital appropriations in 300+ MRDS databases logically organized into the corporate hierarchy.
ALLIED (MRDS / native vfile_)
[Brian Henk] Maintained GM's inter-divisional billings.
CPS (native vfile_ and mmap files)
[Brian Henk] Large scale planning tool ala Janus. Still running on M1. Migrating to client/server on HP/UX.
GM/EDS Phone System (MRDS)
[Brian Henk] GM / EDS operators used the system to locate GM / EDS employees and locations, MRDS.
Labor application
[Michael Finn] We used to keep the system up through the maintenance windows during GM's labor negotiations.
Salesman
Ralph Whitehead, Karen Bush; Regional manager Doug Lapedes
Site Analysts
Fred Zemmin, Jim Shaffer (originally from AccuRay?), Harry Quackenboss, Gail DeRoven, John Lane, David Levites, Pat Lyon, Carol Shingles.
System Administrators
John Waclawski - GM (originally from MIT Multics); Original home of Frank Tofil of Ford
Field Engineers
Ray Boone, Roger Stackhouse
System Operators
Original SysOps (1974)
Steven J. Miller
Jim Madigan
Bill Mellinger
Original Operations Supervisor
Jerry Plum
(all were relocated from Dayton, OH, data center to operate the new installation in Detroit, if memory serves me right)
Other SysOps (1975-1980)
Danny P. Mitchell
Dolores (Dee) Kasiowniak
Notable developments
GM ran a vanilla version of Multics, unlike Ford that pushed SCPs to HIS.
[Bob Fetter] Multics incorporated into a GM-specific network ("GM-NET") in late 70s which operated on a 'kermit-like' message basis over private lines. Almost all other systems were MVS based, with TOPS/20 and DTSS (Dartmouth Time Sharing System) tossed in for good measure.
[Brian Henk] Async screen system developed in 1984 using window_ API. This was widely used throughout many if not all applications.
[Brian Henk] 3270 bisync message handling was added to the screen system in 1987. (The most fun I had was adding and testing 3270 message to the multics login code; can you say 'crash'.) We had to slow Multics communications down so that IBM communications could keep pace.
PLANETS was a modeling and management tool. This may be a descendant of ORAS.
Also see Harry Quackenboss's story about GM influence on the development of the workclass scheduler.
Local Development
[Tim Baeten] While we (GM) did run a very vanilla distribution of Multics, we did supply fixes and updates to HIS. Clearly not as much as Ford, but we did. I personally gave HIS code, including some MAP355 stuff...
[Tim Baeten] Also, while at GM, I designed a couple of operational procedures that were incorporated at least by Ford. The first one was starting the initializer as soon as possible, much sooner then it was by default. This would allow the users to login much quicker. Of course, they couldn't do that much because the rest of the daemons weren't up, but to them Multics was "up." The rest of the daemons were spun up in the "background." Made life a wee bit easier for us SysMaint types, at least as far as the "Is it up yet?" questions went.
[Tim Baeten] The other procedure I created was for installing a new release. Instead of taking the system down, then loading the release tapes. I had the operators pre-load the tapes onto removable packs. At install time, we'd switch the removable drives and boot on the new release. Of course we'd have to finish up some things, but the majority of the install process was done. This cut the install process down time by something like 75-80%.
[Tim Baeten] Before I left GM/EDS, I was working with IMFT and the forums, trying to get a forum post on one system to also get posted on a remote system. I had some success, and had posts flowing back and forth. The only thing I had trouble with was maintaining thread integrity. Unfortunately, I left before I could perfect it.
Anecdotes
See Hodie Natus Est Radici Frater for the story of the Multics error message in Latin at GM. (Observed by SysOp Bill Mellinger during a third shift stint.)
Security Concerns
[Fred Zemmin] A published article claimed that the US Air Force had introduced a bug related to rings into MIT source which got distributed to a very large manufacturing concern, which caused quite a bit of agitation in GM management. (See How the Air Force Cracked Multics Security.) The bug was introduced into hardcore source which we never used to build hardcore. We used the hardcore object directories. GM management was very excited until we walked them through the "process" (a word that was not chic in the late 70's) of building a Multics System Tape. This event was the underlying reason for running the "vanilla" OS. GM trusted that "professionals" from Phoenix would not be so careless but did not trust those "college kids" from MIT. ;-)
[HVQ] I noticed Fred Zemmin's comments about GM management being concerned about an article (I presume written by Thomas Whiteside). When I was onsite at GM, I remember getting a call from CISL. My fuzzy recollection it was Steve Webber or Mike Grady. They asked me to try a command srb 8.8.8 which led to my being told about the patch done to the hardcore module. My recollection is that the patch had not in fact actually introduced a way to set the ring brackets to 0,0,0, it only reported that it did. Nonetheless, this led to a bunch of discussions with the Honeywell account team, and the GM management responsible for Multics system, and working with the Honeywell Multics management about how to notify the customer base and get an update distributed and installed as sites that have various policies and procedures concerning how, and how often, they did system updates.
[HVQ] I am not 100% sure that Fred Zemmin's narrative was in reference to the original incident, or the result of it being written and published. But with respect to the original incident, the GM Computing management was well aware. If this became an issue later it was either because the management had changed, and the new people responsible weren't aware of their predecessors being informed, or it might have been because higher ups inquired, and the GM Multics team delved into the subject with Honeywell again out of an abundance of caution.
Lots of Users
[Michael Finn] The 17000+ users was the result of our policy of not removing user ids, we removed the users from projects. This is because of a security issue with the ACLs. If we removed a user we did not want the id to be re-used and we had no utility to go through the storage system and remove ACLs. We merged the 3 Multics systems into one, and I wrote a utility to extract users from the person name tables and move them to the one system. This allowed us to move users without them having to change passwords. At the time I did this, I also cleaned up the registered users and we currently have about 5300 registered users (many fewer actually use the system now).
Short Operator
[Fred Zemmin] Dolores (Dee) Kasiowniak was very vertically challenged (short) and had to stand on her tip toes to read the system console (TN300/1200). One Friday evening she caught her pukka beads in the keyboard, the necklace broke and tiny beads rolled around the keyboard and some drained past the keys. One bead lodged under the ENTER key of the Initializer console causing the Initializer to transmit a continuous stream of 014o (LF) which eventually ran the Initializer out of buffers and locked up the system.
(Dee says this is NOT TRUE. Her version of the story has no pukka beads.)
Information from Brian Henk, Michael Finn, Fred Zemmin, Bob Fetter, Tim Baeten, Dee Kasiowniak, and Harry Quackenboss.