IUCV in VMCMS

when i was an undergraduate ... i had done a lot of fastpath stuff to get os-360 thruput improved. i then did some generalized stuff for paging and scheduling. after that, i was looking at some of the cms pathlength ... and noticed that cms disk i-o always used the same ccw pattern (effectively cms pre-formated a ckd disk as logical fixed block and then used record oriented access ... stuff that is common today with fixed block disks) and always waited for the disk i-o to complete w-o bothering with any asyncronous activity. reference to long ago and far away presentation that I made at aug68 share meeting

so i invented a "new" ckd ccw opcode ... which condensed the seek-search-read-write sequence into two ccws ... and furthermore the ccws were defined to always return CC=1, csw stored (aka from the virtual machine standpoint, the i-o was complete when the SIO instruction finished ... aka it became syncronous instead of asyncronous).

cambridge (primarily bob adair) were very emphatic about not violating the principle of operations ... and suggested instead that the implementation be done with a "diagnose" instruction (under the theory that the principle of operations defines the diagnose instruction as being machine-model dependent ... leaving an opening for cambridge to define a "virtual machine" model ... and free to define how diagnose instruction operates with a virtual machine model). the cms disk i-o was then remapped to effectively do the same thing that i had done with cc=1, csw stored ... but with a diagnose code.

cms was modified to test for running in a real machine or in a virtual machine at boot ... and set a flag. disk i-o routine then tested the flag and either used real machine SIO sequence ... or virtual machine diagnose sequence. later in the morphing from cp-67 to vm-370 ... and from cambridge monitor system to conversational monitor system ... the option for CMS to run on bare-real machine was eliminated.

later, at cmabridge, i had done a whole set of things for supporting automated benchmarking, including something called the (cp) autolog command. cp kernel at startup had some changes to simulate the autolog command for a "autolog" virtual machine. You could then put code in the autolog virtual machine to perform all sorts of startup initialization ... as well as automatically autologging other virtual machines.

there was starting to be a growing number of virtual machines that provided generalized services ... or service machines ... that on cp boot-ipl required the operator to login, start some application, and then "disconnect".

I had also done some stuff that i referred to as virtual memory Debt Management ... a bunch of stuff having to do with shared segment operation as well as a paged mapped file system. misc. vmm posts early cambridge scientific center reports breastled "virtual memory Debt Management I" and "virtual memory Debt Management II".

at this time there was starting to be specialized code in shared segments ... but the only interface to the shared segment facilities was via the (virtual) ipl command (and being able to IPL named systems ... which could include shared segment definition). One facility that this was made available for was with APL ... the interpreter was a large body of code ... it was sort of packaged as part of the CMS kernel and a special named system was saved ... which then could be "IPL" where both the CMS kernel and the APL interpreter code was "shared".

Possibly the largest vm time-sharing service was HONE

which was vm-cms service with heavy use of apl applications that supported world-wide branch office & field sales and marketing. the problem for hone was that it also had some number of applications written in fortran ... and while it was possible to automatigically put a salesman into the APL application environment as soon as they logged on ... it was rather gludgy to have a salesman perform "IPL CMS" and "IPL APL" to switch between some fortran-based applications and apl-based applications. besides the "VMM" as local modifications at cambridge and some number of other internal locations ... HONE was a big Consumer Debt of the "VMM" operations ... enabling them to automagically switch from APL and FORTRAN application environments (transparent to the sales and marketing people around the world).

So along comes VM-370 release 3 ... and they pick up the autolog command and a subset of the VMM stuff for product release (the vmm subset was called DCSS ... or discontiguous shared segments).

the other stuff included in VM-370 release 3 was vmcf and special message. standard environment had message command that users could send messages to other users on the system or send requests to the (human) operator to have something or other done. An issue was how to request stuff from the "service virtual machines" that had no human operator. vmcf-spm allowed a virtual machine to set option so that incoming messages were intercepted before physical display on the terminal and placed in a buffer that could be read by program. so one thing you could do was send messages to the network service machine ... which would parse it and do specific things.

network service machine then had list of privilege users that were allowed to send control commands. another use for general users was to send a message to the network service machine which would be forwarded to another node on the network and delivered in real time to remote user. so the standard system started out having "instant message" support as the default for users on the same system ... and the methodology using the network service machine extended this "instant messaging" paradigm to all users in the network.

up until this point ... most of the work was still being done by people in the cambridge area. the development group had broken off from the science center and moved into the 3rd floor and taken over the boston programming center ... and when the group outgrew that it moved out into the vacated SBC (service bureau corporation) bldg in burlington mall.

also in this time-frame i was doing what became the resource manager

and working on ecps (relased in vm-370 release 3 time-frame, vm microcode enhancement for 138-148) and vamps (5-way smp support that was canceled before customer ship) ... recent post

general ecps & microcode posts and vamps

so with ecps, endicott was getting heavily into vm support for its product line. there was even a whole strategy that had been done for 138-148 to release the machine as vm-370 only machine ... with vm-370 preloaded as it came from the factory ... which got pre-empted before it actually was able to ship to customers (which would have made it almost like current day LPARs ... where effectively a stripped down subset version of VM as part of the microcode of all machines).

in any case, what i remember of IUCV was that it came out of people with engineering background in the endicott lab ... as opposed to the vmcf-spm oriented stuff that. Folklore has the guilty party as Tom DeForrest ... who long ago and far way had email address of into the microcode of the real machine w-o needing to be handled via the DIAGNOSE code support in the cp kernel.

some drift ... the resource manager was first scp charged-for kernel-SCP code. previously application code was licensed-charged-for ... but all kernel code was still free. the resource manager got to be the guinee pig for kernel priced software (in theory kernel code that was needed for direct hardware support, device drivers, etc ... was still free ... but other kernel code could be charged for). i got to spend six months off & on with the business people mapping out the business strategy for the change to charging for kernel code.

the other opportunity was as part of ecps ... was putting together the strategy for 138-148 w-ECPS and possibility as vm-370 only machine. At the time, the domain for the higher end machines 158-168 was primarily the US ... but 138-148 had much more of a world-wide market. Putting together the ECPS & VM-370 business strategy for 138-148 ... required various one week meetings with not only US business planning people ... but EMEA and AFE business planning people was well as business planning people from the larger world trade companies (england, germany, france, japan, etc).

I had interacted with some of the organizations ... but at a different level ... as part of deploying and propogating HONE-clones world-wide (but this was in support of the sales, marketing, and business planning people ... as opposed to directly working with them on projects).

--