20 Nov
2017
20 Nov
'17
12:57 a.m.
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.
20 Nov
20 Nov
1:01 a.m.
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.
1:06 a.m.
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."
3:50 a.m.
Nemo <cym224(a)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
3:23 p.m.
On Sun, Nov 19, 2017 at 10:50 PM, <arnold(a)skeeve.com> wrote:
Nemo <cym224(a)gmail.com> wrote:
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.
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
.
4:03 p.m.
On Mon, Nov 20, 2017 at 7:25 AM Clem Cole <clemc(a)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
4:31 p.m.
On Mon, Nov 20, 2017 at 11:03 AM, ron minnich <rminnich(a)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.
7:44 p.m.
On 11/20/17, Clem Cole <clemc(a)ccc.com> wrote:
On Mon, Nov 20, 2017 at 11:03 AM, ron minnich
<rminnich(a)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.
7:56 p.m.
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.
11:43 p.m.
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.
11:45 p.m.
On Mon, Nov 20, 2017 at 06:43:28PM -0500, Ron Natalie wrote:
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?
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.
11:49 p.m.
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:
You
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. 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?
21 Nov
21 Nov
1:15 a.m.
Ø 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.
3:29 a.m.
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
3:40 a.m.
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(a)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
3:46 a.m.
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
8:09 a.m.
Grant Taylor via TUHS <tuhs(a)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
4:49 p.m.
On 11/20/17, Grant Taylor via TUHS <tuhs(a)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.
4:34 a.m.
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(a)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@minnie.tuhs.org] On Behalf Of Grant Taylor via TUHS
Sent: Monday, November 20, 2017 10:29 PM
To: tuhs(a)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
5:42 a.m.
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
noon
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(a)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
1:51 p.m.
On Tue, Nov 21, 2017 at 7:00 AM, Ron Natalie <ron(a)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
2:59 p.m.
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.
5:06 p.m.
*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(a)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.
**
5:23 p.m.
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(a)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(a)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.
**
6:29 p.m.
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(a)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(a)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
7:10 p.m.
On Tue, Nov 21, 2017 at 1:29 PM, Larry McVoy <lm(a)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.
3:40 p.m.
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(a)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
3:45 p.m.
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.
22 Nov
22 Nov
1:33 a.m.
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(a)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.
6:35 a.m.
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(a)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(a)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.
9:38 a.m.
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(a)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(a)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(a)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.
1:40 p.m.
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(a)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(a)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(a)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(a)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.
2:09 p.m.
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(a)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(a)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(a)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(a)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.
1:51 p.m.
On Wed, Nov 22, 2017 at 1:35 AM, Wesley Parish <wobblygong(a)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.
2:04 p.m.
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(a)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.
2341
days inactive
2343
days old
36 comments
13 participants
participants (13)
-
arnold＠skeeve.com -
Clem Cole -
Clem cole
-
Dave Horsfall -
Grant Taylor -
Kevin Bowling -
Larry McVoy -
Nemo -
Paul Winalski -
ron minnich -
Ron Natalie -
Ronald Natalie
-
Wesley Parish