re: http://www.garlic.com/~lynn/2006o.html#49 The Fate of VM - was: Re: Baby MVS??? http://www.garlic.com/~lynn/2006o.html#51 The Fate of VM - was: Re: Baby MVS??? http://www.garlic.com/~lynn/2006o.html#52 The Fate of VM - was: Re: Baby MVS???
email from long ago and far away X-To: wheeler Subject: GENDMOD module Could I ask you to get an assembly listing of the GENMOD module so I can study it to determine what changes I have to make to VS APL. If we make this change, it could have a tremendous impact on the HONE system, above what their SEQUOIA system is giving them. There are several very large APL applications on there .... particularly the configurators. If users are sharing that code as well, we could get some big savings ... not to mention the time savings in just loading the workspaces. .... snip ... shared variables was eventually created as an alternative paradigm (to that originally implemented in cms\apl) for accessing system api/functions. apl\cms and apl\sv eventaully evolved into vs apl. the (cms) apl interpreter had been structured into code that could be shared across all the virtual address spaces. however, HONE apl operations had another couple hundred kbytes of commonly used apl applications that appeared in nearly all workspaces http://www.garlic.com/~lynn/subtopic.html#hone i had originally done paged mapped filesystem for cms in the early 70s along with a mechanism that allowed loading of objects from cms paged mapped filesystem as memory objects shared across multiple virtual address spaces. http://www.garlic.com/~lynn/subtopic.html#mmap one of the internal datacenters this was installed on was at HONE. HONE used it to create a "shared" executable image of the APL interpretor (under cms). I had modified the standard CMS executable creation command (GENMOD) and executable load command (LOADMOD) to add support for the shared executable object option. A small subset of the cp & cms memory mapped feature/function was released in vm/370 release 3 called DCSS. However, the full function was in use at a number of internal datacenters, like HONE. The issue in this particular email ... was that there were several large APL applications (like the HONE mega-application mentioned in the previous post, SEQUOIA). These "programs" were mostly static data that was "interpreted" by the APL interpreter (and executable in the 370 sense). The idea here was to modify the APL workspace loader to play some of the same games that I had done in CMS GENMOD/LOADMOD ... so that static APL workspace applications could be loaded as shared memory objects (allowing a single common image to be used across all virtual address spaces). This could significantly cut both the aggregate HONE application real-storage requirements ... as well as I/Os involved in retrieving unique copies off disk for every HONE user.
