Ellen wrote: > Dear VM Community, > > After many years as a VM Systems Programmer and Manager, I'll be leaving > Interactive Data at the end of December to pursue other interests. My thanks > to those of you whom I've known throughout the years and to all the VM > Community for your support. I'd especially like to thank the VM Developers > whose talent, creativity, and dedication make VM such a great system. The VM > mainframe continues to be a key component of Interactive Data's IT operation. > Very best wishes for a Happy Holiday season and a Peaceful New Year.
old email mentioning IDC from long ago and far away: first two paragraphs somewhat related to this old email from 1973 and 1975 http://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks? http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks? http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks? whole lot of posts about trying to get address location independent executable images http://www.garlic.com/~lynn/subtopic.html#adcon being mapped from (CMS) paged mapped filesystem that I had original implemented for cp67 and then ported to vm370 http://www.garlic.com/~lynn/subtopic.html#mmap misc. posts about vm-based commercial time-sharing services http://www.garlic.com/~lynn/subtopic.html#timeshare and some additional topic drift, recent posts discussing mapping objects to virtual address space http://www.garlic.com/~lynn/2006w.html#17 Cache, TLB and OS http://www.garlic.com/~lynn/2006x.html#26 Multiple mappings http://www.garlic.com/~lynn/2006x.html#11 Multiple mappings From: wheeler Date: 03/26/79 07:52:36 For relocate shared segment support, a shared segment may appear anywhere within a virtual machine's address space (it does not need to be at the position specified in the VMABLOK). The way I handled it in DMKVMA was to use the PTO pointers in the VMABLOK to check the shared segments, rather than using the segment index number to displace into the segment table and pick-up the STE. One of the co-op students that helped me write the original shared segment support for release 2 VM (included the sub-set that is now in the product DCSS) is now with Interactive Data Corporation (IDC). They have taken the idea and put a whole group on expanding the idea. They now call it Floating segments (instead of relocating segments). They have a modified assembler for generating adcon free code and are working on the compilers. All this work they have done has greater significance than they realize. It would greatly simplify conversion to an increased address space size. Customers appear to be ordering 4300s in large quantities. Single outstanding problem is how to do centralized maintenance. For example Univ. of Maine has 1 4341 and 8 4331s on order. They would like to do without any tape drives at all on the 4331s and do all maintenance over the network from the 4341. One thing they wanted to know, would it be possible to load data from the CPU's floppy disk reader? They would initially be willing to have one tape drive which they move around as each of the 4331s are installed, but they would then like to get rid of it after that and rely on the network. Several other installations are starting to talk about going the same way (Univ. of Maine is considered a small installation). This question of remote mainenance may become very critical (possibly the most critical) for installations talking about 20, 30, 40 or more CPUs all being serviced from a central site. I would suggest that you find as many people as possible to start looking at it and networking in general before the next share. By comparison all the current activity with performance optimization by customers can be minimized by just ordering additional CPUs (if they can maintain them in a reasonable way). ... snip ... with regard the last paragraph ... misc recent posts on the subject of distributed vm operation and large 43xx installations: http://www.garlic.com/~lynn/2006x.html#18 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2006x.html#30 The Elements of Programming Style http://www.garlic.com/~lynn/2006x.html#31 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2006y.html#5 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2006y.html#6 The Future of CPUs: What's After Multi-Core?
