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
>
>
>
>
>
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…
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
Hi all,
Is there way to have PDR accept arbitrary TCP Multinet connections?
This works:
circuit mul-123 Multinet 207.123.123.123:15001:listen --cost 8 --t3 120
While this does not:
circuit mul-123 Multinet 0.0.0.0:15001:listen --cost 8 --t3 120
I'm sure I've had it working before..
Problem is, that remote 207 address is dynamic.
Cheers,
iain
I've got some proposed changes to the DUP11 simulation code in simh, that
could do with a quick regression test to make sure they don't break when
using RSX as the OS.
I don't know RSX myself, and I haven't managed to turn up any useful info
via google on how to configure a DUP11 with RSX. If anyone has a fairly
simple recipe for getting this working then I could have a go at testing
it.
However, the test required is pretty simple, basically just to confirm that
DECnet still works when using a version of simh that contains my fix. So
ideally, if one of you out there is running this configuration, we could
work together to try it out.
Thanks,
Trevor
For some reasons that I'll get into at some other time, putting a
timeout into BOOT didn't work to get me a crash dump.
So I looked at things the other way around to see what I could do to get
dvdte.c to fool the PDP-10 code that the master front end had rebooted,
which I have been meaning to do for some ten years now. After some
trial and error, I finally got something that worked, viz:
   /* Ten forcing a reload? */
   if (op10m_tlnn(w, (DTE_CMT_L11))) {
     char *fet = NULL;        /* Front end type not known, yet */
     if (dt->dt_ismaster)     /* Is this the master? */
       fet = "master";        /* Yes, remark on that */
     else fet = "restricted"; /* Oh dear... Restricted DTE
performance is unknown */
     fprintf(dt->dt_dv.dv_dbf, /* Finally blat about it */
             "[DTE: PDP-10 forcing a reload on FE%d (%s)]\r\n",
             dt->dt_dten,fet); /* N.B., we have *NO* code for MCB
or DN60 */
       dt->dt_reld11 = -1;    /* Set the reload-11 button */
       dt->dt_rcv_11qc = 0;   /* Reset queue count; we've
rebooted! */
       dt->dt_secptcl = TRUE; /* Force secondary protocol */
       return;                /* Return, caller will invoke
dte_dosecp() */
   }
This will let an unaltered BOOT get you a crash dump, viz:
BOOT V11.0(315)
BOOT>dump.exe/d
[BOOT: Dumping] [OK]
 Number of pages written: 17734
 Number of I/O requests: 203
BOOT>meamon
[BOOT: Loading] [OK]
After Tops-20 gets itself going,
 DDMP: Started
Copying system dump
   from: TOMMYT:<SYSTEM>DUMP.EXE.1
   to: TOMMYT:<SYSTEM>DUMP-21745-ILLUUO.CPY.1
[Copied dump to TOMMYT:<SYSTEM>DUMP-21745-ILLUUO.CPY.1]
I haven't seen messages like this since about 1985, so it was kind of
eerie watching all this low level code just...working. I have not
tested the dvdte.c modification to see if it will prevent a DTEKPA
BUGINF from hanging everything, but I believe it should.
Maybe I'll check that after I fix what caused the crash in the first
place. So I'm looking at the ILLUUO crash dump and it seems that all my
fine code got smashed by the symbol table... Phooey.
Hi,
Due to a combination of things, I'm going to need to take down my
area 23 hecnet router, probably for a 3-6 months.
Near term, I'm short on hobby time, need to do some significant network
reconfiguration, and need to put back together one or several decnet
worthy systems, after some rather frustrating hardware failures.
Ideally, I should have more time late summer or fall, once my kid is in
school and some other pressures let up.
I'm not going anywhere, and appreciate the groupmembers here who have
been so helpful over the years about so many DEC and non-DEC things.
My current peers are as follows, though some of them are currently down.
interface Tunnel50
description HECnet tunnel for Brian Hechinger (Area 52) [Version:311]
interface Tunnel51
description HECnet tunnel for Ian McLaughlin (Area 42) [Version:311]
interface Tunnel52
description HECnet tunnel for Cory Smelosky (Area 9) [Version:311]
interface Tunnel53
description HECnet tunnel for Dave McGuire (Area 61) [Version:311]
interface Tunnel54
description HECnet tunnel for Supratim Sanyal (Area 31) [Version:311]
interface Tunnel57
description HECnet tunnel for Tim Sneddon (Area 12) [Version:311]
interface Tunnel58
description HECnet tunnel for Mark Darvill (Area 22) [Version:311]
interface Tunnel1098
description tunnel to Peter Lothberg <roll(a)Stupi.SE> (STORTR 59.61)
interface Tunnel1099
description tunnel to Peter Lothberg <roll(a)Stupi.SE> (IAD2 59.1020)
Mark
--
Mark G. Thomas <Mark(a)Misty.com>, KC3DRE