25 Feb
2017
25 Feb
'17
3:17 p.m.
Hi!
Some of the stories on here reminded me of the fact that there's also likely
a whole boat-load of UNIX ports/variants in the past that were never released
to customers or outside certain companies.
Not talking about UNIX versions that have become obsolete or which have
vanished by now like IRIX or the original Apple A/UX (now *that* was an
interesting oddball though..) and such, but the ones that either died or
failed or got cancelled during the product development process or were never
intended to be released to the outside ar all.
Personally I came across one during some UNIX consultancy work at Commodore
during the time that they were working on bringing out an SVR4 release for the
Amiga (which they actually sold for some time)
Side-note.. Interestingly enough according to my contacts at that time inside
CBM it was based on the much cheaper to license 3B2 SVR4 codebase and not the
M68k codebase which explained some of the oddities and lack of M68k ABI
compliance of the Amiga SVR4 release..
However..
It turned out that they had been running an SVRIII port on much older Amiga
2000's with 68020 cards for some of their internal corporate networking and
email, UUCP, etc. and was called 'AMIX' internally. But as far as I know it
was never released to the public or external customers.
It was a fairly 'plain jane' SVRIII port with little specific 'Amiga'
hardware
bits supported but otherwise quite complete and pretty stable.
Worked quite well in the 4MB DRAM available on these cards. The later SVR4
didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!)
16MB.
It was known 'outside' that something like this existed as the boot ROM's
on
the 68020 card had an 'AMIX' option but outside CBM few people really knew
much about it.
It may have been used at the University of Lowell as they developed a TI34010
based card that may already have had some support in this release.
Still..
This does make me wonder.. Does anyone else know of these kinds of special
'snowflake' UNIX versions that never got out at various companies/insitutes?
(and can talk about it without violating a whole stack of NDA's ;) )
No special reason.. Just idle curiosity :)
Likely all these are gone forever anyway as prototypes and small run production
devices and related software tends to get destroyed when companies go bust or
get aquired.
Bye, Arno.
25 Feb
25 Feb
3:32 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On Sat, Feb 25, 2017 at 03:17:38PM +0100, Arno Griffioen wrote:
Worked quite well in the 4MB DRAM available on these
cards. The later SVR4
didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!)
16MB.
Back in the days of 4MB SPARC machines (and 68K machines) we joked
that EMACS stood for Eight Megs And Constantly Swapping. David
Rosenthal, a Sun DE, was known for running emacs on the bitmapped
console in terminal mode so as to not let X11 or NeWS eat up ram.
5:35 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On Sat, 25 Feb 2017, Larry McVoy wrote:
On Sat, Feb 25, 2017 at 03:17:38PM +0100, Arno
Griffioen wrote:
Worked quite well in the 4MB DRAM available on
these cards. The later SVR4
didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!)
16MB.
Back in the days of 4MB SPARC machines (and 68K machines) we joked
that EMACS stood for Eight Megs And Constantly Swapping. David
Rosenthal, a Sun DE, was known for running emacs on the bitmapped
console in terminal mode so as to not let X11 or NeWS eat up ram.
From that nickname I came up with "Enough Memory A
Concept Strange", as 8
MB was no longer a lot of memory.
Disclosure - never was an EMACS person, or a vi person, pico was and nano
is more my cup of tea. That said, I can fumble my way around vi if I
absolutely must.
-uso.
7:11 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Steve Nickolas <usotsuki(a)buric.co> wrote:
On Sat, 25 Feb 2017, Larry McVoy wrote:
On my Sun-2/50 at home and my 3-50 at work, I edited in console mode when I was
working on drivers - just because launching Sunview did take too much time and
I needed to reboot frequently. Note that I could not load the driver when I was
e.g. working on the kbd driver.
I stopped with this kind of usage once the console on sparc systems came up and
has been too slow. OK there was a hack to copy the FORTH boot code into RAM to
make it faster, but it still has been slower than the Sun2 or Sun3 machines.
Memory was definitely not a problem on Sparc systems as the Sparc systems I
used never had less than 16MB of RAM (usually 64MB). I started with what I call
a "SparcStation-1-" at home, an engineering sample delivered aprox. 9 months
before the official Sparcstation-1 launch that used a TI Floatingpoint
processor with a gate array adaptor on a piggy back rather than the official
Weitek chip.
Back in the days of 4MB SPARC machines (and 68K
machines) we joked
that EMACS stood for Eight Megs And Constantly Swapping. David
Rosenthal, a Sun DE, was known for running emacs on the bitmapped
console in terminal mode so as to not let X11 or NeWS eat up ram.
From that nickname I came up with "Enough Memory A Concept Strange", as 8
MB was no longer a lot of memory. Disclosure - never was an EMACS person, or a vi
person, pico was and nano
is more my cup of tea. That said, I can fumble my way around vi if I
absolutely must.
I do not know EMACS well enough to use it and I know vi for emergency only. I
usually use my VED (see schilytools).
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
7:16 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
For the record, I use sam, ed, and acme, in that order.
On Feb 25, 2017, at 1:11 PM, Joerg Schilling
<schily(a)schily.net> wrote:
Steve Nickolas <usotsuki(a)buric.co> wrote:
On Sat, 25 Feb 2017, Larry McVoy wrote:
On my Sun-2/50 at home and my 3-50 at work, I edited in console mode when I was
working on drivers - just because launching Sunview did take too much time and
I needed to reboot frequently. Note that I could not load the driver when I was
e.g. working on the kbd driver.
I stopped with this kind of usage once the console on sparc systems came up and
has been too slow. OK there was a hack to copy the FORTH boot code into RAM to
make it faster, but it still has been slower than the Sun2 or Sun3 machines.
Memory was definitely not a problem on Sparc systems as the Sparc systems I
used never had less than 16MB of RAM (usually 64MB). I started with what I call
a "SparcStation-1-" at home, an engineering sample delivered aprox. 9 months
before the official Sparcstation-1 launch that used a TI Floatingpoint
processor with a gate array adaptor on a piggy back rather than the official
Weitek chip.
Back in the days of 4MB SPARC machines (and 68K
machines) we joked
that EMACS stood for Eight Megs And Constantly Swapping. David
Rosenthal, a Sun DE, was known for running emacs on the bitmapped
console in terminal mode so as to not let X11 or NeWS eat up ram.
From that nickname I came up with "Enough Memory A Concept Strange", as 8
MB was no longer a lot of memory. Disclosure - never was an EMACS person, or a vi
person, pico was and nano
is more my cup of tea. That said, I can fumble my way around vi if I
absolutely must.
I do not know EMACS well enough to use it and I know vi for emergency only. I
usually use my VED (see schilytools).
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
6:31 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On Sat, Feb 25, 2017 at 9:32 AM, Larry McVoy <lm(a)mcvoy.com> wrote:
Back in the days of 4MB SPARC machines (and 68K
machines) we joked
that EMACS stood for Eight Megs And Constantly Swapping.
To me the good news is was if you could laugh at yourself I think it was
pretty sign. There were a bunch of them... two more I can remember:
LISP -- Lots of Insipidly Silly Parens
Multics - Many Unbelievably Large Tables In Core Simultaneously
There was a Fortran one I've forgotten that started with "Friendly Only"
..
6:34 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On Sat, Feb 25, 2017 at 9:31 AM, Clem Cole <clemc(a)ccc.com> wrote:
On Sat, Feb 25, 2017 at 9:32 AM, Larry McVoy <lm(a)mcvoy.com> wrote:
PCMCIA - 'People Can't Memorize Computer Industry Acronyms"
-- Charles
Back in the days of 4MB SPARC machines (and 68K
machines) we joked
that EMACS stood for Eight Megs And Constantly Swapping.
To me the good news is was if you could laugh at yourself I think it was
pretty sign. There were a bunch of them... two more I can remember:
LISP -- Lots of Insipidly Silly Parens
Multics - Many Unbelievably Large Tables In Core Simultaneously
6:36 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Compiles Only Because Of Luck.
Completely Obsolete, Badly Outdated Language
Even Feldman Likes it (The other FORTRAN.)
On Feb 25, 2017, at 12:31 PM, Clem Cole
<clemc(a)ccc.com> wrote:
On Sat, Feb 25, 2017 at 9:32 AM, Larry McVoy <lm(a)mcvoy.com> wrote:
Back in the days of 4MB SPARC machines (and 68K machines) we joked that EMACS stood for
Eight Megs And Constantly Swapping.
To me the good news is was if you could laugh at yourself I think it was pretty sign.
There were a bunch of them... two more I can remember:
LISP -- Lots of Insipidly Silly Parens
Multics - Many Unbelievably Large Tables In Core Simultaneously
There was a Fortran one I've forgotten that started with "Friendly Only"
..
7:28 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On 25 Feb 2017, at 17:31, Clem Cole <clemc(a)ccc.com> wrote:
LISP -- Lots of Insipidly Silly Parens
Lots of Irritating Single Parens
(Although why anyone who has looked at the tail of some bit of C-derived language with its
apparently endless sequence of close braces, carefully arranged one-per line to maximise
the wasted screen real-estate would say this is beyond me. One of Python's few good
features is that it is impossible to do this when writing Python -- although somewhere, no
doubt, there are coding style guidelines which say that Python definitions must be
separated from the following definition by 1 + number-of-nesting-levels blank lines.)
27 Feb
27 Feb
6:08 a.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On Sat, 25 Feb 2017, Tim Bradshaw wrote:
(Although why anyone who has looked at the tail of
some bit of C-derived
language with its apparently endless sequence of close braces, carefully
arranged one-per line to maximise the wasted screen real-estate would
say this is beyond me. One of Python's few good features is that it is
impossible to do this when writing Python -- although somewhere, no
doubt, there are coding style guidelines which say that Python
definitions must be separated from the following definition by 1 +
number-of-nesting-levels blank lines.)
The last language I used where white-space was syntactical was FORTRAN...
Death to Python!
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
25 Feb
25 Feb
6:40 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On 25 February 2017 at 09:32, Larry McVoy <lm(a)mcvoy.com> wrote:
On Sat, Feb 25, 2017 at 03:17:38PM +0100, Arno
Griffioen wrote:
Ah, EMACS jokes (though this be off-topic)! I remember one cartoon,
which I cannot place, of someone at a terminal and a platter flying
through the room having broken free from the drive pack, the caption
reading "EMACS tends to hit the disc a little too often."
N.
Worked quite well in the 4MB DRAM available on
these cards. The later SVR4
didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!)
16MB.
Back in the days of 4MB SPARC machines (and 68K machines) we joked
that EMACS stood for Eight Megs And Constantly Swapping.
6:43 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
I remember in 1991 noticing suspiciously high load activity on a workstation of an
engineer on vacation. Turns out he had just left EMACS running.
On Feb 25, 2017, at 12:40 PM, Nemo
<cym224(a)gmail.com> wrote:
On 25 February 2017 at 09:32, Larry McVoy <lm(a)mcvoy.com> wrote:
On Sat, Feb 25, 2017 at 03:17:38PM +0100, Arno
Griffioen wrote:
Ah, EMACS jokes (though this be off-topic)! I remember one cartoon,
which I cannot place, of someone at a terminal and a platter flying
through the room having broken free from the drive pack, the caption
reading "EMACS tends to hit the disc a little too often."
N. Worked quite well in the 4MB DRAM available on
these cards. The later SVR4
didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!)
16MB.
Back in the days of 4MB SPARC machines (and 68K machines) we joked
that EMACS stood for Eight Megs And Constantly Swapping.
26 Feb
26 Feb
12:23 a.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On Sat, 25 Feb 2017, Larry McVoy wrote:
Back in the days of 4MB SPARC machines (and 68K
machines) we joked that
EMACS stood for Eight Megs And Constantly Swapping. David Rosenthal, a
Sun DE, was known for running emacs on the bitmapped console in terminal
mode so as to not let X11 or NeWS eat up ram.
Another acronym is Esc Meta Alt Ctl Shift...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
25 Feb
25 Feb
3:44 p.m.
New subject: Un-released/internal/special UNIX versions/ports during theyears?
I’ve read from early Microsoft employee’s that you had to learn to use vi to get vacation
time, as they ran Xenix on all their backend stuff. Although their first Xenix ads did
mention it was available on the PDP-11, and other than one old post where someone
mentioned that anytime there was a serious bug it was always in the Xenix portion.
It’s kind of funny that despite at one time being the highest installation by site count,
Xenix has all but disappeared. Not that OpenSERVER was either open or much of a good
server. And the only people I ever saw all that excited about UnixWare was telecom
companies.
Sent from Mail for Windows 10
From: Arno Griffioen
Sent: Saturday, 25 February 2017 10:18 PM
To: tuhs(a)minnie.tuhs.org
Subject: [TUHS] Un-released/internal/special UNIX versions/ports during theyears?
Hi!
Some of the stories on here reminded me of the fact that there's also likely
a whole boat-load of UNIX ports/variants in the past that were never released
to customers or outside certain companies.
Not talking about UNIX versions that have become obsolete or which have
vanished by now like IRIX or the original Apple A/UX (now *that* was an
interesting oddball though..) and such, but the ones that either died or
failed or got cancelled during the product development process or were never
intended to be released to the outside ar all.
Personally I came across one during some UNIX consultancy work at Commodore
during the time that they were working on bringing out an SVR4 release for the
Amiga (which they actually sold for some time)
Side-note.. Interestingly enough according to my contacts at that time inside
CBM it was based on the much cheaper to license 3B2 SVR4 codebase and not the
M68k codebase which explained some of the oddities and lack of M68k ABI
compliance of the Amiga SVR4 release..
However..
It turned out that they had been running an SVRIII port on much older Amiga
2000's with 68020 cards for some of their internal corporate networking and
email, UUCP, etc. and was called 'AMIX' internally. But as far as I know it
was never released to the public or external customers.
It was a fairly 'plain jane' SVRIII port with little specific 'Amiga'
hardware
bits supported but otherwise quite complete and pretty stable.
Worked quite well in the 4MB DRAM available on these cards. The later SVR4
didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!)
16MB.
It was known 'outside' that something like this existed as the boot ROM's
on
the 68020 card had an 'AMIX' option but outside CBM few people really knew
much about it.
It may have been used at the University of Lowell as they developed a TI34010
based card that may already have had some support in this release.
Still..
This does make me wonder.. Does anyone else know of these kinds of special
'snowflake' UNIX versions that never got out at various companies/insitutes?
(and can talk about it without violating a whole stack of NDA's ;) )
No special reason.. Just idle curiosity :)
Likely all these are gone forever anyway as prototypes and small run production
devices and related software tends to get destroyed when companies go bust or
get aquired.
Bye, Arno.
26 Feb
26 Feb
5:06 a.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
There is that emulator shoebill which can run A/UX, even the 0.7 version which has the
lower level unisoft sysv source.
But by the time they got around to version 3 it was an incredibly robust UNIX with a very
simple UI, and by nature had access to an incredible amount of apps being source sysv
compatible, and could run most sys6/7 apps, including SoftPC!
It's crazy that Apple never ported it to the PowerPC, as they basically had a next
gen OS right under their nose the whole time, and ended up paying to port NeXT to the
PowerPC, and doing the carbon shuffle to get apps... But Apple has never been shy from
doing things strange.
On February 26, 2017 3:02:20 AM GMT+08:00, Al Kossow <aek(a)bitsavers.org> wrote:
On 2/25/17 6:17 AM, Arno Griffioen wrote:
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
the original Apple A/UX (now *that* was an
interesting oddball though..)
The original release was based on Unisoft UniPlus+, with some boot
resiliency added. 
1 Mar
1 Mar
5:15 a.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Hello!
We (well most of us) all of us know about AIX. Well what about AIX/370?
-----
Gregg C Levine gregg.drwho8(a)gmail.com
"This signature fought the Time Wars, time and again."
On Sat, Feb 25, 2017 at 9:17 AM, Arno Griffioen <arno.griffioen(a)ieee.org> wrote:
Hi!
Some of the stories on here reminded me of the fact that there's also likely
a whole boat-load of UNIX ports/variants in the past that were never released
to customers or outside certain companies.
Not talking about UNIX versions that have become obsolete or which have
vanished by now like IRIX or the original Apple A/UX (now *that* was an
interesting oddball though..) and such, but the ones that either died or
failed or got cancelled during the product development process or were never
intended to be released to the outside ar all.
Personally I came across one during some UNIX consultancy work at Commodore
during the time that they were working on bringing out an SVR4 release for the
Amiga (which they actually sold for some time)
Side-note.. Interestingly enough according to my contacts at that time inside
CBM it was based on the much cheaper to license 3B2 SVR4 codebase and not the
M68k codebase which explained some of the oddities and lack of M68k ABI
compliance of the Amiga SVR4 release..
However..
It turned out that they had been running an SVRIII port on much older Amiga
2000's with 68020 cards for some of their internal corporate networking and
email, UUCP, etc. and was called 'AMIX' internally. But as far as I know it
was never released to the public or external customers.
It was a fairly 'plain jane' SVRIII port with little specific 'Amiga'
hardware
bits supported but otherwise quite complete and pretty stable.
Worked quite well in the 4MB DRAM available on these cards. The later SVR4
didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!)
16MB.
It was known 'outside' that something like this existed as the boot ROM's
on
the 68020 card had an 'AMIX' option but outside CBM few people really knew
much about it.
It may have been used at the University of Lowell as they developed a TI34010
based card that may already have had some support in this release.
Still..
This does make me wonder.. Does anyone else know of these kinds of special
'snowflake' UNIX versions that never got out at various companies/insitutes?
(and can talk about it without violating a whole stack of NDA's ;) )
No special reason.. Just idle curiosity :)
Likely all these are gone forever anyway as prototypes and small run production
devices and related software tends to get destroyed when companies go bust or
get aquired.
Bye, Arno.
8:17 a.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Gregg Levine <gregg.drwho8(a)gmail.com> wrote:
Hello!
We (well most of us) all of us know about AIX. Well what about AIX/370?
What about it?
It definitely existed. It and AIX for the PC were similar but different
from AIX on the RS/6000...
I never saw it personally, but it was orderable.
Arnold
8:45 a.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On Feb 28, 2017, at 10:15 PM, Gregg Levine
<gregg.drwho8(a)gmail.com> wrote:
Hello!
We (well most of us) all of us know about AIX. Well what about AIX/370?
——
AIX/370 was a real product. One of the ones that I don’t ever think saw the light of
day was the i860 AIX port. IBM made two i860 add-in cards for the PS/2. The single
processor version was called the Wizard and there was a 4 processor version with an
integral frame buffer called the W4. We ported AIX to both. The i860 version
actually had more in common with the 370 version than it did with the 386. All of
these AIX versions came from the same source code and used the IBM TCF to allow you to
transparently run executables across nodes in the cluster. The only AIX that didn’t
play was the completely independent (and in my opinion somewhat brain damaged) IBM/RT
UNIX. If there was a TCF-based RT kernel, I never saw it, even inside the IBM labs.
Speaking of odd job control mechanisms. The 386 side had a device that multiplexed the
PS/2 console into multiple streams called the “High Function Terminal.” When we wrote
the virtual console for the Wizard/W4 add in card, we called it the “Low Function
Terminal."
12:14 p.m.
New subject: Un-released/internal/special UNIX versions/ports duringthe years?
I had never hear of an i860 board from IBM, but a little searching, and it almost looks
like it was going to be a thing.
NUMBER 290-817
DATE 901218
TYPE Programming
TITLE INTEL OS/2 AND AIX I860 SOFTWARE DEVELOPMENT TOOLS FOR C AND FORTRAN
ABSTRACT Today, IBM announces C and FORTRAN compiler support for the
PS/2 (R) Wizard Adapter running under both AIX (R) PS/2 and OS/2 (R)
operating systems.
< hundreds of lines of information deleted >
TECHINFO TECHNICAL INFORMATION
SPECIFIED OPERATING ENVIRONMENT
v MACHINE REQUIREMENTS:
| o The Intel OS/2 and AIX i860 Software Development Tools for C and
| FORTRAN require one of the following PS/2 system units:
| - PS/2 Model 70
| - PS/2 Model P75*
| - PS/2 Model 80
| - PS/2 Model 90 XP*
| - PS/2 Model 95 XP*
| The Model P70 is not supported.
====> * These models are not currently supported by AIX PS/2.
Therefore, the PS/2 Wizard Adapter will operate only with IBM
OS/2 on these models.
Or later something like this:
IBM architecture - RT
IBM architecture - RS/6000
IBM architecture - S/370
Intel architecture - i386
(rumors of)
Intel architecture - i860 (Wizard PS/2 cardset with 4xi860)
whatever comes out of Steve Chen's supercomputer work
Of course, with IBM not licensing AIX source to anyone, these are only
IBM machines, but that is not the same as AIX being a non-portable OS.
Rumors are that IBM's customers are pressing very hard for source
licenses and that someday such licenses will be available. Whether
that would lead to ports to other machines, I can't predict.
Very interesting!
Sent from Mail for Windows 10
From: Ronald Natalie
Sent: Wednesday, 1 March 2017 3:45 PM
To: Gregg Levine
Cc: Tuhs
Subject: Re: [TUHS] Un-released/internal/special UNIX versions/ports duringthe years?
On Feb 28, 2017, at 10:15 PM, Gregg Levine
<gregg.drwho8(a)gmail.com> wrote:
Hello!
We (well most of us) all of us know about AIX. Well what about AIX/370?
——
AIX/370 was a real product. One of the ones that I don’t ever think saw the light of
day was the i860 AIX port. IBM made two i860 add-in cards for the PS/2. The single
processor version was called the Wizard and there was a 4 processor version with an
integral frame buffer called the W4. We ported AIX to both. The i860 version
actually had more in common with the 370 version than it did with the 386. All of
these AIX versions came from the same source code and used the IBM TCF to allow you to
transparently run executables across nodes in the cluster. The only AIX that didn’t
play was the completely independent (and in my opinion somewhat brain damaged) IBM/RT
UNIX. If there was a TCF-based RT kernel, I never saw it, even inside the IBM labs.
Speaking of odd job control mechanisms. The 386 side had a device that multiplexed the
PS/2 console into multiple streams called the “High Function Terminal.” When we wrote
the virtual console for the Wizard/W4 add in card, we called it the “Low Function
Terminal."
3:54 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On Wed, Mar 1, 2017 at 2:45 AM, Ronald Natalie <ron(a)ronnatalie.com> wrote:
We had RTs where I was. By the time I came on the scene, they were being
decommissioned in favor of RS/6k hardware (arguably, the RT was pretty
low-powered even for its day), so the students were running around grabbing
them and playing with them. We ran AOS on ours, which was a more-or-less
straight port of 4.3BSD+NFS (maybe they started with Tahoe? I don't know),
but IBM seemed to want to push AIX with them. The RT was my first exposure
to "real" Unix source code.
What was interesting to me was all of the #ifdef's in the source that made
it clear that someone at IBM had obviously tried to port 4.3 to the 370. I
don't think that ever saw the light of day, but there were definitely
vestiges of it in the kernel.
I had understood was that AIX/370 was actually OSF/1 based and totally
separate from AIX 2.x (on the RT) and AIX 3.x (on the RS/6k)? From what you
wrote, it sounds like that wasn't quite right.
If there was a TCF-based RT kernel, I never saw it, even inside the IBM
On Feb 28, 2017, at 10:15 PM, Gregg Levine
<gregg.drwho8(a)gmail.com>
wrote:
Hello!
We (well most of us) all of us know about AIX. Well what about AIX/370?
——
AIX/370 was a real product. One of the ones that I don’t ever think
saw the light of day was the i860 AIX port. IBM made two i860 add-in
cards for the PS/2. The single processor version was called the Wizard
and there was a 4 processor version with an integral frame buffer called
the W4. We ported AIX to both. The i860 version actually had more in
common with the 370 version than it did with the 386. All of these AIX
versions came from the same source code and used the IBM TCF to allow you
to transparently run executables across nodes in the cluster. The only
AIX that didn’t play was the completely independent (and in my opinion
somewhat brain damaged) IBM/RT UNIX. labs.
Speaking of odd job control mechanisms. The 386 side had a device that
multiplexed the PS/2 console into multiple streams called the “High
Function Terminal.” When we wrote the virtual console for the Wizard/W4
add in card, we called it the “Low Function Terminal."
Did the HFT survive into the RS/6k? I seem to recall hearing about that.
Perhaps it was an option on the RT, or somehow could be used with the
"crossbow" card on the 6152?
- Dan C.
4:41 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On 1 March 2017 at 02:45, Ronald Natalie <ron(a)ronnatalie.com> wrote (in part):
[...]
The only AIX that didn’t play was the completely
independent (and in my
opinion somewhat brain damaged) IBM/RT UNIX.
No wonder, given what they did to the poor chip it ran on. #6-)
N.
7:17 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On Wed, Mar 1, 2017 at 2:45 AM, Ronald Natalie <ron(a)ronnatalie.com> wrote:
AIX/370 was a real product.
Indeed it was.
All of these AIX versions came from the same source
code and used the
IBM TCF to allow you to transparently run executables across nodes in the
cluster.
Exactly right. TCF - Transparent Computing Facility -- No mean trick...
you can mix PS/2 and 370 in the cluster, so root on desk allowed me root
on the mainframe too. What was cool was that the TCF will look at the
executable and find the proper CPU. The big mistake was that that node id
was stored in a single 32 bit word and assigned per bit, which was a
scaling issues.
I was at Locus Computing Corp (aka LCC or just "Locus"), who developed AIX
for IBM under contract and TCF was part of it. The direct result of the The
LOCUS Distributed System Architecture
<https://www.amazon.com/Distributed-System-Architecture-Computer-Systems/dp/0262517191/ref=sr_1_1?s=books&ie=UTF8&qid=1488391384&sr=1-1&refinements=p_27%3AGerald+J.+Popek>
from
UCLA. The book actually describes much of the AIX/370 work, but starts
with the original UCLA work. I did not work on the IBM project, although a
number of my peers did. I was higher to help developed TNC - Transparent
Network Computing, which is was used in Intel's Paragon and DEC's
TruClusters and a never shipped HP Cluster Product. Many of the same ideas
but we wanted a separate team that never saw the IBM code so there could
never be any concern about ownership. The architects like me and Roman,
were allowed to talk to the AIX architects, such as Bruce; but we keep
separate development environments at separate sites. After the IBM work
ended, all of the Locus distributed system folks the struct around went to
work on TNC and the technology go sold off and licensed. What was
interesting is that TNC was open'ed sourced after the Compaq/HP mergers and
put into Linux but I've forgotten the URL (I'll search and follow up).
It's a real shame it never went anywhere. It was a very, very cool.
The only AIX that didn’t play was the completely
independent (and in
my opinion somewhat brain damaged) IBM/RT UNIX. If there was a TCF-based
RT kernel, I never saw it, even inside the IBM labs.
That was IBM politics. LCC has the contract for the original AIX port to
the 370. When the RT was developed, the Austin team was ramped up. One
of our members of the TUHS list who is remaining silent I see is not saying
why but I know was there ;-) and might known the actual politics, I never
did. But when the AIX/RT port was forked, they started with AIX/370 code
base and removed the TCF code. But LCC still had the AIX/370 contract
from Enterprise system group to maintain AIX/370. And also, Locus had the
contract from Entry Systems, who all they wanted TCF. So AIX/386 and
AIX/370 as Ron points out were one code base, one dev team (at LCC in
California).
Dan Cross said: "I had understood was that AIX/370 was actually OSF/1
based"
It maybe that by the end, the user space was based on the OSF/1 user space
code. That was true for HP and DEC also. But I can definitely state
AIX/370 and AIX/386 were one set of source trees and all of was done by
Locus Computing Corporation certainly through the mid 1990s.
Clem
2 Mar
2 Mar
3:13 a.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Slightly off or on topic, but since you seem to know, and I've never seen aix 370 in
the eild, did it require VM? Did it take advantage of SNA, and allow front ends, along
with SNA gateways and 3270's?
Or was it more of a hosted TCP/IP accessable system?
On March 2, 2017 2:17:00 AM GMT+08:00, Clem Cole <clemc(a)ccc.com> wrote:
On Wed, Mar 1, 2017 at 2:45 AM, Ronald Natalie < ron(a)ronnatalie.com
<mailto:ron@ronnatalie.com> > wrote:
AIX/370 was a real product.
Indeed it was.
All of these AIX versions came from the same source code and used the
IBM TCF to allow you to transparently run executables across nodes in
the cluster.
Exactly right. TCF - Transparent Computing Facility -- No mean
trick... you can mix PS/2 and 370 in the cluster, so root on desk
allowed me root on the mainframe too. What was cool was that the TCF
will look at the executable and find the proper CPU. The big mistake
was that that node id was stored in a single 32 bit word and assigned
per bit, which was a scaling issues.
I was at Locus Computing Corp (aka LCC or just "Locus"), who developed
AIX for IBM under contract and TCF was part of it. The direct result
of
the The LOCUS Distributed System Architecture
<https://www.amazon.com/Distributed-System-Architecture-Computer-Systems
/dp/0262517191/ref=sr_1_1?s=books&ie=UTF8&qid=1488391384&sr=1-1&refineme
nts=p_27%3AGerald+J.+Popek> from UCLA. The book actually describes
much of the AIX/370 work, but starts with the original UCLA work. I
did
not work on the IBM project, although a number of my peers did. I was
higher to help developed TNC - Transparent Network Computing, which is
was used in Intel's Paragon and DEC's TruClusters and a never shipped
HP
Cluster Product. Many of the same ideas but we wanted a separate team
that never saw the IBM code so there could never be any concern about
ownership. The architects like me and Roman, were allowed to talk to
the AIX architects, such as Bruce; but we keep separate development
environments at separate sites. After the IBM work ended, all of the
Locus distributed system folks the struct around went to work on TNC
and the technology go sold off and licensed. What was interesting is
that TNC was open'ed sourced after the Compaq/HP mergers and put into
Linux but I've forgotten the URL (I'll search and follow up).
It's a real shame it never went anywhere. It was a very, very cool.
The only AIX that didn’t play was the completely independent (and
in my opinion somewhat brain damaged) IBM/RT UNIX. If there was a
TCF-based RT kernel, I never saw it, even inside the IBM labs.
That was IBM politics. LCC has the contract for the original AIX
port
to the 370. When the RT was developed, the Austin team was ramped up.
One of our members of the TUHS list who is remaining silent I see is
not
saying why but I know was there ;-) and might known the actual
politics, I never did. But when the AIX/RT port was forked, they
started with AIX/370 code base and removed the TCF code. But LCC
still
had the AIX/370 contract from Enterprise system group to maintain
AIX/370. And also, Locus had the contract from Entry Systems, who all
they wanted TCF. So AIX/386 and AIX/370 as Ron points out were one
code base, one dev team (at LCC in California).
Dan Cross said: "I had understood was that AIX/370 was actually OSF/1
based"
It maybe that by the end, the user space was based on the OSF/1 user
space code. That was true for HP and DEC also. But I can definitely
state AIX/370 and AIX/386 were one set of source trees and all of was
done by Locus Computing Corporation certainly through the mid 1990s.
Clem
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
3:27 a.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Hello!
Well before it was withdrawn from marketing, it played in a big pool
Namely the mainframes at one of the universities in Norway. And I got
this from a VMer I who is best known for writing the pipelines stuff,
And sadly that was its only customer.
By contrast AIX for RS/6000 gang and its ancestors were well taken
care of and its still available.
-----
Gregg C Levine gregg.drwho8(a)gmail.com
"This signature fought the Time Wars, time and again."
On Wed, Mar 1, 2017 at 1:17 PM, Clem Cole <clemc(a)ccc.com> wrote:
On Wed, Mar 1, 2017 at 2:45 AM, Ronald Natalie <ron(a)ronnatalie.com> wrote:
AIX/370 was a real product.
Indeed it was.
All of these AIX versions came from the same source code and used the
IBM TCF to allow you to transparently run executables across nodes in the
cluster.
Exactly right. TCF - Transparent Computing Facility -- No mean trick...
you can mix PS/2 and 370 in the cluster, so root on desk allowed me root on
the mainframe too. What was cool was that the TCF will look at the
executable and find the proper CPU. The big mistake was that that node id
was stored in a single 32 bit word and assigned per bit, which was a scaling
issues.
I was at Locus Computing Corp (aka LCC or just "Locus"), who developed AIX
for IBM under contract and TCF was part of it. The direct result of the The
LOCUS Distributed System Architecture from UCLA. The book actually
describes much of the AIX/370 work, but starts with the original UCLA work.
I did not work on the IBM project, although a number of my peers did. I was
higher to help developed TNC - Transparent Network Computing, which is was
used in Intel's Paragon and DEC's TruClusters and a never shipped HP Cluster
Product. Many of the same ideas but we wanted a separate team that never saw
the IBM code so there could never be any concern about ownership. The
architects like me and Roman, were allowed to talk to the AIX architects,
such as Bruce; but we keep separate development environments at separate
sites. After the IBM work ended, all of the Locus distributed system
folks the struct around went to work on TNC and the technology go sold off
and licensed. What was interesting is that TNC was open'ed sourced after
the Compaq/HP mergers and put into Linux but I've forgotten the URL (I'll
search and follow up).
It's a real shame it never went anywhere. It was a very, very cool.
The only AIX that didn’t play was the completely independent (and in
my opinion somewhat brain damaged) IBM/RT UNIX. If there was a TCF-based
RT kernel, I never saw it, even inside the IBM labs.
That was IBM politics. LCC has the contract for the original AIX port to
the 370. When the RT was developed, the Austin team was ramped up. One
of our members of the TUHS list who is remaining silent I see is not saying
why but I know was there ;-) and might known the actual politics, I never
did. But when the AIX/RT port was forked, they started with AIX/370 code
base and removed the TCF code. But LCC still had the AIX/370 contract from
Enterprise system group to maintain AIX/370. And also, Locus had the
contract from Entry Systems, who all they wanted TCF. So AIX/386 and
AIX/370 as Ron points out were one code base, one dev team (at LCC in
California).
Dan Cross said: "I had understood was that AIX/370 was actually OSF/1
based"
It maybe that by the end, the user space was based on the OSF/1 user space
code. That was true for HP and DEC also. But I can definitely state
AIX/370 and AIX/386 were one set of source trees and all of was done by
Locus Computing Corporation certainly through the mid 1990s.
Clem
2817
days inactive
2822
days old
24 comments
17 participants
participants (17)
-
Al Kossow -
Arno Griffioen -
arnold＠skeeve.com -
Brantley Coile -
Charles Anthony -
Clem Cole -
Dan Cross -
Dave Horsfall -
Gregg Levine -
Jason Stevens -
jsteve＠superglobalmegacorp.com
-
Larry McVoy -
Nemo -
Ronald Natalie -
schily＠schily.net -
Steve Nickolas -
Tim Bradshaw