- HECnet - lists @ Update

by Wilm Boerhout

Hello friends, I will be moving house on June 20th. Therefore, I will be shutting down my HECnet-related infrastructure a few days before that date; I plan to connect them again a few days (or maybe a week) later. Also, my public IP address will change. “odsw48.mywire.org” will point to the new address, and for my incoming circuits that use the raw IPV4 address, you will have to take that into account. You know who you are 😊 It concerns the following nodes: 29.200 PIVAX0 29.201 PIVAX1 29.202 PIVAX2 29.203 PIVAX3 29.204 PIVAX4 29.205 PIRSTS 29.206 ONAPI4 29.207 VMS046 29.208 PIRTVX 29.209 PIVAXN 29.210 VSIAXP (*) 29.211 PCSAPI (*) 29.212 VAXM8 (*) 29.214 PIZRZV (*) 29.215 PIRSX9 29.221 SERIAL (*) currently not in use Thanks for your understanding, Wilm # supratim(a)riseup.net <mailto:supratim@riseup.net> # tomas(a)prybil.se <mailto:tomas@prybil.se> # bob(a)jfcl.com <mailto:bob@jfcl.com> # Keith.Halewood(a)pitbulluk.org <mailto:Keith.Halewood@pitbulluk.org> # johd(a)zeelandnet.nl <mailto:johd@zeelandnet.nl> # mark.curtis(a)aardvarks-and-platypus.com <mailto:mark.curtis@aardvarks-and-platypus.com> # bqt(a)softjar.se <mailto:bqt@softjar.se> # mark(a)theberrymans.com <mailto:mark@theberrymans.com> # mark(a)matlockfamily.com <mailto:mark@matlockfamily.com>

1 week, 6 days

4
6
0 0

Alternative location for Mim?

by Johnny Billquist

Ok. I can't seem to raise Peter, and this have been going on and been an issue long enough. Do anyone have some alternative location I could run Mim and Anke? Basically - it needs a a static, public IP address, no port blockings whatsoever, and some reasonable bandwidth. In addition, the machine needs to run Linux (a VM would do), its own ethernet interface, and me having access to the machine as root. Some valid reverse DNS for that address would be good as well, but I will probably move Mim to my own domain, so that the name can stay the same in the future if the machine moves around anymore. If anyone have such resources available, and willing to provide for the running of Mim (PDP-11 with RSX) and Anke (PyDECnet), then I'd be happy to move things over, and get things back to running properly. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

2 weeks, 3 days

4
3
0 0

Norman Lastovica - Understanding DECnet - Youtube Video

by Kyle Duren

VSI Channel on Youtube posted a presentation recording from Norman Lastovica (SCI) at the VMS Bootcamp on May 14, 2025. Video Link: https://youtu.be/_NFnhKV4VTw Slides Link: https://fossilfree.app.box.com/s/shz7426kjwojjtcqu4eyzt04z58512mr

2 weeks, 6 days

1
0
0 0

Re: DECserver 300 TCP/IP

by Madeline Autumn-Rose

I've been digging through a lot of documentation and forum posts that seem to indicate the DECserver 300 can do TCP/IP (including some Ask The Wizard posts. Anyone got pointers to which distribution set to track down this version? This post (https://forum.vcfed.org/index.php?threads/decserver-300-management-manual.6…) seems to indicate an older software dist provides that but I don't know which version supports that. -- Madeline Autumn-Rose http://gewt.net Personal stuff http://gimme-sympathy.org Projects

1 month, 1 week

4
5
0 0

Re: DECserver 300 TCP/IP

by Terri Kennedy

[I realized I sent this from a different email address than my list email, so it probably got rejected or held.] I had planned on holding this off longer, until it was fully complete, but https://www.glaver.org/DECserver is a treasure trove of information and firmware for almost all of the DECserver models. The firmware is split into DNAS (V3.3 being the newest version except for the DS700 which has V3.6) and Pre-DNAS directory trees. In particular, I think the firmware being requested can be found in: https://www.glaver.org/DECserver/Pre-DNAS%20DECserver%20Models%20and%20Firm… Comments on the future direction of this collection is welcome. -- Terri

1 month, 1 week

1
0
0 0

Re: [PiDP-11] What's the simplest way to play zork on the base install

by Johnny Billquist

For everyone - it's just that some places have been blocked by a router near Mim and Hecnet-1-1023. I'm trying to reach Peter to get it solved, but at the moment I can't offer much help. If people are on HECnet, they can usually reach Mim that way, and use RPM that way as well. Johnny On 2025-05-22 05:16, Jacob Ritorto wrote: > It's down for me from Western Pennsylvania Comcast, too. > Also my RSX-11M-PLUS machine's HECnet connection to Johnny's site is down. > > On Wed, 21 May 2025 at 22:38, Ggrinton <ggrinton(a)gmail.com > <mailto:ggrinton@gmail.com>> wrote: > > Johnny, I'm still getting timeouts on mim.stupi.net <http:// > mim.stupi.net> > Is there any update or am I doing something wrong? Thanks. > > > -- > You received this message because you are subscribed to the Google > Groups "[PiDP-11]" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to pidp-11+unsubscribe(a)googlegroups.com > <mailto:pidp-11+unsubscribe@googlegroups.com>. > To view this discussion visit https://groups.google.com/d/msgid/ > pidp-11/f882bdf4-53b4-4441-a6e1-ee7d1f77b6c2n%40googlegroups.com > <https://groups.google.com/d/msgid/pidp-11/f882bdf4-53b4-4441-a6e1- > ee7d1f77b6c2n%40googlegroups.com?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to the Google > Groups "[PiDP-11]" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to pidp-11+unsubscribe(a)googlegroups.com > <mailto:pidp-11+unsubscribe@googlegroups.com>. > To view this discussion visit https://groups.google.com/d/msgid/pidp-11/ > CAHYQbfBYN5wd7vhGt%2BT67jh_yQX1SMWoheW--HTTiqroSvio9A%40mail.gmail.com > <https://groups.google.com/d/msgid/pidp-11/ > CAHYQbfBYN5wd7vhGt%2BT67jh_yQX1SMWoheW--HTTiqroSvio9A%40mail.gmail.com? > utm_medium=email&utm_source=footer>. -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

1 month, 2 weeks

1
0
0 0

Subscribe

by Mark Wickens

Sent from my iPhone

3 months, 2 weeks

1
0
0 0

DECnet-Plus and Decnet Phase IV interoperability

by Peter Whisker

Hi Recently I cloned one of my MicroVAX 7.3 simh servers and removed DECnet phase IV from it (which works perfectly) and installed DECnet-Plus from the distribution. I set it up with the same details as for Phase IV and configured the same MAC and area/node - clearly I will not boot both at the same time! The simh setup is identical for both version of the server apart for my having increased memory from 128M to 256M to see if that helped (it didn't). It sort-of works, there is connectivity and adjacencies as I would expect but it is extremely slow. If I "set host" to another machine, or from another machine to it, it works extremely slowly, I see 3 second retries happening all the time. The command "SHOW NSP LOCAL NSAP <local_nsap> REMOTE NSAP * retransmitted pdus, duplicate pdus received" suggested here https://community.hpe.com/t5/operating-system-openvms/very-bad-performance-o ver-native-decnet/td-p/5000605 shows the retransmit count going up. The adjacencies are on ethernet LAN - has anyone got any experience of this problem which might suggest what is happening? Thanks Peter Peter R Whisker BA BAI CEng MIET Chartered Engineer - IT Technical Architect T: +44 1932 842536 M: +44 7870 171768 E: peter(a)whisker.org.uk

3 months, 2 weeks

8
18
0 0

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

by Johnny Billquist

Time for a new release announcement of TCP/IP for RSX-11M-PLUS. This is version 2.17 of BQTCP/IP. It's been a while since the last release, and quite some improvements have been done in several subsystems. Some of them are rather significant, and a recommendation to update to this new version soon is recommended. Highlights: . Improved handling of situation when there is a resource shortage in the IPPOOL which could lead to the system stopping communication. . Rewritten DNS resolver with much better functionality. . Improved DHCP handling which now makes the system properly handle if the network address changes (for example, if network cable is unplugged and plugged into a different network). Detailed information on things that have been done since the last release: ETHACP: . Added a timer in ETHACP in case we don't have any active receivers because pool full. . Rewritten DHCP trigger conditions in ARP handler. IF: . Bugfix in IF: driver. IO.SIF function accidentally could set the interface to DHCP managed. . Added DHCP server information to IF: UCB. . Added detecting of interface network change and request DHCP if needed. IP: . Added trimming of incoming packets when forwarded to higher level protocols. IGMP: . Expanded IGMP with more statistics. Fixed small bugs. . Added support for IGMP V3. UDP: . Changed UDP buffer size limits to be in packets instead of bytes. . Added IO.SRS function to UD: to be able to set receive buffer size. TCP: . The logic of TCP high throughput and high latency was reversed. . In TCP push-on-read handling, an unconditional push was requested, while it should just a push at the end of currently outstanding data. . Bugfix in TCP. Sometimes the retransmit timer was being activated when there was no actual outstanding data. . Improved TCP sending to flush full buffers in more circumstances. IFCONFIG: . Bugfix in IFCONFIG. Changing parameters on an interface could accidentally enable DHCP on the interface. . Fixed IFCONFIG to force RESOLVER rescan when routing table change. . Bugfix in IFCONFIG. When showing multicast table, we could show some garbage. NETSTAT: . Added showing buffer size of UDP sockets in NETSTAT. DNS/RESOLVER: . Added setting a larger UDP buffer size for resolver. . Improved DNS resolver to clean out bad servers list if IP address changes. . Improved DNS resolving to handle caching better. . Corrected a few details in the mDNS protocol based on RFC 6762. . Rewritten DNS name resolver. Improved response handling, CNAME following and mDNS querying and response processing. . Fixed RESACP to always do multicast join. It might not have worked on first attempt, if no default routed existed. . Cleaned up DHCP and RESACP more for handling changing addresses. . Added new logicalname for DNS served from DHCP. . Added that DHCP force reevaluation of own address in DNS when IP address changes. DHCP: . Added sanity checks to DHCP renew time. . Bugfix DHCP receive function. Timeout was missing. . Correct DHCP to fall back to broadcast requests if renew is failing. . Correct which fields are included in a DHCP request based on which state it is in. . Improved DHCP behavior. Some retry mechanisms were broken, and some fields in packets were not set up optimally. . Improved DHCP resilience against badly formatted packets. . Improved DHCP messages. . Fixed so that DHCP don't request a refresh of RESACP until all done. . Correct DHCP handling if DHCP server stops answering. . Correct DHCP handling of renew to work from scratch. . Cleaned up DHCP and RESACP more for handling changing addresses. . Bugfix in DHCP. If we got a new IP address, DHCP crashed. . Added new logicalname for DNS served from DHCP. . Added that DHCP force reevaluation of own address in DNS when IP address changes. TELNETD: . Added a reset of the CLI for a terminal if needed when a telnet connection is closed. . Bugfix in telnetd. Under some circumstances, telnetd could hang. . Additional improvemnts on telnet server buffering. . Improve telnet daemon to better buffer output. MAILD: . Added supression of newline at end of mail program running. . Improved mail submission to detect if there are any actual problems talking to the submission task by the client. . Bugfix. Mail submission from unprivilged users had become broken. . Fixed a cleanup in MAILD when we get an error while receiving a mail over DECnet. We got a register dump because of it. . Bugfix in smtp sending. If there are multiple MX hosts, and the first ones accepts a connection, but gives an error, the mail is marked as pending with a connect fail, even if a later MX host connection worked fine. . Changed mail server task to not allow any operation by non-priv. . Improved smtp sent mail header processing. Multinet: . Improved multinet to not have outstanding I/O when accepting passive TRACERT: . Bugfix in TRACERT. End detection was looking at the result of the last ping instead of the actual address. PDP-11 C header files: . Added a couple of external ints in the PDP-11 C inet.h header file, to expand the interfacing to the resolver. Some additional notes: As usual, I would recommend people to update as soon as possible. The changes are somewhat critical, but will also 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 or LAT. TNC2 can get information about remote connections over DECnet as well, but this requires updates to DECnet. Such patches are not available separately at this time, but are included in the RSX image provided from Johnny Billquist. The TT: driver patches also allows the updated MCR to give more information with the DEV command (SHOW TERMINAL in DCL). The patched TT: driver also makes is possible to get telnetd fully vectorized, as this version provides two more addresses that are required by telnetd to access information in the kernel. 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... INS: Fixes that users cannot circumvent protection on common regions. HEL: Fix that users can login with session ID, or with directory, in addition to name and UIC. ACNT: Add no password change attribute to accounts. PSW: Add no password change handling. SYL (SYSLOG): Add terminal idle tracking on accounts without idle logout. 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, and drops packets. This is 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. NMVACP: Fix handling of "show known nodes" command, which could skip some nodes. NVP: Add ability to use session ID or directory name for user identity in DECnet nodename specifications. EPM: Fix handling of ethernet multicast. NTDEMO: Fix that hosts without names should display DECnet address. NCP: Parse of additional information types in NICE messages. As usual, the distribution is available from: ftp://mim.stupi.net/bqtcp.dsk ftp://mim.stupi.net/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.stupi.net/tcpipdoc I hope people find this update useful. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

3 months, 3 weeks

1
0
0 0

New area?

by peter＠whisker.org.uk

Hi I'm thinking about running up further machines and wonder if anyone would object to me using my own area (eg either 40. or 50.) both of which are available according to the database. I have a permanent static L2 pyDecnet router. I currently peer with Keith's area 29 router and would also seek to peer with area 1 and any others looking for redundancy. Best wishes Peter Whisker Peter R Whisker BA BAI CEng MIET Chartered Engineer - IT Technical Architect E: peter(a)whisker.org.uk

4 months, 2 weeks

3
3
0 0

DECnet event date/time on VAX/VMS

by Keith Halewood

Hi, It has been mentioned elsewhere and maybe a while back too but I'm not quite sure when DECnet (VAX/VMS 7.3) started serving up jewels like: %%%%%%%%%%% OPCOM 13-NOV-2024 15:15:13.82 %%%%%%%%%%% Message from user DECNET on TUPILE DECnet event 4.10, circuit up From node 29.109 (TUPILE), 1-JAN-1977 00:00:53.64 Circuit UNA-0 Regards Keith

4 months, 2 weeks

7
19
0 0

DECnet proxy access under RSX

by Johnny Billquist

I was just made aware that there is a bug in the proxy access handling under RSX. If you enable incoming proxy access, but do not have a proxy database set up, RSX will actually allow remote users to gain access to files (or whatever) as any user they specify, without having to give any password. This is a bug in the network verification program. I just fixed this, and a fixed version is available on MIM::LB:[5,54]NVPFSL.TSK. People should be able to just copy that one over, and then either remove NVP... and then install LB:[5,54]NVPFSL, or just reboot, and the fixed version should be active. You can verify if you have the correct version by checking the version of NVP, like this: .tas nvp... NVP... V08.20 GEN 150. 00021400 DU0:-00012167042 . The fixed version is V08.20. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

7 months, 3 weeks

1
0
0 0

Re: DECnet event date/time on VAX/VMS

by Terri Kennedy

[I previously sent this reply from an email address not registered on this list, so presumaby it got bit-binned.] On 2024-11-13 14:20, Paul Koning wrote: > By "bug" I meant "specification bug". The author of the DNA NetMan > spec messed up here. Yes, VMS faithfully follows that bad design. > > The bugfix amounts to fixing the text of the spec, then changing the > implementations to match the corrected text. I don't know if the > former has ever been done but obviously a number of DECnet > implementations acted as if had been. :-) I have Alpha VMS listings kits, but stupidly gave away my VAX listings. Should someone send me a pointer to where a 7.3 listings kit can be found, I'll try to find and fix it when I get back from vacation next month. On VMS, DECnet is a System Integrated Product (SIP) so it _should_ be in the listings kit, but no guarantees. Yes, I do have a listings license and had VAX/VMS on support at the time V7.3 came out, so if someone wants me to "show my papers" be- fore they'll give me access, I can do that... >> On Nov 13, 2024, at 1:53 PM, Johnny Billquist <bqt(a)softjar.se> wrote: >> >> I would not call it a bug. It was initially defined that way. However, >> RSX officially decided to start treating it as an unsigned 16-bit >> value with the last releases, and documented this. >> >> And it's a change that do make sense. >> >> But if others have not applied the same update, then it makes sense >> that they would zero the value if it have the high bit set. >> >> Johnny >> >> On 2024-11-13 19:26, Paul Koning wrote: >>> The statement in the DECnet spec that julian half-day is 15 bits is >>> an obvious bug with an obvious fix; clearly RSX and others have made >>> that fix. VMS needs to do likewise. >>> paul >>>> On Nov 13, 2024, at 12:50 PM, John Forecast <john(a)forecast.name >>>> <mailto:john@forecast.name>> wrote: >>>> >>>> Depends on the implementation. Nov 9, 2021 on VMS, Ultrix and >>>> probably some others. RSX is good until 2065. >>>> >>>> John. >>>> >>>>> On Nov 13, 2024, at 10:24 AM, Keith Halewood >>>>> <Keith.Halewood(a)pitbulluk.org >>>>> <mailto:Keith.Halewood@pitbulluk.org>> wrote: >>>>> >>>>> Hi, >>>>> It has been mentioned elsewhere and maybe a while back too but I’m >>>>> not quite sure when DECnet (VAX/VMS 7.3) started serving up jewels >>>>> like: >>>>> %%%%%%%%%%% OPCOM 13-NOV-2024 15:15:13.82 %%%%%%%%%%% >>>>> Message from user DECNET on TUPILE >>>>> DECnet event 4.10, circuit up >>>>> From node 29.109 (TUPILE), 1-JAN-1977 00:00:53.64 >>>>> Circuit UNA-0 >>>>> Regards >>>>> Keith >>>>> _______________________________________________ >>>>> HECnet mailing list --hecnet(a)lists.dfupdate.se >>>>> <mailto:hecnet@lists.dfupdate.se> >>>>> To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se >>>>> <mailto:hecnet-leave@lists.dfupdate.se> >>>> >>>> _______________________________________________ >>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se >>>> <mailto:hecnet@lists.dfupdate.se> >>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se >>>> <mailto:hecnet-leave@lists.dfupdate.se> >>> _______________________________________________ >>> HECnet mailing list -- hecnet(a)lists.dfupdate.se >>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se >> >> -- >> Johnny Billquist || "I'm on a bus >> || on a psychedelic trip >> email: bqt(a)softjar.se || Reading murder books >> pdp is alive! || tryin' to stay hip" - B. Idol >> _______________________________________________ >> HECnet mailing list -- hecnet(a)lists.dfupdate.se >> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se > > _______________________________________________ > HECnet mailing list -- hecnet(a)lists.dfupdate.se > To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

7 months, 3 weeks

1
0
0 0

DECnet Connection Field Limits

by Thomas DeBellis

I've gotten far enough along with the Tops-20 finger server that I thought it would be a good idea to capture some of the common assumptions and requirements into a DECnet finger specification document of a sorts. The current working version can be found at: _VENTI2::DECNET-FINGER-SPECIFICATION.TXT_. I emphasize /WORKING VERSION/ as I have been working with (a very patient) Johnny to run tests, and chase down documentation bugs, gaps, inaccuracies and other delusions. It's an active work in progress. In particular, the limits of certain connections field are based what is documented in the January 1980 version of the TOPS-20 DECnet-20 Programmer's Guide and Operations Manual, Order Number AA-5091A-TM. This is quite old as it is based on Tops-20 version 4 and Tops-20 DECnet version 2. However, it is what I had handy and what I remember coding to, back in the day. Connection parameters are partially specified as attributes and are as follows: * ;*USERID*:/userid/ where /userid/ consists of 1 to 16 contiguous alphanumeric ASCII characters (including the hyphen, dollar sign, and underscore) identifying the source task. _Example_: ;USERID:ALIBABA * ;*PASSWORD*:/password/ where /password/ consists of 1 to a contiguous alphanumeric ASCII characters (including the hyphen, dollar sign, and underscore) required by the target task to validate the connection. _Example_: ;PASSWORD:SESAME * *;CHARGE*:/acctno/ where /acctno/ consists of 1 to 16 contiguous alphanumeric ASCII characters (including the hyphen, dollar sign, and underscore) representing the source task's account identification. _Example_: ;CHARGE:ACCT-13C * *;DATA*:/userdata/ where /userdata/ consists of 1 to 16 contiguous alphanumeric ASCII characters (including the hyphen, dollar sign, and underscore) representing user data. _Example_: ;DATA:THIS-IS-A-TEST I've since found out that I'm *wrong* about USERID, and that it actually allows up to 39 characters and have tested this. What specification has these field definitions and limits? I'd like to look at it before I go digging into Tops-20 and, of course, fixing the finger server.

8 months

3
2
0 0

Nodename updating

by Johnny Billquist

I've seen/heard of various stories about how people update their nodename databases on their machines, hacking together scripts, and processing files. So I figured I should write a small mail about the topic (I should create a web-page with this information as well). The main/basic point is that people are creating work for themselves they really don't need. Exactly how you update your nodename database on your machine depends on what OS you are running, but there are basically prepared tools and scripts already existing for pretty much any scenario. And if you happen to have a system or need not currently covered, I can easily create one for you as well. But before going into the solutions, let me explain a bit about the source of the data here. DECnet phase IV do not have a centralized nodename system like DNS. Each node in the DECnet network has its own nodename database, and every machine can have its own name for another machine, independent of what that other machine thinks its own nodename is. However, in order to make it easier for multiple people and machines to talk, it helps if everyone have a somewhat similar database. And here is where the nodename database in MIM comes it. The nodename database that I have on MIM is not the regular DECnet nodename database. Instead I'm using DATATRIEVE to maintain a nodename database, which contains more information than just the number and name. It contains the owner, information about the software and hardware of the node, the location, and when things were updated. This database is what is queried when someone goes to http://mim.stupi.net/nodedb . And that page is generated by just making queries in DATATRIEVE. If someone have a host with DATATRIEVE on it, it is even possible to remotely access this DATATRIEVE database over DECnet (you'll only have read-only access). I have been considering possibly adding a web interface for people to possibly be able to update their own information remotely, but so far that's been a low priority thing. Maybe one day... From this DATATRIEVE database I can then generate the DECnet nodename database on MIM. This is a simple makefile actually. Whenever I run it, it will create a bunch of different files (I'll get to that in a moment), and detect if any changes have happened on the DECnet level of things. If so, it will send a mail to people who have requested it, informing them that the nodename database have been updated, and they should update the nodename database of their own machines. I hope this makes it apparent that creating various files based on the nodename database is actually very simple. This is in a sense what DATATRIEVE is good at. Creating reports is sortof what all these output files are. So - what files do I create today? Well, here is a short list: FIX.CMD - This is a script file suitable for RSX systems using CFE. However, it's sortof specially tailored for MIM, so it's not a file I would recommend anyone else to use. FIX.COM - This is a script for VMS systems using phase IV. FIX.PHV - This is a script for VMS systems using phase V. FIX.IMP - This is a script for VMS for anyone using DECdns. FIX.T20 - This is a script for TOPS-20. HECNET.PY - This is a definition file for PyDECnet. FIX.RST - This is a script for RSTS/E. NODENAMES.DAT - This is basically just the basic information is a simple output form from DATATRIEVE. It exist mostly for historical reasons, but I understand that lots of people actually take this file, and then write code to process, extract and apply information from this file. In addition, some systems can directly import nodenames from another machine on DECnet, meaning you do not have to fetch and run any scripts at all. So here is the actioins you need to do on each system in a summarized form: RSX: In RSX, there is a tool called NNC which copies definitions from another node. Copy over MIM::HECNET:NNC.BAT which is a batch file you can use which does all the work of importing the latest definitions from MIM and updating your local system. All you need to do is just "SUBMIT NNC.BAT" and you are done. VMS: With phase IV, the node copy capability is build into NCP. All you need to do is: "NCP COPY KNOWN NODES FROM MIM TO BOTH" and you are done. With phase V, copy over FIX.PHV and run it, or just directly run it from MIM like this: "@MIM::HECNET:FIX.PHV" If you run DECdns, grab FIX.IMP, and run it with whatever tool is used to manage this (sorry that I can't help more, I don't really have any experience with DECdns). TOPS-20: Grab MIM::HECNET:FIX.T20 and run in in the NCP submode of OPR (if I remember the setup correctly). RSTS/E: Grab MIM::HECNET:FIX.RST, and run it with "@FIX.RST". PyDECnet: Fetch hecnet.py by doing "wget mim.stupi.net/hecnet.py". Place that where you have configured PyDECnet to get the nodenames from, and you are good (not sure if you need to restart PyDECnet). Now. If you have some other system with some specific format you need, just let me know, and I'll create such a file as well. It's trivial for me to do this from DATATRIEVE. If you spot something wrong/bad in some file created today, let me know, and we'll fix it. If you see any errors or omissions in the information in this mail, let me know, and I'll get it corrected. I will create a web page with this information as well. If you want to get a mail whenever the nodename database is updated, just let me know and I'll add you to the list. And HECnet is slowly growing. Occasionally a completely new person/site gets connected. Occasionally people add more nodes. The online presence seems pretty constant. At the moment 19 areas are online. In area 1, currently there are 19 machines online. Looking at Paul's HECnet map (http://akdesign.dyndns.org:8080/map), there are machines online in quite different locations, covering a large part of the world. I find this cool, and even though there isn't a lot being done, it's still fun. Well. Have a nice weekend everyone, and I hope some people find this information useful. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

8 months, 3 weeks

8
18
0 0

NSP Connection Confirm Text (or, just in case I have it backwards...)

by Thomas DeBellis

I've finished the timeout functionality so that the Tops-20 finger server will only wait so long before punting the connection (don't worry, I'm very generous...) I'm now working on the logging functionality. Again, on a connection interrupt, the finger server grabs a bunch of meta-data about the connection and displays it: FNGSRV(1): Sunday, 6-October-2024 12:23:36.52412 AM-EDT From: VENTI2, User: SLOGIN, Data: STREAM* Object Type: Generic (FINGER), Segment Size: 1459 Local Flow Control: Segment, Remote Flow Control: Segment Link Quota: Input Percentage: 50, Buffers: 16, Input Goal: 0 I have three concerns here (or maybe two and a half) 1)I want to write this information to a log file, 2)Since the data is written by concurrent server sub-forks, a)Data can get overwritten b)Latency to start the finger sub-sub-forks is increased The solution is simple enough, I grab everything in the server sub-fork and ship it up to the controller through shared memory for later formatting and storage (and maybe printing). When reviewing what meta-data can be gotten, I noticed that an explicit connection confirm (MTOPR% function .MOCC) can take a pointer to an optional sixteen bytes of data. What I can't quite tell from the documentation is whether the server reads this or whether the server writes it. I find myself being unsure of the wording. 1. If the former (server sends), how does the client read it? 2. If the latter (server reads), how does the client send it? I don't see a single instance of any Tops-20 DECnet program using this, so no help there. I /think/ this is case 1., that is, the server has the option of writing it. However, I was wondering what specification this is in (maybe NSP 4?) and where, so I could read it before I look at the monitor sources to see how the client would read it. I'm assuming it would show up at the client as optional data?

9 months

3
3
0 0

Tops-20 Finger Server Update

by Thomas DeBellis

I thought I would update everyone with where things stand with the Tops-20 finger server. Johnny and I agreed that, by default, the response to a DECnet finger query is a sequences of records, each no longer than 132 bytes (more typically 90), terminated by a line-feed. If the remote finger client or operating system can handle larger buffers, then it can connect with optional data=STREAM. Tops-20 will then dump everything in one giant record. Only the Tops-20 finger client can handle this, although I suspect maybe a VAX client might also be able to do it. I had been making steady progress until I started stress testing it, meaning having a session active on MIM::, TOMMYT::, and VENTI2:: (local), each having a finger command in ready to go and then pushing carriage return on all three as simultaneously as possible. This started generating errors on MIM:: that the "object wasn't available". What was going on was that the structure of the Tops-20 finger server really wasn't architected to have real time response for that much curiosity. It only opens a single SRV:117 (finger) object at a time, waits for a connection, reads the data, hands it off to an idle finger client fork via a pipe, and then gets a new SRV:117 object. In other words, it isn't until the finger client is started with the connection redirected to DECnet that the server is ready to accept another connection. That has what I would consider to be noticeable latency, particularly on failure. An error doesn't really matter for SMTP as it is a background task and just tries again, later. An interactive finger on the other hand, has a user sitting there waiting for a response, so it seemed to me that this wasn't really going to cut it. I took the model of the Tops-20 FAL server, which has a single control fork, looking for illness in sub-forks, all of which open their own FAL server object. The new finger controller now starts separate FNGSRV sub-server forks, creating a FINGER sub-fork for each, gets all the communications lined up, and starts all the FNGSRV sub-forks to listen for connections. This has the advantage of not clobbering the system on FNGSRV startup because resources are gotten or creating sequentially, so there isn't much for a FNGSRV sub-fork to do except wait for a connection and manage its own single FINGER sub-fork. Startup resource allocation looks like this: [Fork FNGSRV opening PIP:1;RECORD-LENGTH:200 for writing] [Fork FNGSRV opening PIP:1.1 for reading] [Fork FNGSRV opening SRV:117 for reading, writing] [Fork FNGSRV opening PIP:2;RECORD-LENGTH:200 for writing] [Fork FNGSRV opening PIP:2.2 for reading] [Fork FNGSRV opening SRV:117 for reading, writing] [Fork FNGSRV opening PIP:3;RECORD-LENGTH:200 for writing] [Fork FNGSRV opening PIP:3.3 for reading] [Fork FNGSRV opening SRV:117 for reading, writing] The resulting JFN's being: JFN File Mode Bytes(Size) 2 FNGSRV.EXE.330 Read, Execute 3 FINGER.EXE.116 Read, Execute 15 PIP:1;RECORD-LENGTH:200 Append 0.(8) 16 PIP:1.1 Read 0.(8) 17 SRV:117 Read, Append 0.(8) 20 PIP:2;RECORD-LENGTH:200 Append 0.(8) 21 PIP:2.2 Read 0.(8) 22 SRV:117 Read, Append 0.(8) 23 PIP:3;RECORD-LENGTH:200 Append 0.(8) 24 PIP:3.3 Read 0.(8) 25 SRV:117 Read, Append 0.(8) The resulting fork structure is: => FNGSRV (2): HALT at STARTS+13, 0.02719 Fork 12: HALT at 0, 0.00018 Fork 13: HALT at 0, 0.00016 Fork 10: HALT at 0, 0.00012 Fork 11: HALT at 0, 0.00012 Fork 6: HALT at 0, 0.00008 Fork 7: HALT at 0, 0.00007 So fork 2 is the finger server controller, forks 12, 10, and 6 are finger server sub-forks, and forks 13, 11, and 7 are the respective Tops-20 finger clients. Times are in tens of microseconds, the maximum resolution that Tops-20 supports. What can be seen is that fork creation is happening in sub-millisecond time. This was not the case in the 1980's with KL10's (I /think/), and modifications were necessary to Tops-20 and the EXEC to capture the increased resolution. I guess I'll have another version ready in about two weeks.

9 months, 1 week

2
3
0 0

Re: Tops-20 Finger Server Update

by Johnny Billquist

MIM can be used as an intermediate node, yes. If you send your mails to MIM::<whatever>::USER the mail will be queued up if the <whatever>:: node isn't responding right now. Johnny On 2024-10-04 09:16, jdmail(a)zeelandnet.nl wrote: > Then we need a node as a mailserver? Can that be done? > > Johan > > > Johnny Billquist schreef op 2024-10-04 02:29: > >> And just if anyone wonders - yes, that also means you cannot send mail >> to users on systems that are not currently online. >> A thing that I always found a bit annoying/irritating. >> >> Another reason why I wrote the mail handling for BQTCP to also do the >> writing and sending as two separate steps, with a queuing in between. >> >> Here is how it looks from VMS: >> >> MAIL> sen >> To: josse::bqt >> %MAIL-E-LOGLINK, error creating network link to node JOSSE >> -SYSTEM-F-UNREACHABLE, remote node is not currently reachable >> >> MAIL> sen >> To: anke::bqt >> %MAIL-E-LOGLINK, error creating network link to node ANKE >> -SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node >> >> MAIL> >> >> >> It instantly tries to connect, and if that don't work, it immediately >> fails. >> >> Johnny >> >> On 2024-10-04 01:38, Johnny Billquist wrote: >>> Sounds like a good improvement. >>> >>> However, I saw something about mail here, that you should be aware of... >>> My MAIL11 implementation is doing the queuing of mails, because that >>> is normal with SMTP, and I just carried over the same behavior to all >>> parts of the system. >>> >>> However, the "standard" MAIL11 application for RSX as well as RSTS/E >>> , along with the DECUS MAIL for RSX (and I suspect also VMS) do not >>> behave that way. If the connecting fails, the sending of mail >>> immediately fail, and it is not queued for retrying. So it would >>> appears that the mail for TOPS-20 you look at is also potentially >>> flawed, which could cause issues. >>> >>> Of course, in that case, you'd normally have a human sitting in front >>> of the terminal, who would then try again... >>> >>> Johnny >>> >>> On 2024-10-04 00:05, Thomas DeBellis wrote: >>>> I thought I would update everyone with where things stand with the >>>> Tops-20 finger server. >>>> >>>> Johnny and I agreed that, by default, the response to a DECnet >>>> finger query is a sequences of records, each no longer than 132 >>>> bytes (more typically 90), terminated by a line-feed. Ifthe >>>> remote finger client or operating system can handle larger buffers, >>>> then it can connect with optional data=STREAM. Tops-20 will then >>>> dump everything in one giant record. Only the Tops-20 finger client >>>> can handle this, although I suspect maybe a VAX client might also be >>>> able to do it. >>>> >>>> I had been making steady progress until I started stress testing it, >>>> meaning having a session active on MIM::, TOMMYT::, and VENTI2:: >>>> (local), each having a finger command in ready to go and then >>>> pushing carriage return on all three as simultaneously as possible. >>>> >>>> This started generating errors on MIM:: that the "object wasn't >>>> available". What was going on was that the structure of the Tops-20 >>>> finger server really wasn't architected to have real time response >>>> for that much curiosity. It only opens a single SRV:117 (finger) >>>> object at a time, waits for a connection, reads the data, hands it >>>> off to an idle finger client fork via a pipe, and then gets a new >>>> SRV:117 object. >>>> >>>> In other words, it isn't until the finger client is started with the >>>> connection redirected to DECnet that the server is ready to accept >>>> another connection. That has what I would consider to be noticeable >>>> latency, particularly on failure. An error doesn'treally matter >>>> for SMTP as it is a background task and just tries again, later. An >>>> interactive finger on the other hand, has a user sitting there >>>> waiting for a response, so it seemed to me that this wasn't really >>>> going to cutit. >>>> >>>> I took the model of the Tops-20 FAL server, which has a single >>>> control fork, looking for illness in sub-forks, all of which open >>>> their own FAL server object. The new finger controller now starts >>>> separate FNGSRV sub-server forks, creating a FINGER sub-fork for >>>> each, gets all the communications lined up, and starts all the >>>> FNGSRV sub-forks to listen for connections. >>>> >>>> This has the advantage of not clobbering the system on FNGSRV >>>> startup because resources are gotten or creating sequentially, so >>>> there isn't much for a FNGSRV sub-fork to do except wait for a >>>> connection and manage its own single FINGER sub-fork. >>>> >>>> Startup resource allocation looks like this: >>>> >>>> [Fork FNGSRV opening PIP:1;RECORD-LENGTH:200 for writing] >>>> [Fork FNGSRV opening PIP:1.1 for reading] >>>> [Fork FNGSRV opening SRV:117 for reading, writing] >>>> [Fork FNGSRV opening PIP:2;RECORD-LENGTH:200 for writing] >>>> [Fork FNGSRV opening PIP:2.2 for reading] >>>> [Fork FNGSRV opening SRV:117 for reading, writing] >>>> [Fork FNGSRV opening PIP:3;RECORD-LENGTH:200 for writing] >>>> [Fork FNGSRV opening PIP:3.3 for reading] >>>> [Fork FNGSRV opening SRV:117 for reading, writing] >>>> >>>> The resulting JFN's being: >>>> >>>> JFN File Mode Bytes(Size) >>>> >>>> 2 FNGSRV.EXE.330 Read, Execute >>>> 3 FINGER.EXE.116 Read, Execute >>>> 15 PIP:1;RECORD-LENGTH:200 Append 0.(8) >>>> 16 PIP:1.1 Read 0.(8) >>>> 17 SRV:117 Read, Append 0.(8) >>>> 20 PIP:2;RECORD-LENGTH:200 Append 0.(8) >>>> 21 PIP:2.2 Read 0.(8) >>>> 22 SRV:117 Read, Append 0.(8) >>>> 23 PIP:3;RECORD-LENGTH:200 Append 0.(8) >>>> 24 PIP:3.3 Read 0.(8) >>>> 25 SRV:117 Read, Append 0.(8) >>>> >>>> The resulting fork structure is: >>>> >>>> => FNGSRV (2): HALT at STARTS+13, 0.02719 >>>> Fork 12:HALT at 0, 0.00018 >>>> Fork 13: HALT at 0, 0.00016 >>>> Fork 10:HALT at 0, 0.00012 >>>> Fork 11: HALT at 0, 0.00012 >>>> Fork 6: HALT at 0, 0.00008 >>>> Fork 7: HALT at 0, 0.00007 >>>> >>>> So fork 2 is the finger server controller, forks 12, 10, and 6 are >>>> finger server sub-forks, and forks 13, 11, and 7 are the respective >>>> Tops-20 finger clients. Times are in tens of microseconds, the >>>> maximum resolution that Tops-20 supports. What can be seen is that >>>> fork creation is happening in sub-millisecond time. This was notthe >>>> case in the 1980's with KL10's (I /think/), and modifications were >>>> necessary to Tops-20 and the EXEC to capture the increased resolution. >>>> >>>> I guess I'll have another version ready in about two weeks. >>>> >>>> >>>> _______________________________________________ >>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se >>>> <mailto:hecnet@lists.dfupdate.se> >>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se >>>> <mailto:hecnet-leave@lists.dfupdate.se> -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

9 months, 1 week

1
0
0 0

DECnet Object Numbers (Again!)

by Thomas DeBellis

Some time ago, I asked about a list of DECnet generic objects and what they meant. I remember seeing a response and now I can't find it or what I thought I saved as a file. Could somebody send me that again? For now, all I have is what SYSDPY shows. This is an annotated list (note that numbers are octal unless otherwise specified: _Object#_ _Name_ _Comment_ 0 TASK 1 FAL1 2 URDS Unit Record Device Service (DN200) 3 ATS 4 CTS 5 TCL1 6 OSI 7 NRM 10 3270 3270 Terminal 11 2780 2780 Remote Job Entry protocol 12 3790 13 TPS 14 DIBOL 15 T20TRM Tops-20/Tops-10/Ultrix Network Remote Terminal (NRT) 16 T20RSP 17 TCL 20 TLK 21 FAL File Access Listener 22 RTL 23 NCU NICE? 24 NETCPY 25 ONCTH 26 MAIL How different from MAIL11? 27 NVT 30 TCON 31 LOOP Loopback Testing 32 EVENT DECnet Event Reporting 33 MAIL11 VAX mail? 34 FTS File Transfer Service 35 PHONE Phone 36 DDMF 37 X25GAT X.25 gateway 40 UETP User Environment Test Package 41 VXMAIL 42 X29SRV 43 RDS 44 X25HST X.25 Host 45 SNAGAT SNA Gateway 46 SNARJE SNA Remote Job Entry 47 SNAGIS 50 MTSS 51 ELF 52 CTERM Control Terminal 53 DNSTA 54 DNSUL 55 DHCF ^D47 POSI Remote OPR ^D63 DTR ^D65 TOPOL ^D66 DQS Digital Queue Service (LAT?) ^D117 FINGER Personal Name service ^D123 PMR ^D201 MS

9 months, 3 weeks

3
3
0 0

Preliminary Tops-20 Finger Server

by Thomas DeBellis

I needed to take a break from finishing up the Tops-20 DECnet/SMTP code, so I finally looked into doing a Tops-20 finger server.Over the weekend, I cobbled something together.For example, on TOMMYT:: FINGER>oinky@venti2 /no-plan OINKYGuinea PigOINKY not logged in Last logout Sun 1-Sep-2024 1:40AM from TTY6 (NRT) No new mail, last read on Tue 12-Apr-2022 10:00PM The finger server is multi-forking and works by creating a group of forks, putting the finger program in each fork and changing the primary input and output to whatever connection is being served.It is general enough so that you could probably have it run any program with little tinkering. Right now, it is in debugging mode and typing a lot of diagnostic information about the link.So, for the above attempt from the client, the finger server console output was: FNGSRV: Connection from TOMMYT, User: SLOGIN, Data: Tops-20_Finger Object Type: Generic (165), Segment Size: 1459 Local Flow Control: Segment, Remote Flow Control: Segment Link Quota: Input Percentage: 50, Buffers: 16, Input Goal: 0 As can be seen, the Tops-20 finger client has been modified to send the name of the local user and optional data identifying the finger client.Probably I’ll change that to the finger version.The RFC for TCP/IP finger is (naturally) silent on what you can send over DECnet, so this doesn’t break anything.So, I can finger myself on MIM:: just fine, viz: FINGER>debellis@mim [Default directory: US00:[DEBELLIS]CLI: DCLSID: TDB Last seen Sep 16 2024 23:04:37 on RT0: from VENTI2:: Logged on 16 times. No plan. Unfortunately, it /doesn’t /work when I sign on to MIM:: and try the local finger client there, viz: $ finger -d VENTI2::OINKY [VENTI2::] $ So, no obvious failure, but no output, either. On VENTI2::, what I’m seeing appears to be a successful connection and that the finger program running in the sub-fork is opening OINKY’s finger plan and sending it back over the link, viz: [Fork FNGSRV opening SRV:117 for reading, writing] FNGSRV: Connection from MIM, Task: DEBELLIS Object Type: Generic (165), Segment Size: 558 Local Flow Control: Segment, Remote Flow Control: Message Link Quota: Input Percentage: 50, Buffers: 16, Input Goal: 0 [Fork 2 opening TOMMYT:FINGER.BIN.5 for reading thawed] [Fork 2 opening TOMMYT:<OINKY>FINGER.PLAN.4 for reading] Currently, the finger server is highly instrumented, so if it detected that something was amiss (like the finger sub-fork was flat out croaking), it would complain about it. Or it should… Finger itself is not so highly instrumented as I wanted to make the changes there as small as possible. If you have a finger client that can do DECnet connections on another platform (I’m thinking VMS or maybe RSTS) and can try it, let me know how you make out. Be aware that I did just hack this together in two and a half days, so I make no claims to any sort of stability. I'm just trying to trouble shoot at this point. —T

9 months, 3 weeks

3
8
0 0

Area 27's new ISP

by Mark Berryman

To the neighbors of area 27: I have a new ISP which will hopefully prove better than Comcast did. My new addresses are: IPv4: 165.188.116.102 IPv6: 2601:b058:1ff:0:d48b:ea7e:93ea:b795 As always, these addresses are in DNS as decnet.theberrymans.com <http://decnet.theberrymans.com/>. I’m still making the final necessary changes on my router but everything should be up and running by the end of the day (GMT -0600). Mark Berryman

9 months, 3 weeks

5
6
0 0

Re: Finger survey

by Terri Kennedy

I'm a bit late to the party, but I figured I'd chime in here anyway 8-} I was the maintainer of VMS Finger from V50.1.00 (when I took it over from Rand Hall) until V50.1.35 which was the last release in July 2000. Which Finger you get by default (and what it supports) on VMS depends on which TCP/IP package you have. There's no native DECnet-only Finger. I've started working on VMS Finger again, including back-porting the V50.1.35 back to VAX/VMS - VAX support was essentially frozen at V50.1.29. Idle time on VMS is a bucket full of eels - VMS kept track of idle time on physical terminals. I'm not sure if it still does. It never did it for terminal-like connections. Brian Schenkenberger wrote a loadable execu- table image, loaded at boot time, that provides idle monitoring for TT devices, as well as hooks to add monitoring of other terminal devices. A separate utility hooks into it during normal systartup_vms.com proces- sing to add monitoring to RT devices (since that device didn't exist at boot time). Although it is copyrighted by him, he allows it to be dis- tributed with VMS Finger (and it works on both VAX and Alpha). I never had an Itanium system of my own (and never desire to), so if you have one and want to run Finger on it, drop me an email and I'll send you a test kit once I have VMS Finger closer to release state. Here's an example of VMS Finger (running on a real VAX to a virtual- ized Alpha): VX4200::$ finger @server/idle/version [SERVER.DECnet] OpenVMS Finger: Version V51.1.36 of 23-Aug-2024 Unauthorized Access Strictly Prohibited SERVER DS10 616 MHz, OpenVMS V8.4-2L1, Thu, 12-Sep-2024 21:28, 4 Users, 0 Batch Uptime 19 18:55, since Sat, 24-Aug-2024 02:33, Load: 0.06 0.04 0.07 PID Username Program Term Login CPU Idle Location TT Type 0000AD16 TERRY $ NTY13: 02:55 0:00 1:19 bedroom.glaver.o VT3xx 0000AA2B TERRY Ltpad NTY14: 02:56 0:00 18:30 bedroom.glaver.o VT3xx 00008634 TERRY Ua NTY12: 16:47 0:38 1:19 portable3-wl.gla VT3xx 0000C496 TERRY $ NTY15: 14:00 0:00 2 office.glaver.or VT3xx 0000C497 TERRY Ltpad NTY16: 14:01 0:00 7:26 office.glaver.or VT3xx Some info on that display - by default, if the node being fingered looks like it could be a DECnet Phase IV node, it tries DECnet first. If you specify something that either isn't a known DECnet node or can't possibly be a DECnet node, it uses TCP/IP: VX4200::$ finger @server.glaver.org/idle/version [SERVER.GLAVER.ORG] OpenVMS Finger: Version V51.1.36 of 23-Aug-2024 Unauthorized Access Strictly Prohibited SERVER DS10 616 MHz, OpenVMS V8.4-2L1, Thu, 12-Sep-2024 21:31, 4 Users, 0 Batch Uptime 19 18:57, since Sat, 24-Aug-2024 02:33, Load: 0.07 0.07 0.07 PID Username Program Term Login CPU Idle Location TT Type 0000AD16 TERRY $ NTY13: 02:55 0:00 1:21 bedroom.glaver.o VT3xx 0000AA2B TERRY Ltpad NTY14: 02:56 0:00 18:33 bedroom.glaver.o VT3xx 00008634 TERRY Ua NTY12: 16:47 0:38 1:21 portable3-wl.gla VT3xx 0000C496 TERRY $ NTY15: 14:00 0:00 4 office.glaver.or VT3xx 0000C497 TERRY Ltpad NTY16: 14:01 0:00 7:29 office.glaver.or VT3xx VMS Finger will still try to link code for use with Joiner Associates' JNET (BITNET) networking stack if you ask for it, but it is untested for decades. If anyone is still running JNET and connected to something, drop me an email. I'm only testing as far back as VAX/VMS V7.3 right now. Eventually I'll see how far back I can go. Hopefully VMS V5.5-2 and ideally VMS V4.4. So much for VMS Finger... I'm also the creator of RSTS/E Finger. It is DECnet-only, but can be con- figured to use any DECnet node as a gateway, either to other DECnet areas or to TCP/IP hosts. Here's RSTS/E 10.1 being Fingered from VMS: SERVER::$ finger @pidp11/version [PIDP11.DECnet] RSTS/E Finger: Version V1.2-09 of 06-Sep-2024 RSTS/E Your Organization Name Here PiDP-11 PIDP11 PDP-11/70, RSTS V10.1-L, Friday, 12-Sep-1924 21:33, 9 Jobs, 63 Max. Uptime 4 07:33:52, since Monday, 8-Sep-1924 14:00 05-Sep-24 - Your message could be here! Edit FINGER$:FINGER.MSG to change it. Job Username PPN Progrm Term Login CPU ST Location TTType 1 SYSTEM 1,2 ERRCPY Det 00:00 SR - Detached - 2 SYSTEM 1,2 MAILQ Det 00:01 SR - Detached - 3 SYSTEM 1,2 OMS Det 00:03 SL - Detached - 4 SYSTEM 1,2 PBS... Det 00:06 SL - Detached - 5 SYSTEM 1,2 EVTLOG Det 00:00 SL - Detached - 6 SYSTEM 1,2 MESMAN Det 00:00 SL - Detached - 7 TERRY 20,254 DCL KB33: 14:01 00:00 ^C SERVER::[11,376] VT320 8 TERRY 20,254 DCL KB34: 02:57 00:00 ^C SERVER::[11,376] VT320 9 SYSTEM 1,2 FINSRV Det 00:00 RN - Detached - And here is RSTS/E 10.1 Fingering an Internet host: $ finger @mim.stupi.net [MIM.STUPI.NET via routing host SERVER] [SERVER.DECnet] [MIM.STUPI.NET] RSX-11M-PLUS system MIM. Fri Sep 13 03:39:27 2024. Up: 1 day, 4:44. Luser Real name Term Idle Logged in From BILLQUIST Johnny Billquist TT15: 17 12 Sep 14:53 s-5eeaac7c-74736162 RSTS/E Finger requires RSTS/E V9.6 or later, since the DECnet/E it relies on is V4.1, which itself requires RSTS/E V9.6 or later. Moving right along: I also wrote an MS-DOS Finger implementation. That isn't as useless as it sounds. If you just say "finger", you get the message "You are the only user, of course". But like RSTS/E Finger, it uses DECnet (Pathworks or whatever product name du jour that product has). The code still exists, but I don't know of any modern Microsoft Windows system that has a DECnet stack available for it. If anyone knows of a DECnet implementation that runs under Windows 10, let me know and I'll resurrect MS-DOS finger as a CLI application for Windows. I can even sign it 8-} Once I have VMS and RSTS/E Finger updated to where I want them, I'd love to have a network interoperability bake-off with as many other implementations as possible. Probably the oddest one I ran into in my testing 30+ years ago was the front-end CPU for a Cray. -- Terri Kennedy

9 months, 3 weeks

3
5
0 0

Kermit-20 Version 5.3(277)-5 Announcement

by Thomas DeBellis

Version 5.3(277)-5 incorporates additional features, enhancements and fixes since edit release 5.3(255)-5 in March of this year (29-Mar-2024). Users of the HECnet community may anonymously transfer files from VENTI2::TOMMYT:<OINKY.K20MIT> and related subdirectories. The changes are summarized below and are further described in TOMMYT:<OINKY.K20MIT.DOCUMENTATION>KERMIT-20_V5_3_277-5-ANNOUNCEMENT.TXT. Rich text is also available in and .PDF and Microsoft .DOCX format. Note that the FAL server on VENTI2:: is *beta code* which required modifications to Tops-20 in order to function properly in an edge case that could happen at boot time. Please email me any issues with FAL transfers off list and I will investigate. ------------------------------------------------------------------------ [256] /PARITY switch to ECHO for batch and other testing purposes[257] Teach INPUT to respect parity, if asked [258] SET PARITY action /ABORT, /PROCEED [259] Fix a few arcane bugs in the C constant expression expander [260] Fix DEFINE to work (again) with ESCAPE and PARITY [261] Decrease repeated parity error messing [262] Remove the legacy INPUT code that uses BIN%'s [263] Stop using a SIN% for a line at a time read [264] Toggle session logging from command level [265] Fix TTY Input Buffer full when doing a TRANSMIT on a PTY [266] Turn TRANSMIT and CAPTURE increasingly hairy switches in SET parameters [267] Give effective data rate at end of TRANSMIT [268] CAPTURE is no longer hidden. Further document it [269] Review, update and correction of all help text [270] Enhance default for SET PROMPT to give some extra useful information [271] Fix TVT setting; it gets overwritten by automatic processing [272] SET TRANSMIT DEFAULT-PROMPT [273] SET TRANSMIT CASE OBSERVE/IGNORE [274] Fix SET INPUT to better support DEFINE [275] SET TRANSMIT SETTINGS-DEFAULTS for backwards compatibility [276] Fix indirect recursion crash when reporting an error with REALLY short packets [277] Variable blips (so we don't get clobbered for very small packets) Kermit-20-Testing-Battery-5.3(277)-5 Updates Updated Help

10 months, 1 week

1
0
0 0

backwr?

by Thomas DeBellis

Has anybody ever used this and had success with it? The magic switches, please? backwr.c is a user contribution to klh10 to write tape files that can be 'mounted' on a 10/20. It comes with no documentation nor does it describe its usage. I puzzled out the command line parser and did: ./backwr -c -T -f ../k20mit-277/k20mit-277.tar > k20tar.tap I want to copy the tar file off the tape to try to read it on the 20 with the 20's implementation of tar. However, when I try to copy the file off the tape, I get ?File data error on file MTA0: If not backwr, what are alternative solutions? The klh10 micro-engine's NI implementation has odd behavior in that if you do a download, you get megabit speeds. If you try to upload on the other hand, you can barely crack 1 kilobaud. So I'm currently uploading the tarball with Kermit, but at 1KBd, it's going to take three days.

10 months, 1 week

1
0
0 0

narkive.com

by Keith Halewood

Hi, I've been using narkive.com in readonly mode to look at comp.os.vms until fairly recently. Now my browser is making the connection and it's being dropped by the other end.... that is, when I'm calling from a UK IP address. If I change my location (access to several UK and non-UK points of presence) to an non-UK address, I can connect without a problem. So far 8 uk-based ISPs (mobile and residential) are being dropped and 6 non-uk (US E, US W, Lux, Japan and Aus) are ok. Pinging works from all. Has narkive.com blocked connections from UK addresses? Keith

10 months, 2 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet