Moving buttembler programs above the line 503

an earlier part of the HONE cms-apl experience was making (and then apl-cms) was making the APL intepreter part of shared code (so you didn't need a unique copy resident in each address space).

the original cp67 facilities for sharing pages across address spaces was fairly hokey. Basically there was a table built into the kernel which defined groups of page areas on disk. A privilege system command, savesys .... allowed specific pages from the users current address space to be written to specific collection area on disk. There was a hack to the virtual IPL (boot) command that instead of simulating the device boot process .... would map pages from a defined group into current address space (including establishing any "sharing" characteristics).

An unshared version of this was used by a number of customers to get fast OS360 ipl-boot (i.e. pages from a virtual os360 guest would be saved after os360 had gone thru is laborious startup process).

An early HONE apl-cms hack was to save pages after APL interpretor had been loaded. cp67 & vm370 could be setup so that it would automatically execute an IPL command at login; so instead of specifying an IPL device ... for most HONE users, it specified a specially group of saved pages that included both the CMS kernel and the APL interpretor.

At the science center

one of the activites that I had done was virtual memory management enhancements to cp67 (cms paged map file system, dynamically loading additional page image stuff ... after virtual IPL-boot ... including shared page-segment specifications). there were two cambridge "Z" publications on the work (I & II, ZZ20-6001 and ZZ20-6002, aka "Z" publications only available internally). various references to some of the stuff involved in the virtual memory management enhancements

The IPL APL hack (which most users didn't even realize was happening) worked for HONE as long as the user never needed to leave the sequoia-apl environment. However, the HONE-APL-Sequoia environment was extremely CPU entensive (one of the characteristics of interpreted APL environment). Some analysis was done finding a few critical configurator components doing sophisticated modeling ... could give back well over half of all HONE cpu useage by being recoded in Fortran. The problem with the IPL hack for shared pages is that it wasn't possible to transparently transition from the IPL-APL environment to a Fortran application and back to IPL-APL.

Early in the VM370 release 2 product cycle, i ported the cp67 VMM enhancements to vm370 and also integrated them into HONE operation. It was now possible to configure the userids for sales&marketing people to automatically IPL-BOOT a relatively normal CMS ... and then automatically transition into an APL-Sequoia environment (that was able to reference a page-image of the APL interpretor on a cms page mapped filesystem ... including specifications for shared page-segments transparent to the end user. It was then possible for Sequoia to setup automated scripts for exiting the APL-Sequoia environment, executing specific Fortran applications and automatically re-entering the APL-Sequoia environment (all transparent to the sales&marketing people using HONE).

This dynamic invoking of shared images was deemed to be relatively useful ... and the vm370 development group picked up a small subset of the changes (w-o the page mapped filesystem support) for vm370 release 3 as something called discontiguous shared segments (DCSS).

--