long ago and far away, vm370 from early/mid 70s

[Anne & Lynn Wheeler]

Concurrent with the benchmarking, shared segment, page mapped
filesystem, resource manager, and other misc. stuff referred
to in these posts
http://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#9 dcss and page mapped filesystem

I was also at the same time doing a lot of the work on VIRGIL/TULLY
(138/148) and ECPS
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist

and at the same time doing system and microcode design for VAMPS,
a five-way multiprocessor effort ... collected past posts mentiong VAMPS
http://www.garlic.com/~lynn/subtopic.html#bounce

For some reason, the product people responsible for both VIRGIL/TULLY
and VAMPS somewhat viewed the other as competing products; even though
i was doing much of the design for both products. There were some
corporate product escalation meetings where I was expected to sit on
both sides of the table simultaneously and argue it out with myself.
VIRGIL/TULLY shipped, but VAMPS was canceled.

Memo to: Endicott
Date: August 27, 1975
Subject: Simplifying Technical Considerations for VAMPS
References: 1) Technical Review of VAMPS Proposal
by KKKKKK and WWWWW dated 8/5/75
2) Update of above dated 8/21/75

As you pointed out last week during the Boeblingen Technical Review
sessions, the VAMPS schedule is a critical PSE factor.

During these sessions it became evident that the technical
considerations of the original VAMPS proposal had not been fully
adjusted to account for a marketing strategy similar to that for the
VIRGIL/TULLY VM proposal.

As described in the Attachment, this revised marketing strategy for
VAMPS provides a number of technical simplifications. These
simplifications are being proposed for resource and schedule reasons
and not for reasons of technical feasibility.

While the possible tradeoffs that these simplifications could allow in
the major redesign MSC and dispatcher areas are not clear, the
significant reduction in the total number of changes should not only
alleviate the resources required, but also possibly the schedule due
to the reduction in dependencies and testing.

If the VAMPS forecast look promising early in September, a more detail
technical design review of the MSC and dispatcher areas should be
immediately arranged in Boeblingen after which more accurate resource
and schedule estimates can be derived.

... snip ...

[Anne & Lynn Wheeler]

ref:
http://www.garlic.com/~lynn/2006w.html#10 long ago and far away, vm370 from early/mid 70s

while only a small subset of the virtual memory management stuff was released as
DCSS vm370 ... and none of the cms paged mapped filesystem stuff ... a little
more of the virtual memory management stuff was used for the original relational/sql
implementation in system/r ..... which provided r/w (unprotected) shared segments
between semi-privileged processes (different system/r database tasks running in
different virtual addresss spaces).

misc. past posts mentioning system/r work
http://www.garlic.comm/~lynn/subtopic.html#systemr

It was also part of the technology transfer of system/r to endicott for what was to become sql/ds.
This addition feature took on the name DWSS (or dynamic writeable shared segments) ... and
there was lots of issues on whether or not it impacted ECPS and microcode on existing customer machines.

recent posts mentioning system/r and DWSS
http://www.garlic.com/~lynn/2006t.html#16 Is the teaching of non-reentrant HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006t.html#39 Why these original FORTRAN quirks?

recent posts on early virtual memory management stuff (a small subset which was going to be released as DCSS in vm370 release 3)
http://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#9 dcss and page mapped file system

i also worked on a semantic network related activity about the same time as the system/r stuff
which used more of the virtual memory management and page mapped technology ... recent reference
http://www.garlic.com/~lynn/2006v.html#48 Why so little parallelism?

[Anne & Lynn Wheeler]

Another CMSBACK status, a year later than the email referenced here
http://www.garlic.com/~lynn/2006t.html#24 CMSBACK

i.e. i had done the original CMSBACK implementation and deployment in
the late 70s on sjr systems and hone ... the following refers to
there additional systems where it was installed:

To: distribution
Date: 12/11/80 15:21:31

CMSBACK is now installed in: Los Gatos (2, CPUs), GPD SNJ (3), GPD STL
(1) Austin (1) Note: Austin has (re)installed CMSBACK in other
locations. It is also being installed in Yorktown.

... snip ...

other recent CMSBACK references:
http://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?; Now : Programming practices
http://www.garlic.com/~lynn/2006t.html#33 threads versus task
http://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
http://www.garlic.com/~lynn/2006u.html#26 Assembler question
http://www.garlic.com/~lynn/2006u.html#30 Why so little parallelism?
http://www.garlic.com/~lynn/2006v.html#24 Z/Os Storage Mgmt products

all of this preceeding the work mentioned in Melinda's history paper
by a couple years (even preceeding the hiring of the people that
Melinda's history paper mentions as having done the original work).

now as to automated operator &/or automated operations ...
the *autolog* command ... mentioned here
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

helped significantly with the automation of service virtual machines
... some recent references here:
http://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC
http://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC
http://www.garlic.com/~lynn/2006v.html#22 vmshare

CMSBACK would be one example of service virtual machine ... another
would be VNET ... another would be the facility developed for
automated benchmarking.

I had originally created the *autolog* command (and the automated
flavor that was done at kernel boot) in support of automated
benchmarking
http://www.garlic.com/~lynn/subtopic.html#bench

aka, i needed automatically (and unattended) to stop a current benchmark,
generate a new kernel with various modifications, reboot to the new kernel,
and start the next set of benchmarks. this could be repeated a couple
times an hour for extended period straight (say 6-10 8hr shifts).

now some rudimentary stuff could be done for automated operations using
combination of service virtual machines (*autolog* command being one
of the enablers) and special message facility ... which allowed
application to capture all text (messages, cp command responses, etc)
that normally would be written to the terminal/screen. a couple recent
posts mentioning spm
http://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
http://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

another service virtual machine would be CJNTEL using special
message ... mentioned here
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

some drift ... the above post also includes a mention from 1981 for public key
infrastructure kind of operation.

however, simple text/message processing was lacking sophisticated parsing ... like
found in parasite/story ... misc. references
http://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2003i.html#73 Computer resources, past, present, and future
http://www.garlic.com/~lynn/2003j.html#24 Red Phosphor Terminal?
http://www.garlic.com/~lynn/2004e.html#14 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006.html#3 PVM protocol documentation found
http://www.garlic.com/~lynn/2006c.html#14 Program execution speed
http://www.garlic.com/~lynn/2006f.html#37 Over my head in a JES exit
http://www.garlic.com/~lynn/2006m.html#35 Draft Command Script Processing Manual
http://www.garlic.com/~lynn/2006n.html#23 sorting was: The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"

or later hllapi-like implementations. also missing was sophisticated
rule infrastructures (allowing specification about what should be done
in different kinds of circumstances).

for other references, part of an old SPMS application document ....

SPMS: CMS/SPM Interface Program 1

1.0 INTRODUCTION

SPMS is a transient CMS command that can be called by an
EXEC or by a program running in a virtual machine. It
enables the user to use the CP Special Message Facility to
intercept messages from CP or from other users and process
them within a CMS program or EXEC. A CP command may be
passed to SPMS to cause the response to that command to be
returned to the caller, or SPMS can be used to trap messages
not associated with any particular CP command. Messages
received through SPMS can be placed in the CMS console stack
and read in by the EXEC or program which called SPMS, or, if
SPMS was called by a program, the addresses of the messages
received can be passed directly back to the program. To use
SPMS properly, the user should have a good knowledge of the
CP and CMS command languages, as well as an understanding of
the CMS console stack concept and the Special Message
Facility.

SPMS provides two modes of operation. In 'immediate' mode,
it issues a single CP command and returns the response (if
any) to that command to the caller, and exits immediately.
In 'continuous' mode, it builds a Special Message 'trap',
which remains active in CMS after SPMS ends. The calling
routine can then continue with other work and issue another
call to SPMS with parameters requesting that any accumulated
messages be returned to it at that time, or that the SPM
trap be removed from CMS.

The Special Message Facility makes a distinction between
messages from CP itself (such as responses to commands), and
messages from other users. SPMS provides options which make
it possible to deal with 'MSG' type messages and 'CP' type
messages separately. When SPMS is used in 'immediate' mode,
it examines the CP command passed to it to determine whether
it is a command that would cause a message to be sent to
another user. If it is a 'MESSAGE' type command, SPMS will
wait for a 'MSG' type response in the assumption that the
issuer is awaiting a response from the recipient of the
message being sent. (Although it will accept a message from
any user as a response.) If the command being issued is not
a 'MESSAGE' type command, SPMS will wait for a 'CP' response
only.

In some situations, the response to a CP command might be
delayed or there might be no response. When using SPMS in
immediate mode, the user may specify how long to wait before
exiting without receiving a response.

Messages placed in the console stack by SPMS are stacked in
FIFO sequence by default. Through the use of an optional
parameter the user may cause the messages to be stacked in a

8 June 1979 1 of 16

... snip ...

and lots of old posts mentioning the subject of automated
operator
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
http://www.garlic.com/~lynn/99.html#107 Computer History
http://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000.html#22 Computer of the century
http://www.garlic.com/~lynn/2000f.html#12 Amdahl Exits Mainframe Market
http://www.garlic.com/~lynn/2001.html#43 Life as a programmer--1960, 1965?
http://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
http://www.garlic.com/~lynn/2001d.html#70 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#44 Where are IBM z390 SPECint2000 results?
http://www.garlic.com/~lynn/2001e.html#47 Where are IBM z390 SPECint2000 results?
http://www.garlic.com/~lynn/2001h.html#8 VM: checking some myths.
http://www.garlic.com/~lynn/2001k.html#13 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001l.html#47 five-nines
http://www.garlic.com/~lynn/2001n.html#47 Sysplex Info
http://www.garlic.com/~lynn/2001n.html#85 The demise of compaq
http://www.garlic.com/~lynn/2002.html#24 Buffer overflow
http://www.garlic.com/~lynn/2002e.html#68 Blade architectures
http://www.garlic.com/~lynn/2002h.html#73 Where did text file line ending characters begin?
http://www.garlic.com/~lynn/2002l.html#62 Itanium2 performance data from SGI
http://www.garlic.com/~lynn/2002n.html#27 why does wait state exist?
http://www.garlic.com/~lynn/2002o.html#14 Home mainframes
http://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
http://www.garlic.com/~lynn/2003.html#37 Calculating expected reliability for designed system
http://www.garlic.com/~lynn/2003g.html#3 Disk capacity and backup solutions
http://www.garlic.com/~lynn/2003h.html#56 The figures of merit that make mainframes worth the price
http://www.garlic.com/~lynn/2003h.html#60 The figures of merit that make mainframes worth the price
http://www.garlic.com/~lynn/2003i.html#27 instant messaging
http://www.garlic.com/~lynn/2003n.html#22 foundations of relational theory? - some references for the
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
http://www.garlic.com/~lynn/2004.html#40 AMD/Linux vs Intel/Microsoft
http://www.garlic.com/~lynn/2004b.html#48 Automating secure transactions
http://www.garlic.com/~lynn/2004m.html#46 Shipwrecks
http://www.garlic.com/~lynn/2004q.html#75 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#53 8086 memory space
http://www.garlic.com/~lynn/2005.html#59 8086 memory space
http://www.garlic.com/~lynn/2005c.html#7 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#9 intel's Vanderpool and virtualization in general (was Re: Cell press release, redacted.)
http://www.garlic.com/~lynn/2005j.html#60 Ancient history
http://www.garlic.com/~lynn/2005m.html#52 Cluster computing drawbacks
http://www.garlic.com/~lynn/2005o.html#30 auto reIPL
http://www.garlic.com/~lynn/2005u.html#37 Mainframe Applications and Records Keeping?
http://www.garlic.com/~lynn/2006i.html#2 The Pankian Metaphor
http://www.garlic.com/~lynn/2006u.html#30 Why so little parallelism?