Sign in / up

* Posts by lynn

11 publicly visible posts • joined 16 Jul 2011

Before the PC: IBM invents virtualisation

lynn
Reply Icon

TSS/360 duplex

somebody recently quoted a soviet press article about a us/soviet track meet .... where the soviets came in 2nd and US came in next to last.

In the early 70s there was TSS/360 duplex benchmark showing it ran 3.8 times faster than same TSS/360 on single process. Somebody wrote it up as TSS/360 having far superior multiprocessor support (much superior than any other operating system in handling multiprocessors ... i.e. any other system would at most get twice the thruput).

It turns out that the both TSS/360 benchmarks actually had much inferior thruput compared to cp67. The scenario was that single processor 360/67 had 1mbyte storage and TSS/360 kernel was so bloated that only small amount was left for application execution (and single process benchmark was page thrashing). The two-processor 360/67 had 2mbytes storage .... which was enough to have more efficient application (after what was taken by the bloated tss/360 kernel) ... getting nearly four times the thruput.

0 0
lynn
Reply Icon

From Annals Of Release No Software Before Its time

posts from two years ago ... after new feature presentation at hilltopics meeting

http://www.garlic.com/~lynn/2009p.html#43

http://www.garlic.com/~lynn/2009p.html#46

in the later half of the 70s ... the internal, virtual-machine based HONE system (provided online world-wide sales & marketing support) implemented loosely-coupled single-system-image support ... with front-end load-balancing and recovery (but not live migration/relocation). In the early 80s this was extended when the US HONE datacenter had a 2nd and 3rd replicated datacenter at geographic distances.

however, in the late 60s, there was two cp67 commercial online timesharing service bureaus startups (sort of precursor to modern day cloud computing). By the mid-70s, at least one had migrated to VM370 based and had made numerous enhancements ... including single-system-image, front-end load balancing and live guest migration (be able to transparently vary offline a processor complex offline for service/maintenance with all the virtual guests migrated to other processors in the complex).

0 0
lynn
Reply Icon

MTS & LLMPS

Lincoln Labs did LLMPS ... a stand-alone monitor that ran some number of applications (in pure 360 mode). Lincoln Labs got a duplex 360/67 (originally for running tss/360) ... but was then the 1st place (outside of science center) to install cp67 (univ. I was at, was 2nd place outside of science center to install cp67).

Folklore is that MTS started out being built off LLMPS at its core.

0 0
lynn
Reply Icon

xmas tree

vmshare reference 10dec87 to xmas exec on bitnet

http://vm.marist.edu/~vmshare/browse?fn=CHRISTMA&ft=PROB

risk digest reference (21dec87)

http://catless.ncl.ac.uk/Risks/5.81.html#subj1

misc. past posts mentioning bitnet (used technology similar to internal network)

http://www.garlic.com/~lynn/subnetwork.html#bitnet

this is old post where I try and reproduce the effects of a 1981 rexx xmas tree that used FSX for 3279

http://www.garlic.com/~lynn/2007v.html#54

note that the bitnet 1987 xmas exec was almost exactly a year before the morris worm on the internet.

0 0
lynn
Reply Icon

virtual paging under virtual paging

VM370 supported the memory of the virtual machine with demand paged virtual memory managed by an approximation to global LRU. MVS/370 running in a virtual machine, managed its virtual pages (in what it thot was "real memory") with an LRU approximation.

LRU or least recently used ... assumed that a page that hasn't been used for the longest time is the least likely page to be used in the future. It can be paged out and the real storage allocated for some other use.

It was possible for MVS/370 with its LRU paging to get in pathological situation when running under vm370 (with its LRU paging). VM370 will select an MVS/370 virtual machine virtual page to be replaced (paged out) because it hasn't been used for a long time (aka least recently used). However, if MVS/370 is also paging (using LRU page replacement), that same page is also the one that MVS/370 will decide to use next (i.e. invalidating the assumptions behind vm370's least-recently-used page replacement)

0 0
lynn
Reply Icon

CTSS, Mutlics, CP40, CP67, etc

note that some of the CTSS people (MIT IBM 7094) went to the 5th flr of 545 tech sq and did MULTICS; others went to the science center on 4th flr of 545 tech sq and did (virtual machine) cp40, cp67, vm370, etc

0 0
lynn
Reply Icon

360/67, tss/360, cp67, mts, orvyl/wylbur

There were quite a few customers sold 360/67 with the promise of running tss/360. when tss/360 looked like it was going to be difficult to birth ... many switched to os/360 or cp67. Michigan did its own (virtual memory) MTS system and Stanford did its own (virtual memory) Orvyl/Wylbur system. Later the Wylbur part was ported to os/360

0 0
lynn
Reply Icon

VMA, virtual machine microcode assist

cp40 & cp67 provided virtual machine support by running the virtual machine in problem state and taking the privilege/supervisor state interrupts for supervisor state instructions and simulated them. Later for vm/370 and 370, virtual machine microcode assist was provided on 370/158 and 370/168 which would executive frequently executed supervisor state instructions according to virtual machine rules.

A superset of this was extended for 370/138 & 370/148 called ECPS ... which included dropping parts of vm370 supervisor into microcode. There was an attempt to ship all 138/148 machines with VM370 pre-installed ... sort of a early software flavor of LPARS ... which was overruled by corporate hdqtrs (at the time there were various parts of the corporation working on killing vm370).

A much larger and more complete facility was done for 370/xa on 3081 called SIE.

Amdahl came out with a "hardware" only "hypervisor" function ... sort of superset of SIE ... but subset of virtual machine configuration.

IBM responded with similar facility PR/SM on the 3090 ... which was further expanded to multiple logical partitions as LPARS. PR/SM heavily relied on the SIE microcode implementation ... and for a long time a vm/370 operating system running in an LPAR couldn't use SIE ... because it was already in use for LPAR. It took additional development where vm370 running in an LPAR (using SIE) could also use SIE for its own virtual machines (aka effectively SIE running under SIE).

0 0
lynn
Reply Icon

s/38 single-level-store

one of the shortcomings of simplified s/38 single-level-store was it treated all disks as common pool of storage with scatter allocation across the pool. As a result all disks had to be backed up as a single integral filesystem and any single disk failure would require a whole filesystem restore (folklore about extended length of time to do a complete restore after single disk failure) . single disk failures were fairly common failure mode and s/38 approach scales up poorly to environment with 300 disks (or more) ... aka on any disk failure take down the whole system while the complete configuration was restored (or length of time the system would be down for complete backup).

this shortcoming was motivation for s/38 to be early adopter of RAID technology ... as means of masking single disk failures.

0 0
lynn

vm history

lots of history in Melinda's history document, i recently provided her with a single file PDF version

http://web.me.com/melinda.varian/Site/Melinda_Varians_Home_Page_files/neuvm.pdf

and kindle version

http://web.me.com/melinda.varian/Site/Melinda_Varians_Home_Page_files/neuvm.azw

built from her multi-file postscript version

Science center first did cp/40 having added virtual memory hardware to 360/40. cp/40 morphed into CP/67 when they were able to obtain 360/67 that came standard with virtual memory hardware. Later cp/67 morphed into vm370 when virtual memory became standard on 370s. lots of past posts mentioning science center

http://www.garlic.com/~lynn/subtopic.html#545tech

TSS/360 was the "official" software for 360/67 ... but they had numerous difficulties. Running same exact simulated application script for fortran edit, compile and execute ... I got better throughput and responses for 35 simulated CP67/CMS users than the IBM SE got with 4 simulated TSS/360 users (running on same identical 360/67 hardware).

In the 70s, the massive (failed) Future System effort (was going to completely replace 370) heavily used the single-level-store from TSS/360.

0 0
lynn
Reply Icon

S/38/AS400

The massive (failed) Future System effort in the early 70s was going to completely replace 370 and drew heavily on single-level-store design from TSS/360. The folklore is that when FS failed, several people retreated to rochester and did a simplified, FS subset as S/38. misc. past posts mentioning future system

http://www.garlic.com/~lynn/submain.html#futuresys

I had learned a lot at the univ. watching tss/360 testing and its comparison with cp67/cms. Later at the science center in the 70s (during the future system period), I continued to do 360/370 stuff ... including a page-mapped filesystem for CMS (which never shipped in standard product) ... avoiding a lot of the tss/360 pitfalls (I would also periodically ridicule the FS effort ... with comments that what I had already had running was better than their bluesky stuff).

0 0