HECnet

hecnet@lists.dfupdate.se

15586 discussions

Ultrix support for Tops-10/Tops-20 NRT!!

by Thomas DeBellis

After I put the changes into Tops-20 Kermit to recognize Ultrix and properly check protocol, I finally got around to testing it against few hosts on HECnet. As I had dimly recalled from the late 1980's, Ultrix supports Tops-10/Tops-20 NRT, viz: Kermit-20>c nofar/st [Remote system *NOFAR*:: is running _ULTRIX-32_] [KERMIT-20: Connecting to DECnet node NOFAR::] and also: Kermit-20>c ostara/stay [Remote system *OSTARA*:: is running _ULTRIX-32_] [KERMIT-20: Connecting to DECnet node OSTARA::] Sure made my day! When I finish wringing some more bugs out of Kermit-20 (I'm redoing the parity routines to use string instructions), I'll see about testing against Ultrix in addition to Tops-10 and older versions of Tops-20 Kermit (I've got them going back to the 1980's) SETHOST currently cannot connect to these hosts as it reports incorrect configuration messages. That's probably an easy enough fix.

3 years, 2 months

HOWTO for VAX/VMS DECnet-Plus open_simh HDLC support and P.S.I.

by Trevor Warwick

I recently added HDLC framing support to the DUP11 and DPV11 devices in open_simh. This has only so far been tested with DECnet-Plus on VMS. I wrote up another couple of examples, showing how to use HDLC as a DECnet datalink, and also how to try a basic configuration of VAX P.S.I. for X.25 communication. They're here: https://notlikethatlikethis.blogspot.com/

3 years, 2 months

pyDECnet --daemon option?

by Robert Armstrong

Paul (or anybody) - has the -daemon (aka "-d") option been removed from pyDECnet v596? It's still listed in the doc files, but running it gives pydecnet: error: unrecognized arguments: --daemon Bob

3 years, 3 months

Linux NRT configuration message

by Thomas DeBellis

In my changes to Kermit-20 and SETHOST, I check the configuration byte to make sure that I'm communicating with either a Tops-10 or Tops-20 system. If it's not one of those, then I want to give a nifty, informative error message, such as: Kermit-20>connect APOLLO:: ?VMS type systems do not support Tops-10/20 NRT communications. Kermit-20>connect MIM:: ?RSX-11M type systems do not support Tops-10/20 NRT communications. Kermit-20>connect TRON:: ?RSTS/E type systems do not support Tops-10/20 NRT communications. Pretty nifty. I do this by doing a lookup into a handy table, indexed by the OS type, viz: hsttyp: eascii <RSTS> ;^d0 eascii <RT-11> ;^d1 eascii <RSTS/E> ;^d2 eascii <RSX-11S> ;^d3 eascii <RSX-11M> ;^d4 eascii <RSX-11D> ;^d5 eascii <IAS> ;^d6 eascii <VMS> ;^d7 eascii <TOPS-20> ;^d8 (TOPS20) eascii <TOPS-10> ;^d9 (TOPS10) eascii <RTS-8> ;^d10 eascii <OS-8> ;^d11 (!!) eascii <RSX-11M+> ;^d12 eascii <MCB> ;^d13 (the DN20!!) hsttyn=.-hsttyp-1 ; Number of defined operating system types So if the number I get is outside of this range, I give an unknown error, such as: Kermit-20>connect ZITI:: ?Remote system sent an illegal configuration message ZITI:: shows as a Linux system. Does anyone know what its configuration byte would be? How about Windows? Ultrix? Any others? I don't recall whether we used NRT or CTERM to get into our Ultrix machine (it was an 8650, consequently upgraded to an 8700). I think we used TCP/IP TELNET.

3 years, 3 months

issues with stupi's email gateway...

by Mark Abene

Hey Johnny, I recently installed DECmail-11 on RSTS the other evening, and I'm noticing some undesirable behavior with the mim.stupi.net email gateway going out from inside HECnet. Firstly, it's worth mentioning that gmail won't accept a recipient address with colons in it, unless you put double quotes around it. For example: MARDUK::PHIBER@mim.stupi.net ...won't be accepted as a recipient, and the message is immediately red-flagged in gmail. However, if you do the following: "MARDUK::PHIBER"@mim.stupi.net ...gmail accepts and delivers it, MIM relays it correctly, and I receive the email in RSTS. Nice. Unfortunately, the reverse is failing. If I respond or send mail out from DECmail, mim.stupi.net's sender address rules reject the message: This is Postmaster <MIM::POSTMASTER> at MIM::. I'm sorry, but I could not deliver your mail. An error occured while trying to send it, and I cannot recover. Orignal recipient was "PHIBER(a)PHIBER.COM" Actual error is: Fatal address error. Additional information: 5.1.7 The sender address <MARDUK::PHIBER@mim.stupi.net> is not a valid 5.1.7 RFC-5321 address. h19-20020a05651c125300b0025e725ef592si33185ljh.300 - gsm tp Please let us know if you can correct the sender address restrictions on mim. I tried with quotes, but that didn't help either. :) Thanks, Mark

3 years, 4 months

Fwd: DECnet to be dropped from Linux

by John H. Reinhardt

Possibly already known, but just in case... -------- Forwarded Message -------- Subject: [cctalk] DECnet to be dropped from Linux Date: Tue, 2 Aug 2022 12:39:21 +0200 From: Liam Proven via cctalk <cctalk(a)classiccmp.org> Reply-To: General Discussion: On-Topic and Off-Topic Posts <cctalk(a)classiccmp.org> To: General Discussion: On-Topic and Off-Topic Posts <cctalk(a)classiccmp.org> https://www.phoronix.com/news/Linux-DECnet-2022-Removal https://lore.kernel.org/lkml/20220731190646.97039-1-stephen@networkplumber.… -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053

3 years, 4 months

Re: DECNET-Plus and X.500

by Mark Abene

Hi Jordi, I've been using your BITXOZ as my DECdns HECNET nodename resolution server for OpenVMS for at least eight years (since you put it up), but it seems that area 7 went offline fairly recently. Is everything ok? Regards, -Mark On Sat, Apr 26, 2014 at 2:56 PM Jordi Guillaumes i Pons < jg(a)jordi.guillaumes.name> wrote: > Hello, > > I'm playing again a little bit with DECNET/OSI. Does anybody have the X500 > directory server install kit at hand? The PAKs are included in the hobbyist > set, but the CSD I have is the 1992 one so I guess there has to be a more > recent one (for VAX, by the way). The DECDns stuff changed from 6.X to 7.X > so I'm pretty sure the version I have in my CDs won't work. > > By the way, BITXOZ is configured as a DECDns server, and "owns" the > HECNET: namespace. All HECNET nodes are loaded in the form HECNET:.NAME. I > toyed previously with a schema like HECNET:.AREAn.NAME but I have ditched > it. My internet domain (jguillaumes.dyndns.org or jordi.guillaumes.name) > has also opened the access to BITXOZ via rfc1006, so anyone with a > DECNET/OSI stack shoud be able to do a $SET HOST jguillaumes.dyndns.org > or a $DIR/APP=FTAM jguillaumes.dyndns.org:: and access that system even > without a working HECNET link. > > Jordi Guillaumes i Pons > jg(a)jordi.guillaumes.name > HECnet: BITXOV::JGUILLAUMES > > > > >

3 years, 4 months

DEC 8646 Four-Bit Tristate Backplane Interconnect.

by Peter Lothberg

DEC 8646 Four-Bit Tristate Backplane Interconnect chip... Anyone knew where I could find some? -Peter

3 years, 5 months

HOWTO for VAX/VMS DECnet-Plus (aka Phase V) synchronous devices with open-simh

by Trevor Warwick

I mentioned here a few months ago that I'd got DECnet-VAX Phase V working under simh using the DUP11. In the meantime, I've fixed some simh DUP11 bugs and also added DPV11 support, all of which is available in the latest version of open-simh on github. In the unlikely event that anyone else wants to try this out, I've written a blog post that I hope contains all the relevant information: https://notlikethatlikethis.blogspot.com/2022/06/decnet-vax-phase-v-wan-con…

3 years, 5 months

Announcing the Open SIMH project

by Paul Koning

Announcing the Open SIMH project SIMH is a framework and family of computer simulators, initiated by Bob Supnik and continued with contributions (large and small) from many others, with the primary goal of enabling the preservation of knowledge contained in, and providing the ability to execute/experience, old/historic software via simulation of the hardware on which it ran. This goal has been successfully achieved and has for these years created a diverse community of users and developers. This has mapped to some core operational principles: First, preserve the ability to run old/historically significant software. This means functionally accurate, sometimes bug-compatible, but not cycle-accurate, simulation. Second, make it reasonably easy to add new simulators for other hardware while leveraging common functions between the simulators. Third, exploit the software nature of simulation and make SIMH convenient for debugging a simulated system, by adding non-historical features to the environment. Fourth, make it convenient for users to explore old system environments, with as close to historical interfaces, by mapping them to new features that modern host operating systems provide. Fifth, be inclusive of people and new technology. It's serious work, but it should be fun. Previously, we unfortunately never spent the time to codify how we would deliver on these concepts. Rather, we have relied on an informal use of traditional free and open-source principles. Recently a situation has arisen that compromises some of these principles and thus the entire status of the project, creating consternation among many users and contributors. For this reason, a number of us have stepped up to create a new organizational structure, which we call "The Open SIMH Project", to be the keeper and provide formal governance for the SIMH ecosystem going forward. While details of the structure and how it operates are likely to be refined over time, what will not change is our commitment to maintaining SIMH as a free and open-source project, licensed under an MIT-style license as shown on the "simh" repository page. It is our desire that all of the past users and contributors will come to recognize that the new organizational structure is in the best interests of the community at large and that they will join us in it. However, this iproject as defined, is where we intend to contribute our expertise and time going forward. At this point, we have in place the following, although we foresee other resources being added in the future as we identify the need and execute against them: A Github "organization" for the project at https://github.com/open-simh A Git repository for the simulators themselves at https://github.com/open-simh/simh The license for the SIMH simulator code base, found in LICENSE.txt in the top level of the "simh" repository. The "SIMH related tools" in https://github.com/open-simh/simtools. This is also licensed under MIT style or BSD style open source licenses (which are comparable apart from some minor wording differences). A "SIMH Steering Group" -- project maintainers and guides. The conventional git style process is used for code contributions, via pull request to the project repository. The Steering Group members have approval authority; this list is likely to change and grow over time. By formalizing the underlying structure, our operational principles and guidance can best benefit the community. These are being developed and formalized, with a plan to publish them soon. We have used our best judgment in setting up this structure but are open to discussion and consideration of other ideas, and to making improvements. Many of us have been part of different projects and understand that past mistakes are real. We have tried to learn from these experiences and apply the collected wisdom appropriately. We desire to hear from the community as we update and refine the operating structure for the Open SIMH project. We hope for your patience and look forward to your support as we work to refine the organization and be able to provide this wonderful resource for anyone to use as we continue to evolve the technology provided by the SIMH system. The SIMH Steering Group Clem Cole Richard Cornwell Paul Koning Timothe Litt Seth Morabito Bob Supnik

3 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet