On Sep 7, 2018, at 10:43 AM, Zane Healy <healyzh at
avanthar.com> wrote:
On Sep 6, 2018, at 4:47 PM, Jeffrey H. Johnson
<jhj at trnsz.com> wrote:
On Sep 6, 2018, at 4:41 PM, Zane Healy
<healyzh at avanthar.com> wrote:
Very cool! I just got my Multics system up and running this last Sunday. I was a
systems analyst on DPS-8 mainframes running GCOS-8 from ?90-93. I?ve come to the
conclusion that not only is that knowledge all evaporated from my head, it also wouldn?t
really help with Multics. :-)
Oh no, a stinkin' GCOS user! Just kidding, of course. While we aren't running the
GCOS Daemon for batch/absentee GCOS processes (mainly because nobody has asked!), gtss,
the interactive GCOS TSS simulator does work, if you happen to have any GCOS tasks
you'd like to run.
I?ve gotten into the GCOS TSS simulator on my Multics system, but that?s about the
extent.
I've used it to run the Honeywell Algol system. I believe the MAP355 assembler used to
build the FNP images also uses the GCOS subsystem.
How on earth did you manage to hook Multics up to
HECnet?
It's a hugely abusive hack [snip]
I vaguely remember taking a course on, I believe the DataNet-8000 (we had DataNet-8?s).
In my mind, the FNP's were part of what made a DPS-8 an impressive system. I?m not
convinced that how you?ve achieved this is the wrong way to go, quite the opposite.
Yes, the distributed architecture of the DPS-8 system indeed makes it "easy" to
connect to additional networks and extend the system capabilities.
Yes, I took this approach after reading all the documents and implementing things in a way
I felt was appropriate to the design of the system, but it still feels 'wrong'
that much of the FNP operating system (and DECnet stack) is executing on a
'modern' CPU using modern C and is not running the original FNP code, but a
reimplementation of that code - at least for now.
There is the utmost respect for the sanctity of the original system and the original
hardware, with pains taken to not do anything to the Multics system would prevent it from
running on the original hardware, and it just seems historically inappropriate to have to
wire a Raspberry Pi (or worse, a PC) to the FNP.
In other cases
there is Multics software which is essentially 'extinct' but various descendants
still exist, so we are working on backporting/crossporting the existing software versions
back to Multics - this includes programming languages like XPL and SNOBOL, software
packages like REDUCE, MACSYMA, OMNITAB, TeX, etc.
Any sign of the Ada compiler? Though I gather it was a pretty poor imitation. One thing
I want to do is find my K&R C book, and see how the C compiler handles things. I was
working on learning C when I first started working at the DPS-8 installation I was at, and
the C Compiler we had was atrocious to put it kindly.
No Ada compiler that we've found yet, sadly.
Saying that the C compiler is atrocious is also extremely kind. I've used it
extensively and wouldn't recommend that to anyone. One of the more exciting things
that it does, other than give generic "syntax errors" is giving seemingly
random, and sometimes negative line numbers for error output.
I have a version of unproto 5 (somewhat modified) to help with porting ANSI C, but the
assistance it provides is minimal - porting existing software is very difficult due to
differences - no "short" types or "long long" types, 36-bit ints and
72-bit longs but no 18-but types, a NUL != 0, 9-bit chars, limitations on array sizes,
inability to return structs from functions, no built-in access to different segment types
like MSFs, etc. On the other hand, there are some extensions beyond basic K&R such as
structure assignment.
There is some work being done to port a new ANSI C compiler.
On Multics, PL1 and FORTRAN are the languages with real first-class support.
--
Jeffrey H. Johnson
jhj at
trnsz.com
https://ban.ai/multics