Jeff wrote:
I'm definitely no substitute for Sir Lynn, but I remember DCSS and DMKSNT in
VM/370 Release 3 PLC 8, which is where I started with VM.
In fact, I used CMSAMS and CMSVSAM then for Unnatural Practices, or at least
not for the purposes for which they were created. I was porting the CP/67
port of LISP/MTS to VM/370, and needed something to replace the named
segment used under CP/67 for LISP's pushdown stack. Instead of checking the
stack pointer for the end of the stack, it would just push onto the stack
and take the program check when it ran off the end. I simulated that by
using DIAG x'64' to attach CMSAMS and CMSVSAM, and then set the protect key
to user key for all but the last 2K (remember 2K pages?) page.
A LISP interpreter written entirely in BAL, with self-modifying code and
almost out of base register addressibility... that was quite an interesting
piece of code.
re:
http://www.garlic.com/~lynn/2009j.html#67
http://www.garlic.com/~lynn/2009j.html#68
http://www.garlic.com/~lynn/2009j.html#76
and post in similar thread that I started in linkedin mainframe discussion
http://www.garlic.com/~lynn/2009j.html#73
I mentioned that Cambridge had done port of apl\360 to (cp67) cms for
cms\apl. This then became one of the main vehicles for deliverying
sales & marketing support on (virtual machine based) HONE (first
cp67 and then moved to vm370 ... eventually with HONE clones all
over the world) ... some past HONE clones
http://www.garlic.com/~lynn/subtopic.html#hone
a quick "named version" was done by getting APL started and then
getting it at a certain point and doing a named system ... that
was not only CMS but also APL. Then when IPL'ed ... the machine
was placed immediately at a point in APL (special place chosen
so it would do some last minute housekeeping and setup). One of the
univ. did something similar for ipl-by-named version of os/360.
for vm370 ... palo alto science center did a lot of additional
stuff for apl\cms (including the apl microcode assist on the 370/145).
For early "vanilla" vm370, HONE started out with ipl-by-name
apl\cms ... with the addition that the cms shared segment was
defined as well as most of the APL executable module and even
some APL "workspace". A early problem had some non-APL applications
and had issue with trying to explain to salesman (which were mostly
hardly computer literate users) how to IPL CMS ... to execute
non-APL applications and then IPL APL ... to get back into the
normal (APL-based) sales & marketing environment.
When I started distributing "CSC/VM" with the enhancements,
HONE was one of the major internal clients (they even con'ed
me into doing several of the early "clone" installations
around the world). With the paged-mapped filesystem and
the enhanced changes ... most sales&marketing could
IPL normal CMS and have their profile setup to immediately
execute APL (cms executable from "S" or "Y" disk that happened
to be paged mapped format) ... and all the page mapping
and shared segment was done as part of normal CMS
program loading.
Then it was possible to have APL processes that would invoke
and execute non-APL applications ... even placing the user
in the non-APL application environment w/o having to explain
to the user about the IPL command or some of the other non-APL
(there was a large sales&marketing APL application called SEQUOIA
that actually hid nearly all APL & CMS characteristics from the
sales & marketing people ... it was even possible that many
sales & marketing people never realized that they were using
APL &/or CMS).
I've several times told the story that between middle 70s until
at least middle 80s .. every couple yrs there would be a promotion of some
sales/marketing person to the head of the dataprocessing business
unit that included HONE. They would be startled to find that
HONE was VM370/CMS based on figure that they could make their
career by forcing HONE to be ported to MVS. This would consume
the HONE organization for possibly 12 months until it was extremely
evident that it was practical. Then things would almost return
to normal until the next person was promoted into the position.
As I've mentioned ... a small subset of the (shared/named) capabilities
was shipped in vm370 release 3 as DCSS. It was then possible
for ("normal") customers to define APL as a named system w/o
requiring the paged mapped filesystem support.
One of the early issues with port of APL\360 for CMS\APL ...
there was a big performance issue with how APL did storage
allocation and (periodic) garbage collection. The problem
wasn't noticed in a "real workspace" environment of APL\360
where the whole workspace was swapped as single unit.
CMS/APL opened workspace up to nearly the full virtual
machine size (which might be 16mbytes) ... and the garbage
collection performed terribly in virtual memory paged
environment ... and had to be significantly redone.
the port to CMS\APL also added APL functions that
could access CMS system services ... i
