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. We also have the DTSS simulator available (which I believe is also working in mainline). Login with the control arguments "-po >unb>dfast_process_overseer_", example: "enter Guest -po >unb>dfast_process_overseer_" It's a hugely abusive hack. Since the DECnet for Linux code is written in C, and the FNP emulation is a C simulation of the FNP/MCS behavior, I've taken advantage of that to simulate a hardwired protocol converter. This also means that rather than having to (re-)implement much of the networking code in obscure MAP355/Level 6 assembly language, the off-loaded networking code which would run on the FNP can run essentially natively on the host. (The overall long-term goal, however, is eliminating host-based services and 'properly' emulating the Level 6 FNP at the instruction level.) We a use additional emulated hardware infrastructure such as emulated terminal servers to ease management, balance connections between FNPs, etc. While we have diverged somewhat from the mainline code, mainly to support our large configuration (8 FNPs, custom networking code, etc), extensive stress testing has exercised the code and located and fixed various bugs over the past 18 months. The most important fixes have been integrated back upstream in the master branch already, while a larger number of enhancements will be in the next release of the simulator. (... Next project is Chaosnet networking!) You are correct. And even some more that isn't yet publicly installed yet, but is running and will soon be made available. I've been something of professional harasser, contacting many Multics people and the past Multics sites trying to track down any leads on software (and hopefully backups) that may still exist, and finding what was run at each site. While successes are few and far between, I've recovered a surprising amount of software. In some cases software has been available from various collections, but was never integrated, compiled, and run on post-MR12 systems until now. Often this involves correcting many OCR errors or retyping listings from scans and microfilm. 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. Finally, we are also working to develop new Multics software and ports. We will be distributing the software and updates through a "package management" system via an online MIKSD (Multics Internet Kermit Service Daemon), which we hope to have available and running next year. The most important utilities and tools from the efforts are being integrated back upstream and will appear in future releases of the base Multics distribution, where appropriate. The BAN.AI system has sort of become the de facto "home base" for these efforts and I'm humbled and grateful to be able to work with so many people who I consider heroes of computer science. Some of the other unique network features that BAN offers besides HECnet access includes Internet email for registered users, and a Internet finger daemon. (finger @m.trnsz.com) Both an FTN (FIDO) and UUCP port is in progress (we hope to support UUHEC.net mail), and MAIL-11 is a certainly a possibility now too. We have rudimentary web and gopher service, but I'm waiting on the integration and completion of the socketdev code before putting more effort into it abusing MCS and the FNP. Other things being worked and in various stages of completion are X.25 networking and IBM 3270 terminal support. If we can complete the X.25 support, I envision creating a 'BAN X.25 PSDN', a virtual hobbyist Telenet/Tymnet-like PSN network for X.25 systems. There are other exciting Multics projects in progress by other parties as well. Feel free to review our system news (pmotd -a) to get an idea of what we've been working on! Thanks!

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. 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. 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

It's actually very easy to set up an entire X.25 network by tunneling over IP using emulated cisco routers on dynamips. I demonstrated this to another list member some years back. By the way, just a minor correction: while Telenet/Sprintnet was a native X.25 network, Tymnet was most certainly not. While the ISIS bus of a Tymnet Engine could be fitted with a wide variety of protocol interface cards (X.25 among them), Tymnet's own internal protocol was simply known as "Tymnet protocol", and was entirely its own thing. There were also a number of X.75 gateways accessible on Tymnet, many on satellite links, to allow users to connect to foreign X.25 networks. -Mark On Fri, Sep 7, 2018 at 8:32 AM, Fred <fcoffey at misernet.net> wrote:

On Fri, Sep 7, 2018 at 10:19 PM, Jeffrey H. Johnson <jhj at trnsz.com> wrote: That would be excellent! I was actually talk about these emulators with some friends of mine. I actually uploaded and compiled a FORTRAN version of adventure in a folder called PHIBER on the first emulated system. It's been there ever since. My emulated cisco 7000 is connected to HECnet 24/7, and I would definitely volunteer to network encapsulated X.25 with Wilcoxson if he was willing. It was Telenet. All their management systems were PR1MEs. Telenet (and later Sprint as owner) was also in the business of selling X.25 subnets, using their TP packet switches (TP 3006, TP 3325, and high-end TP 4000 series) to telcos, financial institutions, and foreign nations (to serve as the national PDN). All subnets typically came with one or two PR1MEs as network management systems. I have intimate first-hand knowledge of Tymnet's original public network (and many of its subnets). I was at one time extremely familiar with TYMCOM/X. That was Tymshare's customized version of TOPS-10 that they used for node code development and revision control, as well as documentation archive for all the network management and debugging facilities. The original Tymnet engines were based around the Interdata 7/32. There were some experimental "turbo engines" that were put into production based on the Motorola 68000, but they weren't nearly as popular. That coincided with the gradual phasing out of the original pdp10's running TYMCOM/X to the (at the time) much newer/faster Sun workstations and servers. The turbo node development was done on Sun 3's if I remember, with an Interdata cross assembler to handle the older node code. But you're probably more interested in TYMCOM/X... I heard that the Living Computer Museum in Seattle is trying to bootstrap TYMCOM/X? That would be awesome! Not sure if they have access to the necessary Tymnet node (engine) hardware needed to multiplex the terminals. All that stuff would have to talk the Tymnet II protocol (like I mentioned earlier, it isn't X.25). Regards, Mark

I ran across these pages a few months ago. I?m still in shock. Hopefully one day they are able to release a distro. BTW, LCM+L should have a decent collection of GCOS-8 doc?s, including doc?s on the DataNet-8000. Regrettably I gave them all my GCOS-8 materials (a large box) a few years ago, as I thought I?d never have any use for them again. At least they went up there. Everyone else that I?m still in contact with dumped theirs in the recycle 20+ years ago. :-( Zane

such a semantics PDUs Isn't X.25 is a network layer. Virtual Circuits span multiple HDLC links. Not sure if RFC1086 or RFC11356 are still relevant. reviving the Dave

X.25 is a bit of a mess. Mostly it's a datalink. If you squint you can think of it as a network layer protocol for endnodes only. X.25 doesn't appear inside the network; I vaguely remember references to "X.75" for that. It looks a lot like the data analog of conventional telephone networks: it describes the wire to the exchange, and how you dial phone calls and what phone numbers look like. paul

Do you mean the X.25 client packets, or the bits coming out the bottom of X.25? The former is straightforward so long as the clients send multiples of 8 bits. The bottom of X.25 is not quite so simple since HDLC is a bit stream datalink, not a byte stream like Ethernet or DDCMP. The analogs you could draw on: for the client side, that's like the "Simulated DMC" that appeared for a short while in SIMH 3.9 and can still be found in my PyDECnet. For the bottom of the datalink, the current DDCMP emulation in SIMH is a good model. I suppose you probably would not do bit stuffing. Not a multiple of 8 bits could still be handled if needed. paul

I don't have it available just yet - but I do plan to release it all eventually, and hopefully there will be no changes necessary in the FNP code by the time of the release. Charles Anthony has been extremely supportive of all the FNP changes, often rewriting my lame hacks into proper code and even implementing planned ideas before I even get a chance to get home and write a single line of code. I'm very grateful to be able to work with such talented and dedicate people. I hope to eventually take over the FNP code and relieve him of some burden. Eric Swenson, who manages the Multics release process, is equally dedicated, enthusiastic, and brilliant. Right now BAN is running on a fork of the V1.0 code, and the Multics system we run has various patches (all of which will be part of MR12.6g+) as well as a massive local effort of tuning and configuration differences from a "stock" cold booted system to support its unique configuration. The upcoming release of the simulation code has already diverged greatly from the V1.0 code and my forked code. Because everything is in such flux right now, I am often discouraged from starting large projects or making big changes (in a hackish way) I know all the work will need to be redone or reworked for a proper solution in the near future - however, everything is going upstream. I'll contact you directly once I have a cleaner setup so we can get some extra testing. -- Jeffrey H. Johnson jhj at trnsz.com https://ban.ai/multics