Change in computers as a hobbiest... 2839

UofMich was one of several universities that were convinced to order 360-67 on the promise of tss-360. when tss-360 floundered, many just used the 67 as 360-65 in batch mode with os-360 (ignoring the virtual memory hardware). UofM wrote Michigan Terminal System (MTS) for the 360-67 and the science center wrote virtual machine system CP67 (original had done cp40 on a 360-40 with special hardware modifications for virtual memory). lots of past posts mentioning science center

melinda's virtual machine history talks about early project mac, 360-67, tss-360 days.

a few MTS references from around the web:

when a couple people came out and installed cp67 in jan68, it had 1052 and 2741 terminal support ... so i had to add the TTY-ascii support. I did a hack involving one-byte length fields ... which later was the cause of system failure when somebody modified the code to support ascii devices that support more than 255 byte lengths. reference (which also mentions mts) other stories from this same site:

typical system configuration was to predefine in software the terminal characteristics connected to each "port" (address). for dial-up, specific ranges of telephone numbers were typically reserved for each terminal type (i.e. fixed mapping between telephone numbers and computers port-addresses) so that the operating system would know ahead of time what kind of terminal it would be talking to.

the guys at cambridge had implemened their terminal support so that it would dynamically determine whether it was talking to a 2741 or 1052 terminal ... and establish the hardware line scanner on the front-end telecommunications controller appropriately (so that the operating system didn't have to pre-configured for terminal type and you could use a common set of phone numbers for both 2741 and 1052).

looking at the specs for the terminal controller ... i decided that i could add tty-ascii support similarly ... dynamically being able to distinquish between 2741, 1052 and tty-ascii (which would allows a common pool of numbers for all terminals, not requiring any differentiation) ... and the telephone box could be configured to have a single telephone dial-in number and a common list of telephone pool numbers (for all terminals) that it roll-over to looking for a non-busy number (on an incoming call).

I had overlooked a minor point in the terminal controller box ... while it was possible to do dynamic terminal type identification and re-buttign any line-scanner to any port address ... they had taken short cuts and hard-wired the line-speed oscillator (determining baud rate) to each port. this wasn't a problem with 2741 and 1052 since they operated at the same baud rate. however, it was a problem with tty terminals since they operated at a different baud rate. for hard-wired terminals it wasn't a problem ... but it presented a problem for dial-in lines. the restriction met that you had to have a different pool of phone numbers (with fixed connection to specific ports) for TTT-ascii terminals than for 2741-1052 terminals (you couldn't publish a single dial-in phone number for all terminals, you had to have one number for tty-ascii terminals and a different number for 2741-1052 terminals).

this somewhat prompted the univ. to start a project to build a front-end terminal controller that supported both dynamic terminal type identification as well as dynamic baud rate determination. somewhere there was a write-up blaiming us for kicking off the plug-compatible controller business. the 360 mainframe channel was reverse engineered and a channel interface card was built for an interdata-3 that was programmed to simulate the mainframe front-end terminal controller. misc. past posts referencing this activity

the 360 pcm activity was supposedly a major motivating factor for the future system project ... drastically increasing the integration between the main processor and external controller boxes (significantly raising the bar for producing a plug compatible controller). misc. past posts mentioning future system project

somewhat in the same time-frame, "unbundling" was announced on 6-23-68 plus 1 ... which including charging separately for application software (as opposed to all software being free) ... somewhat in response to various fed. gov. litigation. kernel software continued to be bundled (free) with the justification that it was required to operate the hardware. misc. past postings mentioning free software and unbundling:

When virtual memory on 370 became available ... TSS-360, MTS, and CP67 were moved to 370. TSS-360 became TSS-370 (although hardly anybody continued to run it, at least until the stripped down version done for AT&T that had unix running on top), MTS stayed MTS, and CP67 became vm370.

in the 70s, you started to see emergance of 370 clone mainframe processors ... among them amdahl. part of this was the size of the 360-370 customer market, some Debt Reduction in the design and manufactoring of processors and availability of free kernel software (i.e. to bring a processor to market you only needed to create a processor ... you didn't have to invest heavily in software also). In the early 70s, amdahl had a seminar at MIT talking about the formation of his (clone 370) computer computing. one of the students asked him about how he talked the (VC) money people into funding the company. he replied that customers had already spent a couple hundred billion in developing 360-370 application software (some indication of the 360-370 customer market size) and even if ibm were to totally walk away from 370 (possibly could be construed as veiled reference to FS project), there was enuf customer software to keep him in business until the end of the century (which was nearly 30 years away at the time). the other advantage for clone manufactors in the 70s was that most of R&D had been diverted to FS for several years, and when FS was finally end (w-o even being announced or customers aware of the effort), there was a dearth of 370 enhancements coming out.

however, even with free kernel software ... the mainstream vendor batch operating system still required a lot of vendor hand holding and support ... which wasn't exactly forthcoming for customers of clone mainframes. as a result one of the big clbutt of early adopters were universities running MTS. however, several universities also would be running vm370 (on both vendor processors as well as clone processors).

the advent of clone processors eventually contributed to changing policy and introduction of charging for kernel software. my resource manager was chosen to be the guinea pig and i got to spend several months on and off with business people working on the policies for kernel software charging (aka unbundling by any other name). the resource manager is coming up on 30th year in a couple more months (although an earlier version that i had done as an undergraduate had been available in cp67)

--