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 Bld, behind world hdqtrs, Detroit MI 1984?
[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. Quackenboss and 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.
October 20, 1998
[Michael Finn] At peak (1983-1985) GM/EDS had 3 systems configured as follows:
|M1||4 cpu||4 scu||4 fnp|
|M2||4 cpu||4 scu||4 fnp|
|M3||3 cpu||3 scu||2 fnp|
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).
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.
CRIS - Corporate Recall Information System (native mmap files)
[Brian Henk] Dealers and customers called in, to verify 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 peek.
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.
[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.
[Michael Finn] We used to keep the system up through the maintenance windows during GM's labor negotiations.
Ralph Whitehead, Karen Bush; Regional mgr Doug Lapedes
Fred Zemmin, Jim Shaffer (originally from AccuRay?), Harry Quackenboss, Gail DeRoven, John Lane, David Levites, Pat Lyon, Carol Shingles.
John Waclawski - GM (originally from MIT Multics); Original home of Frank Tofil of Ford
Ray Boone, Roger Stackhouse
Original SysOps (1974)
Steven J. Miller
Original Operations Supervisor
(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
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.
[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...
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.
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%.
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.
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.)
[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. ;-)
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).
[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, and Dee Kasiowniak.