Draft Command Script Processing Manual
(too old to reply)
2006-06-25 22:13:29 UTC
I have the draft manual for the command script processing program ready for
those that are interested in taking a look at it before I finalize it. If
for some drift, here are old posts reference parasite/story from the
late 70s.

parasite did 3270 terminal emulation. it was less than 8k bytes
executable (written in assembler). story was the scripting processor
... also less than 8k bytes executable (written in assembler). the
above has example of some number of story "scripts". story processing
included support for REX variables ... aka still internal software ...
before it was renamed to REXX and released as a product.

there is even an example story in the above to automatically retain put
bucket from retain.
Anne & Lynn Wheeler
2006-07-06 06:36:29 UTC
I had done a lot of work on location independent code images ... lots of
past postings discussing the difficulty collected here

The standard vm370 system only handled memory mapped objects via named
systems ... defined by the NAMESYS macro assembled in DMKSYS. With the
appropriate privileges, the current range of pages (defined by NAMESYS)
could be "saved". Then contents of a named system could be loaded by an
extension to the IPL command.

Some of the work was described in Cambridge Science Center

Technical Report No. ZZ20-6002, July 1974, C.S.C VM/370 Extended II,
Virtual Memory Management

... extract from the above

The scope of the modifications to VM/370 currently being implemented
will support both the Named System interface and an PAM interface
to a virtual machine. Recognizing that PAM support is dependent on
extensive CMS filesystem changes, simple extensions to the Named
System interace are being made to make some facilities immediately

The user interace will consist of two new commands (and/or diagnose
instruction codes) to equate/connect and disconnect a virtual address
space span to/from a 'Named System'. No change need be made in the
method of defining named systems, although virtual device address and
some other fields may be ignored. The starting virtual page address may
be any legitimate address, inside or outside of a virtual machine
address limit. Page address assignment is sequential as defined by the
NamedSystem, procedding from the intial starting page (which may be
supplied either via the comand or the named system definition as the
defualt). Page assignment is terminated after assigning the last page in
the definition, or on encountering a shared segment in the virtual
memory, or after assigning the highest possible page address (end of
virtual memory, 16M). For named systems which contain as part of their
definition shared segment(s), the relative starting page number within a
segment must be the same as the default in the Named System definition.

... snip ...

The CMS page mapped filesystem and the shared segment changes were
eventually widely released internally on a VM370 release 2 PLC 15 base.
One of the locations that made extensive use of the PAM support w2.15
system was HONE

... the internal world-wide, vm370-based online system for all sales,
marketing and field people.

For HONE, the issue had been that nearly all of the service was
delivered as various kinds of APL applications (originally CMS/APL but
then upgraded to APL/CMS ... and then VS/APL). In the pre-PAM scenario
they had defined a "IPL" named system that included both CMS and APL
(with several shared segments defined for APL in addition to the one CMS
shared segment and misc. non-shared pages)

The issue (for HONE) was that APL was extremely compute intensive and
some of the larger CPU hog applications had been redone in Fortran. The
issue was how to invoke the FORTRAN application from the APL environment
(called SEQUOIA) and then return to SEQUOIA automagically.

The PAM solution was to define APL on a page mapped filesystem. Normal
"CMS" could be IPL'ed (with the single shared segment). The APL image
was loaded from CMS page mapped filesystem (with all the appropriate
shared segments defined). It was now possible to switch back and forth
between APL environment (with shared segments) and Fortran applications
and back again transparently to the end-user.

PAM offered a huge number of operational and performance advantages ...
but the eventual decision was to only release the relative familiar
"NAMESYS" CP kernel changes (minor subset of the full page mapped
facility) as DCSS ... which (I) originally called DisContiguous Shared
Segments ... since the standard product was only going to support
definitions outside the standard virtual machine address space ... and
the primary justificiation for providing the facility was to support
definition of additional shared segment objects.

For VM370 release 3 "DCSS", because the CP kernel changes supporting
page mapped filesystem were not picked up, the CMS changes for page
mapped filesystem was also not picked up. However, a lot of the other
CMS changes that I had done for putting various pieces of CMS into
shared segments was picked up ... i.e. the CMS editor and misc. other stuff.
Anne & Lynn Wheeler
2006-07-06 17:34:18 UTC
misc. more about vm370 release 3 ... from Melinda's history

from her history:

Also in February, 1976, Release 3 of VM/370 became available, including
VMCF and support for 3350s and the new ECPS microcode. Edgar (the
``Display Editing System''), a program product full-screen editor
written by Bob Carroll, also came out in 1976. Edgar was the first
full-screen editor IBM made available to customers, although customers
had previously written and distributed full-screen editors themselves,
and Lynn Wheeler and Ed Hendricks had both written full-screen editors
for 2250s under CMS-67.

... snip ...

it doesn't mention DCSS being part of release 3.

... but it does mention ECPS which I worked on in conjunction with
Endicott. some old detail on studies deciding what to make part of ECPS
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode asssit

except, my quick & dirty recollection was that ECPS support wasn't
shipped until Release 3 PLC4

and then, of course, my resource manager release was 11May76. misc.
collected past posts on various aspects of some of the stuff that
shipped in the resource manager

The same person responsible for VMCF had also redone how shared segments
were protected ... which was also part of VM370 release 3. The issue was
that the decision to ship the alternative shared segment protection was
based on pre-release 3 CMS with only single shared segment with 16
shared pages.

part of the stuff that was included with the DCSS extreme subset of my
virtual memory management
http://www.garlic.com/~lynn/2006m.html#53 DCSS

was additional CMS code for a second shared CMS segment (and 16 more
shared pages). The release 3 change for shared segment/page protection
drastically increased the overhead per shared page which was offset by
enabling the use of VMA for CMS execution. However, the trade-off
decision had been based on a single CMS shared segment (and only 16
shared pages). The new shared segment protection (and enabling VMA use
for CMS virtual machines) shipped at the same time the additional shared
segment facilities shipped (typically doubling the number of shared
pages) ... invalidating the original trade-off analysis.

and repeat (from previous post) of collected posts on cms page mapped

and other collected posts about effort to make cms executable code
location independent (as part of virtual memory management work)
Anne & Lynn Wheeler
2006-07-07 18:52:54 UTC
I had an XT/370 PC sometime in the mid-late 80's. It used PAM as it's
native or default CMS file system if I remember correctly.
http://www.garlic.com/~lynn/2006m.html#53 DCSS
http://www.garlic.com/~lynn/2006m.html#54 DCSS

part of the issue was that even tho xt/370 hard disk was single user, it
used the xt hard disk which had 110ms access with block at a time ...
(plus the latency communicating back&forth between the 370 processor and
cp/88 running on the pc processor). The combination of the significantly
slower disk (vis-a-vis mainframe) and CMS being quite a bit more disk
intensive (vis-a-vis applications developed for the PC environment) ...
there was noticeable perception about poor performance.

PAM offers a much better matchup between filesystem operations and
virtual memory paradigm ... resulting in significant efficiencies
(most ibm mainframe operating systems inherited filesystems that had a
significant real memory and real i/o paradigm orientation).

CMS filesystem operations had "diagnose I/O" for pathlength reduction
but continued to retain channel program (a "real" memory) orientation. I
had done the precursor to CMS "diagnose I/O" as an undergraduate ...
demonstrating significant pathlength reduction for CMS I/O intensive
operation (which was sort of continuation of a lot of cp67 kernel
pathlength operations I was already doing).

The other place that PAM helped was minimizing real storage requirements
for filesystem operations ... especially evident in environments with
limited real storage configurations. Actually the CP kernel PAM
infrastructure could dynamically adapt filesystem operations to the
level of real storage contention and/or amount of real storage
available. In one high-end (real mainframe) filesystem intensive
benchmark, PAM demonstrated something like 300percent increased
efficiency in filesystem operations (compared to highly optimized
standard CMS EDF filesystem).

XT/370 was significantly real memory contrained for lots of cms
operations. I had done various performance analysis on pre-announce
XT/370 "washington" boxes and found significant page thrashing. When the
information was distributed, I got blaimed for delay in XT/370 announce
and ship while they retrofitted the hardware with larger real storage.

However, XT/370, being a single user system, saw no benefit from the
extensive segment/page sharing capability available via PAM (especially
compared to the limited capability offered thru the namesys/dcss method).

misc. past washington, xt/at/370 postings:
http://www.garlic.com/~lynn/94.html#42 bloat
http://www.garlic.com/~lynn/96.html#23 Old IBM's
http://www.garlic.com/~lynn/2000.html#5 IBM XT/370 and AT/370 (was Re:
Computer of the century)
http://www.garlic.com/~lynn/2000.html#29 Operating systems, guest and actual
http://www.garlic.com/~lynn/2000e.html#52 Why not an IBM zSeries
http://www.garlic.com/~lynn/2000e.html#55 Why not an IBM zSeries
http://www.garlic.com/~lynn/2001c.html#89 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001f.html#28 IBM's "VM for the PC" c.1984??
http://www.garlic.com/~lynn/2001i.html#19 Very CISC Instuctions (Was:
why the machine word size ...)
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was:
why the machine word size ...)
http://www.garlic.com/~lynn/2001k.html#24 HP Compaq merger, here we go
http://www.garlic.com/~lynn/2002b.html#43 IBM 5100 [Was: First DESKTOP
Unix Box?]
http://www.garlic.com/~lynn/2002b.html#45 IBM 5100 [Was: First DESKTOP
Unix Box?]
http://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
http://www.garlic.com/~lynn/2002i.html#76 HONE was .. Hercules and
System/390 - do we need it?
http://www.garlic.com/~lynn/2003f.html#8 Alpha performance, why?
http://www.garlic.com/~lynn/2003h.html#40 IBM system 370
http://www.garlic.com/~lynn/2004h.html#29 BLKSIZE question
http://www.garlic.com/~lynn/2004m.html#7 Whatever happened to IBM's VM
PC software?
http://www.garlic.com/~lynn/2004m.html#10 Whatever happened to IBM's VM
PC software?
http://www.garlic.com/~lynn/2004m.html#11 Whatever happened to IBM's VM
PC software?
http://www.garlic.com/~lynn/2004m.html#13 Whatever happened to IBM's VM
PC software?
http://www.garlic.com/~lynn/2005f.html#6 Where should the type
information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#10 Where should the type
information be: in tags and descriptors
http://www.garlic.com/~lynn/2006.html#10 How to restore VMFPLC dumped
files on z/VM V5.1
http://www.garlic.com/~lynn/2006f.html#2 using 3390 mod-9s
http://www.garlic.com/~lynn/2006j.html#36 The Pankian Metaphor