Anne & Lynn Wheeler wrote:
the consolidation of some of the HONE vm370 datacenters provided
opportunity for development of vm370 "single-system-image" support with
front-end load-balancing and availability infrastructure directing
branch office logon to specific processor. The mechanism utilized a
special CKD sequence that performed a logical "compare&swap" channel
program to correctly syncronize logins across all processors in the
complex. The "compare&swap" channel program had originally been
developed by the people at the Uithorn HONE system in Europe ... for
coordinating logins across all processors in loosely-coupled complex. I
believe that JES2 multi-access spool then started using a similar
logical "compare&swap" channel program for its loosely-coupled
operation. This was to avoid the heavy penalty and overhead of doing
full device reserve/release sequence.
Later the US hone complex was replicated first in Dallas and then a 3rd
in Boulder (and could provide geographic availability to US branch offices
logins across all three datacenters).
to slightly wander back to the original thread ... the US HONE VM/370 complex
in the late 70s was possibly the largest single system image operation in
the world.
there were some large ACP/TPF single system image clusters deployed ... but
since
ACP/TPF didn't symmetrical multiprocessor support until much later ... HONE
could actually do larger number of processors. Because large portion of HONE
applications were APL based, HONE was an extremely computational intensive
operation.
Multiple "AP" multiprocessors (with only one of the processors in the
configuration having
I/O channels) could be configured in loosely-coupled operation. You could get
eight "AP" multiprocessors in loosely-coupled configuration (16 processors
total)
with 3830 four-channel switch ... and two-way 3330 string-switch (i.e. each 3330
string connected to two different 3830 controllers).
For additional topic drift, a large body of internal software enhancements never
made it into the product. In the early 80s there was a study done of the
WATERLOO/SHARE
tape and the collection of internal corporate software enhancements. The amount
of
source code on the WATERLOO/SHARE tape and the internal corporate software
enhancements
were comparable in size and both estimated to be larger than the amount of
source
code in the base vm/cms product.
Part of the problem (as I've previously posted) was that in the mid-70s, POK
had convinced
the corporation to kill the vm370 product and move all the people to POK to
support
MVS/XA development ... as part of the only way to get MVS/XA product out the
door.
Endicott managed to get something of a reprieve and save a fraction of the
people
from being re-assigned to supporting MVS/XA development. Somewhat as a result,
there was
a significant bottleneck created getting enhancements for vm/cms out-the-door
...
and a extremely large body of software enhancements accumulated for the product
....
both at the large number of internal corporate datacenters and also from
customer
datacenters.
For completely other drift ... my wife had served in the g'burg JES development
group
before being con'ed into going to POK to be in charge of loosely-coupled
architecture.
While in POK, she originated peer-coupled shared data architecture ... lots of
past
posts with references
http://www.garlic.com/~lynn/subtopic.html#shareddata
... for various reasons ... except for IMS hot-standby ... saw very little
uptake until sysplex
(and large reason she didn't stay in the position for long).
However, for further drift ... a little walk down dbms memory lane from this
thread
from comp.database.theory
http://www.garlic.com/~lynn/2007e.html#31 Quote from comp.object
http://www.garlic.com/~lynn/2007e.html#36 Quote from comp.object
http://www.garlic.com/~lynn/2007e.html#37 Quote from comp.object
which, in turn wandered into referencing this wiki page about IMS
http://en.wikipedia.org/wiki/Information_Management_System
mentioning Vern Watts as the granddad of IMS still being around. Vern was
one of the people my wife work with regarding IMS hot-standby.
however, this other old email reference ...
http://www.garlic.com/~lynn/2007.html#email801016
mentioning Jim passing off some number of things to me as part of his
leaving for Tandem ... includes mention of joint lunch with IMS
developers and telling them to call me after Jim's departure. I can't
remember for sure if Vern was at that lunch meeting or not. I have
some recollection of a German (Hans something?) ... who later left
to work for Amdahl.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
