HECnet

hecnet@lists.dfupdate.se

6 participants
15552 discussions

KINET by KI Research - DECnet for numerous Unix flavors and OS/2?

by supratim＠riseup.net

Once upon a time there seems to have been a company called KI Research at Columbia, Maryland. Circa 1994 they had for sale something called KINET DNA which apparently was a user-mode DECnet stack available for numerous Unix flavors and OS/2 (maybe more operating systems). I came across the name looking for a DECnet implementation for HP-UX. Here's one of the threads from 1993 (!) that I am looking at: http://www.verycomputer.com/30_4d016ca71ca3072b_1.htm Does anyone here have pointers to some archive which might have distributions of KINET? Thanks Supratim

2 years, 10 months

Announcing TCP/IP V2.9 for RSX-11M-PLUS

by bqt＠softjar.se

Time for a new release announcement of TCP/IP for RSX-11M-PLUS. This is version 2.9 of BQTCP/IP. It's been three weeks since the last official update, which is rather short. But there are two significant things that been solved since the last release, which is motivation for a release so shortly after the previous one. Highlights: . Bugfix in name resolved that could cause system crashes under some conditions. . Improvements to DECnet performance. Detailed information on things that have been done since the last release: TCP: . Improved the handling when both sides sends FIN at the same time. DNS: . Bugfix in resolver. Under the wrong conditions, the system could crash. It was a combination of failing DNS, short timeouts on the query itself, and a race condition in the code in this case. So the chances of hitting it were extremely low, but it can happen. MAIL: . Improve handling of hosts with no reverse dns, or giving fake information or trying to do weird commands. Such hosts are not blocked anymore, but are tracked, and only mails to postmaster from such hosts are accepted (this is more in accordance with the relevant RFCs). . Added postmaster sending a warning mail when mail delivery isn't immediately successful, to make people aware that there might be problems. . Improved mail queue processing, making the mail queue not be locked for longer periods. TELNETD: . Improved connection tracking. FTPD: . Add logging of whether transfers completed successfully or not in logs. IPC library: . Bugfix. The _notify() function didn't work right. RSX: . Added patched ECL module for DECnet to improve performance. Some additional notes: As usual, I would recommend people to update as soon as possible. The changes are not critical, but will lead to a much better experience, and might avoid system crashes in rare circumstances. The patches to the TT: driver cannot be applied automatically, but requires users to apply the patches themselves, and then run SYSGEN to generate a new system. Once added, the TNC2 task can be run at login, and will define logical names for the user telling where he is connected from, if using telnet. The TT: driver patches also allows the updated MCR to give more information with the DEV command (SHOW TERMINAL in DCL). The other patches to RSX can be applied automatically by IPGEN, either if used interactively when answering YES to the question about applying RSX patches, or by running IPGEN explicitly to do the patches, with the command: @IPGEN PATCH Specific information about the patches: LAT: Fixes a memory leak, and adds the ability to read where a terminal connection comes from when using LAT, using SF.GMC. RMSDAP: Fixes a bug in getting the file protection, so the XAB gets filled in correctly for remote files. RMSDSP: Fixes that some numbers were displayed in signed octal, which should have been displayed in decimal or unsigned octal, depending on number. DCL: Added terminal attributes for COLOR. MCR: Too many fixes to be listed here... ECL: If the receiving machine is very slow, and the sending machine is very fast, and the receiver announce several large buffers available, ECL cannot keep up, but drops packets. This is sortof a problem with the DECnet flow control, as it is used in RSX. The simple solution is to allow more outstanding buffers when receiving. A more complex solution would be to change how RSX DECnet do flow control, but that would require rewriting a fair chunk of the ECL module. As usual, the distribution is available from: ftp://mim.update.uu.se/bqtcp.dsk ftp://mim.update.uu.se/bqtcp.tap !!! BQTCP is also available through RPM !!! (As an additional note, if there are any problems communicating with Mim using port 21, the ftp service is also available at port 10021) The documentation is also available through ftp on Mim, or also at http://mim.update.uu.se/tcpipdoc I hope people find this update useful. On a final note, Mim have moved. Mim.Update.UU.SE still points to the machine, but the actual name is now Mim.Stupi.NET, and in case Update.UU.SE cease to work at some point, Stupi.NET should still be fine. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

2 years, 10 months

DDCMP sync line support now in SIMH

by paulkoning＠comcast.net

With help from Mark Pizzolato, I added support to SIMH for my DDCMP sync line interface ("DDCMP framer"). This is a USB device, built around a Raspberry Pico, that implements the lower layers of the DDCMP synchronous line protocol. It allows SIMH (or PyDECnet) to talk to real machines that use those interfaces. My ability to test with real hardware is limited; in particular I don't have any coax cable ("integral modem") devices like the DMC-11/AL. But I did test RS232 mode with my Pro 380. The current SIMH on Github includes the necessary code and documentation to allow the use of this device as an emulated DUP, KMC-DUP, or DMC. The current PyDECnet (on my Subversion server) also supports it, and the two will interoperate as you would expect. The design for the device is open source, it can be found on github: https://github.com/pkoning2/ddcmp . At the moment if you want one of these you'll have to build it; I provide the design files but not boards or devices, and I don't plan to. But of course since it's open others may do so if they wish. I'd be very interested in test results of the coax interface since I could only test that against the device itself and against the documentation. paul

2 years, 10 months

Area weirdness on HECnet

by Keith.Halewood＠pitbulluk.org

Hi, Just noticed: ncp tell a1rtr show known circ stat The above shows a circuit ETH-10 adjacent to node 5.1023. It looks like none of the area routers I've looked at actually see the area, ie: a29rt2, a1rtr, python. Needless to say that 5.* is unreachable from my point of view. FYI Keith

2 years, 10 months

So…..

by Keith.Halewood＠pitbulluk.org

So, [Happy new year by the way,] How much of the HECnet just went dark? K

2 years, 10 months

SIMH TOPS-20 question --> recipe for handling Tops20 install tapes --> MTBOOT --> create new PS: structure

by R.Voorhorst＠swabhawat.com

Actually, come to think about it you should be able to create a new PS in 2 phases: 1. boot tape and create a pristine PS: up to and including DLUSER stuff; see installation manual posted earlier. 2. boot another monitor, mount the pristine PS as another structure on it; skip the tape 7 files and use monitor dumper to restore the savesets on the pristine structure. Point to check is if a bootstrap is written to the pristine structure but the installation manual will make that clear. If I have some time I will checkthe problem out if the tape has a problem or not and how to create a structure from it; meanwhile you still cann retrieve files which was your primary requirement I believe. Reindert -----Original Message----- From: Paul Koning [mailto:paulkoning at comcast.net] Sent: Saturday, 25 December, 2021 22:24 To: Reindert Voorhorst <R.Voorhorst at swabhawat.com> Cc: <hecnet at update.uu.se> <hecnet at Update.UU.SE> Subject: Re: [HECnet] SIMH TOPS-20 question --> recipe for handling Tops20 install tapes --> MTBOOT > On Dec 25, 2021, at 3:21 PM, R. Voorhorst <R.Voorhorst at swabhawat.com> wrote: > > I do not see that problem and I posted it here somewhat earlier: > > Swbx04> att -f tu0 simh > Swbx04> g:\temp\bb-d867e-bm_tops20_v41_2020_instl.tap-1 > Swbx04> b tu0 > > And on console: > > MTBOOT> > > The first must be MTBOOT else you cannot load de monitor with /L and ?G143, so no skipping filemarks are needed as the monitor is the first file. > Mark well, it is format simh=tps! So it is, interesting. What's strange is that -f tpc reports success, while -f simh reports an error: After processing 1159680 bytes of tape data (453 records, 5 tapemarks) Read Tape Record Returned Unexpected Status: invalid record length 19827814 bytes of unexamined data remain in the tape image file but indeed in this format I can boot the tape. paul

2 years, 10 months

PSTHRU.EXE poor-man routing object 123 for VMS on VAX

by gerry77＠mail.com

After many months I was able to access again some VAX system where I had stored some interesting bits, and among them the VAX version of PSTHRU.EXE, i.e. the DECnet poor-man routing object for VMS. I do not remember at all where I found it in the first place, and it is nowhere to be found online (there is a namesake file for TOPS-10 though). I could send it to whoever wants it or, if I'm allowed, I could just send it to the mailing list: it's a tiny 6 kB ZIP file with a BACKUP saveset inside. The saveset contains the executable image, its related DCL procedure, and a text file that lists the NCP commands to activate it. The object could generate some optional debug log and apparently (looking at the dump of the executable image) could access some PSTHRU.DAT I don't have any clue about. Also, I wonder if it could be VESTed. It would be nice if it could end up in some repository, at least to avoid losing it again... Let me know, :) G.

2 years, 11 months

PSTHRU.EXE poor-man routing object 123 for VMS on VAX -->Tops10

by R.Voorhorst＠swabhawat.com

The PMR/PSTHRU is on the Trailing Edge Pdp10 archive: TOPS-10 Tools BB-FP64B-SB in Saveset TOPS10 Unsupported Tools in directory: 163 103770(7) <455> 10,773 6-Jul-87 dskb:[10,7,psthru]psthru.mac 36 22550(7) <455> 10,773 12-Jul-83 dskb:[10,7,psthru]psthru.plm 40 5120(36) <455> 10,773 1-Sep-88 dskb:[10,7,psthru]psthru.exe 39 24570(7) <455> 10,773 24-Feb-84 dskb:[10,7,psthru]pmr.mac Reindert -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul Koning Sent: Monday, 27 December, 2021 19:42 To: hecnet at update.uu.se Subject: Re: [HECnet] PSTHRU.EXE poor-man routing object 123 for VMS on VAX > On Dec 26, 2021, at 6:04 PM, Thomas DeBellis <tommytimesharing at gmail.com> wrote: > > ... > Could you elaborate on what 'poor man' routing means, just so I'm sure I have the correct context? I know that this term existed for 20's route NRT sessions. It doesn't exist for CTERM. I don't think I remember seeing it for DAP/FAL/NFT. "Poor man's routing" as it appears in DECnet means a way to communicate with nodes that are unreachable by the primary protocol mechanisms. It works by making the user specify an explicit path to the destination (shades of uucp mail). For example, mail might be addressed to VAX4::STAR::Goldstein, i.e., the recipient was on node STAR but to get there I'd have to use VAX4 as an intermediate point. In Phase II, PMR would be used to reach destinations more than one hop away. With a mix of Phase III and IV, the Phase III nodes would need PMR to reach out of area destinations. And when "hidden areas" were used to deal with topologies that needed more than 63 areas -- such as DEC's internal network -- PMR would be used to get into or out of a hidden area. PMR the concept might be implemented in a number of different ways. Some applications, like MAIL, would provide it as part of the application. File transfer (DAP protocol) would offer it as a side effect of VMS transparent network access. And some applications, I think the old network terminal protocols might be an example, would rely on a separate application layer forwarder program. That would be PMR or PSTHRU, object 123. PMR as a separate program might originate on TOPS-10 since it has a program by that name that also provides the equivalent service on ANF-10. Someone posted the source of that recently (a year ago or so, perhaps). I don't remember ever seeing a protocol spec for the PMR protocol. Since I have the RSTS source code (it's a program PMR.BAS, in Basic-PLUS) I can reverse engineer such a spec, that's on my "soon" list. I don't remember if PMR was included with the DECnet kit. It's a pretty small and simple program. paul

2 years, 11 months

Announcing TCP/IP V2.8 for RSX-11M-PLUS

by bqt＠softjar.se

Time for a new release announcement of TCP/IP for RSX-11M-PLUS. This is version 2.8 of BQTCP/IP. It's been four months since the last official update, and there been various smaller improvements. Highlights: . Several smaller issues have been fixed which could cause crashes under certain circumstances. . Improvements in ICMP error handling. . Performance improvements in TCP, telnetd and Multinet. . Improved behavior in the DNS resolver. . Improved handling of many things in MAIL. . More patches for issues in RSX and LAT. Detailed information on things that have been done since the last release: TCP: . Bugfix. In some special circumstances, TCP could crash out with an odd address trap when doing an IO.REJ. . Fixed TCP handling at close, which could sometimes cause a spurios retransmit. . Fixed TCP behavior at large packet loss, which could lead to very bad performance. We now reset the delayed ACK handling when we get to a delayed transmit. . In Time wait state in TCP, a probe caused RST. It should be ignored. . Improved window update handling in TCP when we have lost packets. ICMP: . Improved ICMP time exceeded error handling. Also affected PING and TRACERT. . Improved ICMP error return value for destination unreachable to have IE.NRJ with subcode in high byte. Second word of IOSB now contain possible additional information. Also affected PING. . Bugfix. ICMP error generation could corrupt the IP pool in some circumstances. . ICMP errors returned for destination unreachable failed to include the correct subcode. DNS: . Improved resolver to ignore leading spaces in hostnames. . Improved name resolver to have more randomness in returning a random result to a name lookup with multiple answers. MAIL: . Changed mail back to using MAILDN for new mail delivery. . Improved MAILD. Refuse connections from hosts with no reverse DNS, or who claim to be someone else at EHLO/HELO. . Fixed maild. If outgoing mail have format=flowed, the mail was missing an extra space on lines starting with space. . Added mail blocking based on from address. . Improved MAILD memory usage. . Improved MAILRD handling of LAST keyword. . Improved MAILRD handling of reading current/next/previous mail. . Improved MAIL11 address rewriting in MAILD. HTTPD: . Bugfix in HTTPD. CGI execution could cause a spurious error. RSX: . Added patched LAT, DCL, RMSDSP, RMSDAP . Changed TT: driver patch. Updated MCR. Some additional notes: As usual, I would recommend people to update as soon as possible. The changes are not critical, but will lead to a much better experience. The patches to the TT: driver cannot be applied automatically, but requires users to apply the patches themselves, and then run SYSGEN to generate a new system. Once added, the TNC2 task can be run at login, and will define logical names for the user telling where he is connected from, if using telnet. The TT: driver patches also allows the updated MCR to give more information with the DEV command (SHOW TERMINAL in DCL). The other patches to RSX can be applied automatically by IPGEN, either if used interactively when answering YES to the question about applying RSX patches, or by running IPGEN explicitly to do the patches, with the command: @IPGEN PATCH Specific information about the patches: LAT: Fixes a memory leak, and adds the ability to read where a terminal connection comes from when using LAT, using SF.GMC. RMSDAP: Fixes a bug in getting the file protection, so the XAB gets filled in correctly for remote files. RMSDSP: Fixes that some numbers were displayed in signed octal, which should have been displayed in decimal or unsigned octal, depending on number. DCL: Added terminal attributes for COLOR. MCR: Too many fixes to be listed here... As usual, the distribution is available from: ftp://mim.update.uu.se/bqtcp.dsk ftp://mim.update.uu.se/bqtcp.tap !!! BQTCP is also available through RPM !!! (As an additional note, if there are any problems communicating with Mim using port 21, the ftp service is also available at port 10021) The documentation is also available through ftp on Mim, or also at http://mim.update.uu.se/tcpipdoc I hope people find this update useful. On a final note, Mim have moved. Mim.Update.UU.SE still points to the machine, but the actual name is now Mim.Stupi.NET, and in case Update.UU.SE cease to work at some point, Stupi.NET should still be fine. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

2 years, 11 months

SIMH TOPS-20 question --> recipe for handling Tops20 install tapes --> MTBOOT

by R.Voorhorst＠swabhawat.com

I do not see that problem and I posted it here somewhat earlier: Swbx04> att -f tu0 simh g:\temp\bb-d867e-bm_tops20_v41_2020_instl.tap-1 Swbx04> b tu0 And on console: MTBOOT> The first must be MTBOOT else you cannot load de monitor with /L and ?G143, so no skipping filemarks are needed as the monitor is the first file. Mark well, it is format simh=tps! The tap-1 extension is because 7-Zip found another file .tap was already there (the old one). However I could not run dumper from the tape when trying it in install mode, so after DLUSER I got no further, but I did not test that any further for lack of need. Reindert From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Thomas DeBellis Sent: Saturday, 25 December, 2021 20:47 To: hecnet at Update.UU.SE Subject: Re: [HECnet] SIMH TOPS-20 question --> recipe for handling Tops20 install tapes Try skipping forwarding one or two file marks. There was some kind of stuff at the beginning of the tape that I didn't recognize. The monitor was after two file marks. So do a rewind then skip forward one file mark and maybe mtboot will be there. On 12/25/21 2:20 PM, Paul Koning wrote: On Dec 25, 2021, at 5:29 AM, R. Voorhorst <R.Voorhorst at swabhawat.com <mailto:R.Voorhorst at swabhawat.com> > wrote: I think Paul cannot get these files loaded on his Tops20 V4.1 system from hecnet, being barred by lacking decnet and/or Kermit functionality. In the end (!) the tape recipe works as follows: Get a FRESH copy of tape BB-D867E-BM_TOPS20_V41_2020_INSTL.TAP-1 (after unzip) from Pdp10 archive into a host directory. In simh when the monitor Tops20 V4.1 has been fired up or before: ATT ?F TU0 SIMH G:\TEMP\BB-D867E-BM_TOPS20_V41_2020_INSTL.TAP-1 or your favorite location I found that SIMH is happy attaching it with -f tpc -- previously I had misread the messages printed by that command and thought it had an error. So according to the installation manual, that tape is the "install" tape and is supposed to be bootable. But if I mount it and issue "boot tu0", nothing happens. When I stop simh it tells me PC is 0. paul

2 years, 11 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet