HECnet

hecnet@lists.dfupdate.se

1 participants
15582 discussions

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

1 year, 1 month

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

1 year, 1 month

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

1 year, 1 month

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.

1 year, 1 month

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

1 year, 1 month

Are your processes not using any time?

by Thomas DeBellis

I had been making some efficiency tweaks to a few things, particularly GLXLIB, the Galaxy Object Time System when I began to notice that programs sometimes appeared to not be using any processor time at all. I found that the normal JSYS that returns fork run time (RUNTM%) only gives millisecond resolution. Tops-20 exposes a 100 Khz interface via the HPTIM% JSYS. 'High precision' in this case meant the maximum internal clock rate of the DK10 real time clock. So, although the KL10 had a megahertz clock, Tops-20 lops off a decimal order of magnitude, presumably to remain compatible with TENEX. The maximum resolution is thus 10 microseconds, a hundred times the RUNTM% resolution. Unfortunately, the HPTIM% JSYS only works for your own process, not others. So, I modified the monitor code to be able to get high precision run times for any forks in the job. I then modified the EXEC to display the high precision times if requested. What I also found out was that, by default, the EXEC will only display a tenth of a second, whereas RUNTM% will return two decimal orders of magnitude more. The comparisons below are perhaps of interest. About the shortest I've seen is 1.5 ms (0.00015). Given the increasing speed of simulations, one assumes that DK10 resolution will be exceeded at some point. ------------------------------------------------------------------------ $i fork ORION (1): Background, SLEEP at 767721, 0:00:00.1 QUASAR (2): Background, SLEEP at 767721, 0:00:00.0 MOUNTR (3): Background, SLEEP at 2420, 0:00:00.0 BATCON (4): Background, SLEEP at 767723, 0:00:00.1 NMLT20 (5): Background, SLEEP at US%DES+165, 0:00:00.0 => FAL (6): Background, SLEEP at 767721, 0:00:00.0 Fork 13: SLEEP at 767723, 0:00:00.0 Fork 12: SLEEP at 767723, 0:00:00.0 Fork 11: SLEEP at 767723, 0:00:00.0 Fork 10: SLEEP at 767723, 0:00:00.0 Fork 7: SLEEP at 767723, 0:00:00.0 $ $i fork /high-precision ORION (1): Background, SLEEP at 767721, 0:00:00.12459 QUASAR (2): Background, SLEEP at 767721, 0:00:00.05135 MOUNTR (3): Background, SLEEP at 2420, 0:00:00.06751 BATCON (4): Background, SLEEP at 767723, 0:00:00.19957 NMLT20 (5): Background, SLEEP at US%DES+165, 0:00:00.09560 => FAL (6): Background, SLEEP at 767721, 0:00:00.08322 Fork 13: SLEEP at 767723, 0:00:00.01310 Fork 12: SLEEP at 767723, 0:00:00.01577 Fork 11: SLEEP at 767723, 0:00:00.00381 Fork 10: SLEEP at 767723, 0:00:00.00362 Fork 7: SLEEP at 767723, 0:00:00.00320

1 year, 2 months

Re: [simh] OpenSIMH Networking Support on the MacOS

by Paul Koning

(resending with the correct HECnet address) > On Jul 25, 2024, at 12:16 AM, Chris Hanson <cmhanson(a)eschatologist.net> wrote: > > I haven’t successfully used SIMH networking on macOS yet but one of the things that I’ve seen in building SIMH with an Xcode project that I created was that there is *a lot* of type confusion in the codebase nowadays: It has lots of use of int, int32, etc. that should actually be one of ptrdiff_t, ssize_t, size_t, off_t, and so on. > > While I appreciate the desire to be compatible with older C89 compilers, this is one of those things that opens one up to subtle bugs on 64-bit platforms—especially when trying to build for a mix of LP64 and ILP64 platforms. I think the better way to handle that would be to provide cover definitions for pre-C99 compilers and pre/non-POSIX systems, so the codebase can use the correct types throughout. I suppose, but Mark P has a point: it doesn't make a whole lot of sense to do major editing on the codebase if it isn't broken. Clearly, ptrdiff and ssize are not issues, because nothing in the SIMH suite creates data structures that are more than 32 bits in size. If we had Alpha emulation for machines that support more than 4 GB of physical memory (if there are any Alphas for which that is true) then for that case the use of size_t would matter, but clearly not for anything else. Off_t is unlikely to be an issue either, unless you needed a virtual disk bigger than 4 GB. Those might, just barely, be supported on VAX (MSCP) and maybe some PDP-11 OS as well, though I know for a fact that RSTS/E tops out right at 4 GB and probably never actually had real disks that big. > Another pretty serious problem is that a lot of platforms set USE_SHARED rather than just USE_NETWORK and wind up “wrapping” the libpcap API, loading the library with dlopen(3) and calling through stubs that have their own prototypes defined. This is extremely dangerous because something like libpcap can adjust its signatures and headers simultaneously to manage source and binary compatibility while changing behavior at the same time. This is especially important when something like libpcap is provided by the OS. Um, the dlopen stuff seems to be an option, and it's only there on Linux as far as I can tell. Is it actually a problem? I'm not sure why it's there, I'll admit that. > ... > Similarly, the conflation of the various different integer types risks becoming a field full of land mines. While one can argue that SIMH is never dealing with enough data to run into 32-bit truncation on 64-bit systems so it’s not worth worrying about, this is another area where “it works fine, don’t change it” is just fine right up until the point where it isn’t. It’d be best to be consistent with POSIX here (rather than self-consistent) and to provide a thin adapter layer for pre-POSIX systems. It does seem that you're hypothesizing possible breakage but I don't see any way that it can happen in reality. Remember that SIMH works on 32 bit systems. It follows that the 32-bit types should not be a problem even if new code would not do it that way. paul

1 year, 2 months

FINGER survey...

by Johnny Billquist

I've been busy with my silly things as usual, and lately implemented a FINGER client and server for RSX, and I realized there are a couple of things to maybe check with other people on HECnet. First of all - finger as such is a (sortof) well known tool/service on the TCP/IP internet. And I've had a finger server and client for TCP/IP under RSX for a long time, but have never really shared it, since it was a bit "odd". But even before this, I knew of a FINGER implementation available from DECUS for RSX. I've known that I wanted to make FINGER available for others for a long time, but recently I started thinking of also adding in DECnet capability in my finger implementation. So the last few weeks I've been tinkering with this, and I've finally completed the work and made my new finger implementation available as a package. The FINGER from DECUS mentions the following: FINGER is a utility to display information about a selected user or group of users. It can be invoked for users on the local node or on a remote node over DECnet, and is com- patible with the VMS implimentation of FINGER. Full function- ality requires an RSX-11M+ system with resource accounting and DECnet. So, not only have there been this RSX implementation from DECUS, there apparently also exist(ed) an implementation from somewhere for VMS. FINGER over TCP uses the well known TCP port 79, while the DECUS RSX (and I assume VMS) DECnet implementation uses object number 117. My implementation then responds to both these access paths, as well as being able to query locally, and also try to connect to remote systems using either of these methods. And I now have this running on MIM:: So my questions are: . Do anyone else have any finger service running on any HECnet node? . Do anyone else know what other implementations even exist, and for which OSes? I do think FINGER is somewhat useful to find who might be logged in and active, as well as finding out more information about people on different systems in general. On the internet, finger servers are nowadays unusual to see, since privacy and security concerned people just feel that finger gives out way too much information anonymously. So I am not encouraging people to run this if they have such concerns. But like I said, personally, I do find it useful, and will keep it available on any RSX system that I am running. 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

1 year, 3 months

Tops-20 Kermit Version 5.3(255)-5 Maintenance Release Announcement

by Thomas DeBellis

Version 5.3(255)-5 incorporates additional features, enhancements and fixes since the minor release of 5.3(248)-5 in November 2023. These are as follows and can be identified in the code with the edit number as the prefix of a comment. [249] Implement relative directory connect [251] Emit new directory name when either wildcarded structure or directory changes [252] Fix some of the directory parsing logic to properly handle .CMDEV and .CMDIR [253] Fix ^A to print the number of pages sent and the total; was always omitting total [254] Implement CDUP, generic 'G' [255] Make CWD accept ".." as token for Unix, DOS, Windows, and OS/2 CDUP The changes were mainly driven to simulator relative directory connection as Tops-20 directory punctuation (I.E., '<' and '>') can too easily be confused with piping requests on some Kermit clients. On some, it proved impossible to convince them otherwise... Generic 'G' is an addition to the Kermit protocol. C-Kermit currently implements this in addition to Tops-20 Available for ANONYMOUS NFT from VENTI2:: and from https://www.kermitproject.org/kermit-20.html.

1 year, 3 months

Re: hii guys..tops20 expert needed

by Anders Andersson

"merlyn drforbin" <kropotkin(a)gmx.com> wrote: >Any way to set endpoint buffer size on panda decnet phase IV Could some of this (in SYSTEM:7-CONFIG.CMD) be what you are looking for? This is from RARITY (not PANDA, but DEC vanilla distribution,kind of), I'm not sure I have the correct values myself, been experimenting. ; DECnet parameters: ;default is DECNET BUFFER-SIZE 576 decnet buffer-size 1476 ;default is DECNET MAXIMUM-BUFFERS 80 ;decnet maximum-buffers 40 -- Anders Andersson, Uppsala, Sweden

1 year, 3 months

← Newer
1
2
3
4
5
6
7
8
...
1559
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet