HECnet

hecnet@lists.dfupdate.se

15586 discussions

by Dan B

anybody would know where to sind power supply schematics for vaxstation vaxserver 10 3100 (not sure if 20 uses same schematics)

3 years, 6 months

Does anyone have a Tops20 printer daemon that prints to a IP network printer?

by Peter Lothberg

Does anyone have a Tops20 printer daemon that prints to a IP network printer? -P

3 years, 6 months

Pydecnet Router

by Iain Hardcastle

Hi all, Is there way to have PDR accept arbitrary TCP Multinet connections? This works: circuit mul-123 Multinet 207.123.123.123:15001:listen --cost 8 --t3 120 While this does not: circuit mul-123 Multinet 0.0.0.0:15001:listen --cost 8 --t3 120 I'm sure I've had it working before.. Problem is, that remote 207 address is dynamic. Cheers, iain

3 years, 7 months

Does anyone have simh RSX-11 running DECnet on a simulated DUP11 ?

by Trevor Warwick

I've got some proposed changes to the DUP11 simulation code in simh, that could do with a quick regression test to make sure they don't break when using RSX as the OS. I don't know RSX myself, and I haven't managed to turn up any useful info via google on how to configure a DUP11 with RSX. If anyone has a fairly simple recipe for getting this working then I could have a go at testing it. However, the test required is pretty simple, basically just to confirm that DECnet still works when using a version of simh that contains my fix. So ideally, if one of you out there is running this configuration, we could work together to try it out. Thanks, Trevor

3 years, 7 months

Rebooting your klh10 pseudo-RSX20F master front end

by Thomas DeBellis

For some reasons that I'll get into at some other time, putting a timeout into BOOT didn't work to get me a crash dump. So I looked at things the other way around to see what I could do to get dvdte.c to fool the PDP-10 code that the master front end had rebooted, which I have been meaning to do for some ten years now. After some trial and error, I finally got something that worked, viz: /* Ten forcing a reload? */ if (op10m_tlnn(w, (DTE_CMT_L11))) { char *fet = NULL; /* Front end type not known, yet */ if (dt->dt_ismaster) /* Is this the master? */ fet = "master"; /* Yes, remark on that */ else fet = "restricted"; /* Oh dear... Restricted DTE performance is unknown */ fprintf(dt->dt_dv.dv_dbf, /* Finally blat about it */ "[DTE: PDP-10 forcing a reload on FE%d (%s)]\r\n", dt->dt_dten,fet); /* N.B., we have *NO* code for MCB or DN60 */ dt->dt_reld11 = -1; /* Set the reload-11 button */ dt->dt_rcv_11qc = 0; /* Reset queue count; we've rebooted! */ dt->dt_secptcl = TRUE; /* Force secondary protocol */ return; /* Return, caller will invoke dte_dosecp() */ } This will let an unaltered BOOT get you a crash dump, viz: BOOT V11.0(315) BOOT>dump.exe/d [BOOT: Dumping] [OK] Number of pages written: 17734 Number of I/O requests: 203 BOOT>meamon [BOOT: Loading] [OK] After Tops-20 gets itself going, DDMP: Started Copying system dump from: TOMMYT:<SYSTEM>DUMP.EXE.1 to: TOMMYT:<SYSTEM>DUMP-21745-ILLUUO.CPY.1 [Copied dump to TOMMYT:<SYSTEM>DUMP-21745-ILLUUO.CPY.1] I haven't seen messages like this since about 1985, so it was kind of eerie watching all this low level code just...working. I have not tested the dvdte.c modification to see if it will prevent a DTEKPA BUGINF from hanging everything, but I believe it should. Maybe I'll check that after I fix what caused the crash in the first place. So I'm looking at the ILLUUO crash dump and it seems that all my fine code got smashed by the symbol table... Phooey.

3 years, 7 months

area 23 will be offline for awhile

by Mark G Thomas

Hi, Due to a combination of things, I'm going to need to take down my area 23 hecnet router, probably for a 3-6 months. Near term, I'm short on hobby time, need to do some significant network reconfiguration, and need to put back together one or several decnet worthy systems, after some rather frustrating hardware failures. Ideally, I should have more time late summer or fall, once my kid is in school and some other pressures let up. I'm not going anywhere, and appreciate the groupmembers here who have been so helpful over the years about so many DEC and non-DEC things. My current peers are as follows, though some of them are currently down. interface Tunnel50 description HECnet tunnel for Brian Hechinger (Area 52) [Version:311] interface Tunnel51 description HECnet tunnel for Ian McLaughlin (Area 42) [Version:311] interface Tunnel52 description HECnet tunnel for Cory Smelosky (Area 9) [Version:311] interface Tunnel53 description HECnet tunnel for Dave McGuire (Area 61) [Version:311] interface Tunnel54 description HECnet tunnel for Supratim Sanyal (Area 31) [Version:311] interface Tunnel57 description HECnet tunnel for Tim Sneddon (Area 12) [Version:311] interface Tunnel58 description HECnet tunnel for Mark Darvill (Area 22) [Version:311] interface Tunnel1098 description tunnel to Peter Lothberg <roll(a)Stupi.SE> (STORTR 59.61) interface Tunnel1099 description tunnel to Peter Lothberg <roll(a)Stupi.SE> (IAD2 59.1020) Mark -- Mark G. Thomas <Mark(a)Misty.com>, KC3DRE

3 years, 8 months

Have you been able to take a crash dump on your PDP-10? (Actually an RSX20F/DTE question)

by Thomas DeBellis

Does anybody know how I could find out what the PDP-11 front end running RSX20F is supposed to do when it is forced to reboot by the PDP-10? What else does it do besides go into secondary protocol and signal the 10 that it is alive? The klh10 micro-engine does not currently handle this and it is affecting my ability to take a crash dump. The saga is below. ------------------------------------------------------------------------ *The Background*: I ran into an unexpected issue when reworking some of the logic in TTYSRV to 'normalize' the arguments to the GETOK%. Again, the ACJ can't do much directly with a JFN as it is a small number that has no meaning outside of job context. I'm not sure that you could (easily) figure out what the JFN means with SNOOP% and PEEK%, either, because the active JSB is the ACJ's and not that of the fork pending on the GETOK%, which means you have to map that and then chase down the OFN (which might not be so bad). Since other monitor GETOK%'s which are asking about file related JFN's (say for Secure files and directories) resolve the JFN to the actual text of the file specification, having the terminal device resolved before feeding the GETOK% seemed like the right thing to do and I reworked some code, which was basically some reordering. The monitor assembled just fine, no .PSECT complaints. There are 25 pages free in section zero, but everything I've done is all in the swappable monitor (NRCOD .PSECT), so I didn't expect any problems there, either. So everything looks fine, I've done it a bunch of times before, yet: BOOT>tlinkm [BOOT: Loading] [OK] [TOMMYT mounted] VENTI2, PANDA TOPS-20 Monitor 7.1(21745)-5 Internet: Loading host names [OK] System restarting, wait... Date and time is: Friday, 8-April-2022 8:32PM Why reload? other debug Run CHECKD? no [KLH10: Illegal exec mode op, PC = 0: 0 0,0] ********** *BUGHLT "ILLUUO" *ADDITIONAL DATA: 300000000001, 000000000001, 000000000000 ********** [DTE: Unsupp sts bits 240020,,32463] [HALTED: Program Halt, PC = 1043534] Well! That's not very promising. Actually, kind of stunning. The monitor has transferred control into accumulator zero, which contains a zero, which is an illegal opcode. That can show up as an Illegal UUO (I'll get to the DTE bits in a minute). I couldn't believe it was my code, so I did the obvious thing and break-pointed it with Executive DDT (EDDT), viz: BOOT>TLINKM/L Loads the monitor, does not start it BOOT>/g141 Starts monitor Executive DDT (SYSDDT) EDDTF[ 1 Keeps EDDT locked in memory DBUGSW[ 2 Write-enable swappable monitor GOTSWM$B Breakpoint after swappable monitor loaded 147$G Normal start up When it hits the breakpoint: CALL SWPMLK$X Lock swappable monitor CALL SWPMWE$X Write-enable swappable monitor Set a breakpoint in the TLINK% JSYS entry and proceed .TLINK$B $P And... Same thing. So that means my code is effectively dark at the point of the crash because the breakpoint is never hit. It would appear that the additional 93 (decimal) words I wrote pushed something someplace, causing an address space overwrite. That is puzzling, as I would have thought that LINK would have caught that or the postlude. Whatever it is, it means that it's time for a crash dump and some quality time with FILDDT and other utilities. I dusted off MAKDMP, duly created an 8,193 page DUMP.EXE and rebooted, crashed with an ILLUUO, reloaded BOOT and started it to get the crash dump (with the /D, switch). And I got that odd DTE message and a hung machine. KLH10> load boot.sav Using word format "c36"... Loaded "boot.sav": Format: DEC-CSAV Data: 4630, Symwds: 0, Low: 040000, High: 054641, Startaddress: 040000 Entvec: JRST (120 ST: 0147, 124 RE: 0, 137 VR: 500701,,21745) KLH10> go Starting KN10 at loc 040000... [DTE: Unsupp sts bits 240020,,32463] KLH10>> halt [HALTED: FE command, PC = 772446] KLH10> Some more poking around shows that BOOT is hung in the following loop, waiting for a response from the 11 that never comes. SETEP4: MOVEI Q1,.DTMMN ;MONITOR MODE ON MOVEM Q1,DTECMD ; STORE IN COMMAND J5: MOVEI Q1,TO11DB ;RING THE BELL XCT DTCNOW ;DO IT J6: SKIPN DTEFLG ;WAIT FOR COMPLETION J7: JRST .-1 ; ... BOOT is forcing the 11 into something called by Tops-20 to be 'monitor mode'. This does not happen on the normal first boot case because at that time, the enumeration of devices has not taken place and the DTE is not known nor is it connected to the priority interrupt system. When BOOT is reloaded, the PDP-10 hardware is already conditioned and BOOT detects this. What the KLH10 DTE code sees is that a request has come in with bit 200000 high in the left half word, which is the LOAD-11 indicator. And it doesn't have code to handle that, viz: if (op10m_tlnn(w, (DTE_CMT_PWF|DTE_CMT_L11|DTE_CMT_INI))) { fprintf(dt->dt_dv.dv_dbf, "[DTE: Unsupp sts bits %lo,,%lo]", (long)LHGET(w), (long)RHGET(w)); return; } That's the message that is coming out, above. What can be seen is that the PDP-11 has not been signaled that anything has happened, so it waits for something to happen, except that now dvdte is waiting for another command which the 10 will never issue. I have seen this behavior before. Sometimes, the klh10 micro-engine can get so active that a clock interrupt from the host operating system doesn't come in time for the keep alive counter to be incremented. The 20 declares the 11 down, issues a DTEPKA BUGINF, attempts to restart it and ...everything hangs... At the time I addressed the issue with a hack: I put programmable waits into DTESRV (set via the BOOT% JSYS) and gave the micro-engine a chance to catch its breath before Tops-20 lowers the boom. So one way to address the issue is to hack BOOT not to wait forever. It's a hack, but it will get the job done. I think... The other is to change dvdte.c to do what a regular 11 running RSX20F would do.

3 years, 8 months

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

by Johnny Billquist

Time for a new release announcement of TCP/IP for RSX-11M-PLUS. This is version 2.10 of BQTCP/IP. It's been three months since the last official update. Some major improvements and bugfixes have been done, and it is strongly recommended that systems are updated. Some of the errors fixed could cause system crashes under the right conditions. Highlights: . Improved TCP performance . Improved telnet behavior and features . Improved ftp/ftpd behavior . Improved mail daemon . More RSX patches Detailed information on things that have been done since the last release: ARP: . Bugfix in ARP cache timer. If the time to the next event related to the ARP cache was too big, the timer stopped. IP: . Bugfix. IP packet processing could cause a crash with fragmented packets. TCP: . Improve TCP flow control. . Fix to make sure TCP socket in last-ack state will time out. . Improved TCP reception code. (Sequence and window check.) . Improved TCP probe handling and keepalive handling. . Improved TCP retransmit handling. . Changed semantics of TCP window update statistics. . Improved TCP performance by better ACK handling at packet loss. . Improved TCP window update and ack sending. . Improved TCP retransmit and congestion recovery. IFCONFIG: . Added more TCP tuning parameters to IFCONFIG. FTP/FTPD: . Fix FTPD log file lock error. Implemented retries. . Bugfix in FTP and FTPD. When block mode read of files was done, a multibuffer implementation was used which did not free memory at completion. . Added cleartext error messages in FTP and FTPD. . Changed ftp directory Unix format timestamp. MAILD: . Improved MAILD SMTP server to better handle relaying and bad host detection. . Improved MAILD mail delivery to not do parallel delivery to the same destination by several tasks. . Changed MAILD to use possibly multiple tasks for delivering new mails, since to some destinations, mail deliver can be really slow. Also changed SMTP mail receiver to accept mails from hosts even if they present bogus host names in HELO/EHLO command. . Added some more spoof notification calls in smtp mail receiver. TELNET/TELNETD: . Improve telnet option negotiation in server and client. . Added terminal type option to telnet client. . Removed binary mode from telnet client. . Added processing of SB/SE functions in telnet client. . Added processing of SB/SE functions in telnet server. . Added proper handling of terminal names in telnet server. . Added proper handling of terminal names in telnet client. Multinet: . Bugfix in Multinet. Under some circumstances, the timers would stop. LPT: . Added hardtab expansion in LPT printer despooler. . Added a simple TXT print spooler symbiont. XLISP: . Changed XLISP INET daemon functionality to use a filename based on port connection accepted on. Patch updates: . Datatrieve-11: . Fixed DTR leap year bug. . Fixed DDMF (remote DTR) server to set correct default directory. . Improve DTR programming interface to allow DECnet to work in parallel with DTR. . Updated MCR. . Added patched ACNT, PSW and SYSLOG to distribution. . Added patched NVPFSL.TSK to distribution. . Added patched HELRES.TSK to distribution. 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 or LAT. 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... 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. 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. On a final note, Mim have moved. Mim.Update.UU.SE does not exist anymore as a domain name. The machine is now only available as Mim.Stupi.NET. 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 years, 8 months

Tops-20 CTY, Part 4

by Thomas DeBellis

I finally finished some initial code for the access control job (ACJ) to detect and report spying. The documentation and monitor code for TLINK% were confusing enough that I initially just write wrote some code to break out what was being sent so I could figure out how it all worked. Some random things I found of note: When a job is first created and the EXEC is getting cranked up, it calls TLINK% called to refuse links, viz: 9-Apr-2022 18:06:21 ACJ: TLINK% SAB:CLR Obj:-1 by job 10, user not logged in user, program , TTY46 The -1 argument for the object means, "My Terminal", in this case TTY46 is being conditioned to refuse links. On a batch login, I refuse links and advice, as can be seen by the below: 8-Apr-2022 23:29:18 ACJ: TLINK% STA:CLR Obj:-1 by job 11, user SLOGIN, program TERMIN, TTY21 8-Apr-2022 23:29:18 ACJ: TLINK% SAB:CLR Obj:-1 by job 11, user SLOGIN, program TERMIN, TTY21 The EXEC commands which did this are: Terminal (feature or type) NO Receive Advice Terminal (feature or type) NO Receive Links The batch job in question was MONGEN, because I'm in the middle of tweaking a few things in the TLINK% JSYS code to make my life easier in the ACJ. Since I'm impatient, from the following you can see that I did an ^Epeek to watch the batch job execute: 8-Apr-2022 23:29:21 ACJ: TLINK% ERO Obj:-1 Rem:21 by job 10, user SLOGIN, program EXEC, TTY46 The regular (non-debugging) code which displays this is less nerdy and maybe easier on the eyes, viz: 8-Apr-2022 23:29:21 ACJ: SPYING: user SLOGIN, Job 11, TTY21 by job 10, user SLOGIN, program EXEC, TTY46 Maybe I'll put in some extra code to break out whether one of them is batch or the line type. Or something. Right now, I'm just making the JSYS code in TTYSRV easier for me to work with. Some of it dates back to TENEX days and it's been modified to the extent that I found it confusing to work with (but that's me). The actual problem is that the GETOK% is called before the arguments are resolved. It is not explicitly laid out in the JSYS reference manual that, unlike the first terminal argument (which must be a terminal designator), the second can be a JFN, which is worthless outside of job context. So it needs to get converted to a line number before it gets handed to the ACJ.

3 years, 8 months

try #4: area 23 will be offline for awhile

by Mark G Thomas

Hi, I'm trying again, as I suspect maybe the mailing list has been rejecting my prior attempts due to some case sensitivity in matching submitting e-mail senders with subscriber addresses. If this message makes it, maybe someone can investigate, as I expect it might cause grief for others too. Due to a combination of things, I'm going to need to take down my area 23 hecnet router, probably for a 3-6 months. Near term, I'm short on hobby time, need to do some significant network reconfiguration, and need to put back together one or several decnet worthy systems, after some rather frustrating hardware failures. Ideally, I should have more time late summer or fall, once my kid is in school and some other pressures let up. I'm not going anywhere, and appreciate the groupmembers here who have been so helpful over the years about so many DEC and non-DEC things. My current peers are as follows, though some of them are currently down. interface Tunnel50 description HECnet tunnel for Brian Hechinger (Area 52) [Version:311] interface Tunnel51 description HECnet tunnel for Ian McLaughlin (Area 42) [Version:311] interface Tunnel52 description HECnet tunnel for Cory Smelosky (Area 9) [Version:311] interface Tunnel53 description HECnet tunnel for Dave McGuire (Area 61) [Version:311] interface Tunnel54 description HECnet tunnel for Supratim Sanyal (Area 31) [Version:311] interface Tunnel57 description HECnet tunnel for Tim Sneddon (Area 12) [Version:311] interface Tunnel58 description HECnet tunnel for Mark Darvill (Area 22) [Version:311] interface Tunnel1098 description tunnel to Peter Lothberg <roll(a)Stupi.SE> (STORTR 59.61) interface Tunnel1099 description tunnel to Peter Lothberg <roll(a)Stupi.SE> (IAD2 59.1020) Mark -- Mark G. Thomas <Mark(a)Misty.com>, KC3DRE

3 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet