Mainframe Limericks... 3828
Hunkeler Peter , KIUB 34
multics started about then. lots of early 545 tech sq folklore ... mostly about cp67 and vm370 ... in melinda's history paper
but when multics (5th flr, 545 tech sq) didn't choose 360-67, but instead GE machine ... the science center; 4th flr, 545 tech sq
started their own virtual memory project (which happened to also included virtual machines) for 360-67. some of the (mit) ctss people went to work on the 5th flr ... and some went to work on the 4th flr (so both activities have some common heritage w-ctss).
Old Hashing Routine 3830
Shmuel Metz , Seymour J. 360-67 shipped with virtual memory supporting both 24-bit addressing and 32-bit addressing options (i.e. you could have 4gbyte virtual address...
since 360-67 hardware was not going to be immediately available, the science center had a 360-40 modified with virtual memory hardware and produced cp40 in 1966. when 360-67 became available in 1967, they ported cp40 from custom modified 360-40 to 360-67 and renamed it cp-67.
cp67 was somewhat ahead of multics ... possibly because the implementation was not as large or as complex.
multics web page
there are even some cp67 stories by one of the people that worked on multics
and some ibm 7094-ctss stories
some people from cambridge came out and installed cp67 at the univ the last week in jan68 (third cp67 installation after cambridge and lincoln labs). I did a bunch of work on cp67, especially mft and mvt running under cp67 in virtual machine ... and was invited to spring SHARE in houston where cp67 was announced. I then gave a talk on some of the work at the fall68 SHARE meeting in boston. some old posts giving part of that presentation
Another item that I got to do for cp67 was adding TTY-ascii terminal support (which plays in one of the cp67 stories from the multics site). As part of that work, I tried to make the 2702 terminal controller do something that it could actually do. Somewhat as a result, the univ. started a project to build our own terminal controller; reverse engineer ibm channel interface and build our own channel board for Interdata-3 ... programmed to emulate 2702 (with some additional stuff the 2702 couldn't do). somewhere there was an article blaiming four of us for spawning the plug compatible controller business
later in POK ... getting ready for virtual memory announcement for 370, there was an effort to basically integrate virtual memory (some of the components from cp67) into mvt for os-vs2 SVS (instead of running mvt in virtual machine ... ccwtrans and some other stuff from cp67 was hacked into the side of a mvt kernel). basically mvt kernel where most of the infrastructure thot it was running in a real 16mbyte address space ... but was using virtual memory hardware to map the (single) 16mbyte address space to the real machine memory.
Nanodata vs Microdata
I have a hard copy of the second edition of Microdata's manual; those less fortunate can find it on Al Kossow's web site. But my memory...
Microcomputers As A Space Spinoff
I recently bought, cheap, second-hand, an old issue of a British astronomy magazine. It had reviews of the Meade RCX400 telescope, and the Cape...
then SVS (single virtual storage) was enhanced with multiple virtual address space support and morped into os-vs2 mvs (multiple virtual storage) which eventually was shortened to just mvs.
Mainframe Limericks... 3829
Shmuel Metz , Seymour J. re: refers to posting refers to abbreviated quote from Melinda's history paper at...
in the mid-70s, as part of getting ready for 370-xa that would come out in the early 80s with 3081 ... work on mvs-xa was begun. up in cambridge. the vm370 development group had grown out of the space in 545 tech sq and had moved out to the old service bureau corp. building in burlington mall. POK convinced the corporation to shutdown burlington mall location, kill vm370 product, and that all the vm370 development people had to be moved to POK to support mvs-xa development (in order to meet the mvs-xa product schedule).
some people didn't want to move ... and instead stayed in boston area, many going to work for DEC (on things like vms). recent post referencing 16percent of vm370 group going to work for DEC (extracted from melinda's paper)
endicott managed to stave off vm370 product actually being end and got a few of the original development people moved to endicott ... there is more detail in melinda's paper (however, large number of people did move to POK as part of supporting mvs-xa development).
in some of the threads about the internal network
being larger than the arpanet-internet from just about the beginning until possibly mid-85 ... i also slightly dig multics.
in the mid-70s, the number of vs2 and vs1 customer "batch" installations were larger than the number of customer vm370 installations. the number of customer vm370 installations was larger than the number of internal, corporate vm370 installations (although in places like the internal network ... the number of vm370 internal installations far outnumbered any other operating system internal installations, mvs, jes2, jes3).
for a short period, while i was at the science center ... i also personally built, distributed and supported highly modified vm370 for small number of internal locations. however, that number was more than the total number of all multics systems ever deployed.
also some past postings about the number of vax systems sold (by year, us-non-us, model, etc) ... and that the number of vm 4331-4341 systems were larger than the total number of vax systems information be: in tags and descriptors