George:
Allow me to fill you in a bit on at least one of the "MVS group's
attempt to do in VM".
IIRC, it was shortly after the death of FS (Future Systems) when I and
several others were selected for a task force to answer the question
"how can we reduce the amount of development required to modify our
operating systems (MVS and VM) to support any new processors that POK
develops?"
We looked at several ways to make the nuclei of both systems similar and
couldn't find an acceptable solution. One of the members of the task
force, Karl Finkemeyer, had developed an idea he called "the thin layer"
while at the Heidelburg Scientific Center (BTW, this eventually led to
PR/SM). We argued that the main uses of VM were: 1) to support migration
from one operating system to another and 2) support of the CMS
development environment. We determined that "the thin layer" would
support the migration issue, as it would provide enough independent
system images (two or more) which would allow coexistence of different
operating systems in the same CEC. We also believed that if we could
effectively run CMS in MVS, that this would solve issue number 2 because
it would support hundreds of CMS users. We believed that if we could do
both, there would be no need for VM. At least one of the VM advocates
immediately resigned from the task force at that time.
Four of us teamed up to do a proof of concept by installing a running
CMS under MVS. We added a CMS command to TSO which caused TSO to GETMAIN
a sufficiently large area of storage from its own address space and then
to load the CMS nucleus in that storage. Using SIE, it would dispatch
the CMS nucleus. I implemented a CMS file system mini-disk structure in
VSAM using control area access and later planned to use the VSAM actual
block processor.
Our proof of concept worked sufficiently well that the decision was made
to staff the CMS under MVS project. Karl and I were to be the technical
team leads of the two development teams. We were in the process of
staffing when the project was killed. My understanding is that a devout
VM advocate let the word slip at SHARE, which caused Gene Amdahl to
declare publicly that he would support VM if IBM were to abandon it.
Since we never used VM to support our project's development (except as a
model for comparing our TSO/CMS version to VM's CMS), I can't agree that
our use of VM was necessary to our project's development, and was not
the reason the project was cancelled.
Of course, we all know that PR/SM was eventually released and I have
always held that CMS under MVS helped pave the way for OMVS, but that's
only conjecture.
Mike Myers
Mentor Services Corporation
On 2/19/2010 7:14 PM, George Henke wrote:
<[email protected]> wrote:
The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers>as
well.
Wow, Lynn and Anne, thank you for that wonderful history.
"I remember it well"
I did not arrive on the scene at POK (bldg #10, I think, Global Services)
until late, and then only as an outsider consultant (only a Class "B"
integrator, not a Class "A" developer like yourself).
But I remember the war stories I heard there, even then, of how the MVS
group had tried to do in VM, until top management found out somehow that
the MVS group was quietly using (needed) VM to test MVS.
And I remember HONE, but I did not know it was driven by VM. I remember it
as maybe a system to pose technical questions to.
And then, of course, there was PROFS, IBM's own precursor to email. It had
it all including an organization chart.
"Those were the days"
Thank you.
On Fri, Feb 19, 2010 at 6:43 PM, Anne& Lynn Wheeler<[email protected]>wrote:
The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as
well.
[email protected] (George Henke) writes:
After all is not MVS a far more robost operating system than VM which, by
the admission of its own authors, is really little more than a hypervisor
developed, of yore, to test different versions of MVS?
some number of commercial online timesharing service bureaus were
spun-off providing (secure) online interactive operation. recent
mention of tymshare here
http://www.garlic.com/~lynn/2010d.html#57 Adventure - Or Colossal Cave
Adventure
however, there were others. a couple of them relatively rapidly moved up
the value chain providing all sorts of financial information (including
to numerous highly competitive organizations on wallstreet in secure
environment). misc. past posts mentioning commercial timesharing
operation
http://www.garlic.com/~lynn/submain.html#timeshare
for much of its life vm/cms provided major interactive computing in
addition to virtual guest testing. in the wake of the 23jun69
announcement, several internal "HONE" datacenters were setup with cp67
virtual machine to provide hands-on experience for branch office
personal with guest operating systems. past post mentioning vm/cms-based
online HONE system
http://www.garlic.com/~lynn/subtopic.html#hone
however, the science center (besides doing virtual machine systems,
initial cp40 and then morphed into cp67) ... also ported apl\360 to cms
for cms\apl (doing a lot of work for operation in virtual memory
environment). Lots of apl-based applications were developed providing
sales&marketing support which were also deployed on HONE. Eventually the
online interactive sales&marketing support applications came to dominant
all HONE operation (and the virtual guest use withered away)
... including (any kind of) mainframe having to be preprocessed by HONE
applications (before they could be submitted).
the technology for majority of the internal network was also done at the
science center ... and for a long period, the majority of the internal
machines on this network (larger than the arpanet/internet from just
about the beginning until possibly late '85 or early '86) ... and were
vm/cms machines primarily providing interactive computing. misc. past
posts mentioning the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
At one point, I got involved with the disk engineering development&
product test labs in bldg. 14&15 ... and they let me play disk
engineer. At one point that had tried to use MVS on their mainframe
machines for testing of devices under development ... but experienced a
15min MTBF w/MVS operating a single testcell. They had to drop back to
(scheduled) stand-alone testing (i.e. dedicated time, preschedule,
schedule tending to be 7x24 around the clock).
I decided to redo i/o supervisor so it would never fail ... and
eventually was able to support any number of concurrent, on-demand
testcell operation ... significantly improving dasd development and test
productivity. I happened to do a purely internal document describing the
environment and happened to mention the MVS 15min MTBF. I then got a
phone call from the MVS operation ... I initially thot would be related
to going through the list of things that could be fixed in MVS. Instead
it turned out to be part of bringing the wrath of the MVS organization
down on me head for even making any references to issues with MVS (some
temptation to attribute reputation to carefully managing information)
A couple years later ... with the pending introduction of 3380s, the
engineers had several dozen (57) hardware error regression tests ...
all of which resulted in MVS hang/failure and needing to reboot; in
2/3rds of the cases, there wasn't even any record of what had caused the
hang/reboot. old email reference:
http://www.garlic.com/~lynn/2007.html#email801015
misc. past posts getting to play disk engineer (and some referencing
bringing
down the wrath of the MVS organization)
http://www.garlic.com/~lynn/submain.html#disk
there was a situation in the aftermath of the demise of the future
system effort (was going to completely replace 360/370),
http://www.garlic.com/~lynn/submain.html#futuresys
a mad rush to get stuff back into the 370 product pipeline (which was
allowed to go dry during the future system period) ... as well as
concerted effort to launch XA. POK managed to convince the corporation
to kill the vm370 product, shutdown the vm370 development group at
burlington mall, and move all the people to POK (otherwise they wouldn't
be able to make the mvs/xa ship date). Eventually Endicott managed to
acquired the vm370 product mission ... but effectively had to constitute
a development group from scratch. There is also a joking reference that
the head of POK was a major contributor to DEC VAX/VMS since so many
people wouldn't move and left, going to work for DEC (on VMS).
There were enormous number of vm/43xx machines mid-range mostly
providing interactive computing (both internally within the corporation
and at customer sites) ... it somewhat competed with vax/vms in the same
market. The big difference between the vm/43xx sales and vax/vms sales
were the large vm/43xx corporate orders that in some cases were nearly a
1000 machines. Going into the mid-80s, the mid-range market saw a shift
to workstations and large PCs ... it can be seen in the drop off in
vax/vms sales as well as lack of uptake for the 4331/4341 followon
(4361/4381 had anticipated seeing similar huges sales as 4331/4341, but
the mid-range market was moving to other platforms). misc. old email
related to vm/43xx
http://www.garlic.com/~lynn/lhwemail.html#43xx
Another trivial example was that the original relational/sql
implementation was vm/cms system/r ... some past posts
http://www.garlic.com/~lynn/submain.html#systemr
there was then technology transfer from SJR to endicott for sql/ds.
this old post mentioning some people in jan92 meeting in ellison's
conference room
http://www.garlic.com/~lynn/95.html#13
one of the people mentioned, claims to have handled the technology
transfer from endicott to STL for DB2.
--
42yrs virtualization experience (since Jan68), online at home since Mar1970
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
