[TUHS] UNIX on S/370

[TUHS] UNIX on S/370

[Noel Chiappa]

    > From: Kevin Bowling

    > The earliest stuff may be covered by Novell's grant of early code.
    > ...
    > Would be fun to run *ix on any of them.

Alas, the Bell port of Unix to the /370 needs that underlying layer of code
from IBM, and that's probably not going to escape. Too bad, it would be pretty
cool.

       Noel

[TUHS] UNIX on S/370

[Kevin Bowling]

My interpretation from the BTSJ port was that it was a cheater port
more analogous to Cygwin that ran on top of MVS rather than a "real"
VM guest but it's been several years since I read the paper.

I have some private correspondence from Dick Johnson who worked on a
port of OSF/1 that was marketed as AIX/ESA:
"I'll give you a little AIX/ESA history and try to answer your
questions. I currently volunteer at the Computer History Museum, so I
am a bit of a computer history buff myself.

Starting in the late 1980s I was working at IBM SSD in San Jose. The
IBM Palo Alto Scientific Center had developed AIX/370 (my neighbor
Wally Iimura was one of the developers) to compete with Amdahl UTS,
and the decision was made to create a major UNIX offering for the IBM
mainframe based on the OSF/1 kernel from CMU. I was the leader of a
group in San Jose that did the AIX/ESA device support for all the
storage devices (DASD and tape). The bulk of AIX/ESA development was
carried out by a large group of several hundred in Kingston, NY.

The AIX/ESA code base was almost completely different from that of
AIX/370 and AIX for the RS/6000 (there had been an effort to port the
RS/6000 AIX to the mainframe that was abandoned).

When it was released, the product did not sell well, and never
exceeded 35 customer licenses. This was for many reasons. Marketing
did not push it, and the MVS people created Open MVS that allowed UNIX
to run in MVS. However the AIX/ESA OS itself was very solid and we
routinely handed a workload of over 1000 logged on users on a single
IBM mainframe. All the usual UNIX environment was provided. My group
did the device drivers that supported DASD up to the 3390 and also the
tape drives and tape library then selling. AIX/370 multi-processor
support was fairly primitive (there was only a single kernel lock),
but AIX/ESA had complete multi-processor and multi-threading support.

There was a complete of manuals that went with the AIX/ESA product.
There was the usual Operators Guide, User's Guide, etc. They had Navy
blue covers, but I did not keep any of them myself. I do not know of
any place to find soft copy of any of them. I believe the product was
shipped only on tape. As a developer I installed AIX/ESA many times,
but I was always using VM for this. The combination of being able to
run it in a virtual machine along with the PER hardware of the
mainframe made it pretty easy to debug problems.

Even though the product was not a success, I was proud of our work on
it and really enjoyed the work."

Regards,

On Wed, Nov 22, 2017 at 8:38 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > From: Kevin Bowling
>
>     > The earliest stuff may be covered by Novell's grant of early code.
>     > ...
>     > Would be fun to run *ix on any of them.
>
> Alas, the Bell port of Unix to the /370 needs that underlying layer of code
> from IBM, and that's probably not going to escape. Too bad, it would be pretty
> cool.
>
>        Noel

[TUHS] UNIX on S/370

[ron minnich]

On Wed, Nov 29, 2017 at 2:43 PM Dave Horsfall <dave at horsfall.org> wrote:

>
>
> (It bloody well worked, Mr Minnich, OK?)
>
>
?
what'd I say?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171129/30bba34f/attachment.html>

[TUHS] UNIX on S/370

[Dave Horsfall]

On Mon, 20 Nov 2017, Larry McVoy wrote:

> So tape I can see being more weird, but isn't raw disk just "don't put 
> it in buffer cache"?

DMA too, hence the process is locked in core.  I think the read/write had 
to be a multiple of 512 bytes as well (I lost my Edition 6 manuals along 
with my treasured -- and original! -- Lions books in a house move).

> From what I've been able to gather early tape in Unix was dicey, 
> something about the driver doing seek.  Was there more to it than that?

IIRC, the driver kept track of the current block under the head, and 
issued forward/backward skips accordingly; I have no idea whether SimH 
gets that right (as opposed to doing a random seek).

(It bloody well worked, Mr Minnich, OK?)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] UNIX on S/370

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3656 bytes --]

I had access to the sources.    We had a room in our facility that I referred to as the “toxic waste dump” where we had firewalled off to suit the IBM intellectual property hacks to approve us to have their

source code.    Somewhere, there’s probably an EXABYTE tape (no longer readable) with the source kicking around.   Yes, there were different directories under “mach” (if I’m remembering that) but this isn’t much different than any other UNIX port.   You’ve got your own startup, interrupt handling, and low level memory management.    Fortunately, all four of the mach types supported paging.

 

 

From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Clem Cole
Sent: Wednesday, November 22, 2017 8:40 AM
To: Kevin Bowling
Cc: The Eunuchs Hysterical Society
Subject: Re: [TUHS] UNIX on S/370

 

I can verify that AIX/386 and AIX/370 were a common set of SCCS sources at Locus when they did the development for IBM.   So if you can find the base sources for the one you should have much of the other.   There were obviously some low level tools that were specific to each architecture and the compiler back ends were different. 

 

I do not have access to any of the that, as I was not directly involved with that project, since I was leading the TNC work for Intel, HP, DEC and Sun; I was specifically fire walled from the original IBM TCF project at the time (I was one of the architects and we all got together regularly but for legal reasons, Locus was careful about who had access to what sources).    I know folks that did have access to the IBM IP and I can ask around. i.e. Walker, Joe Hopfield, et al would people to ask, if you can find them.

 

On Wed, Nov 22, 2017 at 4:38 AM, Kevin Bowling <kevin.bowling at kev009.com> wrote:

I was asking about s/370 UNIX flavors

 

I can help you with AIX for i386, I’m probably one of the main “historians” for that vintage of IBM stuff.. here ya go http://ps-2.kev009.com/aixps2/. All the docs are scattered on my server there. It WILL run under virtualization but is picky anout which. Google will point you to guides. 

 


On Tuesday, November 21, 2017, Wesley Parish <wobblygong at gmail.com> wrote:

As would I. I'd also be interested in that i386 AIX Clem mentioned.

It would be interesting studying the different ways the *BSD and the
SVR4 and the AIX people etc adapted the Unix code to the i386
architecture. It'd make an interesting topic for discussion. (Likewise
in comparison with the "native" i80x86 Unix-like OSes like Coherent,
Minix and Linux. :)

Wesley Parish

On 11/22/17, Kevin Bowling <kevin.bowling at kev009.com> wrote:
> I'm also interested if any of these s/370 *ix ever escaped captivity.
> The earliest stuff may be covered by Novell's grant of early code.
> I'd be willing to pay for a lawyer to help liberate any contested
> material.
>
> I have an R/390 (1990s era), z800 (2000s era) and z114 (2010s era) at
> home.  And Hercules.  Would be fun to run *ix on any of them.
>
> Regards,
>
> On Sun, Nov 19, 2017 at 5:57 PM, Nemo <cym224 at gmail.com> wrote:
>> Recent commentary on porting led me to read the article on porting
>> UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf)
>> to support 5ESS development because the existing PDP11s were being
>> overwhelmed.  I confess to not having this read this before and find
>> it interesting.  Any recollections from anyone on the matter.  And
>> whatever happened to it?
>>
>> N.
>

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/49362a5f/attachment-0001.html>

[TUHS] UNIX on S/370

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1702 bytes --]

I don’t think PS/2 hardware is going to be an issue.    The i386 i/o architecture is pretty much the same, in/out instructions, despite the cute allusion in the name to the  IBM Channel architecture, the microchannel is just another PC memory bus like the ISA it “replaced.”   Not to say it had some good features to it (the idea of a card ID and better spped).    The machines also had a few ISA slots.  

 

 

From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Clem Cole
Sent: Wednesday, November 22, 2017 8:52 AM
To: Wesley Parish
Cc: The Eunuchs Hysterical Society
Subject: Re: [TUHS] UNIX on S/370

 

 

 

On Wed, Nov 22, 2017 at 1:35 AM, Wesley Parish <wobblygong at gmail.com> wrote:

As would I. I'd also be interested in that i386 AIX Clem mentioned

 

A big issue/hurdle I suspect is that AIX/386 was done for a PS/2 HW; (microchannel) which besides IBM and NCR, there is not a lot of in the wild.   So simulation might be a PITA.​  Also the graphics was done for some IBM specific displays (I've forgotten the names), that nobody else made (which were really expensive at the time IIRC -- which again may have been an issue on why this was not popular).   

 

We had a lot of Gateway 386 (ISA/EISA based) PC's at Locus which were the system of choice we used for TNC prototyping and all we had in Boston and San Diego.   The LA guys must have had AIX running on them; but I'm not sure if that code was ever released.  I'd have to ask some one like Hopfield who would have done that kind of hacking.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/7061db26/attachment.html>

[TUHS] UNIX on S/370

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

On Wed, Nov 22, 2017 at 1:35 AM, Wesley Parish <wobblygong at gmail.com> wrote:

> As would I. I'd also be interested in that i386 AIX Clem mentioned
>

A big issue/hurdle I suspect is that AIX/386 was done for a PS/2 HW;
(microchannel) which besides IBM and NCR, there is not a lot of in the
wild.   So simulation might be a PITA.​  Also the graphics was done for
some IBM specific displays (I've forgotten the names), that nobody else
made (which were really expensive at the time IIRC -- which again may have
been an issue on why this was not popular).

We had a lot of Gateway 386 (ISA/EISA based) PC's at Locus which were the
system of choice we used for TNC prototyping and all we had in Boston and
San Diego.   The LA guys must have had AIX running on them; but I'm not
sure if that code was ever released.  I'd have to ask some one like
Hopfield who would have done that kind of hacking.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/e43548ad/attachment.html>

[TUHS] UNIX on S/370

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2922 bytes --]

I can verify that AIX/386 and AIX/370 were a common set of SCCS sources at
Locus when they did the development for IBM.   So if you can find the base
sources for the one you should have much of the other.   There were
obviously some low level tools that were specific to each architecture and
the compiler back ends were different.

I do not have access to any of the that, as I was not *directly* involved
with that project, since I was leading the TNC work for Intel, HP, DEC and
Sun; I was specifically fire walled from the original IBM TCF project at
the time (I was one of the architects and we all got together regularly but
for legal reasons, Locus was careful about who had access to what
sources).    I know folks that did have access to the IBM IP and I can ask
around. i.e. Walker, Joe Hopfield, et al would people to ask, if you can
find them.

On Wed, Nov 22, 2017 at 4:38 AM, Kevin Bowling <kevin.bowling at kev009.com>
wrote:

> I was asking about s/370 UNIX flavors
>
> I can help you with AIX for i386, I’m probably one of the main
> “historians” for that vintage of IBM stuff.. here ya go
> http://ps-2.kev009.com/aixps2/. All the docs are scattered on my server
> there. It WILL run under virtualization but is picky anout which. Google
> will point you to guides.
>
>
> On Tuesday, November 21, 2017, Wesley Parish <wobblygong at gmail.com> wrote:
>
>> As would I. I'd also be interested in that i386 AIX Clem mentioned.
>>
>> It would be interesting studying the different ways the *BSD and the
>> SVR4 and the AIX people etc adapted the Unix code to the i386
>> architecture. It'd make an interesting topic for discussion. (Likewise
>> in comparison with the "native" i80x86 Unix-like OSes like Coherent,
>> Minix and Linux. :)
>>
>> Wesley Parish
>>
>> On 11/22/17, Kevin Bowling <kevin.bowling at kev009.com> wrote:
>> > I'm also interested if any of these s/370 *ix ever escaped captivity.
>> > The earliest stuff may be covered by Novell's grant of early code.
>> > I'd be willing to pay for a lawyer to help liberate any contested
>> > material.
>> >
>> > I have an R/390 (1990s era), z800 (2000s era) and z114 (2010s era) at
>> > home.  And Hercules.  Would be fun to run *ix on any of them.
>> >
>> > Regards,
>> >
>> > On Sun, Nov 19, 2017 at 5:57 PM, Nemo <cym224 at gmail.com> wrote:
>> >> Recent commentary on porting led me to read the article on porting
>> >> UNIX to S/370 (https://www.bell-labs.com/usr
>> /dmr/www/otherports/ibm.pdf)
>> >> to support 5ESS development because the existing PDP11s were being
>> >> overwhelmed.  I confess to not having this read this before and find
>> >> it interesting.  Any recollections from anyone on the matter.  And
>> >> whatever happened to it?
>> >>
>> >> N.
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/aa360895/attachment.html>

[TUHS] UNIX on S/370

[Kevin Bowling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]

I was asking about s/370 UNIX flavors

I can help you with AIX for i386, I’m probably one of the main “historians”
for that vintage of IBM stuff.. here ya go http://ps-2.kev009.com/aixps2/.
All the docs are scattered on my server there. It WILL run under
virtualization but is picky anout which. Google will point you to guides.

On Tuesday, November 21, 2017, Wesley Parish <wobblygong at gmail.com> wrote:

> As would I. I'd also be interested in that i386 AIX Clem mentioned.
>
> It would be interesting studying the different ways the *BSD and the
> SVR4 and the AIX people etc adapted the Unix code to the i386
> architecture. It'd make an interesting topic for discussion. (Likewise
> in comparison with the "native" i80x86 Unix-like OSes like Coherent,
> Minix and Linux. :)
>
> Wesley Parish
>
> On 11/22/17, Kevin Bowling <kevin.bowling at kev009.com <javascript:;>>
> wrote:
> > I'm also interested if any of these s/370 *ix ever escaped captivity.
> > The earliest stuff may be covered by Novell's grant of early code.
> > I'd be willing to pay for a lawyer to help liberate any contested
> > material.
> >
> > I have an R/390 (1990s era), z800 (2000s era) and z114 (2010s era) at
> > home.  And Hercules.  Would be fun to run *ix on any of them.
> >
> > Regards,
> >
> > On Sun, Nov 19, 2017 at 5:57 PM, Nemo <cym224 at gmail.com <javascript:;>>
> wrote:
> >> Recent commentary on porting led me to read the article on porting
> >> UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf
> )
> >> to support 5ESS development because the existing PDP11s were being
> >> overwhelmed.  I confess to not having this read this before and find
> >> it interesting.  Any recollections from anyone on the matter.  And
> >> whatever happened to it?
> >>
> >> N.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/4af1045b/attachment.html>

[TUHS] UNIX on S/370

[Wesley Parish]

As would I. I'd also be interested in that i386 AIX Clem mentioned.

It would be interesting studying the different ways the *BSD and the
SVR4 and the AIX people etc adapted the Unix code to the i386
architecture. It'd make an interesting topic for discussion. (Likewise
in comparison with the "native" i80x86 Unix-like OSes like Coherent,
Minix and Linux. :)

Wesley Parish

On 11/22/17, Kevin Bowling <kevin.bowling at kev009.com> wrote:
> I'm also interested if any of these s/370 *ix ever escaped captivity.
> The earliest stuff may be covered by Novell's grant of early code.
> I'd be willing to pay for a lawyer to help liberate any contested
> material.
>
> I have an R/390 (1990s era), z800 (2000s era) and z114 (2010s era) at
> home.  And Hercules.  Would be fun to run *ix on any of them.
>
> Regards,
>
> On Sun, Nov 19, 2017 at 5:57 PM, Nemo <cym224 at gmail.com> wrote:
>> Recent commentary on porting led me to read the article on porting
>> UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf)
>> to support 5ESS development because the existing PDP11s were being
>> overwhelmed.  I confess to not having this read this before and find
>> it interesting.  Any recollections from anyone on the matter.  And
>> whatever happened to it?
>>
>> N.
>

[TUHS] UNIX on S/370

[Kevin Bowling]

I'm also interested if any of these s/370 *ix ever escaped captivity.
The earliest stuff may be covered by Novell's grant of early code.
I'd be willing to pay for a lawyer to help liberate any contested
material.

I have an R/390 (1990s era), z800 (2000s era) and z114 (2010s era) at
home.  And Hercules.  Would be fun to run *ix on any of them.

Regards,

On Sun, Nov 19, 2017 at 5:57 PM, Nemo <cym224 at gmail.com> wrote:
> Recent commentary on porting led me to read the article on porting
> UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf)
> to support 5ESS development because the existing PDP11s were being
> overwhelmed.  I confess to not having this read this before and find
> it interesting.  Any recollections from anyone on the matter.  And
> whatever happened to it?
>
> N.

[TUHS] UNIX on S/370

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

On Tue, Nov 21, 2017 at 1:29 PM, Larry McVoy <lm at mcvoy.com> wrote:

> So is there any chance of getting the code released under a BSD compat
> ​ ​
> license?


​You'd need a champion at HP, and I don't know anyone that's left.

What's the state of OSF/1 these days?  I really don't know.  Mach was a CMU
license.   You might be able to find the Paragon version which was older.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/d6556a11/attachment.html>

[TUHS] UNIX on S/370

[Larry McVoy]

So is there any chance of getting the code released under a BSD compat
license?

On Tue, Nov 21, 2017 at 12:23:14PM -0500, Clem Cole wrote:
> FWIW:  The one sad thing I look back one and fear was a the greatest
> contribution of TNC that was lost was Vprocs - the virtual process layer,
> that Roman and I created - originally for the Paragon and HP systems.   We
> took a tip from Sun's VFS layer and said what we really need is a layer the
> kernel with new interface to allow virtual process technology.  They you
> can support a number of different types of interfaces the same way you can
> support different file systems.
> 
> We spliced had it running is OSF1, HP-UX, Linux (2.4), SVR4, an Apple
> kernel and had started putting into an Solaris for one of the super
> computer firms (I've forgotten now whom).   I started putting it into a
> FreeBSD release at one point, but was over whelmed by other kernel changes
> and just could not keep up with he mainline - it been on my 'to do.'      I
> think that's why OpenSSI gave up.      Unless Linus really got excited it
> was not going be able to stay in on the side.
> 
> Which is a shame because once you put the changes in, to support the vproc
> layer, then its easier to make changes of course because you have a clean
> interface.   As I said, just like VFS cleaned up the file system and i-node
> layer and removed a bunch of stuff that had bleed into the places in the
> kernel it really did not belong.   The same is true for the process layer
> and some of the other UNIX name spaces (semaphores, systemV shared memory,
> etc..).   Vproc really cleaned that up.
> 
> 
> 
> On Tue, Nov 21, 2017 at 12:06 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> >
> > *OpenSSI (Single System Image) Clusters for Linux
> > <http://openssi.org/cgi-bin/view?page=openssi.html>??? is the URL for the
> > project*
> >
> > *Note Bruce has retired since he wrote the following, but the *
> > *paper describing the work is:   *Open Single System Image (openSSI)
> > Linux Cluster Project, Bruce J. Walker, Hewlett-Packard
> > <http://www.openssi.org/ssi-intro.pdf>
> >
> > Bruce.walker at hp.com
> >
> > Abstract
> >
> > The openSSI Cluster project is an ongoing open source project which was
> > started two years ago to bring together some of the best Linux and Unix
> > clustering technologies into a single integrated and yet modular project.
> >
> > Linux is rich in cluster technology but is segmented into 6 different
> > cluster areas
> > - high performance, load-leveling, web-service, storage, database and high
> > availability. The openSSI project address all cluster environments by
> > simultaneously addressing the three key cluster goals - availability,
> > scalability and manageability.
> > To accomplish this ambitious goal, the project was started with a Linux
> > adaptation of the NonStop Clusters for Unixware code, contributed by
> > Compaq/HP. That code included membership, internode communication,
> > clusterwide process management, clusterwide devices, a cluster filesystem,
> > clusterwide IPC (pipes, fifos, msgqueues, semaphores, etc.) and clusterwide
> > tcp/ip networking. Other open source clustering code has been integrated
> > into the modular architecture, including openGFS, openDLM, LVS, Lustre and
> > a small component of Mosix. The architecture of the project allows for
> > subsetting and substitution of components. A full function initial release
> > is available in both source and RPM form. Many enhancement opportunities
> > still exist both in integrating with other technologies and by improving
> > scalability and availability.
> > *???*
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] UNIX on S/370

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3542 bytes --]

FWIW:  The one sad thing I look back one and fear was a the greatest
contribution of TNC that was lost was Vprocs - the virtual process layer,
that Roman and I created - originally for the Paragon and HP systems.   We
took a tip from Sun's VFS layer and said what we really need is a layer the
kernel with new interface to allow virtual process technology.  They you
can support a number of different types of interfaces the same way you can
support different file systems.

We spliced had it running is OSF1, HP-UX, Linux (2.4), SVR4, an Apple
kernel and had started putting into an Solaris for one of the super
computer firms (I've forgotten now whom).   I started putting it into a
FreeBSD release at one point, but was over whelmed by other kernel changes
and just could not keep up with he mainline - it been on my 'to do.'      I
think that's why OpenSSI gave up.      Unless Linus really got excited it
was not going be able to stay in on the side.

Which is a shame because once you put the changes in, to support the vproc
layer, then its easier to make changes of course because you have a clean
interface.   As I said, just like VFS cleaned up the file system and i-node
layer and removed a bunch of stuff that had bleed into the places in the
kernel it really did not belong.   The same is true for the process layer
and some of the other UNIX name spaces (semaphores, systemV shared memory,
etc..).   Vproc really cleaned that up.



On Tue, Nov 21, 2017 at 12:06 PM, Clem Cole <clemc at ccc.com> wrote:

>
> *OpenSSI (Single System Image) Clusters for Linux
> <http://openssi.org/cgi-bin/view?page=openssi.html>​ is the URL for the
> project*
>
> *Note Bruce has retired since he wrote the following, but the *
> *paper describing the work is:   *Open Single System Image (openSSI)
> Linux Cluster Project, Bruce J. Walker, Hewlett-Packard
> <http://www.openssi.org/ssi-intro.pdf>
>
> Bruce.walker at hp.com
>
> Abstract
>
> The openSSI Cluster project is an ongoing open source project which was
> started two years ago to bring together some of the best Linux and Unix
> clustering technologies into a single integrated and yet modular project.
>
> Linux is rich in cluster technology but is segmented into 6 different
> cluster areas
> - high performance, load-leveling, web-service, storage, database and high
> availability. The openSSI project address all cluster environments by
> simultaneously addressing the three key cluster goals - availability,
> scalability and manageability.
> To accomplish this ambitious goal, the project was started with a Linux
> adaptation of the NonStop Clusters for Unixware code, contributed by
> Compaq/HP. That code included membership, internode communication,
> clusterwide process management, clusterwide devices, a cluster filesystem,
> clusterwide IPC (pipes, fifos, msgqueues, semaphores, etc.) and clusterwide
> tcp/ip networking. Other open source clustering code has been integrated
> into the modular architecture, including openGFS, openDLM, LVS, Lustre and
> a small component of Mosix. The architecture of the project allows for
> subsetting and substitution of components. A full function initial release
> is available in both source and RPM form. Many enhancement opportunities
> still exist both in integrating with other technologies and by improving
> scalability and availability.
> *​*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/cabcbc21/attachment-0001.html>

[TUHS] UNIX on S/370

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]

*OpenSSI (Single System Image) Clusters for Linux
<http://openssi.org/cgi-bin/view?page=openssi.html>​ is the URL for the
project*

*Note Bruce has retired since he wrote the following, but the *
*paper describing the work is:   *Open Single System Image (openSSI) Linux
Cluster Project, Bruce J. Walker, Hewlett-Packard
<http://www.openssi.org/ssi-intro.pdf>

Bruce.walker at hp.com

Abstract

The openSSI Cluster project is an ongoing open source project which was
started two years ago to bring together some of the best Linux and Unix
clustering technologies into a single integrated and yet modular project.

Linux is rich in cluster technology but is segmented into 6 different
cluster areas
- high performance, load-leveling, web-service, storage, database and high
availability. The openSSI project address all cluster environments by
simultaneously addressing the three key cluster goals - availability,
scalability and manageability.
To accomplish this ambitious goal, the project was started with a Linux
adaptation of the NonStop Clusters for Unixware code, contributed by
Compaq/HP. That code included membership, internode communication,
clusterwide process management, clusterwide devices, a cluster filesystem,
clusterwide IPC (pipes, fifos, msgqueues, semaphores, etc.) and clusterwide
tcp/ip networking. Other open source clustering code has been integrated
into the modular architecture, including openGFS, openDLM, LVS, Lustre and
a small component of Mosix. The architecture of the project allows for
subsetting and substitution of components. A full function initial release
is available in both source and RPM form. Many enhancement opportunities
still exist both in integrating with other technologies and by improving
scalability and availability.
*​*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/b77d3212/attachment.html>

[TUHS] UNIX on S/370

[Paul Winalski]

On 11/20/17, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
>
> Ya....  From what (little) I know about 3270 (and 5250 for AS/400s?)
> reminds me of HTML forms with the mainframe as the web server and the
> terminal as the client web browser.

That's a good analogy.  3270s were designed to be transaction
processing terminals.  The application displays a form on the screen;
the user fills in the form and presses an interrupt key; the
application reads back the modified form.  Not truly interactive in
the way that TTYs and screen terminals were.

-Paul W.

[TUHS] UNIX on S/370

[Larry McVoy]

On Tue, Nov 21, 2017 at 10:40:35AM -0500, Ron Natalie wrote:
> Yes, definitely more to TCF than just what I mentioned, I just wanted to indicate why you wouldn???t necessarily need to be connected to the 370-node directly in order to use it.
> 
> It was really handy (though somewhat confusing at times) when we were doing the 4 process i860 addition to the system.     It was far too easy to just let use an i386 instance of some application rather than providing the native one (since the W4 card was a microchannel card that went into the PS2).   Unless you tried really hard, you couldn???t tell if the app was running remotely.


Yeah, so imagine something like TNC plus my N kernels on NUMA idea.  Seems
pretty have your cake and eat it too.

[TUHS] UNIX on S/370

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2970 bytes --]

Yes, definitely more to TCF than just what I mentioned, I just wanted to indicate why you wouldn’t necessarily need to be connected to the 370-node directly in order to use it.

 

It was really handy (though somewhat confusing at times) when we were doing the 4 process i860 addition to the system.     It was far too easy to just let use an i386 instance of some application rather than providing the native one (since the W4 card was a microchannel card that went into the PS2).   Unless you tried really hard, you couldn’t tell if the app was running remotely.

                                

 

From: Clem Cole [mailto:clemc@ccc.com] 
Sent: Tuesday, November 21, 2017 8:52 AM
To: Ron Natalie
Cc: Grant Taylor; The Eunuchs Hysterical Society
Subject: Re: [TUHS] UNIX on S/370

 

 

 

On Tue, Nov 21, 2017 at 7:00 AM, Ron Natalie <ron at ronnatalie.com> wrote:


The other choice is to use TCF.   TCF allowed you to transparently run binaries on a remote machine and it took care of redirecting stdin/stdout back to your machine.

 

​It did a heck of lot more than that.   TCF made all the systems participating in the cluster one transparent machine - TCF - the Transparent Computing Facility.  Processes migrated between processors, for execution.   Your 'login session' was as Ron points out typically an x-windows/xterm.   But resources that you used over the course of the session could be anywhere within the cluster.    Nodes could come and go and the cluster survive.   You can read all about it in the Locus book which available from Amazon [MIT press - Popek and Walker].

 

The two biggest errors IMO was that the cluster size was screwed down to 32 and the kernel was ad hoc and very heavily hacked, so it was hard to put the features into other systems.

 

FYI:  the follow on to it, TNC (Transparent Network Computing); corrected both of those issues.  TNC becme the OS for Intel Paragon which scaled to 4096 nodes.   Locus moved the technology into 18 different components and made them available separately.   They were all eventually made open source.  The TNC file system became DEC's TruCluster FS, a project which I lead and brought me to DEC.   I had also lead a group in Boston that had put TNC into HP-UX with full process migration before we did the work for DEC actually, but HP cancelled the project before it ever shipped.  Bruce  and the west coast Locus folks put most of TNC into Linux a few years ago before he retired and as I say, succeeded to release it as open source -- I can dig up a URL for that project, if folks are interested.  I had it running on a small 8 node cluster about 8-10 years ago; it was very cool; but was using a older version of the RH and a 2.4 Linux kernel around the time Linux went to the the 2.6 kernel.

 

Clem

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/ac00e5a5/attachment-0001.html>

[TUHS] UNIX on S/370

[Larry McVoy]

On Tue, Nov 21, 2017 at 08:51:30AM -0500, Clem Cole wrote:
> FYI:  the follow on to it, TNC (Transparent Network Computing); corrected
> both of those issues.  TNC becme the OS for Intel Paragon which scaled to
> 4096 nodes.   Locus moved the technology into 18 different components and
> made them available separately.   They were all eventually made open
> source.  The TNC file system became DEC's TruCluster FS, a project which I
> lead and brought me to DEC.   I had also lead a group in Boston that had
> put TNC into HP-UX with full process migration before we did the work for
> DEC actually, but HP cancelled the project before it ever shipped.  Bruce
> and the west coast Locus folks put most of TNC into Linux a few years ago
> before he retired and as I say, succeeded to release it as open source -- I
> can dig up a URL for that project, if folks are interested.  I had it
> running on a small 8 node cluster about 8-10 years ago; it was very cool;
> but was using a older version of the RH and a 2.4 Linux kernel around the
> time Linux went to the the 2.6 kernel.

I would be very very interested in seeing that.

[TUHS] UNIX on S/370

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]

On Tue, Nov 21, 2017 at 7:00 AM, Ron Natalie <ron at ronnatalie.com> wrote:

>
> The other choice is to use TCF.   TCF allowed you to transparently run
> binaries on a remote machine and it took care of redirecting stdin/stdout
> back to your machine.
>

​It did a heck of lot more than that.   TCF made all the systems
participating in the cluster one transparent machine - TCF - the
Transparent Computing Facility.  Processes migrated between processors, for
execution.   Your 'login session' was as Ron points out typically an
x-windows/xterm.   But resources that you used over the course of the
session could be anywhere within the cluster.    Nodes could come and go
and the cluster survive.   You can read all about it in the Locus book
which available from Amazon [MIT press - Popek and Walker].

The two biggest errors IMO was that the cluster size was screwed down to 32
and the kernel was ad hoc and very heavily hacked, so it was hard to put
the features into other systems.

FYI:  the follow on to it, TNC (Transparent Network Computing); corrected
both of those issues.  TNC becme the OS for Intel Paragon which scaled to
4096 nodes.   Locus moved the technology into 18 different components and
made them available separately.   They were all eventually made open
source.  The TNC file system became DEC's TruCluster FS, a project which I
lead and brought me to DEC.   I had also lead a group in Boston that had
put TNC into HP-UX with full process migration before we did the work for
DEC actually, but HP cancelled the project before it ever shipped.  Bruce
and the west coast Locus folks put most of TNC into Linux a few years ago
before he retired and as I say, succeeded to release it as open source -- I
can dig up a URL for that project, if folks are interested.  I had it
running on a small 8 node cluster about 8-10 years ago; it was very cool;
but was using a older version of the RH and a 2.4 Linux kernel around the
time Linux went to the the 2.6 kernel.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/2503619c/attachment.html>

[TUHS] UNIX on S/370

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 348 bytes --]

On Tue, Nov 21, 2017 at 12:42 AM, Grant Taylor via TUHS <
tuhs at minnie.tuhs.org> wrote:

>
> So ... what communications technology and protocol was used?

​Ethernet - TCP/IP​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/62a6cb94/attachment.html>

[TUHS] UNIX on S/370

[Ron Natalie]

Well you had two choices.   You could telnet/rlogin in to the 370 AIX instance or use an xterm running there to direct things to your PS/2.

The other choice is to use TCF.   TCF allowed you to transparently run binaries on a remote machine and it took care of redirecting stdin/stdout back to your machine.


-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Grant Taylor via TUHS
Sent: Tuesday, November 21, 2017 12:42 AM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] UNIX on S/370

On 11/20/2017 09:34 PM, Clem cole wrote:
> Right.    Generally you used the ps/2 as the terminals for AIX/370

So ... what communications technology and protocol was used?  Serial? 
(I assume that you could have some sort of establishment controller with (a)synch serial ports.)  Or would it be some sort of red headed step child that ran across twinax / 3270 even though the 3270 terminals couldn't really support it?

> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.

*chuckle*



--
Grant. . . .
unix || die

[TUHS] UNIX on S/370

[arnold]

Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:

> Ya....  From what (little) I know about 3270 (and 5250 for AS/400s?) 
> reminds me of HTML forms with the mainframe as the web server and the 
> terminal as the client web browser.  What with the mainframe sending 
> [protected,hidden] fields to the terminal that displayed them and 
> trusted what the terminal sent back.

Also from what little I know, that's a decent analogy.

> *headshake*  Times were different. 
>   I am guessing that there is also security through obscurity based on 
> what information was available at the time.

Bear in mind that said terminals were wired directly to the peripheral
controller, usually within the same building, in cable conduits under the
floor, in the ceiling overhead or in various combinations thereof.  It
wasn't TCP/IP over wireless!

Moving the interaction with the human into a peripheral made a lot of
sense; you often had dozens or hundreds of the terminals hooked up to
the mainframes, and the interrupt per single-character model of Unix
and other minicomputer OSes would have brought a mainframe to its knees,
crying like a baby.

Arnold

[TUHS] UNIX on S/370

[Grant Taylor]

On 11/20/2017 09:34 PM, Clem cole wrote:
> Right.    Generally you used the ps/2 as the terminals for AIX/370

So ... what communications technology and protocol was used?  Serial? 
(I assume that you could have some sort of establishment controller with 
(a)synch serial ports.)  Or would it be some sort of red headed step 
child that ran across twinax / 3270 even though the 3270 terminals 
couldn't really support it?

> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.

*chuckle*



-- 
Grant. . . .
unix || die

[TUHS] UNIX on S/370

[Larry McVoy]

On Mon, Nov 20, 2017 at 10:14:41PM -0700, Warner Losh wrote:
> I assume you aren't talking about things like mmap where you can't really
> bcopy it...

Correct.

> At Fusion I/O we had hooks into our PCIe flash card driver that would do
> DMA directly into user buffers (since we wanted IOPS and any extra copies
> got in the way of that). 

Yeah, cool, sorta like the SGI stuff, but that was stuff that you had to 
add and SGI had to add.

The only place I can see dma right into user buffers would be if the user
blocked in the read, it was to a raw device, *and* the OS took care to make
sure that those page[s] were locked.  I can see the 1st 2 but I've not run
into the last one except for specialized stuff like O_DIRECT.

[TUHS] UNIX on S/370

[Warner Losh]

On Nov 20, 2017 8:51 PM, "Larry McVoy" <lm at mcvoy.com> wrote:

Actually, how common was that?  I know at SGI we did that with O_DIRECT
on files (and just automatically on the way for in networking and page
flipped on the way out).  But it was a pile of work, you had to lock
all the pages so that the pageout daemon didn't page them out, etc.

So under what circumstances would Unix do DMA to/from user buffers
rather than bcopy it?


I assume you aren't talking about things like mmap where you can't really
bcopy it...

At Fusion I/O we had hooks into our PCIe flash card driver that would do
DMA directly into user buffers (since we wanted IOPS and any extra copies
got in the way of that). We also played fun tricks with 'extended I/O
primitives' that were implemented with ioctls, but still did I/O to/from
user buffers. This was so we could construct 1 transaction for what's
basically an atomic writev (more complicated than that, because the atomic
operation also supported delete/trim operations at the same time). This was
to simplify checkpointing since it was an all or nothing thing: if we
couldn't do it, or the system crashed in the middle, the transaction never
happened. There were other, more extended I/O operations that involved read
as well that were kinda crazy, but useful for a market segment we did well
in. Also likely no the sort of thing that you were thinking about, but it
was a novel use of DMA to user buffers.

Warner

On Mon, Nov 20, 2017 at 10:15:58PM -0500, Ron Natalie wrote:
> That's a common optimization, but the only real requirement in the UNIX
> kernel is the raw I/O bypasses the kernel buffer cache.
>
>
> -----Original Message-----
> From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Noel Chiappa
> Sent: Monday, November 20, 2017 9:57 PM
> To: tuhs at tuhs.org
> Cc: jnc at mercury.lcs.mit.edu
> Subject: Re: [TUHS] UNIX on S/370
>
>     > From: Larry McVoy
>
>     > So tape I can see being more weird, but isn't raw disk just "don't
put
>     > it in buffer cache"?
>
> One machines/controllers which are capable of it, with raw devices DMA
> happens directly into the buffers in the process (which obviously has to
be
> resident while the I/O is happening).
>
>     Noel

--
---
Larry McVoy                  lm at mcvoy.com
http://www.mcvoy.com/lm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/92117e5a/attachment.html>

[TUHS] UNIX on S/370

[Clem cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

Right.    Generally you used the ps/2 as the terminals for AIX/370

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Nov 20, 2017, at 10:40 PM, Ron Natalie <ron at ronnatalie.com> wrote:
> 
> I'm pretty sure you could, but only on very rudimentary line mode stuff.    Note that an IBM mainframe terminal doesn't really have the same paradigm as an ASCII terminal.
> 
> You could go to a VM monitor and type IPL AIX and watch UNIX boot up.
> 
> 
> -----Original Message-----
> From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Grant Taylor via TUHS
> Sent: Monday, November 20, 2017 10:29 PM
> To: tuhs at minnie.tuhs.org
> Subject: Re: [TUHS] UNIX on S/370
> 
>> On 11/20/2017 06:15 PM, Ron Natalie wrote:
>> AIX deflected all this by actually making the user facing stuff hang 
>> off the i860/i386 nodes.
> 
> Does that mean that you couldn't access AIX/370 from a traditional mainframe terminal?
> 
> That seems bizarre to me.  But it does sound like some other strange things I've heard come out of IBM before.
> 
>> I remember talking extensively to Barry Appleman (VM’s TCP IP guY) 
>> about writing an X3270 xterm variant.
> 
> What would that have done?  Are you meaning an app that would run on
> non-AIX/370 OSs that could then act similar to the i860/i386 client / node?  (Was it trying to emulate a traditional serial dumb terminal?)
> 
> #confused
> 
> 
> 
> --
> Grant. . . .
> unix || die
> 

[TUHS] UNIX on S/370

[Larry McVoy]

Actually, how common was that?  I know at SGI we did that with O_DIRECT
on files (and just automatically on the way for in networking and page
flipped on the way out).  But it was a pile of work, you had to lock
all the pages so that the pageout daemon didn't page them out, etc.

So under what circumstances would Unix do DMA to/from user buffers
rather than bcopy it?

On Mon, Nov 20, 2017 at 10:15:58PM -0500, Ron Natalie wrote:
> That's a common optimization, but the only real requirement in the UNIX
> kernel is the raw I/O bypasses the kernel buffer cache.
> 
> 
> -----Original Message-----
> From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Noel Chiappa
> Sent: Monday, November 20, 2017 9:57 PM
> To: tuhs at tuhs.org
> Cc: jnc at mercury.lcs.mit.edu
> Subject: Re: [TUHS] UNIX on S/370
> 
>     > From: Larry McVoy
> 
>     > So tape I can see being more weird, but isn't raw disk just "don't put
>     > it in buffer cache"?
> 
> One machines/controllers which are capable of it, with raw devices DMA
> happens directly into the buffers in the process (which obviously has to be
> resident while the I/O is happening).
> 
>     Noel

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] UNIX on S/370

[Grant Taylor]

On 11/20/2017 08:40 PM, Ron Natalie wrote:
> I'm pretty sure you could, but only on very rudimentary line mode stuff.

*nod*

> Note that an IBM mainframe terminal doesn't really have the same paradigm 
> as an ASCII terminal.

Ya....  From what (little) I know about 3270 (and 5250 for AS/400s?) 
reminds me of HTML forms with the mainframe as the web server and the 
terminal as the client web browser.  What with the mainframe sending 
[protected,hidden] fields to the terminal that displayed them and 
trusted what the terminal sent back.  *headshake*  Times were different. 
  I am guessing that there is also security through obscurity based on 
what information was available at the time.

> You could go to a VM monitor and type IPL AIX and watch UNIX boot up.

I wonder if USS / OMVS terminal ~ application on more modern mainframes 
still run into issues.



-- 
Grant. . . .
unix || die

[TUHS] UNIX on S/370

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

I'm pretty sure you could, but only on very rudimentary line mode stuff.    Note that an IBM mainframe terminal doesn't really have the same paradigm as an ASCII terminal.

You could go to a VM monitor and type IPL AIX and watch UNIX boot up.


-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Grant Taylor via TUHS
Sent: Monday, November 20, 2017 10:29 PM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] UNIX on S/370

On 11/20/2017 06:15 PM, Ron Natalie wrote:
> AIX deflected all this by actually making the user facing stuff hang 
> off the i860/i386 nodes.

Does that mean that you couldn't access AIX/370 from a traditional mainframe terminal?

That seems bizarre to me.  But it does sound like some other strange things I've heard come out of IBM before.

> I remember talking extensively to Barry Appleman (VM’s TCP IP guY) 
> about writing an X3270 xterm variant.

What would that have done?  Are you meaning an app that would run on
non-AIX/370 OSs that could then act similar to the i860/i386 client / node?  (Was it trying to emulate a traditional serial dumb terminal?)

#confused



--
Grant. . . .
unix || die

[TUHS] UNIX on S/370

[Grant Taylor]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

On 11/20/2017 06:15 PM, Ron Natalie wrote:
> AIX deflected all this by actually making the user facing stuff hang off 
> the i860/i386 nodes.

Does that mean that you couldn't access AIX/370 from a traditional 
mainframe terminal?

That seems bizarre to me.  But it does sound like some other strange 
things I've heard come out of IBM before.

> I remember talking extensively to Barry Appleman (VM’s TCP IP guY) about 
> writing an X3270 xterm variant.

What would that have done?  Are you meaning an app that would run on 
non-AIX/370 OSs that could then act similar to the i860/i386 client / 
node?  (Was it trying to emulate a traditional serial dumb terminal?)

#confused



-- 
Grant. . . .
unix || die

[TUHS] UNIX on S/370

[Ron Natalie]

That's a common optimization, but the only real requirement in the UNIX
kernel is the raw I/O bypasses the kernel buffer cache.


-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Noel Chiappa
Sent: Monday, November 20, 2017 9:57 PM
To: tuhs at tuhs.org
Cc: jnc at mercury.lcs.mit.edu
Subject: Re: [TUHS] UNIX on S/370

    > From: Larry McVoy

    > So tape I can see being more weird, but isn't raw disk just "don't put
    > it in buffer cache"?

One machines/controllers which are capable of it, with raw devices DMA
happens directly into the buffers in the process (which obviously has to be
resident while the I/O is happening).

    Noel

[TUHS] UNIX on S/370

[Noel Chiappa]

    > From: Larry McVoy

    > So tape I can see being more weird, but isn't raw disk just "don't put
    > it in buffer cache"?

One machines/controllers which are capable of it, with raw devices DMA happens
directly into the buffers in the process (which obviously has to be resident
while the I/O is happening).

    Noel

[TUHS] UNIX on S/370

[Larry McVoy]

So tape I can see being more weird, but isn't raw disk just "don't put it
in buffer cache"?

From what I've been able to gather early tape in Unix was dicey, something
about the driver doing seek.  Was there more to it than that?

On Tue, Nov 21, 2017 at 02:33:55AM +0000, Clem Cole wrote:
> It???s not so much that they don???t mix, it???s not quite the same.    Some
> coprocessor ideas work really well into the Unix I/O model, others don't.
>  Raw disk and tape I/O ala a PDP11 or VAX for instance is not easy on an
> IBM channel controller or a CDC PPU.
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Nov 20, 2017 at 6:45 PM Larry McVoy <lm at mcvoy.com> wrote:
> 
> > On Mon, Nov 20, 2017 at 06:43:28PM -0500, Ron Natalie wrote:
> > >
> > >
> > > > I get that PDP-11 and VAX used memory mapped I/O but was that somehow
> > > exposed above the device driver layer?  If so, I missed that, because I
> > had
> > > no conceptual or technical problem with talking to an I/O
> > >
> > > > channel, it was pretty easy.  And I suck at writing drivers.
> > >
> > > There's nothing that restricts a device driver to memory mapped I/O.
> > You
> > > do what ever you have to do to initiate the I/O.   Even the x86's
> > originally
> > > used special instructions to start the I/O (in/out).    The DENELCOR HEP
> > > supercomputer (we did this port around 1983) we had to bounce I/O
> > requests
> > > off a separate I/O processor different from where the kernel was running.
> > > Similar constucts were used on other machines.
> >
> > Yeah, that's what I thought.  But other people were saying that I/O
> > processors and Unix didn't mix.  I don't get that, seems like whatever
> > the model is is hidden under the driver, that's the whole point of the
> > driver design is it not?
> >
> -- 
> Sent from a handheld expect more typos than usual

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] UNIX on S/370

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3045 bytes --]

 

 

Ø  When I was at Locus, where we did the AIX/370 and AIX/386 stuff Ron mentions we started over.  Charlie can correct me, but IIRC the compiler was IBM's and as Ron said, AIX/370 too lived as a VM 'service.'  I think I have mention on this list previously, it was targeted for the IBM University customers and was not marketed widely; which was a darned shame because it was a excellent product (and TCF was ahead of its time).    Some one on this lost mentioned needing tons of floppies to install AIX/386 which is was so wrong.   You needed only one, if you had another system (386 or 370 on the network), you just booted the new 'node' and let TCF take over.  You 'joined' the cluster, disk replication would start to fill your disk in. It was extremely fast and easy.  Oh yes - AIX/TCF supported mixed instruction sets between the 370 and x86! (TCF looked for the proper node that had the correct HW provisioning to execute any specific process).  We used to show it off at trade shows, including migrating people's vi sessions 'around' the world when we had a cluster that spanned different physical sites [great fun].    Interesting security flaw -- root on any node in the cluster (like a local 386 node) was the same as root on the 370 nodes.

 

It’s been decades (but I still have my IBM contractor’s badge my desk).    We  added the i860 modes to the cluster.   We actually used more of the 370 code on our nodes than we did the x86 code.   Gosh, somewhere I have the how to boot up a new node on the cluster instructions.    “SERVICE” isn’t the proper term (services were more along the lines of the print spoolers, and some of the MVS stuff).   AIX  ran as the guest operating system much as the other IBM OS’s (CMS, MVS, ….).     Yes as time went by I head they had managed to get AIX up on the bare metal.   I never used it that way.   The mainframes I was running AIX had other guest operating systems.    I’m trying to put out of my  mind the fast that I used to be responsible for an MVS system.

 

And yes, VM made things easier.    It got you slightly removed from the hardware.     The disk wasn’t that big of a thing.    AIX punted by not actually doing the tricky channel stuff like talking directly to the IBM terminals (3270’s) or 3705.   3705 programming was a black art even on the IBM native OS’s and then we had some funky third party (COMTEN) hardware to deal with.    AIX deflected all this by actually making the user facing stuff hang off the i860/i386 nodes.    

 

Conversely getting the IBM mainframe operating systems (notably VM/CMS, but to some extent MVS) to talk to the non-IBM world was equally interesting.   I remember talking extensively to Barry Appleman (VM’s TCP IP guY) about writing an X3270 xterm variant.    I remember him launching into the Monty Python pet store skit at the suggestion.   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/9c7246d1/attachment.html>

[TUHS] UNIX on S/370

[Ron Natalie]

In fact, on the HEP, we didn't have a traditional interrupt service routine.
When the I/O completed a new kernel thread was spawned to run the
"interrupt" and start the next I/O.
Later on, I wrote a UNIX port that ran on a MultibusII that used a Message
Passing bus paradigm.    IO starts and incoming completions were more along
the line of message packets than the PDP-11 CSRs and interrupt vectors.
UNIX is pretty gosh-darn resilient about hardware paradigms.

-----Original Message-----
From: Larry McVoy [mailto:lm@mcvoy.com] 
Sent: Monday, November 20, 2017 6:45 PM
To: Ron Natalie
Cc: 'Larry McVoy'; 'Paul Winalski'; 'The Eunuchs Hysterical Society'
Subject: Re: [TUHS] UNIX on S/370

On Mon, Nov 20, 2017 at 06:43:28PM -0500, Ron Natalie wrote:
> 
> 
> > I get that PDP-11 and VAX used memory mapped I/O but was that 
> > somehow
> exposed above the device driver layer?  If so, I missed that, because 
> I had no conceptual or technical problem with talking to an I/O
> 
> > channel, it was pretty easy.  And I suck at writing drivers.
> 
> There's nothing that restricts a device driver to memory mapped I/O.
You
> do what ever you have to do to initiate the I/O.   Even the x86's
originally
> used special instructions to start the I/O (in/out).    The DENELCOR HEP
> supercomputer (we did this port around 1983) we had to bounce I/O 
> requests off a separate I/O processor different from where the kernel was
running.
> Similar constucts were used on other machines.

Yeah, that's what I thought.  But other people were saying that I/O
processors and Unix didn't mix.  I don't get that, seems like whatever the
model is is hidden under the driver, that's the whole point of the driver
design is it not?

[TUHS] UNIX on S/370

[Larry McVoy]

On Mon, Nov 20, 2017 at 06:43:28PM -0500, Ron Natalie wrote:
> 
> 
> > I get that PDP-11 and VAX used memory mapped I/O but was that somehow
> exposed above the device driver layer?  If so, I missed that, because I had
> no conceptual or technical problem with talking to an I/O 
> 
> > channel, it was pretty easy.  And I suck at writing drivers.
> 
> There's nothing that restricts a device driver to memory mapped I/O.    You
> do what ever you have to do to initiate the I/O.   Even the x86's originally
> used special instructions to start the I/O (in/out).    The DENELCOR HEP
> supercomputer (we did this port around 1983) we had to bounce I/O requests
> off a separate I/O processor different from where the kernel was running.
> Similar constucts were used on other machines.

Yeah, that's what I thought.  But other people were saying that I/O
processors and Unix didn't mix.  I don't get that, seems like whatever
the model is is hidden under the driver, that's the whole point of the
driver design is it not?

[TUHS] UNIX on S/370

[Ron Natalie]

> I get that PDP-11 and VAX used memory mapped I/O but was that somehow
exposed above the device driver layer?  If so, I missed that, because I had
no conceptual or technical problem with talking to an I/O 

> channel, it was pretty easy.  And I suck at writing drivers.

There's nothing that restricts a device driver to memory mapped I/O.    You
do what ever you have to do to initiate the I/O.   Even the x86's originally
used special instructions to start the I/O (in/out).    The DENELCOR HEP
supercomputer (we did this port around 1983) we had to bounce I/O requests
off a separate I/O processor different from where the kernel was running.
Similar constucts were used on other machines.

[TUHS] UNIX on S/370

[Larry McVoy]

On Mon, Nov 20, 2017 at 04:56:27PM -0600, Michael Parson wrote:
> On Mon, 20 Nov 2017, Larry McVoy wrote:
> >On Mon, Nov 20, 2017 at 12:27:25PM -0700, arnold at skeeve.com wrote:
> >>Any idea what Linux/370 does?  I think it runs on bare iron.
> >
> >Pretty sure that's correct, we used to run Linux/370 on simulator to
> >build BitKeeper images for it.  I don't remember any VM stuff.
> 
> When I was at IBM, I had a few customers running the product I supported
> under Linux on z, and what wikipedia says matches my memory of it being
> able to run either on metal or as a VM:
> 
>   Linux runs on standard, general purpose mainframe CPs (Central
>   Processors) as well as IFLs (Integrated Facility for Linux). IFLs are
>   mainframe processors dedicated to running Linux, either natively or
>   under a hypervisor (z/VM or KVM on z). Microcode restricts IFLs from
>   running "traditional" workloads, such as z/OS, but they are physically
>   identical to other z System processors. IFLs are typically less
>   expensive to acquire from IBM than CPs.

Sorry, we were running Linux/370 on Hercules simulator:

http://www.hercules-390.org/

which I _thought_ emulated the bare metal.

[TUHS] UNIX on S/370

[Michael Parson]

On Mon, 20 Nov 2017, Larry McVoy wrote:
> On Mon, Nov 20, 2017 at 12:27:25PM -0700, arnold at skeeve.com wrote:
>> Any idea what Linux/370 does?  I think it runs on bare iron.
>
> Pretty sure that's correct, we used to run Linux/370 on simulator to
> build BitKeeper images for it.  I don't remember any VM stuff.

When I was at IBM, I had a few customers running the product I supported
under Linux on z, and what wikipedia says matches my memory of it being
able to run either on metal or as a VM:

   Linux runs on standard, general purpose mainframe CPs (Central
   Processors) as well as IFLs (Integrated Facility for Linux). IFLs are
   mainframe processors dedicated to running Linux, either natively or
   under a hypervisor (z/VM or KVM on z). Microcode restricts IFLs from
   running "traditional" workloads, such as z/OS, but they are physically
   identical to other z System processors. IFLs are typically less
   expensive to acquire from IBM than CPs.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

[TUHS] UNIX on S/370

[Larry McVoy]

Who knows if it will go anywhere.  I got dragged out of retirement with
hints of piles of money, so far, they loaned me a box.

I believe the likely target for this would be AMD's Epyc.  They have already
pushed one box to serve up about 100Gbit/sec of movies and that's with them
doing TLS in the kernel; be faster if they could get the NIC to do that.

https://news.ycombinator.com/item?id=15367421

The limiting factor, so far as I can tell, is memory BW and PCIe lanes.
Epyc seems to deliver more of that.

On Mon, Nov 20, 2017 at 02:56:04PM -0500, Arthur Krewat wrote:
> I would love to see the results of that, including more information about
> the architecture in question.
> 
> 
> On 11/20/2017 2:10 PM, Larry McVoy wrote:
> >On Mon, Nov 20, 2017 at 02:07:27PM -0500, Paul Winalski wrote:
> >>It would mean that you wouldn't have to implement machine check
> >>support and other hardware error handling.  The VM hypervisor would do
> >>that for you.  It would also let you run multiple versions of UNIX
> >>simultaneously.  Very convenient if you're doing kernel or driver
> >>development.
> >Indeed.  I'm currently trying to convince Netflix that the way to get the
> >most performance out of a NUMA machine is to boot a different kernel on
> >each NUMA domain.  One way we might demo that is on a 4 domain system
> >lock down 3 hypervisors and their guest OS to 3/4 of the NUMA domains
> >and give the host kernel the 4th.
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] UNIX on S/370

[Larry McVoy]

On Mon, Nov 20, 2017 at 02:44:03PM -0500, Paul Winalski wrote:
> System/360/370 had a radically different I/O model.  I/O devices and
> their control units were connected to specialized coprocessors called
> I/O channels.  Devices were addressed via a number with three hex
> digits, the first of which was the channel number.  The CPU had an
> instruction called start I/O (SIO) that took as parameters a device
> address and the address of a series of channel command words (CCWs)
> that indicated to the channel the I/O operation to perform and its
> parameters (such as the address of the I/O buffer in main memory).
> The CPU was notified of I/O termination by three interrupts:
> channel-end (the I/O channel reached the end of its channel program),
> control-unit-end (the I/O control unit completed a command), and
> device-end (the I/O device completed a command).

Yep, familiar with this model.  I wrote a device driver for the Unix 
side of an I/O channel (talking to an Ibis disk if I recall correctly).
I didn't find it hard, the I/O channel processor did all the real work,
talking to it was sort of like doing networking.

Truth be told, it was a polling driver, this was early on in the ETA-10
days and interrupts on the I/O channel didn't work.  So that simplified
the driver to the point that it was almost trivial.

I get that PDP-11 and VAX used memory mapped I/O but was that somehow
exposed above the device driver layer?  If so, I missed that, because
I had no conceptual or technical problem with talking to an I/O channel,
it was pretty easy.  And I suck at writing drivers.

[TUHS] UNIX on S/370

[Arthur Krewat]

I would love to see the results of that, including more information 
about the architecture in question.


On 11/20/2017 2:10 PM, Larry McVoy wrote:
> On Mon, Nov 20, 2017 at 02:07:27PM -0500, Paul Winalski wrote:
>> It would mean that you wouldn't have to implement machine check
>> support and other hardware error handling.  The VM hypervisor would do
>> that for you.  It would also let you run multiple versions of UNIX
>> simultaneously.  Very convenient if you're doing kernel or driver
>> development.
> Indeed.  I'm currently trying to convince Netflix that the way to get the
> most performance out of a NUMA machine is to boot a different kernel on
> each NUMA domain.  One way we might demo that is on a 4 domain system
> lock down 3 hypervisors and their guest OS to 3/4 of the NUMA domains
> and give the host kernel the 4th.
>

[TUHS] UNIX on S/370

[Paul Winalski]

On 11/20/17, Clem Cole <clemc at ccc.com> wrote:
> On Mon, Nov 20, 2017 at 11:03 AM, ron minnich <rminnich at gmail.com> wrote:
>
> IMO: The issue was less understanding how channels worked, as much as the
> biasing between the UNIX I/O model *vs.* the mainframe I/O model.   360 and
> CDC boxes for that matter, were a coprocessor that was programmed for the
> I/O.   Figuring out how to splice that into the UNIX world efficiently was
> not always easy.

The PDP-11 and VAX used memory-mapped I/O.  Devices presented
themselves to the CPU as special areas of main memory.  Instead of
retrieving or storing data, these memory locations performed device
operations when you read or wrote to them.

System/360/370 had a radically different I/O model.  I/O devices and
their control units were connected to specialized coprocessors called
I/O channels.  Devices were addressed via a number with three hex
digits, the first of which was the channel number.  The CPU had an
instruction called start I/O (SIO) that took as parameters a device
address and the address of a series of channel command words (CCWs)
that indicated to the channel the I/O operation to perform and its
parameters (such as the address of the I/O buffer in main memory).
The CPU was notified of I/O termination by three interrupts:
channel-end (the I/O channel reached the end of its channel program),
control-unit-end (the I/O control unit completed a command), and
device-end (the I/O device completed a command).

CCW programs were capable of primitive conditional branching and
looping.  It was possible to set up a channel program to perform
sequential multi-buffered reading or writing, using the device-end
interrupts to determine when each buffer was free for reuse.  If no
I/O errors occurred, it was possible to read or write a whole tape
file with a single SIO instruction.

-Paul W.

[TUHS] UNIX on S/370

[Larry McVoy]

On Mon, Nov 20, 2017 at 11:36:51AM -0800, Larry McVoy wrote:
> On Mon, Nov 20, 2017 at 12:36:05PM -0700, Warner Losh wrote:
> > On Mon, Nov 20, 2017 at 12:10 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> > > On Mon, Nov 20, 2017 at 02:07:27PM -0500, Paul Winalski wrote:
> > > > It would mean that you wouldn't have to implement machine check
> > > > support and other hardware error handling.  The VM hypervisor would do
> > > > that for you.  It would also let you run multiple versions of UNIX
> > > > simultaneously.  Very convenient if you're doing kernel or driver
> > > > development.
> > >
> > > Indeed.  I'm currently trying to convince Netflix that the way to get the
> > > most performance out of a NUMA machine is to boot a different kernel on
> > > each NUMA domain.  One way we might demo that is on a 4 domain system
> > > lock down 3 hypervisors and their guest OS to 3/4 of the NUMA domains
> > > and give the host kernel the 4th.
> > 
> > Having a single nic presents a bit of a challenge for this... I look
> > forward to this demo...
> 
> Nope, do disks/mics/mem per domain.  So no bonding.

Sorry s/mics/nics/
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] UNIX on S/370

[Larry McVoy]

On Mon, Nov 20, 2017 at 12:36:05PM -0700, Warner Losh wrote:
> On Mon, Nov 20, 2017 at 12:10 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> > On Mon, Nov 20, 2017 at 02:07:27PM -0500, Paul Winalski wrote:
> > > It would mean that you wouldn't have to implement machine check
> > > support and other hardware error handling.  The VM hypervisor would do
> > > that for you.  It would also let you run multiple versions of UNIX
> > > simultaneously.  Very convenient if you're doing kernel or driver
> > > development.
> >
> > Indeed.  I'm currently trying to convince Netflix that the way to get the
> > most performance out of a NUMA machine is to boot a different kernel on
> > each NUMA domain.  One way we might demo that is on a 4 domain system
> > lock down 3 hypervisors and their guest OS to 3/4 of the NUMA domains
> > and give the host kernel the 4th.
> 
> Having a single nic presents a bit of a challenge for this... I look
> forward to this demo...

Nope, do disks/mics/mem per domain.  So no bonding.

[TUHS] UNIX on S/370

[Warner Losh]

On Mon, Nov 20, 2017 at 12:10 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Mon, Nov 20, 2017 at 02:07:27PM -0500, Paul Winalski wrote:
> > It would mean that you wouldn't have to implement machine check
> > support and other hardware error handling.  The VM hypervisor would do
> > that for you.  It would also let you run multiple versions of UNIX
> > simultaneously.  Very convenient if you're doing kernel or driver
> > development.
>
> Indeed.  I'm currently trying to convince Netflix that the way to get the
> most performance out of a NUMA machine is to boot a different kernel on
> each NUMA domain.  One way we might demo that is on a 4 domain system
> lock down 3 hypervisors and their guest OS to 3/4 of the NUMA domains
> and give the host kernel the 4th.
>

Having a single nic presents a bit of a challenge for this... I look
forward to this demo...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/8cd35543/attachment.html>

[TUHS] UNIX on S/370

[Larry McVoy]

On Mon, Nov 20, 2017 at 12:27:25PM -0700, arnold at skeeve.com wrote:
> Any idea what Linux/370 does?  I think it runs on bare iron.

Pretty sure that's correct, we used to run Linux/370 on simulator to
build BitKeeper images for it.  I don't remember any VM stuff.

[TUHS] UNIX on S/370

[arnold]

Paul Winalski <paul.winalski at gmail.com> wrote:

> On 11/20/17, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> >
> > Maybe this is my lack of knowledge of VM showing, but how did having VM
> > help
> > you over running on the bare hardware?
>
> It would mean that you wouldn't have to implement machine check
> support and other hardware error handling.  The VM hypervisor would do
> that for you.  It would also let you run multiple versions of UNIX
> simultaneously.  Very convenient if you're doing kernel or driver
> development.

The "simpler hardware handling" is a big inducement to building
on top of VM. Or at least starting out that way.

Even though AIX/370 was aimed at the educational market, my impression
is that it was still pretty expensive.  When I worked at the Emory U
computing center (mid 80s) I heard about it, but management wasn't
interested in trying to get it for their S/390.

I'm pretty sure I remember hearing at some point, I don't remember when,
that AIX/370 could run either under VM or on bare iron.

Any idea what Linux/370 does?  I think it runs on bare iron.

Arnold

[TUHS] UNIX on S/370

[Larry McVoy]

On Mon, Nov 20, 2017 at 02:07:27PM -0500, Paul Winalski wrote:
> It would mean that you wouldn't have to implement machine check
> support and other hardware error handling.  The VM hypervisor would do
> that for you.  It would also let you run multiple versions of UNIX
> simultaneously.  Very convenient if you're doing kernel or driver
> development.

Indeed.  I'm currently trying to convince Netflix that the way to get the
most performance out of a NUMA machine is to boot a different kernel on
each NUMA domain.  One way we might demo that is on a 4 domain system
lock down 3 hypervisors and their guest OS to 3/4 of the NUMA domains 
and give the host kernel the 4th.

[TUHS] UNIX on S/370

[Paul Winalski]

On 11/20/17, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>
> Maybe this is my lack of knowledge of VM showing, but how did having VM
> help
> you over running on the bare hardware?

It would mean that you wouldn't have to implement machine check
support and other hardware error handling.  The VM hypervisor would do
that for you.  It would also let you run multiple versions of UNIX
simultaneously.  Very convenient if you're doing kernel or driver
development.

-Paul W.

[TUHS] UNIX on S/370

[Toby Thain]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]

On 2017-11-20 11:47 AM, Charles H Sauer wrote:
> I was waiting for Clem to weigh in on this, since I assume he knows more
> about it than I do.
>  
> I wasn’t paying much attention to Unix on 370, but my impression has
> always been that there were multiple 370 ports. The only ones that were
> completed, to my knowledge, were the ESS one and AIX/370. I don’t know
> of the ESS one being available outside of AT&T.
>  
> I don’t know anything about the compilers used, would assume they were
> PCC-based, even if provided by IBM.

Yes, Johnson's paper[1] lists pcc's targets as Honeywell 6000, IBM 370,
Interdata 8/32, DG Nova, "and others".

From time to time I wonder what became of those pcc versions...

--Toby

[1] https://dl.acm.org/citation.cfm?doid=512760.512771

>  
> In 1989, when I left IBM, there were certainly plenty of 370 people
> inside IBM that would have understood 370 channels. ...
>  
> Charlie
>  
> *From:* Clem Cole
> *Sent:* Monday, November 20, 2017 10:37 AM
> *To:* Noel Chiappa
> *Cc:* The Eunuchs Hysterical Society
> *Subject:* Re: [TUHS] UNIX on S/370
>  
>  
>  
> On Mon, Nov 20, 2017 at 11:05 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
> wrote:
> 
>        
>     Maybe this is my lack of knowledge of VM showing, but how did having
>     VM help
>     you over running on the bare hardware?
> 
>  
> ​As an IBM person, I would ask Charlie to answer here, but I believe the
> answer from the Locus side was tools​ primarily and I also think they
> did not have to support as much specific HW (/i.e./ smaller foot print
> of devices).

[TUHS] UNIX on S/370

[Charles H Sauer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]

I was waiting for Clem to weigh in on this, since I assume he knows more about it than I do.

I wasn’t paying much attention to Unix on 370, but my impression has always been that there were multiple 370 ports. The only ones that were completed, to my knowledge, were the ESS one and AIX/370. I don’t know of the ESS one being available outside of AT&T.

I don’t know anything about the compilers used, would assume they were PCC-based, even if provided by IBM.

In 1989, when I left IBM, there were certainly plenty of 370 people inside IBM that would have understood 370 channels. I would have thought that to still be true in 1991, even with the buyout packages that encouraged people to retire. (It wasn’t until Gerstner became CEO in April 1993 that IBM abandoned the “full employment” traditions.)

What Clem says about the smaller footprint of devices rings true. There were also likely customers that wanted to run AIX alongside other VMs, just as there were customers who wanted to run MVS alongside other VMs.

Charlie

From: Clem Cole 
Sent: Monday, November 20, 2017 10:37 AM
To: Noel Chiappa 
Cc: The Eunuchs Hysterical Society 
Subject: Re: [TUHS] UNIX on S/370



On Mon, Nov 20, 2017 at 11:05 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

      
  Maybe this is my lack of knowledge of VM showing, but how did having VM help
  you over running on the bare hardware?


​As an IBM person, I would ask Charlie to answer here, but I believe the answer from the Locus side was tools​ primarily and I also think they did not have to support as much specific HW (i.e. smaller foot print of devices).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/8fb01559/attachment.html>

[TUHS] UNIX on S/370

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

On Mon, Nov 20, 2017 at 11:05 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>
> Maybe this is my lack of knowledge of VM showing, but how did having VM
> help
> you over running on the bare hardware?
>

​As an IBM person, I would ask Charlie to answer here, but I believe the
answer from the Locus side was tools​ primarily and I also think they did
not have to support as much specific HW (*i.e.* smaller foot print of
devices).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/810fe2ad/attachment.html>

[TUHS] UNIX on S/370

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2369 bytes --]

On Mon, Nov 20, 2017 at 11:03 AM, ron minnich <rminnich at gmail.com> wrote:

>
> When would this  have been? In 1978 Szurkowski and I went to the
> then-famed Atlantic City Computer Show (still in Atlantic-city, pre-casino,
> so it was cheap, and very much the place Springsteen wrote about) and
> stopped at Princeton and talked to someone who was doing such a port. Would
> that have been Tom?
>
​I would think so.​





> I stopped at the now-closed Palo Alto office of IBM in 1991 or so. Some
> ex-Locus researchers told me that the 'move to native' for AIX was being
> slowed down a bit by the lack of people who knew how channels really worked
> ... they implied that many of them had retired! Does any of that comment
> ring true?
>
​I can not say.  I'm sure who that would have been.​  The Locus AIX/370 was
mostly in LA [lead by Bruce Walker and late Gerry Popek].

IMO: The issue was less understanding how channels worked, as much as the
biasing between the UNIX I/O model *vs.* the mainframe I/O model.   360 and
CDC boxes for that matter, were a coprocessor that was programmed for the
I/O.   Figuring out how to splice that into the UNIX world efficiently was
not always easy.

I fought this war many times over my career.   Often it was just easier to
have a lot of really fast similar processors in the main CPU.   The idea
being that if you have enough of them and anyone will do, you don't have to
think about it/do anything special in the SW.

In the the case of the IBM channel or the CDC PPUs, or even later the
Masscomp machines, if you have these coprocessors that can do a lot of the
work for you, but are not as fast as or as flexible as the main processor,
what is best to process what part of the I/O where?

In the case of the MC500 the network processor was a 186 then a 286, and we
ran the TCP stack on it so the host would not have to do anything.   By the
time of the MC5000, we just ran the 286 as a very large packet buffer but
could smooth out packet or interrupt storms, which was the same trick we
did on the CDC Cyber years earlier (the PPU  had monitored the network link
the same way).

I believe that AIX/370 struggled with some of those same choices.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/ef30877d/attachment.html>

[TUHS] UNIX on S/370

[Noel Chiappa]

    > From: Clem Cole <clemc at ccc.com>

    > IIRC Tom Lyons started a 370 port at Princeton and finished it at
    > Amdahl.  But I think that was using VM

Maybe this is my lack of knowledge of VM showing, but how did having VM help
you over running on the bare hardware?

    Noel

[TUHS] UNIX on S/370

[ron minnich]

On Mon, Nov 20, 2017 at 7:25 AM Clem Cole <clemc at ccc.com> wrote:

>
> As for other 370 ports, IIRC Tom Lyons started a 370 port at Princeton and
> finished it at Amdahl.
>

When would this  have been? In 1978 Szurkowski and I went to the then-famed
Atlantic City Computer Show (still in Atlantic-city, pre-casino, so it was
cheap, and very much the place Springsteen wrote about) and stopped at
Princeton and talked to someone who was doing such a port. Would that have
been Tom?

 Charlie can correct me, but IIRC the compiler was IBM's and as Ron said,
> AIX/370 too lived as a VM 'service.'
>

I stopped at the now-closed Palo Alto office of IBM in 1991 or so. Some
ex-Locus researchers told me that the 'move to native' for AIX was being
slowed down a bit by the lack of people who knew how channels really worked
... they implied that many of them had retired! Does any of that comment
ring true?

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/363074d7/attachment-0001.html>

[TUHS] UNIX on S/370

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2980 bytes --]

On Sun, Nov 19, 2017 at 10:50 PM, <arnold at skeeve.com> wrote:

> Nemo <cym224 at gmail.com> wrote:
>
> > Recent commentary on porting led me to read the article on porting
> > UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf)
> > to support 5ESS development because the existing PDP11s were being
> > overwhelmed.  I confess to not having this read this before and find
> > it interesting.  Any recollections from anyone on the matter.  And
> > whatever happened to it?
> >
> > N
> ​.
>


​Since a number of the UNIX folks (​tjk, wnj, myself to name three) were
old MTS and TSS hackers, a couple of us were always fascinated with this
port but I never knew much about it.   As I've said before, fsck was
modeled about a program that was originally for TSS and MTS.    There were
definite lesson's learned from those systems by some of us when we came to
UNIX and I think when some of the TSS folks in NY left CMU or UMich they
took some UNIX lessons with them.

Anyway in reading that paper,  I've wondered how much help the TSS group in
NY gave the AT&T team and who @ IBM it was.   If I had a to bet, Dean
Hiller had to be mixed up in it.  Dean was Mr. TSS and had been my boss at
CMU computer center.   I remember showing Dean UNIX running on 11/34 @ EE
and he being pretty impressed at how much we could do on such a small
system.

As for other 370 ports, IIRC Tom Lyons started a 370 port at Princeton and
finished it at Amdahl.   But I think that was using VM, although it may
have had the access to the BTL compiler to start.

When I was at Locus, where we did the AIX/370 and AIX/386 stuff Ron
mentions we started over.  Charlie can correct me, but IIRC the compiler
was IBM's and as Ron said, AIX/370 too lived as a VM 'service.'  I think I
have mention on this list previously, it was targeted for the IBM
University customers and was not marketed widely; which was a darned shame
because it was a excellent product (and TCF was ahead of its time).    Some
one on this lost mentioned needing tons of floppies to install AIX/386
which is was so wrong.   You needed only one, if you had another system
(386 or 370 on the network), you just booted the new 'node' and let TCF
take over.  You 'joined' the cluster, disk replication would start to fill
your disk in. It was extremely fast and easy.  Oh yes - AIX/TCF supported
mixed instruction sets between the 370 and x86! (TCF looked for the proper
node that had the correct HW provisioning to execute any specific
process).  We used to show it off at trade shows, including migrating
people's vi sessions 'around' the world when we had a cluster that spanned
different physical sites [great fun].    Interesting security flaw -- root
on any node in the cluster (like a local 386 node) was the same as root on
the 370 nodes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/5bafd9aa/attachment.html>

[TUHS] UNIX on S/370

[arnold]

Nemo <cym224 at gmail.com> wrote:

> Recent commentary on porting led me to read the article on porting
> UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf)
> to support 5ESS development because the existing PDP11s were being
> overwhelmed.  I confess to not having this read this before and find
> it interesting.  Any recollections from anyone on the matter.  And
> whatever happened to it?
>
> N.

That article (as noted) was originally published in the Bell System
Technical Journal special issue on UNIX.

The System III manuals say something like "UNIX is an operating system
for DEC PDP-11, Vax 11/780 and IBM S/370 computers" so at least within
the Bell System, the S/370 was supported.

It does not seem to have been released to the world, which is a shame;
it may be because of the underlying I/O supervisor which was a modified
IBM OS. 

Arnold

[TUHS] UNIX on S/370

[Dave Horsfall]

On Sun, 19 Nov 2017, Nemo wrote:

> Recent commentary on porting led me to read the article on porting UNIX 
> to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf) to 
> support 5ESS development because the existing PDP11s were being 
> overwhelmed.  I confess to not having this read this before and find it 
> interesting.  Any recollections from anyone on the matter.  And whatever 
> happened to it?

I dimly recall one Ian Johnston (then at Bell, but formerly UNSW) doing a 
/370 port...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] UNIX on S/370

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

Never heard of that port.   I was involved with IBM on the AIX for the 370/i386/i860 products.   AIX/370 ran under VM/370.   It was entirely ASCII using the TCF to use the i386 for a combination of consoles (IBM dubbed the “high function terminal” which we had the i860 version called the Low Function Terminal) along with X.

[TUHS] UNIX on S/370

[Nemo]

Recent commentary on porting led me to read the article on porting
UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf)
to support 5ESS development because the existing PDP11s were being
overwhelmed.  I confess to not having this read this before and find
it interesting.  Any recollections from anyone on the matter.  And
whatever happened to it?

N.