ACM fellow for "reinventing virtual machines"
Anne & Lynn Wheeler
and somebody name ACM fellow for "reinventing virtual machines":
http://fellows.acm.org/fellow_citation.cfm?id=4094918&srt=year&year=2008
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Gene Wirchenko
>and somebody name ACM fellow for "reinventing virtual machines":
>http://fellows.acm.org/fellow_citation.cfm?id=4094918&srt=year&year=2008
I feel an urge to reinvent something. Is fire taken?
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Charlie Gibbs
(Gene Wirchenko) writes:
> Anne & Lynn Wheeler <ly...@garlic.com> wrote:
>
>> and somebody name ACM fellow for "reinventing virtual machines":
>> http://fellows.acm.org/fellow_citation.cfm?id=4094918&srt=year&year=2008
>
> I feel an urge to reinvent something. Is fire taken?
"Necessity is the mother of the reinvented wheel."
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Marc Auslander
For whatever reason, the industry was stuck wrt virtualizing i86. All
the existing state of the art involved hardware or guest OS mods or both to
make virtualization work decently.
Rosenblum et.al figured out how to dynamically patch the running OS
(windows) that they couldn't modify directly so that it behaved
decently under a VM implemented on hardware without full
virtualization support.
And they did a superb job of engineering the whole thing, triggering a
new industry.
Chris Barts
> and somebody name ACM fellow for "reinventing virtual machines":
> http://fellows.acm.org/fellow_citation.cfm?id=4094918&srt=year&year=2008
All your posts about VM at IBM, and some bits got triggered in my head:
Didn't IBM try to kill VM? Wasn't IBM's strategy focused on OS/360 and
MVS, with VM just in the way from a corporate standpoint? Because it
doesn't make sense to have multiple incompatible OSes for the 'same'
hardware, as DEC learned when they standardized around VMS when they
killed the 36-bit line in favor of the VAX and the Alpha.
Anne & Lynn Wheeler
> All your posts about VM at IBM, and some bits got triggered in my head:
> Didn't IBM try to kill VM? Wasn't IBM's strategy focused on OS/360 and
> MVS, with VM just in the way from a corporate standpoint? Because it
> doesn't make sense to have multiple incompatible OSes for the 'same'
> hardware, as DEC learned when they standardized around VMS when they
> killed the 36-bit line in favor of the VAX and the Alpha.
how many times?
it wasn't suppose to have even gotten started ... there was some
creative financing at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
to fund the hardware modifications that added virtual memory to 360/40
... and then to replace the 360/40 with a 360/67 (when standard product
machine with virtual memory came available). the "official" time-sharing
and virtual memory system was "tss/360". lots more of this history can
be seen in Melinda's history at:
http://www.princeton.edu/~melinda
then there followed several attempts by tss/360 group to have the cp/67
effort terminated
then there was lots of effort by "os/360" group to not have a
cp67->vm370 product effort (when virtual memory was added as standard
feature to 370).
cp67 & vm370 weren't exactly incompatible ... since a number of
customers would run standard os/360 products in virtual machines ... and
the biggest customer was internal corporate development (so they were
some ambivalent regarding this other operating system ... since so much
of internal operation had become dependent on it).
internally, first there was a custom modification so that cp67 (running
on real 360/67) would simulate the 370 architecture (which had a number
of differences from 360/67 virtual memory architecture) ... for
development of virtual memory support in the other operating systems
(os/360, dos/360 ... for dos/vs, vs1, vs2). In addition to doing
development under cp67 ... the initial prototype for vs2 involved
borrowing code from cp67 for part of the actual implementation (i.e.
for morph of os/360 MVT to vs2/svs). Then there was a version of cp67
modified to run on real 370 architecture (first system to run on real
370 virtual memory hardware ... in some cases, was used as early
hardware regression test).
the company then went through its "Future System" period
http://www.garlic.com/~lynn/submain.html#futuresys
... when lots of work on 370 hardware & software projects went into
abeyance ... since "Future System" was going to completely replace
370. After "Future System" was killed, there was a mad rush to get
products back into the 370 product line. As part of the mad rush, there
was crash program to breath life into a 370 following (31-bit, 370-xa).
The group responsible for "mvs/xa" made the case that vm370 product
needed to be killed, the vm370 product group shutdown (at the time in
the old SBC bldg. in Burlington Mall), and all the people transferred to
helping with mvs/xa development (if they were going to meet their
schedule). Endicott eventually managed to save the vm370 product mission
... but it had to reconstitute a development group from scratch.
Some number of people from the vm370 product development decided to
leave the company and stay in the boston area ... rather than move (this
was 1976). There was joke that the mvs/xa decision to kill vm370 was one
of the biggest contributions to vms (since some number of the people
that stayed in the boston area went to DEC).
hanc...@bbs.cpcn.com
> All your posts about VM at IBM, and some bits got triggered in my head:
> Didn't IBM try to kill VM? Wasn't IBM's strategy focused on OS/360 and
> MVS, with VM just in the way from a corporate standpoint? Because it
> doesn't make sense to have multiple incompatible OSes for the 'same'
> hardware, as DEC learned when they standardized around VMS when they
> killed the 36-bit line in favor of the VAX and the Alpha.
From the Pugh & et al history of the IBM System/360...
IBM originally hoped for a single modularized operating system, that
would expand as needed for large users but stay compact for small
users. But developing it turned out to be a major nightmare ("the
birth of a baby takes nine months no matter how many women are
assigned"--Brooks) and they discovered that even the simplest version
required too many resources to be able to run on the S/360 low end
machines like the model 30. (I think they planned on selling that
machine with as little as 16k of memory). So in a rush they developed
several basic os's (BPS and BOS) as well as DOS, which remains in use
to this day. Our System/360 model 40 required about 15k to support
DOS (but that did not include spooling).
I was told that DOS was supposed to be only a temporary expedient
until they had more time to refine OS to work on low-end machines, but
that never came to be.
Indeed, I'm curious as to what kind of operating system, if any, was
delivered with the earliest System/360 that went into service at
customer sites. They needed _something_, if only to supply the I/O
routines and instructions that ran in 'supervisor state'.
Indeed, I'm surprised that how anxious customers were to upgrade their
machines to System/360. I'm not sure System/360 gave that much
performance improvement running with emulation; without emulation all
programs would require a rewrite to a more complex and unfamiliar
language. System/360 architecture was very different than that of
both the low end 14xx and high end 709x machines and required a steep
learning curve for even experienced programmers.
(The Pugh history does not go into the customers' experiences with the
first machines; information on those experiences would be greatly
appreciated.)
Also, for business customers, was increased CPU speed really that
significant? I don't think S/360 tape and disk I/O were--at first--
much faster than 7090/1401 I/O, and for business users that was key.
The only big advtg I can think of is that the S/360 printer and card
reader were faster.
As an aside, in general and business press articles of the time, they
talk of glowing terms of the new computer. But articles did not get
into the down and dirty about the reality and frustrations of getting
programs to work and execute production on a reliable basis; obviously
companies kept that dirty laundry hidden from reporters, and of course
reporters of that era didn't know what tough questions to ask.
Anne & Lynn Wheeler
> Also, for business customers, was increased CPU speed really that
> significant? I don't think S/360 tape and disk I/O were--at first--
> much faster than 7090/1401 I/O, and for business users that was key.
> The only big advtg I can think of is that the S/360 printer and card
> reader were faster.
re:
http://www.garlic.com/~lynn/2009b.html#67 IBM tried to kill VM?
my first programming job was porting 1401 MPIO to 360/30. The univ. ran
709 with 1401 for unit record front-end (card->tape &
tape->printer/punch). The 360/30 had 1401 hardware emulation mode ... so
it could be used w/o actually requiring MPIO port ... but possibly
they felt it was an exercise in getting acquainted with 360.
It was good for me since I got to design & implement my own monitor,
storage management, device drivers, multitasking, some number of other
things.
The 709 ibsys monitor would process student (fortran) jobs in subsecond
elapsed time (tape-to-tape).
When 360/67 (running in 360/65 mode; replace 1401/70) with os/360 MFT
... it was taking nearly a minute per student fortran jobs ... this was
a lot of (serialized) unit record latency and job-scheduler in 3-step
fortran compile, link/edit & go.
My student programming job grew into having repsonsibility for system
programming support for os/360. I first added HASP ... which help things
by eliminating the serialized unit record latency (spooling, overlapping
unit record operation with program comple & execution).
However, it was still taking much longer to process student fortran
workload than the 709/1401 lashup.
old post with some elapsed time numbers from presentation I gave at
Aug68 SHARE meeting in boston
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
Part of the numbers were thruput comparison of os/360 running in cp/67
virtual machine. However, part of the numbers are heavy optimization
work that i had done on os/360 getting avg. student job elapsed time
down under 13seconds ... compared to an "out-of-the-box" system that was
(still) over 30 seconds (having added HASP).
Part of the difference between 709 monitor and os/360 ... was each "job
step" in os/360 (3 steps in normal job) required an enormous number of
(random) disk accesses. I was able to achieve significant reduction in
elapsed time ... by very carefully placing required data on disk to
optimize disk arm motion.
The student job problem was eventually solved when we installed Watfor
from University of Waterloo ... basically a "monitor" (more analogous to
709 operation) ... which required a single "system" job step (to load
watfor) and then it would serially process large number of student
fortran jobs (finally processing on 360 was faster than 709).
Nick Spalding
<ccb56399-23c7-4775...@z6g2000pre.googlegroups.com>
on Fri, 6 Feb 2009 10:54:46 -0800 (PST):
BOS was what was on the first /30 that I installed in 1965 or 1966. It
was serial number 30 from the Sindelfingen plant.
> Indeed, I'm surprised that how anxious customers were to upgrade their
> machines to System/360. I'm not sure System/360 gave that much
> performance improvement running with emulation; without emulation all
> programs would require a rewrite to a more complex and unfamiliar
> language. System/360 architecture was very different than that of
> both the low end 14xx and high end 709x machines and required a steep
> learning curve for even experienced programmers.
> (The Pugh history does not go into the customers' experiences with the
> first machines; information on those experiences would be greatly
> appreciated.)
>
> Also, for business customers, was increased CPU speed really that
> significant? I don't think S/360 tape and disk I/O were--at first--
> much faster than 7090/1401 I/O, and for business users that was key.
> The only big advtg I can think of is that the S/360 printer and card
> reader were faster.
>
> As an aside, in general and business press articles of the time, they
> talk of glowing terms of the new computer. But articles did not get
> into the down and dirty about the reality and frustrations of getting
> programs to work and execute production on a reliable basis; obviously
> companies kept that dirty laundry hidden from reporters, and of course
> reporters of that era didn't know what tough questions to ask.
--
Nick Spalding
Peter Flass
> Chris Barts <chbarts...@gmail.com> writes:
>> All your posts about VM at IBM, and some bits got triggered in my head:
>> Didn't IBM try to kill VM? Wasn't IBM's strategy focused on OS/360 and
>> MVS, with VM just in the way from a corporate standpoint? Because it
>> doesn't make sense to have multiple incompatible OSes for the 'same'
>> hardware, as DEC learned when they standardized around VMS when they
>> killed the 36-bit line in favor of the VAX and the Alpha.
>
> how many times?
>
> it wasn't suppose to have even gotten started ... there was some
> creative financing at the science center
> http://www.garlic.com/~lynn/subtopic.html#545tech
>
Lynn - you have so much interesting and original material, you should
take the time to organize it and write it up as a bookend to Melinda's
history. It would be lots of fuin to read!
Peter Flass
> machines like the model 30. (I think they planned on selling that
> machine with as little as 16k of memory). So in a rush they developed
> several basic os's (BPS and BOS) as well as DOS, which remains in use
> to this day. Our System/360 model 40 required about 15k to support
> DOS (but that did not include spooling).
I never saw a 16k /30. I saw lots of 32k boxes. My first employer did
a lot of work designing and programming systems for customers who were
converting from 1401's. DOS supervisors could get at least as small as
6k (I generated one once for fun), though 8k was more typical. On a 16k
box you wouldn't have been able to do anything with the remaining 8k.
>
> I was told that DOS was supposed to be only a temporary expedient
> until they had more time to refine OS to work on low-end machines, but
> that never came to be.
I was always disappointed that IBM didn't try to make the systems more
outwardly compatible. For example, I hoped the JCL would become more
alike over time, but although both DOS and OS JCL evolved, they evolved
in different directions. I wonder what marketing plan this supported.
>
> Indeed, I'm surprised that how anxious customers were to upgrade their
> machines to System/360. I'm not sure System/360 gave that much
> performance improvement running with emulation; without emulation all
> programs would require a rewrite to a more complex and unfamiliar
> language. System/360 architecture was very different than that of
> both the low end 14xx and high end 709x machines and required a steep
> learning curve for even experienced programmers.
Most customers wanted a redesign/rewrite. The 1401 systems they had
were mostly card and tape, and they wanted to start using disk. The
1401 programs were almost all Autocoder with lots of patches (decimal, I
was recently reminded.) They wanted to start using COBOL and chuck the
1401 stuff completely.
>
> Also, for business customers, was increased CPU speed really that
> significant? I don't think S/360 tape and disk I/O were--at first--
> much faster than 7090/1401 I/O, and for business users that was key.
> The only big advtg I can think of is that the S/360 printer and card
> reader were faster.
Disk. The 2311 was twice was big (and maybe twice as fast?) as the 1311.
Mike Hore
>...
> my first programming job was porting 1401 MPIO to 360/30. The univ. ran
> 709 with 1401 for unit record front-end (card->tape &
> tape->printer/punch). The 360/30 had 1401 hardware emulation mode ... so
> it could be used w/o actually requiring MPIO port ... but possibly
> they felt it was an exercise in getting acquainted with 360.
>
> It was good for me since I got to design & implement my own monitor,
> storage management, device drivers, multitasking, some number of other
> things.
>
> The 709 ibsys monitor would process student (fortran) jobs in subsecond
> elapsed time (tape-to-tape).
This is a good place to reminisce a little...
Back around 1967 I think it was, I was working in the Computer
Department at Sydney University. Our main machine then was an EE KDF-9
which we all loved. Anyway the Atomic Energy Research facility in the
south of Sydney was upgrading from a 7040/1401 combination to a 360/50,
and they were donating the 7040/1401 to us. I spent a few weeks down
there getting familiar with the 7040/1401. They'd already taken
delivery of the new 360/50, but as I remember it was sitting idle a lot
of the time -- the jobs at that place were mostly production Fortran
jobs and nobody wanted the grief of being an early adopter on the 360.
Anyway the 1401 was being used not for spooling, for direct input of
card decks. This was obviously very inefficient, especially since the
7040 only had channel A (the CPU) which meant that I/O wasn't even
overlapped. But as I remember they only had 6 tape drives and all were
needed for a Fortran compilation. Anyway the 1401 would chug away at a
couple of cards a second while Fortran was doing its input phase. The
inefficiency didn't matter a lot at that facility, but was obviously
going to be a problem back at the University.
When we eventually got the 7040/1401, a lot of our users switched from
(KDF-9) Algol to Fortran, since until the usage built up on the 7040
they could get several turnarounds in a day, instead of one. But the
inefficient running mode was still obviously a problem. A couple of
years later they managed to get another couple of tape drives from
somewhere, which allowed proper spooling to be done, but I'd left there
by then. I think around that time they also got 7040 Watfor, which made
things even faster for student jobs.
At about the time I left, the University was starting to think about a
new machine to replace the KDF-9 - I was pushing for a Burroughs B6700,
but they chose a Cyber 180. I don't know if IBM thought they were a
chance, but nobody was considering them. My memory of the 7040 is as a
machine that was fairly primitive compared to the KDF-9, but with
impressive software which contrasted with what we had to put up with on
the KDF-9 (a lot of the latter we'd written ourselves, but with very
limited manpower). The Fortran compiler was able to keep many of the
tape drives spinning by overlapping rewind on one unit with reading on
another - a rewind didn't tie up the CPU, even though the actual I/O
did. The impression was of a lot of things happening in parallel, even
though they weren't. The KDF-9, by contrast, could really have all its
I/O devices running in parallel, along with the CPU.
In 1971 I was in a little 2-man company where we used to buy time in the
evenings at the "other" university in Sydney, the University of NSW.
They had another 360/50, running OS/360 with MFT (Lynn, you'll know the
correct terminology). Anyway, memory used fixed partitions. They had
an 8MB mass storage device which was very slow at 8 microseconds. I
remember the charges were independent of where in memory the job loaded,
so I always tried to get a partition in fast memory, to keep the charges
down. I think they were using 360 Watfor for student jobs in the
daytime, but I wasn't around then. A lot of people owe a lot to the
University of Waterloo.
Cheers, Mike.
---------------------------------------------------------------
Mike Hore mike_h...@OVE.invalid.aapt.net.au
---------------------------------------------------------------
Walter Bushell
Peter Flass <Peter...@Yahoo.com> wrote:
> Most customers wanted a redesign/rewrite. The 1401 systems they had
> were mostly card and tape, and they wanted to start using disk. The
> 1401 programs were almost all Autocoder with lots of patches (decimal, I
> was recently reminded.) They wanted to start using COBOL and chuck the
> 1401 stuff completely.
Until they found out what it would cost to convert the programs.
Anne & Lynn Wheeler
> Until they found out what it would cost to convert the programs.
re:
http://www.garlic.com/~lynn/2009b.html#67 IBM tried to kill VM?
http://www.garlic.com/~lynn/2009b.html#71 IBM tried to kill VM?
the univesity had a 407 "plug-board" accounting program that ran
daily. this morphed into a 1401 program that simulated the 407
plugboard. then this was auto-translated into 360 cobol program (still
ran daily).
daily runs on 360/67 (running as 360/65 with os/360) still ended by
printing out the 407 sense switch settings. one day, there was values
printed than normal. everything was suspended while they tried to figure
out what happened. after an hr or so (not being able to find anybody
that understood the program) ... they decided just to rerun the
application.
In the early 70s, Amdahl had a seminar at MIT (large auditorium with
lots of attendence). One question was what justification did he use to
get (venture) funding for his clone processor business. His reply was
that customers already had a couple hundred billion invested in 360
software applications ... and even if IBM were to totally walk away from
360, there was enough applications to keep him in business until the end
of the century.
misc. past posts mentioning 407 plug-board:
http://www.garlic.com/~lynn/99.html#137 Mainframe emulation
http://www.garlic.com/~lynn/2000.html#19 Computer of the century
http://www.garlic.com/~lynn/2001f.html#5 Emulation (was Re: Object code (was: Source code - couldn't resist compiling it :-))
http://www.garlic.com/~lynn/2001m.html#52 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2002d.html#21 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2003j.html#23 A Dark Day
http://www.garlic.com/~lynn/2003n.html#41 When nerds were nerds
http://www.garlic.com/~lynn/2004d.html#44 who were the original fortran installations?
http://www.garlic.com/~lynn/2005e.html#29 Using the Cache to Change the Width of Memory
http://www.garlic.com/~lynn/2005n.html#3 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2006b.html#5 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006s.html#66 Why these original FORTRAN quirks?; Now : Programming practices
http://www.garlic.com/~lynn/2008c.html#10 Usefulness of bidirectional read/write?
misc. past posts mentioning Amdahl's talk at MIT:
http://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2002j.html#20 MVS on Power (was Re: McKinley Cometh...)
http://www.garlic.com/~lynn/2003.html#36 mainframe
http://www.garlic.com/~lynn/2003e.html#13 unix
http://www.garlic.com/~lynn/2003e.html#15 unix
http://www.garlic.com/~lynn/2003h.html#32 IBM system 370
http://www.garlic.com/~lynn/2003i.html#3 A Dark Day
http://www.garlic.com/~lynn/2003p.html#30 Not A Survey Question
http://www.garlic.com/~lynn/2004d.html#22 System/360 40th Anniversary
http://www.garlic.com/~lynn/2004h.html#20 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004l.html#51 Specifying all biz rules in relational data
http://www.garlic.com/~lynn/2004m.html#53 4GHz is the glass ceiling?
http://www.garlic.com/~lynn/2004o.html#66 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005b.html#47 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005e.html#35 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005r.html#49 MVCIN instruction
http://www.garlic.com/~lynn/2006.html#7 EREP , sense ... manual
http://www.garlic.com/~lynn/2006c.html#18 Change in computers as a hobbiest
http://www.garlic.com/~lynn/2007f.html#61 Is computer history taught now?
http://www.garlic.com/~lynn/2007f.html#77 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007g.html#57 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007k.html#46 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007m.html#15 Patents, Copyrights, Profits, Flex and Hercules
http://www.garlic.com/~lynn/2007m.html#34 IBM 8000 ???
http://www.garlic.com/~lynn/2007p.html#9 CA to IBM product swap
http://www.garlic.com/~lynn/2007t.html#68 T3 Sues IBM To Break its Mainframe Monopoly
http://www.garlic.com/~lynn/2007v.html#101 It keeps getting uglier
http://www.garlic.com/~lynn/2008g.html#54 performance of hardware dynamic scheduling
http://www.garlic.com/~lynn/2008k.html#53 recent mentions of 40+ yr old technology
http://www.garlic.com/~lynn/2008m.html#1 Yet another squirrel question - Results (very very long post)
Walter Bushell
Anne & Lynn Wheeler <ly...@garlic.com> wrote:
> Walter Bushell <pr...@panix.com> writes:
> > Until they found out what it would cost to convert the programs.
>
> re:
> http://www.garlic.com/~lynn/2009b.html#67 IBM tried to kill VM?
> http://www.garlic.com/~lynn/2009b.html#71 IBM tried to kill VM?
>
> the univesity had a 407 "plug-board" accounting program that ran
> daily. this morphed into a 1401 program that simulated the 407
> plugboard. then this was auto-translated into 360 cobol program (still
> ran daily).
What they didn't reconvert the program directly to 360. Ah, no such
program and beyond I/O probably consumed close to 0 resources.
I've found that if you replace a program, with one of immensely greater
functionality but leave 1 out of a million features of the old, you'll
get endless complaints.
Joe Morris
> Peter Flass <Peter...@Yahoo.com> wrote:
>> Most customers wanted a redesign/rewrite. The 1401 systems they had
>> were mostly card and tape, and they wanted to start using disk. The
>> 1401 programs were almost all Autocoder with lots of patches (decimal, I
>> was recently reminded.) They wanted to start using COBOL and chuck the
>> 1401 stuff completely.
>
> Until they found out what it would cost to convert the programs.
What was the name of the IBM (Type 3?) program that read Autocoder source
and spat out an allegedly equivalent COBOL program? All I remember of it
was looking at the output and immediately deciding not to waste my time
trying to use it.
One of my cow orkers swiped a line from Doc Smith's _Lensman_ books to
summarize our opinion of the "converter" by noting the he "could chew a
mouthful of card chips and *puke* a better program."
Joe Morris
Walter Bushell
Anne & Lynn Wheeler <ly...@garlic.com> wrote:
> the univesity had a 407 "plug-board" accounting program that ran
> daily. this morphed into a 1401 program that simulated the 407
> plugboard. then this was auto-translated into 360 cobol program (still
> ran daily).
But nobody knows what it does. Circumstances could break it at any time,
and there is no replacement possible, the plugboarder doesn't work there
anymore and is probably doesn't remember anything about it and if he
does doesn't want to talk about it or is dead.
Anne & Lynn Wheeler
> What they didn't reconvert the program directly to 360. Ah, no such
> program and beyond I/O probably consumed close to 0 resources.
>
> I've found that if you replace a program, with one of immensely greater
> functionality but leave 1 out of a million features of the old, you'll
> get endless complaints.
re:
http://www.garlic.com/~lynn/2009b.html#74 IBM tried to kill VM?
I think there was an intermediate step where the 1401 program (that
emulated 407 plug-board) was auto-translated to 709 cobol ... and then
the 709 cobol was auto-translated to 360 cobol (and as mentioned, they
couldn't find anybody still around that understood the original 407
plug-board).
recent related "re-engineering" post
http://www.garlic.com/~lynn/2009.html#87 Cleaning Up Spaghetti Code vs. Getting Rid of It
Peter Flass
Actually, PPOE did a good business for years doing mostly redesigns and
rewrites of 1401 stuff on 360's. The customers I saw used emulation
only until the new code was ready, especially as going into and out of
emulation on a /30 required an IPL. Most 1401 stuff was run from cards
and everyone held their breath that there wouldn't be a major jam
reading in the program.
Walter Bushell
"Joe Morris" <j.c.m...@verizon.net> wrote:
Somewhat like Microsoft Words HTML, which although horrid actually
works. I had one friend who started using that or what was it Front
Page, until she looked at the code and dropped it because the code was
horrid. I actually said, "I tried to tell you so."
jmfbahciv
That's why you do your research first. A lot of that is looking
over the shoulders of the "secretaries" to watch what they do
the most, learn their shortcuts, and listen for the times they
start swearing using longshoremen language.
These kinds of conversions are fun to do. You naturally become
a bit god in their eyes and they are eager to learn and do learn...
more than you. They also come up with some remarkable "improvements"
which can keep you supplied in cake and beer for the rest of your
work life in that area.
/BAH
Peter Flass
Yes, but this assumes someone who could actually look at the code and
understand it, which rules out 90% of the boobosity out there. Probably
back page, since word hides all its badness where no one can see it.
Rich Alderson
Which reminds me of an incident in the Financial Systems Group at the
University of Chicago Computation Center in August, 1979. (I'm sure of the
month because it was in my first couple of weeks on that job.)
Kris Yasutake started with the group about the same time that I did. (I was an
internal hire, going from half time in Applications to full time in FS; Kris
was an outside hire, from the National Opinion Research Center.) She was a
go-getter, and was a little bored with the stuff she was handed her first week,
so she went to the assistant manager and told him that she didn't have enough
to do.
He found something. A large part of the University's accounting system was
done with 1401 Autocoder programs that reprised the accounting machine work
done in the 1950s. They were written by a gentleman who still worked for the
Comptroller's Office, and his young protege, who had gone on to become the
assistant manager of Financial Systems. They were not (well) commented, and
there was no documentation other than the accounting codebooks.
Kristine's assignment was to learn Autocoder and create flow charts of the
entire accounting system.
I moved from FS to the systems programming group in August, 1982. Kris
finished her assignment shortly before that move. We took her out for a
celebratory lunch, as I recall.
(As far as I know, she never ever told a manager she didn't have enough to do
ever again, but I haven't seen her since I moved to Stanford in 1984.)
--
Rich Alderson "You get what anybody gets. You get a lifetime."
ne...@alderson.users.panix.com --Death, of the Endless
Joe Pfeiffer
>
> (As far as I know, she never ever told a manager she didn't have enough to do
> ever again, but I haven't seen her since I moved to Stanford in 1984.)
Be Careful What You Wish For
jmfbahciv
I always asked, knowing I'd get a mess. If you want to learn about how
stuff gets done, clean up one those messes. Scratching the surface
uncovers lots of worms to catch fish with.
/BAH
capek@ieee.org <Peter Capek>
360 in a virtual machine... brings to mind the
story recounted below, which was posted on the CYHIST mailing list...
It has an air of plausibility
about it, but I can't vouch for it; reposted verbatim, except for line
breaks. Peter Capek
Date: Tue, 28 Jan 1997 09:50:02 EST
From: "Wesley J. Miller ((8-444) 919-254-9774)" <pun...@VNET.IBM.COM>
Subject: CM> Emulation
X-cc: jay...@VNET.IBM.COM
______________________________________________________________________
______________________________________________________________________
A friend, Jim Ayres, passed along the following story about emulation
that may well
set a record for both nesting of emulations and absurdity in the
courts and unions.
Wesley
===========================================================================
The most outrageous case of nesting Operating Systems:
I had a customer who had a payroll system setup in the 1950's using
407 punch card accounting
machines. There was a problem (labor dispute, I think) that led to a
permanent injunction that
forbade the customer from changing the system.
When they acquired a 1401 system in the early 1960's, the method had
to be brought over, intact,
from the 407 to the 1401. They bought a program, called FARGO. Each
wire on the 407 plug board
was coded into a punch card, and the deck of cards was feed to FARGO
as input. FARGO's output
was 1401 source code that emulated the original 407 function. This was
found satisfactory to
the court, and became the way of doing business.
In 1967, the customer acquired a System/360 model 30, and migrated the
FARGO generated code to
the 360/30 - 1401 Emulator. When the 360/30 was running in 1401 mode,
it was using different
microcode and WAS a 1401 for all practical purposes.
Later a software emulator was installed that allowed the 1401 code to
be run as a 360 DOS
application in one of the three partitions that DOS/360 then
supported.
As time went along, the company was bought by a larger firm, who moved
its system to a 360 model 65
using OS/360. The application was now run under a DOS emulator within
OS/360.
Finally, the parent company moved the entire DP operation of the
smaller company to a VM/370
system. It's OS applications were run in a VM guest machine. Thus the
stack of systems emulated
became something like this:
VM/370 <- OS/360 <- DOS/360 <- 1401 Emulator <- 1401 407/Emulator <-
407
Each of the transistions had to be blessed by the court. It has been
twenty years since I
had contact with that customer, and I have often wondered if that 407
function was now being
emulated a few layers deeper.
Probably, the principals are now all dead or retired, but if not,
someone may still be sitting
at a (virtual) keypunch to prepare a (virtual) card to be read into a
(virtual ** 5) 407 accounting
machine to write a real paycheck.
Jim Ayres
jay...@vnet.ibm.com
krw
@t3g2000yqa.googlegroups.com>, peter...@gmail.com says...>
Michael Wojcik
> [story from Jim Ayres, via Wesley Miller]
> ... Thus the stack of systems emulated became something like this:
>
> VM/370 <- OS/360 <- DOS/360 <- 1401 Emulator <- 1401 407/Emulator <-
> 407
>
> Each of the transistions had to be blessed by the court. It has been
> twenty years since I
> had contact with that customer, and I have often wondered if that 407
> function was now being emulated a few layers deeper.
The thing to do would be to run the OS/360 image under VM/360 running
in Hercules under Windows in a VMWare virtual machine running under
Linux on a laptop. Then you'd have a portable 407 emulator, and you
could run your payroll from the local Starbuck's.
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Anne & Lynn Wheeler
Michael Wojcik <mwo...@newsguy.com> writes:
> The thing to do would be to run the OS/360 image under VM/360 running
> in Hercules under Windows in a VMWare virtual machine running under
> Linux on a laptop. Then you'd have a portable 407 emulator, and you
> could run your payroll from the local Starbuck's.
re:
http://www.garlic.com/~lynn/2009b.html#67 IBM tried to kill VM?
http://www.garlic.com/~lynn/2009b.html#71 IBM tried to kill VM?
http://www.garlic.com/~lynn/2009b.html#74 IBM tried to kill VM?
http://www.garlic.com/~lynn/2009b.html#76 IBM tried to kill VM?
a little x-over from this thread:
http://www.garlic.com/~lynn/2009c.html#15 Bletchley Park fires up Big Green-Eyed Monster
http://www.garlic.com/~lynn/2009c.html#17 Bletchley Park fires up Big Green-Eyed Monster
there was something a decade or so ago about some FAA installation in
and/or around Denver that was running some old 360 code under
Fundamental Software
http://www.funsoft.com/
on Sequent (intel architecture) systems.
Joe Morris
> The discussion about emulation of a 407 on a 1401 on an emulator on a
> 360 in a virtual machine... brings to mind the
> story recounted below, which was posted on the CYHIST mailing list...
> It has an air of plausibility
> about it, but I can't vouch for it; reposted verbatim, except for line
> breaks. Peter Capek
[snip]
> Probably, the principals are now all dead or retired, but if not,
> someone may still be sitting
> at a (virtual) keypunch to prepare a (virtual) card to be read into a
> (virtual ** 5) 407 accounting
> machine to write a real paycheck.
>
> Jim Ayres
> jay...@vnet.ibm.com
well...not quite the same thing, but as a demo I've run
A real Intel box with a Pentium
Windows XP Professional
VMWare Workstation
Red Hat Linux
Hercules
VM/370
CMS
...and somewhere I've got the distribution tape images for OS/360 and could
probably dig out IESRPG to do the 407 emulation task.
Joe Morris
ArarghMai...@not.at.arargh.com
<j.c.m...@verizon.net> wrote:
<snip>
>well...not quite the same thing, but as a demo I've run
>
>A real Intel box with a Pentium
> Windows XP Professional
> VMWare Workstation
> Red Hat Linux
> Hercules
> VM/370
> CMS
>
>...and somewhere I've got the distribution tape images for OS/360 and could
>probably dig out IESRPG to do the 407 emulation task.
Now, if Hercules supported the 360s 140x feature then you could do:
A real Intel box with a Pentium
Windows XP Professional
VMWare Workstation
Red Hat Linux
Hercules
VM/370
OS/360
1401
407
:-)
--
ArarghMail902 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the extra stuff from the reply address.
Mike Hore
> Now, if Hercules supported the 360s 140x feature then you could do:
>
> A real Intel box with a Pentium
> Windows XP Professional
> VMWare Workstation
> Red Hat Linux
> Hercules
> VM/370
> OS/360
> 1401
> 407
> :-)
Would Hercules run under VirtualPC on a PowerPC Mac? VPC supports most
Windows versions.
Morten Reistad
Wasn't there a competition about running the largest number of
emulations inside each other? You couldn't duplicate a host-client
relationship, but you could otherwise run the same emulator twice.
I..e Linux -> Vmware -> windows -> wmware -> BSD is ok
-- mrr
Anne & Lynn Wheeler
Morten Reistad <fi...@last.name> writes:
> Wasn't there a competition about running the largest number of
> emulations inside each other? You couldn't duplicate a host-client
> relationship, but you could otherwise run the same emulator twice.
>
> I..e Linux -> Vmware -> windows -> wmware -> BSD is ok
well in the early 70s, science center
http://www.garlic.com/~lynn/subtopic.html#545tech
real 360/67
standard cp67
in virtural 360/67, modified cp67 providing virtual 370 architecutre
in virtual 370, modified cp67 that ran on 370 architecture
cms
having a standard cp67 and modified cp67 (with support for virtual 370)
was a security issue. cambridge system had access by various
non-employees/students from various educational institutions in the
cambridge area. 370 virtual memory hadn't been announced and was a
closely guarded corporate secret.
the above configuration was in regular use a year before the first
engineering 370 with virtual memory hardware was operational. in fact,
the modified cp67 for running on 370 hardware ... was regression test
for that engineering 370. there is even folklore that when it was first
ipled/booted, it failed. after some diagnostic ... it turned out that
the engineers had (incorrectly) reversed the op-codes for some 370
instructions. as an expediate, the cp67 kernel was quickly modified to
use the (incorrect) opcodes.
the other scenario was that in the early part of this decade there were
efforts running linux in virtual machines. mainframe hardware had LPARs
(dating back to the 80s, hypervisor, pr/sm) ... i.e. logical
partitions. This is basically a subset of virtual machine supervisor
migrated into the hardware/microcode of the machine ... which allows
"partititoning" of the hardware into a small number (couple dozen) of
"partitions".
One early test had a "small" LPAR (i.e. limited amount of real machine
resources) running a copy of virtual machine supervisor. then in the
virtual machine supervisor ... over 40,000 linux virtual machines were
created. old post with extracts from vmesa-l touting peak linux virtual
machines (41,400):
http://www.garlic.com/~lynn/2000b.html#62 VM (not VMS or Virtual Machine, the IBM sort)
old posts mentioning the work at the science center supporting
370 virtual machines in cp67:
http://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
http://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
http://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
http://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
http://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
http://www.garlic.com/~lynn/2006q.html#49 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006w.html#3 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006x.html#19 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2007i.html#16 when was MMU virtualization first considered practical?
http://www.garlic.com/~lynn/2007m.html#11 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007p.html#74 GETMAIN/FREEMAIN and virtual storage backing up
http://www.garlic.com/~lynn/2007q.html#23 GETMAIN/FREEMAIN and virtual storage backing up
http://www.garlic.com/~lynn/2007r.html#68 High order bit in 31/24 bit address
ArarghMai...@not.at.arargh.com
<mike_h...@OVE.invalid.aapt.net.au> wrote:
>ArarghMai...@NOT.AT.Arargh.com wrote:
>
>> Now, if Hercules supported the 360s 140x feature then you could do:
>>
>> A real Intel box with a Pentium
>> Windows XP Professional
>> VMWare Workstation
>> Red Hat Linux
>> Hercules
>> VM/370
>> OS/360
>> 1401
>> 407
>> :-)
>
>Would Hercules run under VirtualPC on a PowerPC Mac? VPC supports most
>Windows versions.
You are asking the wrong person, I have no idea.
Charlie Gibbs
(Morten Reistad) writes:
> Wasn't there a competition about running the largest number of
> emulations inside each other? You couldn't duplicate a host-client
> relationship, but you could otherwise run the same emulator twice.
>
> I..e Linux -> Vmware -> windows -> wmware -> BSD is ok
I once ran two levels of emulator on my Amiga: Transformer, which
emulates an 8088 on the Amiga's 68000, and dosemu, which emulates
an 8080 on an 8088. Since these are both software interpreters,
when I then fired up the CP/M version of BASIC-80, I was running
three nested interpreters. The doubly-interpreted BASIC interpreter
took 7 seconds to calculate a sine, but it got there eventually.
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!