Moving buttembler programs above the line 501
Original APL was apl-360 out of the phili science center.
some people at the cambridge science center
took apl-360 interpreter (leaving out all the monitor stuff) and adapted it to CMS and adding the capability to make system calls. the other item was the storage management had to be completely redone. under apl-360 there were typically 15k to 32k byte workspaces that were completely swapped. Storage management for buttignments involved always buttigning a brand new available storage location ... until it ran out of unallocated storage in the workspace ... and then it did garbage collection to reclaim unused storage. That wasn't too bad in 15kbyte workspace ... but try that in an 4mbyte or even 16mbyte cms virtual address space ... and you would constantly page thrash the machine.
in the late '70s, there was the scenerio of some of the dasd testcell regression programs being modified to run under mvs ... however they...
besides being sold to customers, the science center also offered cp67-cms timesharing
to various students in the cambridge area (MIT, BU, Harvard, etc) as well as internal corporate business accounts. There were some interesting security issues when business planners from corporate hdqtrs started using CMS-APL on the cambridge machine to analyse the most sensitve and confidential corporate business data (on the same machine that had some number of area college students). Back then, APL was frequently the vehicle for doing business what-if scenarios, the type of thing that is frequently done with spreadsheets today.
an earlier part of the HONE cms-apl experience was making (and then apl-cms) was...
a clone of the cambridge cp67-cms system was eventually created for the data processing marketing division which grew into the HONE system
supporting world wide sales and marketing people. For instance, in the early 70s when EMEA hdqtrs moved from white plains to paris ... I got to do the cloning of HONE system at the new EMEA hdqtrs outside paris.
Along the way, the palo alto science center did some enhancements to cms-apl and also tdid the 370-145 APL microcode performance buttist (apl on 145 with the buttist ran about as fast as apl on a 168 w-o the buttist). This was released to customers as apl-cms for vm370-cms (as opposed to the original cms-apl done at the cambridge science center originally on cp67-cms and then made available on vm370-cms).
A couple issues was the lingering ambivalence about the system call interface done in cms-apl ... as well as not having a MVS version. Eventually a group was formed in STL to do vsapl ... which would support both vm370-cms and mvs and then picked up a lot of the stuff from apl-cms from the group at the palo alto science center. vsapl also got the shared variable paradigm for doing things like system calls and other features (replacing the system call implementation that had been done for cms-apl). the shared variable paradigm was consistant with the rest of the apl paradigm ... the cms-apl system call was quite out of place (although had been extremely useful for a number of years).
not really highlighted was that most of the early APLs ... up until cms-apl (and then apl-cms) typically offered 16-32kbyte workspaces ... apl-360 "service" offered by...
There was a separate issue at HONE. Since HONE was part of the sales and marketing division ... periodically they got a new executive that had been promoted up from branch manager at some large branch. The sales & marketing had constantly been indoctrinated that the strategic data processing was MVS ... and they were quite dismayed to find the whole internal corporate operation was mostly run on VM370 ... the internal corporate network
was almost all vm370 as well as most of the internal mainframe machines.
The US HONE system was possibly the largest vm370 timesharing service in existance ... in addition to beng cloned at numerous locations around the world. In the late 70s it went thru a consolidation of all the US HONE centers to a single datacenter in cal. Then because of various disaster scenarios ... it was replicated first in Dallas and then in Boulder ... with load-balancing and fall-over across the distributed centers.
some of those details ... TSS-360 was the "official" system for 360-67 ... while cp67 was done at cambridge science center at one point i believe there were something like...
Most of the HONE services and applications were implemented in APL. Several times a new HONE executive (after general availability of APL also on MVS) would declare that HONE needed to migrate off of vm370 on to APL running on MVS. This would put a stop to all new HONE application development for something like 3-6 months until it became evident it wasn't possible ... and then the issue would be quietly dropped ... until the next new executive from the field showed up.
A major HONE applicatins were the order configurators ... and starting with the 370 115-125 ... salesman couldn't place an order w-o it having been processed by a HONE configurator.
For nearly 15 years i would custom craft HONE operating system kernels as well as provide various kinds of system support services .... sort of as a hobby in my spare time when i wasn't doing something else. At some point, the latest new executive was doing the latest round of why couldn't HONE be migrated to MVS ... and the issue came up that HONE wasn't really a standard release operating system. He then got upset when it dawned on him that it was supplied by somebody he had never heard of before ... and who showed up on no organizational charts anywhere.
slightly related recent posts:
note that this was further aggrevated by smp support. the gimick with allowing cms with shared segments to be run with the 158-168 microcode buttist ... effectively involved...
--
Moving buttembler programs above the line 502
Alt Folklore Computers from Newsgroups