Seeking Info on XDS Sigma 7 APL 2878

iverson and falkoff were at the phili science center and phili was supporting apl-360. cambridge science center

took apl-360 and ported it to cp67-cms and virtual memory for cms-apl. apl-360 installations typically provided 16kbyte to 32kbyte workspaces. part of cms-apl was moving apl-360 interpretor to (large) virtual memory environment. this initially ran into big problem with apl-360 storage allocation ... on every buttignment would allocate new storage location ... and when memory was exhausted, would perform garbage collection and compact storage allocation. this wasn't bad on 16k-32k real-storage workspace paradigm where the whole workspace was always swapped in total. however, for a possibly couple megabyte workspace in paged virtual memory ... this was guaranteed to quickly touch every virtual page ... regardless of the aggregate size of the variables (if it ran long enuf with enuf buttignment operations). this would quickly exhibit page thrashing appearance (and touch every virtual page) in the configurations of the period.

one of the things used was the early precursor to vs-repack (before it was released as product ... also done by cambridge) which monitored all data fetch and stores and all instruction fetches (which was also used for hotspot end analysis). i've commented before that we had these floor-to-ceiling "plot" printouts that ran down the office corridor; time was along the horizontal (running down the corridor), and storage address was vertical (giving storage location fetch-store over time). apl had this very saw tooth appearance ... a sloped black band that quickly went from bottom of storage to top of storage very quickly and then a solid vertical band where garbage collection was performed. the whole thing had to be rewritten for virtual memory environment.

the other thing that was done for cms-apl was to allow it to directly invoke system calls. this caused quite a bit of heart burn in philly since it violated apl purity. however it (along with large virtual address spaces) allowed some real applications to be done. eventually we had the business people in armonk loading all the (exremely sensitive) customer sales & install information and using the cambridge apl facilities to perform business analysis and planning (aka apl was being used for a lot of stuff that spreadsheets are commoningly used for today).

this also created something of a significant security issue since the data was the most sensitive-valuable the company had ... and the cambridge system also allowed a lot of students from various univ. in the area (mit, harvard, bu, etc).

this also opened the way for the HONE APL applications that eventually was the basis for worldwide sales and marketing support (the US hone vm370 datacenter system consolidated in northern cal. in the late 70s had nearly 40k user definitions, and there were clones of the system all over the world) ... misc. past HONE and-or APL posts

the system call abomination violation of apl purity was eventually resolved with the introduction of shared variable paradigm ... and apl-sv.

before that, the palo alto science center had taken cms-apl and done a number of enhancements in the vm370 time-frame and produced apl-cms. they also had done the 370-145 apl microcode performance enhancment (lots of apl-cms applications on 370-145 with microcode buttist ran at thruput of 370-168 ... aka nearly factor of 10 improvement).

and a repeat from a previous post:

here is falkoff's "The IBM family of APL systems"

for some drift ... the vs-repack product in addition to doing storage fetch-storage capture and plots ... also provided semi-automated application re-organization ... optimizing for virtual memory, paged environment. misc. past vs-repack posts:

--