Re: DOS descendant still lives was Re: slight reprieve on the z.

[Anne & Lynn Wheeler]

t...@vse2pdf.com (Tony Thigpen) writes:
> The 4300 did not come out of Endicott. It was developed in Germany, in
> the same lab that developes DOS/VSE.

As an undergraduate I do lots of work on cp67 (including to run in
256kbyte machine). The morph of cp67 to vm370, did a lot of
simplification of cp67 at the same time bloating the kernel size so
performance was seriously impacting running in 256kbytes. Boeblingon
does 115&125 ... and at one point I get dragged into optimizing vm370 to
run on 256kbyte 125 customer machines.

boeblingon does 135 and 138.  Then Boeblingon does 4331. Endicott had
con'ed me into doing lots of work on 148, vm/370 ecps. At the same time
I was helping Endicott with 148 vm370 ECPS, the 125 group also asked me
to do the design and specification for a 5-way 125 SMP machine (which
never shipped, it turns out the Endicott 148 people felt threaten that
5-way 125 multiprocessor would impact their market ... which put me in
odd position since I was doing both).

Later was dragged into doing a lot of work with regard to 4341.

Across the street, the disk engineering group in bldg. 14 and the disk
product test group in bldg. 15 dragged me into playing disk engineer ...
some past posts
http://www.garlic.com/~lynn/subtopic.html#disk

the product test group in bldg 15 would typically get the 3rd or 4th
engineering model for doing disk i/o testing. they got the 3rd
enginneering model of 3033 and very early E4 (4341) engineering machine
for testing.  Because I was doing so much stuff for them, I would get
lots of time on bldg. 15 system for other stuff I might want to do. The
performance test marketing group in Endicott con'ed me into doing
customer benchmarking on the bldg. 15 enginneering E4/4341 ... since I
had bettter access to the machine ... than they had to early engineering
machines in Endicott. some old email
http://www.garlic.com/~lynn/lhwemail.html#43xx

email includes references that when the E4/4341 originally arrived in
bldg. 15 ... it had the proceessor cycle slowed down (allowed machine to
work as they refined the engineering) so that the benchmarks were not as
good as they could be. Later as they refined the machine, they were able
to crank down the processor cycle.

One of the benchmarks was for LLNL that was looking at getting 70 4341s
for a compute farm (sort of the precursor to modern cluster, GRID and
supercomputing). It showed 4341 was faster than 158&3031 and 4341
cluster was faster, cheaper, much less floor space and environmentals
than 3033. The cluster 4341 threat to 3033 was so big that at one point,
the head of POK got corporate to cut the allocation of critical 4341
manufacturing component in half.

other trivia: circa 1980, there was plan to move the large variety of
internal microprocessors to 801/RISC, including low (vertical
microcode) 370s, what was to be as/400, lots of controllers, etc. For
various reasons that effort floundered and they continued with various
CISC microprocessors. I helped somebody in endicott with white paper
showing that VLSI was moving to the point, that large part of 370 could
be implemented in silicon ... as opposed to having to be emulated
... which would be much faster & price/performance than pure emulation
in 801/RISC (other side effect was that some number of 801/RISC
engineers leave and go to work on RISC projects at other vendors).

Boeblingon does 4361 (4331 follow-on) and Endicott does 4381 (4341
follow-on) in CISC. IBM was expecting that 4361/4381 would continue the
enormous 4331/4341 sales explosion, but by that time the mid-range
market was starting to move to workstations and large PCs.

Previous posts mentions in the wake of the FS failure, there was mad
rush to get stuff back into 370 product pipeline, this included 3033
(168 logic remap to faster chips) and 3081/xa kicked off at the same
time
http://www.jfsowa.com/computer/memo125.htm

Turns out during the 3033 engineering period, I was also involved in a
16-way 370 SMP effort and we con'ed some of the 3033 processor engineers
to work on it in their spare time. At first everybody thot it was really
great effort, and then somebody tells the head of POK that it could be
decades before MVS had effective 16-way support ... and he then invites
some of us to never visit POK again ... and tells the 3033 processor
engineers to stop being distracted by other activities.

With the 3033 out the door, the 3033 processor engineers start work on
trout1.5 (aka 3090, in parallel with ongoing 3081/xa) circa 1980.  Part
of the 3090 effort was to use 4331 as service processor running a highly
modified version of vm370 release 6 ... and I periodically get dragged
into that effort. The 3090 service processor eventually gets upgraded to
pair of 4361s running highly modified version of vm370 release 6 ... a
couple (later) old email references
http://www.garlic.com/~lynn/2010e.html#email861031
http://www.garlic.com/~lynn/2010e.html#email861223

Early days of REXX (well before ships to 

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Anne & Lynn Wheeler]

other trivia

in the wake of FS and mad rush ... 303x was kicked off ... as mentioned
3033 was 168 logic remapped to 20% faster chips ... that happened to
have ten times more circuits per chip. Using original 168 logic, 3033
would have been only 20% faster than 168 (aka 3.6mips). However, some
specific logic rework to use the larger circuits per chip got it up to
50% faster than 168 (4.5mips).

158 manufacturing had been enormously automated ... somewhat like what
they quote for incremental cost of an automobile rolling off the
line. The 158 integrated channel microcode was used for the 303x channel
director (158 engine w/o 370 microcode and with the integrated channel
microcode). 3031 was two 158 engines, one with just the 370 microcode and
a 2nd (channel director) with just just the integrated channel
microcode. A 3032 is 168-3 reworked to use 303x channel director for
external channels.

some benchmark numbers for LLNL ... looking at getting 70 4341s for
computer farm (precursor to modern GRID, cloud, and supercomputers)

  158   3031  4341

Rain  45.64 secs   37.03 secs 36.21 secs
Rain4 43.90 secs   36.61 secs 36.13 secs

also times approx;
   145168-3  91
   145 secs.  9.1 secs  6.77 secs

also had run in 35.77 on CDC6600. 158 370 was slower than 3031 because
the (single) 158 engine was being shared between the 370 microcode and
the integrated channel microcode (which ran even when channels were
idle).

Part of the original morph from cp67 (and 360/67) to VM370 (multiple 370
models) was vm370 had table of supported 370 models ... with various
model characteristics. As part of my moving from cp67 to vm370 ... old
email reference:
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

... I replaced the static table of supported 370 models with dynamic
code to determaine the characteristics ... it made it much simpler to
deploy a csc/vm production system to different machines (like
engineering models) not included in the shipped static table of
supported machines. some posts discussion work at the scientific center
(why it was called csc/vm). some past scientific center posts
http://www.garlic.com/~lynn/subtopic.html#545tech

Later I transfer to San Jose research ... on the san jose plant site
(accross the street from bldgs. 14&15) and csc/vm morphs into sjr/vm.
Old 4341 email about engineering model processor cycle time includes
reference to checking the DSPSL value ... which is one of my dynamically
determined values ... old reference
http://www.garlic.com/~lynn/2006y.html#email790220

from my dynamic adaptive resource manager ... which was guinea
pig for starting to charge for system/kernel software (customers
referred to as "fair share" since the default resource management
policy was "fair share") ... some past posts
http://www.garlic.com/~lynn/subtopic.html#fairshare

then somebody leaks the benchmark numbers to the press ... and
they initially try to blame me ... reference
http://www.garlic.com/~lynn/2006y.html#email790226

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Shmuel Metz (Seymour J.)]

In <87egefr5wr@garlic.com>, on 12/21/2015
   at 10:52 AM, Anne & Lynn Wheeler  said:

>It showed 4341 was faster than 158&3031

Doesn't that depend on whether your benchmark is packed decimal or
gloating poin arithmetic?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Clark Morris]

On 20 Dec 2015 18:15:48 -0800, in bit.listserv.ibm-main you wrote:

>In <3555618195553184.wa.paulgboulderaim@listserv.ua.edu>, on
>12/20/2015
>   at 07:14 PM, Paul Gilmartin
><000433f07816-dmarc-requ...@listserv.ua.edu> said:
>
>>On Sun, 20 Dec 2015 20:11:27 -0500, Shmuel Metz (Seymour J.) wrote: >
one example explicitly named being VSE/Power versus Power/VS.
>>>
>>>POWER was an addon.
>>> 
>>Is VSE without POWER almost, but not quite, entirely unlike OS
>>without JES?
>
>Yes, especially when you're using different SPOOL software and don't
>want to convert. Or is that too hard to grasp?
> 
We used ASAP for spooling in my shop and GRASP was another option.

Clark Morris

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Anne & Lynn Wheeler]

jcew...@acm.org (Joel C. Ewing) writes:
> No (about the "free", not about the "dead for decades"), DOS/VS was the
> last really free base (last version Release 34?).   Perhaps technically
> DOS/VSE was "free", as there didn't appear to be a monthly licensing
> charge for DOS/VSE itself (Computerworld, April 30, 1979, p4), but in
> the practical sense a production DOS/VSE system was definitely not free
> as there were monthly support charges for DOS/VSE and separate monthly
> licensing plus support charges for must-have VSE add-on components like
> VSE/Power and others.  DOS/VSE came out with the IBM 4331 & 4341
> processors in 1979 and supported running in both S/370 mode or the
> ECPS:VSE mode supported by the 4300 processor family.

various legal actions resulted in 23June1969 unbundling announcement
where (application) software & other stuff started to be charged for
(however they made the case the kernel software should still be free).
some past posts
http://www.garlic.com/~lynn/submain.html#unbundle

during future system effort 370 efforts were being killed off (lack of
370 products there era is credited with clone processors market
foothold). after future system failed ... past posts
http://www.garlic.com/~lynn/submain.html#futuresys

there was mad rush to get stuff back into 370 product pipeline.
POK kick off 3033 (168 logic mapped to faster chips) and
3081/XA in parallel ... reference
http://www.jfsowa.com/computer/memo125.htm
 
XA had a lot of extensions tailored for MVS.

Endicott did something similar for e-architecture (4331 & 4341) tailored
for vs1 In large part a single virtual address space supported as
part of the hardware architecture. Rather than having segment & page
tables ... there were two new instructions that told the machine what
virtual address was at what real address ... and invalidated the virtual
address.

However there was an enormous explosion in vm/4300 sales (before
announce, 4341s were referred to a "E4") ... which required multiple
virtual address space ... which met that large number of 4300s ran in
370 mode rather than e-mode. Note that POK had convinced corporate to
kill off the vm370 product and move all the development people to POK as
part of MVS/XA development (including excuse that MVS/XA would ship on
time, if they couldn't get the additional resources). Endicott manage to
save the vm370 product mission, but had to reconstitute a development
group from scratch. some old 4300 related email
http://www.garlic.com/~lynn/lhwemail.html#43xx

Note that VS1 and VM/370 "ECPS" was different than e-machine
architecture. It originated with the 138/148 (virgil/tully) ...  where
selected high use kernel/system instructions paths were implemented in
microcode. The low & mid-range machine were vertical microcode machines
with an avg of 10 native instructions per 370 instruction (somewhat
analogous to mainframe emulators that run on Intel platforms). Kernel
instruction paths tended to get 10:1 performance improvement when moved
to microcode. I did the initial study and effort for the VM/370 ECPS
... old post with results for selecting pathlengths to be moved to
microcode (I was told, that I needed to select the 6kbytes of highest
executed kernel, which turned out to account of 80% of vm/370 kernel
execution)
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

trivia ... the methodology for selecting the VS1 paths wasn't nearly so
rigorous.

other trivia ... major motivation for Future System product was as
countermeasure to clone controllers ... but the (failed) Future System
effort contributed significantly to the rise of the clone processors.
The threat of clone processors resulted in decision to transition to
charging for system/kernel software. I continued to work on 370 stuff
all during the FS period ... even periodically ridiculing FS stuff
... which wasn't exactly career enhancing. Also one of my hobbies was
developing advanced enhanced operating systems for internal
datacenters ... some old email
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

In any case, the mad rush to get stuff back into 370 product pipeline
contributed to decision to pick up various of my stuff and ship it in
products for customers. One part of that stuff (dynamic adaptive
resource manager) was selected to be guinea pig for starting to charge
for system/kernel software ... and I had to spend some amount of time
with lawyers & business types going over policies for system/kernel
software charging.

even more trivia: when 3033 looked at doing something similar to ECPS
... it didn't work out as well. 3033 was horizontal microcode machine
that had been optimized so it was executing nearly one 370 instruction
per machine cycle. Directly dropping system/kernel 370 pathlengths into
microcode could even result in running slower than the original 370.

-- 
virtualization experience 

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Tony Thigpen]

> Endicott did something similar for e-architecture (4331 & 4341)
> tailoredfor vs1

The 4300 did not come out of Endicott. It was developed in Germany, in 
the same lab that developes DOS/VSE.


Tony Thigpen

Anne & Lynn Wheeler wrote on 12/21/2015 03:05 AM:

jcew...@acm.org (Joel C. Ewing) writes:

No (about the "free", not about the "dead for decades"), DOS/VS was the
last really free base (last version Release 34?).   Perhaps technically
DOS/VSE was "free", as there didn't appear to be a monthly licensing
charge for DOS/VSE itself (Computerworld, April 30, 1979, p4), but in
the practical sense a production DOS/VSE system was definitely not free
as there were monthly support charges for DOS/VSE and separate monthly
licensing plus support charges for must-have VSE add-on components like
VSE/Power and others.  DOS/VSE came out with the IBM 4331 & 4341
processors in 1979 and supported running in both S/370 mode or the
ECPS:VSE mode supported by the 4300 processor family.


various legal actions resulted in 23June1969 unbundling announcement
where (application) software & other stuff started to be charged for
(however they made the case the kernel software should still be free).
some past posts
http://www.garlic.com/~lynn/submain.html#unbundle

during future system effort 370 efforts were being killed off (lack of
370 products there era is credited with clone processors market
foothold). after future system failed ... past posts
http://www.garlic.com/~lynn/submain.html#futuresys

there was mad rush to get stuff back into 370 product pipeline.
POK kick off 3033 (168 logic mapped to faster chips) and
3081/XA in parallel ... reference
http://www.jfsowa.com/computer/memo125.htm

XA had a lot of extensions tailored for MVS.

Endicott did something similar for e-architecture (4331 & 4341) tailored
for vs1 In large part a single virtual address space supported as
part of the hardware architecture. Rather than having segment & page
tables ... there were two new instructions that told the machine what
virtual address was at what real address ... and invalidated the virtual
address.

However there was an enormous explosion in vm/4300 sales (before
announce, 4341s were referred to a "E4") ... which required multiple
virtual address space ... which met that large number of 4300s ran in
370 mode rather than e-mode. Note that POK had convinced corporate to
kill off the vm370 product and move all the development people to POK as
part of MVS/XA development (including excuse that MVS/XA would ship on
time, if they couldn't get the additional resources). Endicott manage to
save the vm370 product mission, but had to reconstitute a development
group from scratch. some old 4300 related email
http://www.garlic.com/~lynn/lhwemail.html#43xx

Note that VS1 and VM/370 "ECPS" was different than e-machine
architecture. It originated with the 138/148 (virgil/tully) ...  where
selected high use kernel/system instructions paths were implemented in
microcode. The low & mid-range machine were vertical microcode machines
with an avg of 10 native instructions per 370 instruction (somewhat
analogous to mainframe emulators that run on Intel platforms). Kernel
instruction paths tended to get 10:1 performance improvement when moved
to microcode. I did the initial study and effort for the VM/370 ECPS
... old post with results for selecting pathlengths to be moved to
microcode (I was told, that I needed to select the 6kbytes of highest
executed kernel, which turned out to account of 80% of vm/370 kernel
execution)
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

trivia ... the methodology for selecting the VS1 paths wasn't nearly so
rigorous.

other trivia ... major motivation for Future System product was as
countermeasure to clone controllers ... but the (failed) Future System
effort contributed significantly to the rise of the clone processors.
The threat of clone processors resulted in decision to transition to
charging for system/kernel software. I continued to work on 370 stuff
all during the FS period ... even periodically ridiculing FS stuff
... which wasn't exactly career enhancing. Also one of my hobbies was
developing advanced enhanced operating systems for internal
datacenters ... some old email
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

In any case, the mad rush to get stuff back into 370 product pipeline
contributed to decision to pick up various of my stuff and ship it in
products for customers. One part of that stuff (dynamic adaptive
resource manager) was selected to be guinea pig for starting to charge
for system/kernel software ... and I had to spend some amount of time
with lawyers & business types going over policies for system/kernel
software charging.

even more trivia: when 3033 looked at doing something similar to ECPS
... it didn't work out as well. 3033 was horizontal microcode machine
that 

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Mike Schwab]

 No wonder they didn't break.

On Mon, Dec 21, 2015 at 6:27 AM, Tony Thigpen  wrote:
>> Endicott did something similar for e-architecture (4331 & 4341)
>> tailoredfor vs1
>
> The 4300 did not come out of Endicott. It was developed in Germany, in the
> same lab that developes DOS/VSE.
>
> Tony Thigpen
>
>
> Anne & Lynn Wheeler wrote on 12/21/2015 03:05 AM:
>>
>> jcew...@acm.org (Joel C. Ewing) writes:
>>>
>>> No (about the "free", not about the "dead for decades"), DOS/VS was the
>>> last really free base (last version Release 34?).   Perhaps technically
>>> DOS/VSE was "free", as there didn't appear to be a monthly licensing
>>> charge for DOS/VSE itself (Computerworld, April 30, 1979, p4), but in
>>> the practical sense a production DOS/VSE system was definitely not free
>>> as there were monthly support charges for DOS/VSE and separate monthly
>>> licensing plus support charges for must-have VSE add-on components like
>>> VSE/Power and others.  DOS/VSE came out with the IBM 4331 & 4341
>>> processors in 1979 and supported running in both S/370 mode or the
>>> ECPS:VSE mode supported by the 4300 processor family.
>>
>>
>> various legal actions resulted in 23June1969 unbundling announcement
>> where (application) software & other stuff started to be charged for
>> (however they made the case the kernel software should still be free).
>> some past posts
>> http://www.garlic.com/~lynn/submain.html#unbundle
>>
>> during future system effort 370 efforts were being killed off (lack of
>> 370 products there era is credited with clone processors market
>> foothold). after future system failed ... past posts
>> http://www.garlic.com/~lynn/submain.html#futuresys
>>
>> there was mad rush to get stuff back into 370 product pipeline.
>> POK kick off 3033 (168 logic mapped to faster chips) and
>> 3081/XA in parallel ... reference
>> http://www.jfsowa.com/computer/memo125.htm
>>
>> XA had a lot of extensions tailored for MVS.
>>
>> Endicott did something similar for e-architecture (4331 & 4341) tailored
>> for vs1 In large part a single virtual address space supported as
>> part of the hardware architecture. Rather than having segment & page
>> tables ... there were two new instructions that told the machine what
>> virtual address was at what real address ... and invalidated the virtual
>> address.
>>
>> However there was an enormous explosion in vm/4300 sales (before
>> announce, 4341s were referred to a "E4") ... which required multiple
>> virtual address space ... which met that large number of 4300s ran in
>> 370 mode rather than e-mode. Note that POK had convinced corporate to
>> kill off the vm370 product and move all the development people to POK as
>> part of MVS/XA development (including excuse that MVS/XA would ship on
>> time, if they couldn't get the additional resources). Endicott manage to
>> save the vm370 product mission, but had to reconstitute a development
>> group from scratch. some old 4300 related email
>> http://www.garlic.com/~lynn/lhwemail.html#43xx
>>
>> Note that VS1 and VM/370 "ECPS" was different than e-machine
>> architecture. It originated with the 138/148 (virgil/tully) ...  where
>> selected high use kernel/system instructions paths were implemented in
>> microcode. The low & mid-range machine were vertical microcode machines
>> with an avg of 10 native instructions per 370 instruction (somewhat
>> analogous to mainframe emulators that run on Intel platforms). Kernel
>> instruction paths tended to get 10:1 performance improvement when moved
>> to microcode. I did the initial study and effort for the VM/370 ECPS
>> ... old post with results for selecting pathlengths to be moved to
>> microcode (I was told, that I needed to select the 6kbytes of highest
>> executed kernel, which turned out to account of 80% of vm/370 kernel
>> execution)
>> http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
>>
>> trivia ... the methodology for selecting the VS1 paths wasn't nearly so
>> rigorous.
>>
>> other trivia ... major motivation for Future System product was as
>> countermeasure to clone controllers ... but the (failed) Future System
>> effort contributed significantly to the rise of the clone processors.
>> The threat of clone processors resulted in decision to transition to
>> charging for system/kernel software. I continued to work on 370 stuff
>> all during the FS period ... even periodically ridiculing FS stuff
>> ... which wasn't exactly career enhancing. Also one of my hobbies was
>> developing advanced enhanced operating systems for internal
>> datacenters ... some old email
>> http://www.garlic.com/~lynn/2006v.html#email731212
>> http://www.garlic.com/~lynn/2006w.html#email750102
>> http://www.garlic.com/~lynn/2006w.html#email750430
>>
>> In any case, the mad rush to get stuff back into 370 product pipeline
>> contributed to decision to pick up various of my stuff and ship it in
>> products for customers. One part of that stuff (dynamic adaptive
>> 

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Tony Thigpen]

Not only the 4300, but also the MP3000, which also did not break. :-)

Tony Thigpen

Mike Schwab wrote on 12/21/2015 10:36 AM:

  No wonder they didn't break.

On Mon, Dec 21, 2015 at 6:27 AM, Tony Thigpen  wrote:

Endicott did something similar for e-architecture (4331 & 4341)
tailoredfor vs1


The 4300 did not come out of Endicott. It was developed in Germany, in the
same lab that developes DOS/VSE.

Tony Thigpen


Anne & Lynn Wheeler wrote on 12/21/2015 03:05 AM:


jcew...@acm.org (Joel C. Ewing) writes:


No (about the "free", not about the "dead for decades"), DOS/VS was the
last really free base (last version Release 34?).   Perhaps technically
DOS/VSE was "free", as there didn't appear to be a monthly licensing
charge for DOS/VSE itself (Computerworld, April 30, 1979, p4), but in
the practical sense a production DOS/VSE system was definitely not free
as there were monthly support charges for DOS/VSE and separate monthly
licensing plus support charges for must-have VSE add-on components like
VSE/Power and others.  DOS/VSE came out with the IBM 4331 & 4341
processors in 1979 and supported running in both S/370 mode or the
ECPS:VSE mode supported by the 4300 processor family.



various legal actions resulted in 23June1969 unbundling announcement
where (application) software & other stuff started to be charged for
(however they made the case the kernel software should still be free).
some past posts
http://www.garlic.com/~lynn/submain.html#unbundle

during future system effort 370 efforts were being killed off (lack of
370 products there era is credited with clone processors market
foothold). after future system failed ... past posts
http://www.garlic.com/~lynn/submain.html#futuresys

there was mad rush to get stuff back into 370 product pipeline.
POK kick off 3033 (168 logic mapped to faster chips) and
3081/XA in parallel ... reference
http://www.jfsowa.com/computer/memo125.htm

XA had a lot of extensions tailored for MVS.

Endicott did something similar for e-architecture (4331 & 4341) tailored
for vs1 In large part a single virtual address space supported as
part of the hardware architecture. Rather than having segment & page
tables ... there were two new instructions that told the machine what
virtual address was at what real address ... and invalidated the virtual
address.

However there was an enormous explosion in vm/4300 sales (before
announce, 4341s were referred to a "E4") ... which required multiple
virtual address space ... which met that large number of 4300s ran in
370 mode rather than e-mode. Note that POK had convinced corporate to
kill off the vm370 product and move all the development people to POK as
part of MVS/XA development (including excuse that MVS/XA would ship on
time, if they couldn't get the additional resources). Endicott manage to
save the vm370 product mission, but had to reconstitute a development
group from scratch. some old 4300 related email
http://www.garlic.com/~lynn/lhwemail.html#43xx

Note that VS1 and VM/370 "ECPS" was different than e-machine
architecture. It originated with the 138/148 (virgil/tully) ...  where
selected high use kernel/system instructions paths were implemented in
microcode. The low & mid-range machine were vertical microcode machines
with an avg of 10 native instructions per 370 instruction (somewhat
analogous to mainframe emulators that run on Intel platforms). Kernel
instruction paths tended to get 10:1 performance improvement when moved
to microcode. I did the initial study and effort for the VM/370 ECPS
... old post with results for selecting pathlengths to be moved to
microcode (I was told, that I needed to select the 6kbytes of highest
executed kernel, which turned out to account of 80% of vm/370 kernel
execution)
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

trivia ... the methodology for selecting the VS1 paths wasn't nearly so
rigorous.

other trivia ... major motivation for Future System product was as
countermeasure to clone controllers ... but the (failed) Future System
effort contributed significantly to the rise of the clone processors.
The threat of clone processors resulted in decision to transition to
charging for system/kernel software. I continued to work on 370 stuff
all during the FS period ... even periodically ridiculing FS stuff
... which wasn't exactly career enhancing. Also one of my hobbies was
developing advanced enhanced operating systems for internal
datacenters ... some old email
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

In any case, the mad rush to get stuff back into 370 product pipeline
contributed to decision to pick up various of my stuff and ship it in
products for customers. One part of that stuff (dynamic adaptive
resource manager) was selected to be guinea pig for starting to charge
for system/kernel software ... and I had to spend some amount of time

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Paul Gilmartin]

On Sun, 20 Dec 2015 20:11:27 -0500, Shmuel Metz (Seymour J.) wrote:
>
>>one example explicitly named being VSE/Power versus Power/VS.
>
>POWER was an addon.
> 
Is VSE without POWER almost, but not quite, entirely unlike OS without JES?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Shmuel Metz (Seymour J.)]

In <3555618195553184.wa.paulgboulderaim@listserv.ua.edu>, on
12/20/2015
   at 07:14 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>On Sun, 20 Dec 2015 20:11:27 -0500, Shmuel Metz (Seymour J.) wrote: >
>>>one example explicitly named being VSE/Power versus Power/VS.
>>
>>POWER was an addon.
>> 
>Is VSE without POWER almost, but not quite, entirely unlike OS
>without JES?

Yes, especially when you're using different SPOOL software and don't
want to convert. Or is that too hard to grasp?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Shmuel Metz (Seymour J.)]

In <56773a22.1090...@acm.org>, on 12/20/2015
   at 05:30 PM, "Joel C. Ewing"  said:

>but the ComputerWorld article I referenced said that with DOS/VSE 
>users started to pay for components that used to be free with IBM 
>DOS/VS,

And you believed them because?

>one example explicitly named being VSE/Power versus Power/VS.

POWER was an addon.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Steve Thompson]

On 12/20/2015 08:14 PM, Paul Gilmartin wrote:

On Sun, 20 Dec 2015 20:11:27 -0500, Shmuel Metz (Seymour J.) wrote:



one example explicitly named being VSE/Power versus Power/VS.


POWER was an addon.


Is VSE without POWER almost, but not quite, entirely unlike OS without JES?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


If you are running under VM, not so much.

If you are running "bare metal", then yeah.

However, certain JECL commands ("Power directives") will not work 
that you need to have working -- they start off like this:


* $$ CLI __

It has been ages, but as I recall, that was an include from POWER 
(not from a library). Well those things just would not happen.


// ASSIGN SYSPRT,00E

This is similar to a DD that would look something like this in MVS:

//SYSPRT   DD  UNIT=00E

So, you would lose all the "writers" from spool to actual printer 
devices. Your JOB running in a Partition (as the are called in 
DOS) would use the printer, in this case, as if it owned it. That 
is, it would not be writing to spool, it would be driving the 
printer directly.



Man, I remember just enough DOS JCL/JECL to be bloody dangerous 
-- I haven't touched it since the last VSE/ESA migration I was 
involved in (2002-2003?).


Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Joel C. Ewing]

On 12/20/2015 03:36 PM, Shmuel Metz (Seymour J.) wrote:
> In <56771642.3000...@acm.org>, on 12/20/2015
>at 02:57 PM, "Joel C. Ewing"  said:
>
>> No (about the "free", not about the "dead for decades"), DOS/VS was
>> the last really free base (last version Release 34?).   Perhaps
>> technically DOS/VSE was "free", as there didn't appear to be a
>> monthly licensing charge for DOS/VSE itself (Computerworld, April 30,
>> 1979, p4), but in the practical sense a production DOS/VSE system was
>> definitely not free as there were monthly support charges for
>> DOS/VSE
> Are you sure that you're thinking of DOS/VSE itself and not addons
> like VSE/AF?
>
>> plus support charges for must-have VSE add-on components like
>> VSE/Power and others. 
> The same could be said of DOS/VS or even of DOS/360. Those addons were
> optional.
>
I can speak from my own knowledge only on IBM DOS/VSE not on IBM DOS/VS
(prior to DOS/VSE our shop ran Itel DOS/VS on S/360 boxes), but the
ComputerWorld article I referenced said that with DOS/VSE users started
to pay for components that used to be free with IBM DOS/VS, one example
explicitly named being VSE/Power versus Power/VS. So even if Power was
optional with DOS/VS, it was apparently still free.  It was also stated
that more components over time would be separated off from the VSE SCP
by IBM (to make them separately chargeable) and they would require both
DOS/VSE and VSE/AF (also a monthly license charge) as a base for all
other components.  That sounds to me like multiple monthly charges could
not be avoided with DOS/VSE and at least implied that had not been the
case before with some users of DOS/VS.  I recall our management dealing
with multiple OS component software charges with DOS/VSE, but I wasn't
that aware of pre-VSE system costs, which involved some 3rd-party-vendor
arrangement.

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Shmuel Metz (Seymour J.)]

In <56771642.3000...@acm.org>, on 12/20/2015
   at 02:57 PM, "Joel C. Ewing"  said:

>No (about the "free", not about the "dead for decades"), DOS/VS was
>the last really free base (last version Release 34?).   Perhaps
>technically DOS/VSE was "free", as there didn't appear to be a
>monthly licensing charge for DOS/VSE itself (Computerworld, April 30,
>1979, p4), but in the practical sense a production DOS/VSE system was
>definitely not free as there were monthly support charges for
>DOS/VSE

Are you sure that you're thinking of DOS/VSE itself and not addons
like VSE/AF?

>plus support charges for must-have VSE add-on components like
>VSE/Power and others. 

The same could be said of DOS/VS or even of DOS/360. Those addons were
optional.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Joel C. Ewing]

On 12/19/2015 07:48 PM, Shmuel Metz (Seymour J.) wrote:
> In , on 12/18/2015
>at 08:31 PM, Clark Morris  said:
>
>> Are there any current IBM references to DOS/VSE?
> DOS/VSE is the old free base, and has been dead for decades. There are
> probably lots of references to the current descendent, and perhaps
> even to VSE/ESA.
No (about the "free", not about the "dead for decades"), DOS/VS was the
last really free base (last version Release 34?).   Perhaps technically
DOS/VSE was "free", as there didn't appear to be a monthly licensing
charge for DOS/VSE itself (Computerworld, April 30, 1979, p4), but in
the practical sense a production DOS/VSE system was definitely not free
as there were monthly support charges for DOS/VSE and separate monthly
licensing plus support charges for must-have VSE add-on components like
VSE/Power and others.  DOS/VSE came out with the IBM 4331 & 4341
processors in 1979 and supported running in both S/370 mode or the
ECPS:VSE mode supported by the 4300 processor family.
>
>> Does anyone run VSE on the bare metal?
> ITYM on the bare LPAR; I'm not aware of any z processors that supports
> running anything but PR/SM on the bare metal. DOS/VSE requires S/370
> mode, which is no longer available, but z/VSE should run just fine on
> a bare LPAR.
>  

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Stevet]

Yeah, except PC DOS is more like DPS on a S/360-20. DOS on a S/360-30 was more 
advanced than PC DOS. 

Sent from iPhone - small keyboard fat fingers - expect spellinf errots.

> On Dec 19, 2015, at 12:29 PM, Joel C. Ewing  wrote:
> 
> But if the comment was made by someone whose education is limited to
> Intel, he probably is convinced IBM mainframe DOS is equivalent to PC DOS.
>Joel C. Ewing
> 
>> On 12/18/2015 06:31 PM, Clark Morris wrote:
>>> On 18 Dec 2015 09:44:15 -0800, in bit.listserv.ibm-main you wrote:
>>> 
>>> Nice, maybe someone should introduce them to the Mainframe Basics Redbook.
>>> 
>>> 
>>>   On Friday, December 18, 2015 12:42 PM, Walter Davies 
>>>  wrote:
>>> 
>>> 
>>> Our board of supervisors like to say the mainframe is running on DOS. One
>>> is an ex intel management employee.
>> Since VSE (DOS descendant) is still supported and upgraded (I suspect
>> mostly under VM), the statement could be accurate.  Are there any
>> current IBM references to DOS/VSE?  Does anyone run VSE on the bare
>> metal?
>> 
>> Clark Morris
 On Fri, Dec 18, 2015 at 8:40 AM, Grinsell, Don  wrote:
 
 Cute.  The problem is there's nobody there to call bull$h!t or do a fact
 check.  We see this sort of testimony here as well often implying that we
 are still running an antiquated s/360 that absolutely nobody knows anything
 about anymore.
 
 --
 
 Donald Grinsell
 State of Montana
 406-444-2983
 dgrins...@mt.gov
 
 "Hell is other people."
 ~ Jean-Paul Sartre
 
 
 
>> 
> 
> 
> -- 
> Joel C. Ewing,Bentonville, AR   jcew...@acm.org
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Joel C. Ewing]

But if the comment was made by someone whose education is limited to
Intel, he probably is convinced IBM mainframe DOS is equivalent to PC DOS.
Joel C. Ewing

On 12/18/2015 06:31 PM, Clark Morris wrote:
> On 18 Dec 2015 09:44:15 -0800, in bit.listserv.ibm-main you wrote:
>
>> Nice, maybe someone should introduce them to the Mainframe Basics Redbook.
>>
>>
>>On Friday, December 18, 2015 12:42 PM, Walter Davies 
>>  wrote:
>>
>>
>> Our board of supervisors like to say the mainframe is running on DOS. One
>> is an ex intel management employee.
> Since VSE (DOS descendant) is still supported and upgraded (I suspect
> mostly under VM), the statement could be accurate.  Are there any
> current IBM references to DOS/VSE?  Does anyone run VSE on the bare
> metal?
>
> Clark Morris
>> On Fri, Dec 18, 2015 at 8:40 AM, Grinsell, Don  wrote:
>>
>>> Cute.  The problem is there's nobody there to call bull$h!t or do a fact
>>> check.  We see this sort of testimony here as well often implying that we
>>> are still running an antiquated s/360 that absolutely nobody knows anything
>>> about anymore.
>>>
>>> --
>>>
>>> Donald Grinsell
>>> State of Montana
>>> 406-444-2983
>>> dgrins...@mt.gov
>>>
>>> "Hell is other people."
>>> ~ Jean-Paul Sartre
>>>
>>>
>>>
>


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Shmuel Metz (Seymour J.)]

In , on 12/18/2015
   at 08:31 PM, Clark Morris  said:

>Are there any current IBM references to DOS/VSE?

DOS/VSE is the old free base, and has been dead for decades. There are
probably lots of references to the current descendent, and perhaps
even to VSE/ESA.

>Does anyone run VSE on the bare metal?

ITYM on the bare LPAR; I'm not aware of any z processors that supports
running anything but PR/SM on the bare metal. DOS/VSE requires S/370
mode, which is no longer available, but z/VSE should run just fine on
a bare LPAR.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

DOS descendant still lives was Re: slight reprieve on the z.

[Clark Morris]

On 18 Dec 2015 09:44:15 -0800, in bit.listserv.ibm-main you wrote:

>Nice, maybe someone should introduce them to the Mainframe Basics Redbook.
> 
>
>On Friday, December 18, 2015 12:42 PM, Walter Davies 
>  wrote:
> 
>
> Our board of supervisors like to say the mainframe is running on DOS. One
>is an ex intel management employee.

Since VSE (DOS descendant) is still supported and upgraded (I suspect
mostly under VM), the statement could be accurate.  Are there any
current IBM references to DOS/VSE?  Does anyone run VSE on the bare
metal?

Clark Morris
>
>On Fri, Dec 18, 2015 at 8:40 AM, Grinsell, Don  wrote:
>
>> Cute.  The problem is there's nobody there to call bull$h!t or do a fact
>> check.  We see this sort of testimony here as well often implying that we
>> are still running an antiquated s/360 that absolutely nobody knows anything
>> about anymore.
>>
>> --
>>
>> Donald Grinsell
>> State of Montana
>> 406-444-2983
>> dgrins...@mt.gov
>>
>> "Hell is other people."
>> ~ Jean-Paul Sartre
>>
>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DOS descendant still lives was Re: slight reprieve on the z.

[Tony Thigpen]

There are a bunch of us z/VSE customers. Many on bare iron. Many on z/VM.

Tony Thigpen

Clark Morris wrote on 12/18/2015 07:31 PM:

On 18 Dec 2015 09:44:15 -0800, in bit.listserv.ibm-main you wrote:


Nice, maybe someone should introduce them to the Mainframe Basics Redbook.


On Friday, December 18, 2015 12:42 PM, Walter Davies 
 wrote:


Our board of supervisors like to say the mainframe is running on DOS. One
is an ex intel management employee.


Since VSE (DOS descendant) is still supported and upgraded (I suspect
mostly under VM), the statement could be accurate.  Are there any
current IBM references to DOS/VSE?  Does anyone run VSE on the bare
metal?

Clark Morris


On Fri, Dec 18, 2015 at 8:40 AM, Grinsell, Don  wrote:


Cute.  The problem is there's nobody there to call bull$h!t or do a fact
check.  We see this sort of testimony here as well often implying that we
are still running an antiquated s/360 that absolutely nobody knows anything
about anymore.

--

Donald Grinsell
State of Montana
406-444-2983
dgrins...@mt.gov

"Hell is other people."
~ Jean-Paul Sartre



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN