- HECnet - lists @ Update

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

by R.Voorhorst＠swabhawat.com

I think Paul cannot get these files loaded on his Tops20 V4.1 system from hecnet, being barred by lacking decnet and/or Kermit functionality. In the end (!) the tape recipe works as follows: Get a FRESH copy of tape BB-D867E-BM_TOPS20_V41_2020_INSTL.TAP-1 (after unzip) from Pdp10 archive into a host directory. In simh when the monitor Tops20 V4.1 has been fired up or before: ATT ?F TU0 SIMH G:\TEMP\BB-D867E-BM_TOPS20_V41_2020_INSTL.TAP-1 or your favorite location Then in Tops20: ENA CAP R OPR SET TAPE MTA0: UNAV This may already have been set ^Z EXIT Then in command prompt: REWIND MTA0: to be safe SKIP MTA0: 7 FILES files is necessary else you get some special problems! This bypasses the initial files on the tape R DUMPR TAPE MTA0: PRINT TTY: gives you the contents of the savesets EXIT With modified former commands (RESTORE) in DUMPR you can also retrieve the files necessary. $rew mta0: $skip mta0: 7 fILES $r dumper DUMPER>tape mta0: DUMPER>print tty: ^L DUMPER tape # 1, "SYSTEM files for TOPS-20 V4.1", Thursday, 7-Apr-83 1221 file last write size (pages) checksum DDB for PS:<NEW-SYSTEM> PS:<NEW-SYSTEM>2020-ARPA-MONMED.EXE.1 5-Apr-83 1928 321 PS:<NEW-SYSTEM>2020-ARPA-MONSML.EXE.1 5-Apr-83 1924 321 PS:<NEW-SYSTEM>2020-MONMED.EXE.1 5-Apr-83 1837 326 ETC. Reindert From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Thomas DeBellis Sent: Saturday, 25 December, 2021 04:11 To: hecnet at Update.UU.SE Subject: Re: [HECnet] SIMH TOPS-20 question OK, that's done: you can look at the following on VENTI2: via anonymous FAL T41SUB: => TOMMYT:<OINKY.T2041.NEW-SUBSYS> SYSTEM files for TOPS-20 V4.1, 7-Apr-83 1221 T41SYS: => TOMMYT:<OINKY.T2041.NEW-SYSTEM> SUBSYS files for TOPS-20 V4.1, 7-Apr-83 1223 T41UET: => TOMMYT:<OINKY.T2041.UETP-LIB> UETP files for TOPS-20 V4.1, 7-Apr-83 1226 So NFT does what you think it would, viz: NFT>dirECTORY (OF REMOTE FILES) venti2::T41SUB:*.*.* Access information for node VENTI2::/ACCOUNT: User: Password: [Fork NFT opening DCN:VENTI2-FAL for reading, writing] VENTI2::TOMMYT:<OINKY.T2041.NEW-SUBSYS> ACTGEN.EXE.1;P424242 11 5632(36) 20-Dec-1982 11:52:47 ACTGEN.HLP.1;P424242 1 612(7) 11-Aug-1977 15:44:36 ACTSYM.UNV.1;P424242 20 10104(36) 15-Apr-1982 04:23:27 . . . This is, of course, built into DCL for VMS and RSX. There are hooks for it in Tops-20, but they don't appear to have done it. I also put a 'directory' of the tape in the top level anonymous directory so you can grab it, viz: NFT>dir venti2::TOPS-20-4-1-INSTALLATION.TXT [Fork NFT opening DCN:VENTI2-FAL for reading, writing] VENTI2::TOMMYT:<OINKY> TOPS-20-4-1-INSTALLATION.TXT.1 8 18538(7) 24-Dec-2021 21:49:35 The non-ARPA monitors appear to have DECnet (I.E., NODE% points to NSPSRV, not STG), so maybe you can find something useful. However, I did not see some expected DECnet utilities (like FAL and NFT), so I would assume there is a secondary installation tape for that. This is some really old code; it appears to predate Multinet, or maybe the KS didn't have enough memory to handle both ARPA and DECnet. I'd have to find source someplace. The UETP files are of interest to me for testing purposes. On 12/24/21 8:29 PM, Paul Koning wrote: Ok, thanks. As you may notice, I'm really rather ignorant about TOPS-20. I've never used it before, and only just barely touched it in recent weeks. paul On Dec 24, 2021, at 6:21 PM, Thomas DeBellis <tommytimesharing at gmail.com <mailto:tommytimesharing at gmail.com> > wrote: Let me know how you make out with that. If worse comes to worst, let me know and I will grab the tape, restore the files and give you an ANONYMOUS FAL pointer to grab them. On 12/24/21 5:48 PM, Thomas DeBellis wrote: That would only work for a Tops-20 labeled or ANSI labeled tape. You want to run DUMPER, then tape mt0: rewind print tty: The tapes are not in TPC format, they are in TPS format (if the extention is .TAP, .TPS or TPE) On 12/24/21 4:46 PM, Paul Koning wrote: On Dec 24, 2021, at 3:17 PM, Peter Lothberg <mailto:roll at stupi.com> <roll at stupi.com> wrote: Take MRC's "Panda distribution" if you just want it up and runnning. I'ts somwhere on trailing edge.. -P What I'm trying to do is fill out the missing bits of the TOPS-20 4.1 DECnet Phase II system I have. I think tape image BB-D867E-BM.tap is the relevant kit. When I attached it in TPC format I get some messages that look scary but perhaps they are just confusing. I don't know how to ask TOPS-20 what it sees on the tape, though. "dir mt0:" complains that someone else owns the tape. paul

3 years, 6 months

3
4
0 0

SIMH TOPS-20 question

by paulkoning＠comcast.net

I want to do some more installing of TOPS-20 bits for DECnet testing. The needed tape images seem to be all there on Bitsavers, but they aren't in a format I recognize. SIMH doesn't seem to like them at all. Any ideas? paul

3 years, 6 months

4
9
0 0

SIMH TOPS-20 question --> combined tapeset --> specs

by R.Voorhorst＠swabhawat.com

It is Trailing-Edge - PDP-10 Archives - BB-D867E-BM in .gz format Reindert -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Thomas DeBellis Sent: Saturday, 25 December, 2021 02:19 To: hecnet at Update.UU.SE Subject: Re: [HECnet] SIMH TOPS-20 question --> combined tapeset Hum... Intriguing. Let me grab it and mess around with it. I actually do regular Tops-20 backups and have fixed a number of issues with dumper, so maybe I'll crack it. On 12/24/21 8:09 PM, R. Voorhorst wrote: > Thomas, > > No, he isn't doing bare metal restore but you cannot get this boot tape directly in dumper because the initial files are blocking the savesets. > He only wants to retrieve some files in the savesets. > > I tried to skip files from the rewind state to the point just beyond dumper as some images of this tape give bad exe errors in 4.1, but I fail to pinpoint the start of the savesets. > At the spot of dumper, the tape gives ?bad .exe file format and skipping files beyond does not work either, the tape looks damaged? > Also restoring to a new initialized disk from mtboot itself does not work either at the moment as dumper cannot be started from the tape. > To be continued. > > Reindert > > -----Original Message----- > From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On > Behalf Of Thomas DeBellis > Sent: Saturday, 25 December, 2021 01:22 > To: hecnet at Update.UU.SE > Subject: Re: [HECnet] SIMH TOPS-20 question --> combined tapeset > > simh format would be known as TPS format to KLH10, internally as "Wilson & Supnik" format. This is what klh10 claims to use by default. > > The below is a standard build tape that you boot from, which we always thought was kind of neat. > > I missed that he was building from bare metal. > > On 12/24/21 7:03 PM, R. Voorhorst wrote: >> Paul, >> >> The tape is simh format >> Instead of booting the disk you must boot the tape in simh format and >> the MTBOOT prompt will appear. >> From there onwards, look at the Tops20 V4.1 installation manual in bitsaver. >> >> Swbx04> att -f tu0 simh >> F:\Shares\Distribution\Pdp_10\Media\Tops-20\BB-D867E-BM.tap >> Swbx04> b tu0 >> MTBOOT> >> >> Tape format for V7tape for instance: >> ; Tape directory for V7.0 TOPS-20 installation tape >> ; Bytes: 22519060, Records: 8704, Files(EOF marks): 7 >> TF-Format: raw >> 0: 2560*597 EOF ; MONITR.EXE >> 1528320: 2560*125 EOF ; EXEC.EXE >> 1848320: 2560*8 EOF ; DLUSER.EXE >> 1868800: 1270 EOF ; DLUSER data >> 1870070: 2560*36 EOF ; DUMPER.EXE >> 1962230: 2590*7937 EOF ; DUMPER savesets for <SYSTEM>, etc. >> 22519060: EOF >> EOT: >> >> This tape follows about the same pattern >> >> Reindert >> >> -----Original Message----- >> From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On >> Behalf Of Paul Koning >> Sent: Friday, 24 December, 2021 22:46 >> To: hecnet at update.uu.se >> Subject: Re: [HECnet] SIMH TOPS-20 question >> >> >> >>> On Dec 24, 2021, at 3:17 PM, Peter Lothberg <roll at stupi.com> wrote: >>> >>> Take MRC's "Panda distribution" if you just want it up and runnning. >>> I'ts somwhere on trailing edge.. >>> >>> -P >> What I'm trying to do is fill out the missing bits of the TOPS-20 4.1 >> DECnet Phase II system I have. I think tape image BB-D867E-BM.tap is >> the relevant kit. >> >> When I attached it in TPC format I get some messages that look scary >> but perhaps they are just confusing. I don't know how to ask TOPS-20 >> what it sees on the tape, though. "dir mt0:" complains that someone >> else owns the tape. >> >> paul >> >>

3 years, 6 months

1
0
0 0

SIMH TOPS-20 question --> combined tapeset

by R.Voorhorst＠swabhawat.com

Paul, The tape is simh format Instead of booting the disk you must boot the tape in simh format and the MTBOOT prompt will appear. >From there onwards, look at the Tops20 V4.1 installation manual in bitsaver. Swbx04> att -f tu0 simh F:\Shares\Distribution\Pdp_10\Media\Tops-20\BB-D867E-BM.tap Swbx04> b tu0 MTBOOT> Tape format for V7tape for instance: ; Tape directory for V7.0 TOPS-20 installation tape ; Bytes: 22519060, Records: 8704, Files(EOF marks): 7 TF-Format: raw 0: 2560*597 EOF ; MONITR.EXE 1528320: 2560*125 EOF ; EXEC.EXE 1848320: 2560*8 EOF ; DLUSER.EXE 1868800: 1270 EOF ; DLUSER data 1870070: 2560*36 EOF ; DUMPER.EXE 1962230: 2590*7937 EOF ; DUMPER savesets for <SYSTEM>, etc. 22519060: EOF EOT: This tape follows about the same pattern Reindert -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul Koning Sent: Friday, 24 December, 2021 22:46 To: hecnet at update.uu.se Subject: Re: [HECnet] SIMH TOPS-20 question > On Dec 24, 2021, at 3:17 PM, Peter Lothberg <roll at stupi.com> wrote: > > Take MRC's "Panda distribution" if you just want it up and runnning. > I'ts somwhere on trailing edge.. > > -P What I'm trying to do is fill out the missing bits of the TOPS-20 4.1 DECnet Phase II system I have. I think tape image BB-D867E-BM.tap is the relevant kit. When I attached it in TPC format I get some messages that look scary but perhaps they are just confusing. I don't know how to ask TOPS-20 what it sees on the tape, though. "dir mt0:" complains that someone else owns the tape. paul

3 years, 6 months

2
3
0 0

native Dup sync line revisited --> preliminary tests reveals problems

by R.Voorhorst＠swabhawat.com

L.S. This is the follow-up from the Dup-without-Kdp in character mode discussion somewhat earlier, where I stated it was not supported per the specifications in Simh comments and Mark P had some comments about that it was supported. During a moment of spare time, I reactivated a triple node Rsx-11M+ test set, used for specific Decnet testing for Phase-I to IV. These triple nodes were setup for using every possible device for Decnet communications, amongst them the native (non-kdp) Dup. This one in multipoint mode is character based and is driven through a Rsx Ddcmp software driver to participate in Decnet communications. If Simh Dup simulation is supported in native character mode, this would establish sufficient proof for a well-functioning character based synchronous line. When the Dup line is interfaced to a Dmc line, the test reveals flapping line behaviour: line up - circuit fault - line down; when trying to transfer data an immediate circuit fault appears. When the Dup is interfaced to another Dup, there is packet exchange so basically it should be able to work. However, although there are no problems with the lower length (8) signaling packets, the moment 22 char packets are transferred, the receiver complains about bad header as well as bad data crc checksums, so the packets are somewhat mangled. It prohibits to start Decnet communications. It looks like this in the snippet below: DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D DF 01 28 04 01 40 02 02 00 .........(.. at ... DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D 46 .....F DBG(10561953465)> DUP RCV: rxnexttime=10561870955 (-20000 usecs) DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet len: 22 DBG(10561953465)> DUP PKT: Data Message, Count: 12, Num: 1, Flags: SQ, Resp: 0, HDRCRC: BAD, DATACRC: BAD DBG(10561955696)> DUP PKT: Line0: >>> XMT Packet len: 8 DBG(10561955696)> DUP PKT: Control: Type: 2 (NAK) Reason: 1 (HCRC), Flags: SQ, Resp: 0 DBG(10561955696)> DUP XMT: Line:0 0000 05 02 C1 00 00 01 85 A9 ........ DBG(10561955696)> DUP XMT: rxnexttime=10561953465 (-541 usecs) DBG(10561955696)> DUP PKT: dup_svc(dup=0) - 8 byte packet transmission complete Per Mark P's comment that some kind of filtering takes place in non-kdp dup mode, that might indicate that the source of the problems could be located in that corner. That behaviour needs to be examined. So it looks that basically character mode Dup is (was meant to be) supported, but that it needs to be tuned; this functional mode was probably not tested in the past as the accent was on Ddcmp processing within Simh for Dmc/Dmr and Kdp/Dup device setups. Reindert

3 years, 6 months

5
18
0 0

native Dup sync line revisited --> preliminary tests reveals problems --> test setup?

by R.Voorhorst＠swabhawat.com

Hi Paul, How was this tested: 11M+ to 11M+ or 11M+ to PyDecnet? Reindert -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul Koning Sent: Thursday, 23 December, 2021 02:36 To: hecnet at update.uu.se Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals problems > On Dec 13, 2021, at 9:15 AM, Paul Koning <paulkoning at comcast.net> wrote: > > ... > So if the plain sync device emulation were to do the above, that would give us an emulation that interoperates with the DMC emulation if the software controlling the device is running DDCMP. More on this... I built an M+ system with DUP lines, and unlike what was reported in this thread, I did NOT see problems talking to other things (like PyDECnet or DMC emulation) that expect plain data without frame length fields. I don't see frame lengths in the trace. I don't understand this because the code is clearly there in the emulator, so apparently it's not being hit. Not by DECnet/RSX anyway. More to be studied. paul

3 years, 6 months

3
4
0 0

DECnet/m+

by mark＠matlockfamily.com

?Supratim, Thanks for your comments on the HECnet mail-list. Also, I enjoyed reading about your work modifying the Frodo distribution for a dual ethernet 11/93. Nice work! I?ve been planning to update the Frodo distribution to update some of the layered product software (BasicPlus2, Datatrieve and APL to use I/D space) and the latest TCP/IP including the new updates to the TYDRV that require a SYSGEN to rebuild. BestRegards, Mark > On Dec 22, 2021, at 2:50 PM, Supratim Sanyal <supratim at riseup.net> wrote: > ? > Sorry - Mark already responded. > > There is interesting history behind "FRODO" too ... > > On 12/22/21 1:35 PM, Mark Matlock wrote: > >> Paul, >> You could also download ftp://ftp.trailing-edge.com/pub//rsx_dists/rsx11mpbl87.dsk.bz2 which is >> a baseline RSX11M+ V4.6 disk image ready for a SYSGEN from [200,200] It also has DECnet V4.6 already in [137,10] for a NETgen. This DECnet distribution only generates endnotes however and you may want to get an >> area routing DECnet distribution from MIM. >> >> Also a RSX11M+ V4.6 with DECnet (for Unibus systems) and a very old version of Johnny?s BQTCP/IP is available at: >> >> http://www.rsx11m.com/PiDP11_DU0.zip >> >> It has area routing DECnet running but you would really need to update the TCP/IP but you can FTP >> that from Mim.update.uu.se and get Johnny?s latest version. >> >> Best, >> Mark >> >> >> >> >>> On Dec 22, 2021, at 12:14 PM, Paul Koning <paulkoning at comcast.net> wrote: >>> >>> >>> >>>> On Dec 22, 2021, at 1:07 PM, Johnny Billquist <bqt at softjar.se> wrote: >>>> >>>> Hi, Paul. Sorry I didn't answer earlier. Saw some other mails I should have responded too as well, but been a bit busy. >>>> >>>> Anyway. 4.0 is way old and have various issues you do not want or need. Locate M+ 4.6 instead. That's basically the only version I'd recommend. >>>> And yes, M+ is definitely easier to deal with than 11M. >>>> >>>> You can find both tapes at http://bitsavers.org/bits/DEC/pdp11/magtapes/rsx11mplus/ >>>> >>>> Basically you want BB-J0830-01.L01_RSX11M+_V4.6_BRU_1999.tap, which should be bootable, and contain all you need for M+ itself. There is a second tape (BB-J0830-01.M01_RSX11M+_V4.6_1999.tap), which might be the second tape if the whole thing came on two tapes. (I got M+ 4.6 on TK50, which just came on a single cartridge.) >>>> >>>> Then you want DECnet, which is decnet11mp46-netkit.tap. The manuals are online, but of course you can also just ask. And since you seem to have already managed once, it should hopefully not be too complicated. >>> I used the DECnet 4.0 kit because I could not make sense out of that 4.6 kit. The installation procedure in the manual (DECnet/RSX 4.5, which says it's for M+ 4.3) doesn't work at all with that tape. It says to use FLX to copy PREGEN.CMD from the tape, but the tape isn't anything FLX understands. Instead, it seems to be an ANSI labeled tape with 3 files on it, the first one named "INSTALL". Is that a BRU tape? Or a DSC tape? What do I do with it? >>> >>> paul > --

3 years, 6 months

1
0
0 0

PyDECnet File Transfer Support?

by nf6x＠nf6x.net

Are there any thoughts about adding file transfer capabilities to PyDECnet at some point in the future? If a pyDECnet node could implement a FAL server to share a directory and/or offer a way to copy files to/from other nodes over DECnet, that would be really cool. I think it could make a very nice option for moving files between DECnet nodes and modern systems without needing to wrestle with Linux DECnet drivers or install TCP/IP on the DECnet nodes. I don't know how hard it would be to implement, or if there's any way I could contribute. I'm imagining a silly future in which there is a native Python implementation of an entire RSX-11 or VMS system. :) While I'm here... is this mailing list disappearing soon due to the Update eviction? I plan to chip in for an Update membership for 2022. -- Mark J. Blair, NF6X <nf6x at nf6x.net> https://www.nf6x.net/

3 years, 6 months

7
18
0 0

DECnet/m+

by paulkoning＠comcast.net

I'm trying to build a DECnet/RSX system, and since I've never done anything like that I figured I'd try M+ as (right?) the easiest option. Did a sysgen, that seemed to work ok. Found a DECnet kit on Bitsavers, the 4.0 one marked "3errs", used that to do netgen. That too seemed ok. Now I'm trying "netins". That fails mid-way and I have no clue why: >@[5,1]netins >* Do you want to install and load the CEX system? [Y/N]: y >* Do you want to install and start DECnet? [Y/N]: n >* On what device are the network tasks [D=DU0:] [S]: >INS XX:[5,54]NTINIT >INS XX:[5,54]NTL >INS XX:[5,54]MLD >INS XX:[5,54]EVC >INS XX:[5,54]NCPRES >; INS XX:[5,54]CFERES >; INS XX:[5,54]VNP >INS XX:[5,54]NMVACP >SET /SYSUIC=[5,54] >ASN XX:=LB: >LOA NM:/HIGH/VEC >CON ONL NM: >ASN =LB: >SET /SYSUIC=[2,54] >INS XX:[5,54]LOO >INS XX:[5,54]LOO/TASK=LOO... >INS XX:[5,54]EVFRES >SET /UIC=[5,54] >NCP SET SYS 12:56:33 Task "NTL..." terminated Odd address or other trap four R0=000000 R1=000000 R2=000005 R3=000004 R4=151775 R5=157724 SP=120614 PC=160252 PS=170000 Any ideas? paul

3 years, 6 months

4
15
0 0

SimH ethernet on Windows

by rien.timmer1947＠gmail.com

How do I setup the ethernet connection on Windows in order to enable SimH/VAXVMS to communicate with the world? I used: Set xu enable Set xu eth7 (my Wi-Fi connection) This gives me: sim> sho xu XU address=2013F948-2013F94F, vector=50, BR5, MAC=08:00:2B:00:01:05 type=DELUA, throttle=disabled attached to eth7 But VMS does not recognize UNA-0. Groeten, Rien Timmer

3 years, 6 months

1
0
0 0

Disallow login on DZ line in VMS

by system＠TMESIS.COM

Johnny Billquist <bqt at softjar.se> writes: >That /NOTYPE_AHEAD would disable logins in VMS is a bit surprising. >In my eyes, that's very unintuitive. /NOINTERACTIVE seems much more >sensible (yay for RSTS/E). When a terminal has no associated process and it receives unsolicited input, it forks into routine UNSOL in module TTYSUB. UNSOL notifies the job controller of the occurrance by sending a message to the job cntroller's permanet mailbox. This message contains the device name and precipitates the creation of a login process. There are various other actions based upon the type of terminal and other attributes of the device that may occur prior to the actions of the job controller but without TYPE_AHEAD, none of this occurs. >Sounds like VMS also have /NOINTERACTIVE...? VMS has no /NOINTERACTIVE. Interactive is a process right assigned to a process that is instantiated via an unsolicited interrupt on a terminal device. >In RSX, /NOTYPE_AHEAD just means you don't have any typeahead. If you >try typing something when nothing is reading, the characters are just >thrown away. But if a read is in progress, things works just as normal. I thought this was a question concerning VMS. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.

3 years, 6 months

4
4
0 0

Disallow login on DZ line in VMS

by system＠TMESIS.COM

"Mark J. Blair" <nf6x at nf6x.net> writes: > > >> On Dec 20, 2021, at 6:00 PM, Brian Schenkenberger, VAXman- = ><system at TMESIS.COM> wrote: >>=20 >>> Sounds like VMS also have /NOINTERACTIVE...? >>=20 >> VMS has no /NOINTERACTIVE. Interactive is a process right assigned >> to a process that is instantiated via an unsolicited interrupt on a >> terminal device. > >/NOINTERACTIVE is not listed in the HELP SET TERM text, but SET TERM = >TTAn: /PERM/NOINTERACTIVE is accepted as a command where I tried it in = >v5.5 and v7.3, and it changes the first characteristic shown by SHOW = >TERM from "Interactive" to "Passall". /shrug /[NO]PASSALL is obsolete. You'll also find that it will disable other terminal features you may desire keeping. >From the VMS HELP for SET TERMINAL/TYPE_AHEAD: SET TERMINAL /TYPE_AHEAD /TYPE_AHEAD (default) /NOTYPE_AHEAD Controls whether the terminal accepts unsolicited input to the limit of the type-ahead buffer. When you specify the /NOTYPE_AHEAD qualifier, the terminal accepts input only when a program or the system issues a read to the terminal, such as for user input at the DCL prompt ($). When you specify the /TYPE_AHEAD qualifier, the amount of data that can be accepted is governed by the size of the type-ahead buffer. That size is determined by system generation parameters. >Thank you for your explanation of how a login prompt gets triggered. >That was neat. It's quite different from the way that happens in >unix-like OSes. Yup. Having a getty hanging about on all possible terminals seems a bit 1970 to me. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.

3 years, 6 months

1
0
0 0

Disallow login on DZ line in VMS

by nf6x＠nf6x.net

The recent thread "Disallow system from dz lines (OpenVMS/VAX 7.3)" started me wondering how to entirely disable the login prompts on a given serial line, such as to use the port for some other purpose like controlling external hardware. I've been trying to find out how to do that in the manuals, but I haven't found it yet. It seems like it might be something to do with SET TERM, but I don't see obvious flags for that. Can anybody offer any hints? I won't be too surprised if my eyes have already glided over the answer in the manuals and HELP SET TERM text. -- Mark J. Blair, NF6X <nf6x at nf6x.net> https://www.nf6x.net/

3 years, 6 months

6
8
0 0

Disallow login on DZ line in VMS

by system＠TMESIS.COM

"Mark J. Blair" <nf6x at nf6x.net> writes: >The recent thread "Disallow system from dz lines (OpenVMS/VAX 7.3)" = >started me wondering how to entirely disable the login prompts on a = >given serial line, such as to use the port for some other purpose like = >controlling external hardware. I've been trying to find out how to do = >that in the manuals, but I haven't found it yet. It seems like it might = >be something to do with SET TERM, but I don't see obvious flags for = >that. Can anybody offer any hints? I won't be too surprised if my eyes = >have already glided over the answer in the manuals and HELP SET TERM = >text. Set the terminal line /NOTYPE_AHEAD. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.

3 years, 6 months

1
0
0 0

DECnet/E programming manual / examples

by wboerhout＠gmail.com

Hi folks, I need to port a simple DECnet task-to-task program to RSTS/E V10.1, DECnet/E V4.1 Do any of you PDP-11 buffs have a DECnet/E programming manual. I know bitsavers doesn't. A small example in Fortran, Basic, Basic-Plus will also do. The functionality, expressed in VMS DCL, is as follows: $ open /read /write NETCHN REMOTE::"150=" $ write NETCHN "''f$trnlnm(SYS$NODE)'" $ read NETCHN time $ close NETCHN Thanks, Wilm

3 years, 6 months

4
11
0 0

Disallow system from dz lines (OpenVMS/VAX 7.3)

by supratim＠riseup.net

OpenVMS VAX 7.3: This stops remote logins to SYSTEM even if correct password is provided (works for set host and telnet with Digital TCP/IP, though my version of MULTINET does not honor it). Is there a way to deny SYSTEM account access when correct password is provided from DZ lines? Network:? -----? No access? ------??????????? -----? No access? ------ Batch:??? ##### Full access ######??????????? ##### Full access ###### Local:??? ##### Full access ######??????????? ##### Full access ###### Dialup:?? -----? No access? ------??????????? -----? No access ------ Remote:?? -----? No access? ------??????????? -----? No access ------ Thank you. Supratim

3 years, 6 months

5
9
0 0

continued adventure with buggy DECnet on VAX/VMS 3.5

by supratim＠riseup.net

I turned the Ethernet circuit off and set up a DMC line to DECnet/Python. What seems to be interesting is the Area does not seem to be propagating as part of the DECnet address and confusing DECnet/Python. [Non-Issue, just saying.] The following four things are reported in a loop. Event type 4.11, Initialization failure, line fault#012? From node 31.32 (PIPY), occurred 17-Dec-2021 16:03:05.499#012? Circuit = DDCMP-31-42#012??? Reason = Circuit synchronization lost Event type 4.10, Circuit up#012? From node 31.32 (PIPY), occurred 17-Dec-2021 16:03:15.473#012? Circuit = DDCMP-31-42#012 Adjacent node = 31.42 DDCMP-31-42 packet from wrong node 42 Event type 4.18, Adjacency down#012? From node 31.32 (PIPY), occurred 17-Dec-2021 16:03:15.494#012? Circuit = DDCMP-31-42#012??? Reason = Adjacency address out of range#012 Adjacent node = 31.42

3 years, 6 months

2
3
0 0

LAT

by bqt＠softjar.se

Jeez. After a lot of pain, and still not entirely good, I can at least report some good things about LAT with regards to Linux and RSX. As I mentioned before, there is some kind of a problem between the Linux latd and RSX LAT server. Using llogin to login on RSX systems, the terminal hangs after a while, and there is also some memory leak causing RSX to eventually become non-functional. The Linux latd code is horribly weird and ever after digging through it for days, it still does things I cannot explain. But there is definitely one bug in there, which is that it does not count credits when receiving data_b slots. That means the sender can run out of credits, while the Linux latd thinks the remote still have credits, and will not extend more. The "funny" thing is that Linux latd do count the credits when sending data_b slots. So I'd say that is a very obvious error in Linux latd (also - LAT documentation clearly states that data_b slots counts against credits). I've fixed this, and that solved the hanging problem towards RSX. I'm honestly surprised if this has not been a problem anywhere else, as it's the same for any kind of system. Either other systems are not sending data_b slots, or else there are bugs on more sides. I can provide the patch for this problem, but I wonder if anyone still "owns" that software, to whom I should send this... Second, Linux latd sends attention slots with a stop code of 0x40. This is, according to the LAT documentation, as well as RSX code, an undefined value. Not sure where the Linux latd got that value from. Third, Linux latd is broken when it comes to tracking and dealing with ACKs. This one I have not been able to figure out/understand. I can see on the wire that it's sending packets with a lower ACK number than the previous packet it sent out. Looking at the code, as well as trying to understand this in general seems crazy. It should not be possible for this to happen, but it does. Fortunately, it is on a stop message, for which RSX isn't happy about for other reasons anyway, so it don't matter. But I still thing it's totally crazy. Now, with all that said, I have also had to find and fix a couple of bugs in the RSX LAT code, which also is a little difficult to penetrate. Seems DEC can't really have tested this code that much, and whoever wrote it wasn't careful. Fixed version of the LAT bits have been included in the latest BQTCP distribution. If you install the RSX patches, LAT will be fixed. There are actually two problems I found in there. 1. If a circuit is closed down, and there is currently a transmit in progress, that transmit then becomes a lost buffer upon completion (this is the original RSX error I saw and mentioned before). This is clearly a case of timing issues, which I guess whoever wrote the code just didn't think about, or test carefully. 2. Slot attention messages with a valid stop code cause the system to crash. This is really weird. Because Linux latd was using an undefined value in the attention message, things worked just fine, but if I corrected that, RSX crashed. Which suggests that all terminal servers and other LAT software is in fact also using this wrong value in the attention message. Fixing this was just required saving and restoring a couple of registers at the right place. Again, this can't have been tested at all. Possibly the person writing the code thought he tested it by using DECservers or whatever, but if they actually were sending the wrong code, all looked good, but things did not get executed the way it should. Finally, Linux latd sends a circuit stop message that RSX do not like at all. The reason being that RSX at that point have already deleted the circuit, so it becomes a stop message for a circuit that does not exist. This will cause the illegal message counter to count, but nothing worse than that. I should break out a DECserver and compare to that. But I figure I should let people know about what I've been up to lately, which might also be interesting for others in here... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

3 years, 6 months

2
1
0 0

Wanted: details on "system specific" NICE messages

by paulkoning＠comcast.net

I'm thinking it would be nice (in the tools with PyDECnet) to be able to do not just standard NICE requests like any other NCP, but also system-specific ones. I can find out what the RSTS ones look like, but I don't know about other systems. I'm pretty sure that both VMS and RSX have system-specific requests, SHOW and/or SET, for things like network objects or logical links and perhaps other stuff. Is there documentation that describes these? Does anyone have information handy? A few days ago VMS listings (from fiche) appeared in Bitsavers, and I suppose I can try to read NCP listings that are in there. Chances are they are in BLISS which I don't know at all... paul

3 years, 6 months

2
5
0 0

DECnet-VAX V3.0, VMS V3.5 (Was Re: Oldest VAX/VMS for VAX-11/730 on HECNET) --> Supratim:vms/decnet 3.5 poisoned?

by R.Voorhorst＠swabhawat.com

Hi Supratim, These tapes can be attached to the simh tdc# devices, read on Vms as Dda0: etc, and behave as disk as expected. Functioning on simh Rq (Vms Dua/b) is kind of a fluke. It looks like the decnet on vms 3.5 is poisoned by phase-IV pieces as Ethernet components are present and component versions in sh exec are not on phase-III levels. Is there an original distro for Vms 3.5 with original Decnet 3.5? Analyse/image on the netacp reveals a lot of patching been done on that program and more then netrtg31 itself does and as it carries version 2 the original is likely not there anymore. Reindert From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Supratim Sanyal Sent: Thursday, 16 December, 2021 19:52 To: hecnet at Update.UU.SE Subject: Re: DECnet-VAX V3.0, VMS V3.5 (Was Re: [HECnet] Oldest VAX/VMS for VAX-11/730 on HECNET) --> retract BTW, the "BE-X083A-BE - DECNET-VAX FULL FUNCTION" thing is not a tape; after failing to mount it as a tape numerous times, a "od -a" dump looked like a disk to me, and guess what, it mounted as a RD54. That is the license I used and looks like it patched to DECnet v3.5. I may have a pretty unique installation then, to be preserved. http://iamvirtual.ca/VAX11/VAX-11-software.html Session log: ^M$ @sys$update:vmsinstal.com NETRTG031.A^M ^M ^M VAX/VMS Software Product Installation Procedure^M ^M ^M It is 14-DEC-1984 at 22:33.^M Enter a question mark (?) at any time for help.^M ^M * Are you satisfied with the backup of your system disk [YES]? ^M * Where will the distribution volumes be mounted: sys$manager:^M ^M %VMSINSTAL-E-NOPRODS, None of the specified products were found.^M ^M Enter the products to be installed from the next distribution volume set.^M * Products [EXIT]: *^M ^M The following products will be installed:^M ^M NETRTG V3.1^M NETRTG V4.0^M ^M ^M Beginning installation of NETRTG V3.1 at 22:33^M ^M %VMSINSTAL-I-RESTORE, Restoring product saveset A...^M ^M DECnet-VAX Full Function Key installation^M ^M %PATCH-I-NOLCL, image does not contain local symbols^M %PATCH-I-NOGBL, some or all global symbols not accessible^M %PATCH-I-WRTFIL, updating image file VMI$ROOT:[SYSUPD.NETRTG031]NETACP.EXE;1^M %VMSINSTAL-I-MOVEFILES, Files will now be moved to their target directories...^M ^M Successful installation of NETRTG V3.1 at 22:33^M ^M ^M ^M Beginning installation of NETRTG V4.0 at 22:33^M ^M %VMSINSTAL-I-RESTORE, Restoring product saveset A...^M %NETRTG-E-BADVMS, This kit requires version 4.0 of VMS.^M %VMSINSTAL-E-STEP8FAIL, The installation of NETRTG V4.0 has failed.^M ^M Enter the products to be installed from the next distribution volume set.^M * Products [EXIT]: ^M ^M VMSINSTAL procedure done at 22:33^M ^M On 12/16/2021 12:54, Paul Koning wrote: You may have a license problem. If you have a DECnet that supports Ethernet, it must be Phase IV (or V, of course). That means it is required to know about areas. If you have a version that doesn't deal with areas, either it is terminally broken or it is crippled in a way that disables multi-area configurations. You'll need to fix that in order to use it on HECnet. While it's certainly possible to put a Phase III node anywhere in HECnet, with the reachability limitations that Phase III has, it isn't possible to use a "broken areas" Phase "IV" node at all. (Well, unless you can connect it into area 1, I suppose.) paul On Dec 16, 2021, at 11:08 AM, Supratim Sanyal <mailto:supratim at riseup.net> <supratim at riseup.net> wrote: On 12/16/2021 05:41, R. Voorhorst wrote: Question remains, how did you get Decnet 3.0 running and did you obtain the necessary patch. Yes, applied the license. I chose VAX/VMS 3.5 because in March of 2020 you had gone as far as getting a license error on VMS3.0 that said it needed VMS3.4+. I also tried to use the licensed NETACP.EXE on vms3.0, does not look promising, says it has problems loading. At this point, Cisco may be the answer with the nifty feature for DECnet NAT, I will explore it sometime. Anyway, my experiments are here if you or anyone is interested: https://www.dropbox.com/sh/x4e6ie4lrwi9wns/AABMogcguAcL8xPwMIDxOtNva?dl=0 On 12/16/2021 04:55, Johnny Billquist wrote: Uh? The mac address AA-00-04-00-2A-7C means it has address 31.42. Just sayin... It's forced at the Linux/SimH level. On 12/15/2021 20:05, Paul Koning wrote: You've got to set MAX AREA large enough; 63 is the obvious value. With it not set, the system apparently is defaulting it to 1, so when you gave it a node address without area number it defaulted the area number to 1, which of course can't work. There is no option, at least in NCP, for any Area parameters. NCP>help set exec SET EXECUTOR Use the SET EXECUTOR command to create or modify parameters in the volatile database which controls the network on the executor node. Use the DEFINE EXECUTOR command to create or modify parameters in the volatile database which controls the network on the executor node. SET EXECUTOR (parameters ...) Additional information available: ALL ADDRESS node-address BROADCAST ROUTING TIMER BUFFER SIZE number COUNTER TIMER seconds DEFAULT ACCESS DELAY FACTOR DELAY WEIGHT IDENTIFICATION INACTIVITY TIMER INCOMING TIMER MAXIMUM ADDRESS MAXIMUM BROADCAST NONROUTERS MAXIMUM BROADCAST ROUTERS MAXIMUM BUFFERS MAXIMUM CIRCUITS MAXIMUM COST MAXIMUM HOPS MAXIMUM LINKS MAXIMUM VISITS NONPRIVILEGED OUTGOING TIMER PIPELINE QUOTA PRIVILEGED RETRANSMIT FACTOR ROUTING TIMER SEGMENT BUFFER SIZE STATE SUBADDRESS range TYPE Examples NODE SET EXECUTOR Subtopic? SET EXECUTOR Subtopic? ex SET EXECUTOR Examples NCP>SET EXECUTOR ADDRESS 11 BUFFER SIZE 576 This command sets the executor node's address to 11 and buffer size to 576 bytes. NCP>SET EXECUTOR STATE ON This command sets the executor node's operational state to ON. SET EXECUTOR Subtopic? ^Z NCP>exit $ -- Supratim Sanyal, W1XMT 39.19151 N, 77.23432 W QCOCAL::SANYAL via HECnet

3 years, 6 months

4
3
0 0

Oldest VAX/VMS for VAX-11/730 on HECNET

by nf6x＠nf6x.net

I'm trying to find the oldest VAX/VMS version which: * Supports DECnet Phase IV over ethernet * Supports the VAX-11/730 * I can get my hands on images of the OS installation and anything (licenses?) needed for DECnet Phase IV I found a .tap image of the VAX/VMS 3.0 distribution at the Russian mirror site. Version 3.0 interests me because I think it was the one that was released to coincide with the VAX-11/730 release. I was able to install it on a SIMH emulation of the 730. I gather that the normal VAX/VMS 3.0 distribution for the VAX-11/730 would be on an RL02 pack instead of a magtape, and I hope that I might figure out how to reconstruct an RL02 pack distribution from what is on the tape image. I have not found any scans of the DECnet-VAX Software Installation Guide or the DECnet-VAX System Manager's Guide yet, and I don't know what needs to be done to install and/or configure DECnet in such an old VMS version. I see that stuff related to DECnet is present after installation, such as STARTNET.COM and NCP.EXE, but DECnet-VAX is referred to as an optional component which must be licensed separately. I gather from discussions elsewhere that there may be at least one critical file missing that serves as the "license" for DECnet-VAX? STARTNET.COM comments instruct that it can be run after creating the permanent database, and trying to run it generates errors like: $ @sys$manager:startnet.com %OPCOM, 8-DEC-1982 13:55:13.31, message from user NETACP DECnet starting %NCP-I-NMLRSP, listener response - File open error, Permanent database %RMS-E-FNF, file not found I don't know how to create the permanent database under VAX/VMS 3.0 yet. I tried running NCP.EXE and issuing a SET EXECUTOR command. It asks for a node address in the range of 1..255, so does that imply that whatever (incomplete?) DECnet code is present there is for Phase III? I'm experimenting with SIMH VAX-11/730 simulations for now. Eventually, I'd like to downgrade the OpenVMS v7.3 installation that came on my real VAX-11/730's R80 drive to something less bloated and more contemporary with my system, but still able to connect to HECNET over ethernet. -- Mark J. Blair, NF6X <nf6x at nf6x.net> https://www.nf6x.net/

3 years, 6 months

9
39
0 0

DECnet-VAX V3.0, VMS V3.5 (Was Re: Oldest VAX/VMS for VAX-11/730 on HECNET) --> retract

by R.Voorhorst＠swabhawat.com

Sorry, misread the header so my assumptions were wrong Question remains, how did you get Decnet 3.0 running and did you obtain the necessary patch. From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of R. Voorhorst Sent: Thursday, 16 December, 2021 10:35 To: hecnet at Update.UU.SE Subject: RE: DECnet-VAX V3.0, VMS V3.5 (Was Re: [HECnet] Oldest VAX/VMS for VAX-11/730 on HECNET) --> what is this? Supratim, The log is somewhat strange: Decnet 3.0 is phase III, but your executor listings gives management version 4.0.0 and routing version 2.0.0 and type nonrouting IV. Besides, Decnet 3.0 is phase-III and will not support Ethernet, ever (yet you have Una-0 line/circuit), so there is somewhat wrong in your total decnet configuration or you are trying out something unmentioned yet. My executor for Decnet 3.0 gives the following: Node Volatile Characteristics as of 16-DEC-2021 10:15:29 Executor node = 84 (SWBV84) Identification = SWBV84 DNET-3.0 R-III (63).84 Management version = V3.0.0 Incoming timer = 45 Outgoing timer = 45 NSP version = V3.2.0 Maximum links = 32 Delay factor = 64 Delay weight = 2 Inactivity timer = 60 Retransmit factor = 10 Routing version = V1.3.0 Type = routing Routing timer = 600 Maximum address = 255 Maximum circuits = 32 Maximum cost = 40 Maximum hops = 9 Maximum visits = 10 Maximum buffers = 128 Buffer size = 576 Default access = incoming and outgoing But it will not work because we only have a licemse for another version. In the id I placed area 63 as memento as it will communicate with phase-IV routers up to address 255 in that area and these nodes will assume node 84 to be present in that area. I am curious how you got an operating license to make this work or is that what creates the flaws? Reindert From: owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE> [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Supratim Sanyal Sent: Thursday, 16 December, 2021 01:01 To: hecnet at Update.UU.SE <mailto:hecnet at Update.UU.SE> Subject: DECnet-VAX V3.0, VMS V3.5 (Was Re: [HECnet] Oldest VAX/VMS for VAX-11/730 on HECNET) OK, so I fired up a VAX/VMS 3.5 node and gave it the address 42 (just a coincidence, not an answer to any question). I demoted it to an end-node on a dedicated virtual ethernet adapter for the circuit with DECnet/Python. No adjacency is established. A tshark indicates DECnet-VAX V3.0 is appearing as 1.42 on the wire. Since there is no way to ask DECnet-VAX V3.0 to pretend it is 31.42, I am not sure what the next step, if any, might be to hook this up to my area on HECnet. tshark dump is at https://www.dropbox.com/s/40hvr4x6iq3esl8/tshark-31.12-31.42-DECnet-VAX-V3.… . Maybe Paul has some advice? Note: When DECnet-VAX V3.0 was configured as a L1 router, it oscillated between "circuit up" and "line fault" every few seconds. $ mc ncp show exec char Node Volatile Characteristics as of 14-DEC-1984 23:46:34 Executor node = 42 (XXXV) Identification = DECnet-VAX V3.0, VMS V3.5 Management version = V4.0.0 Incoming timer = 45 Outgoing timer = 45 NSP version = V3.2.0 Maximum links = 32 Delay factor = 80 Delay weight = 5 Inactivity timer = 60 Retransmit factor = 10 Routing version = V2.0.0 Type = nonrouting IV Routing timer = 600 Broadcast routing timer = 40 Maximum address = 1023 Maximum circuits = 16 Maximum cost = 1022 Maximum hops = 30 Maximum visits = 63 Max broadcast nonrouters = 64 Max broadcast routers = 32 Maximum buffers = 100 Buffer size = 576 Nonprivileged user id = DECNET Default access = incoming and outgoing Pipeline quota = 1200 $ mc ncp show circuit una-0 char Circuit Volatile Characteristics as of 14-DEC-1984 23:47:01 Circuit = UNA-0 State = on Service = disabled Cost = 3 Router priority = 64 Hello timer = 15 Type = Ethernet $ mc ncp show line una-0 char Line Volatile Characteristics as of 14-DEC-1984 23:47:20 Line = UNA-0 Receive buffers = 4 Controller = normal Protocol = Ethernet Service timer = 4000 Hardware address = AA-00-04-00-2A-7C Buffer size = 1498 Regards, Supratim On 12/9/21 7:40 PM, Paul Koning wrote: On Dec 9, 2021, at 6:02 PM, Johnny Billquist <mailto:bqt at softjar.se> <bqt at softjar.se> wrote: On 2021-12-09 23:52, Mark J. Blair wrote: So, basically like bang paths in uucp? Maybe I will play with that sometime! Yes. But depending on application, it might be that all machines have to be up and running at the moment you're trying to use it, as opposed to UUCP which was store and forward. Right. Roughly speaking, the sending application sees that there are multiple nodes, and that it uses PMR for this. It connects to the first of the nodes, object 63. It then sends it the rest of the connect information. PMR picks off the next node. If that's the last node, it connects to the requested object, otherwise again to another PMR. VMS has PMR-like capability for network file access because RMS recognizes file names with node name prefixes, so it's an automatic consequence of that feature. RSTS NFT (the application which does network file access) doesn't support PMR as far as I remember. So if you have VMS nodes around you can chain node names in file access, with RSTS-only you cannot. MAIL does it internally I think. Some vague memory says that RSTS network terminal ("set host") has PMR support, I need to look. I'll definitely add PMR to PyDECnet at some point fairly soon. paul --

3 years, 6 months

4
4
0 0

DECnet-VAX V3.0, VMS V3.5 (Was Re: Oldest VAX/VMS for VAX-11/730 on HECNET) --> what is this?

by R.Voorhorst＠swabhawat.com

Supratim, The log is somewhat strange: Decnet 3.0 is phase III, but your executor listings gives management version 4.0.0 and routing version 2.0.0 and type nonrouting IV. Besides, Decnet 3.0 is phase-III and will not support Ethernet, ever (yet you have Una-0 line/circuit), so there is somewhat wrong in your total decnet configuration or you are trying out something unmentioned yet. My executor for Decnet 3.0 gives the following: Node Volatile Characteristics as of 16-DEC-2021 10:15:29 Executor node = 84 (SWBV84) Identification = SWBV84 DNET-3.0 R-III (63).84 Management version = V3.0.0 Incoming timer = 45 Outgoing timer = 45 NSP version = V3.2.0 Maximum links = 32 Delay factor = 64 Delay weight = 2 Inactivity timer = 60 Retransmit factor = 10 Routing version = V1.3.0 Type = routing Routing timer = 600 Maximum address = 255 Maximum circuits = 32 Maximum cost = 40 Maximum hops = 9 Maximum visits = 10 Maximum buffers = 128 Buffer size = 576 Default access = incoming and outgoing But it will not work because we only have a licemse for another version. In the id I placed area 63 as memento as it will communicate with phase-IV routers up to address 255 in that area and these nodes will assume node 84 to be present in that area. I am curious how you got an operating license to make this work or is that what creates the flaws? Reindert From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Supratim Sanyal Sent: Thursday, 16 December, 2021 01:01 To: hecnet at Update.UU.SE Subject: DECnet-VAX V3.0, VMS V3.5 (Was Re: [HECnet] Oldest VAX/VMS for VAX-11/730 on HECNET) OK, so I fired up a VAX/VMS 3.5 node and gave it the address 42 (just a coincidence, not an answer to any question). I demoted it to an end-node on a dedicated virtual ethernet adapter for the circuit with DECnet/Python. No adjacency is established. A tshark indicates DECnet-VAX V3.0 is appearing as 1.42 on the wire. Since there is no way to ask DECnet-VAX V3.0 to pretend it is 31.42, I am not sure what the next step, if any, might be to hook this up to my area on HECnet. tshark dump is at https://www.dropbox.com/s/40hvr4x6iq3esl8/tshark-31.12-31.42-DECnet-VAX-V3.… . Maybe Paul has some advice? Note: When DECnet-VAX V3.0 was configured as a L1 router, it oscillated between "circuit up" and "line fault" every few seconds. $ mc ncp show exec char Node Volatile Characteristics as of 14-DEC-1984 23:46:34 Executor node = 42 (XXXV) Identification = DECnet-VAX V3.0, VMS V3.5 Management version = V4.0.0 Incoming timer = 45 Outgoing timer = 45 NSP version = V3.2.0 Maximum links = 32 Delay factor = 80 Delay weight = 5 Inactivity timer = 60 Retransmit factor = 10 Routing version = V2.0.0 Type = nonrouting IV Routing timer = 600 Broadcast routing timer = 40 Maximum address = 1023 Maximum circuits = 16 Maximum cost = 1022 Maximum hops = 30 Maximum visits = 63 Max broadcast nonrouters = 64 Max broadcast routers = 32 Maximum buffers = 100 Buffer size = 576 Nonprivileged user id = DECNET Default access = incoming and outgoing Pipeline quota = 1200 $ mc ncp show circuit una-0 char Circuit Volatile Characteristics as of 14-DEC-1984 23:47:01 Circuit = UNA-0 State = on Service = disabled Cost = 3 Router priority = 64 Hello timer = 15 Type = Ethernet $ mc ncp show line una-0 char Line Volatile Characteristics as of 14-DEC-1984 23:47:20 Line = UNA-0 Receive buffers = 4 Controller = normal Protocol = Ethernet Service timer = 4000 Hardware address = AA-00-04-00-2A-7C Buffer size = 1498 Regards, Supratim On 12/9/21 7:40 PM, Paul Koning wrote: On Dec 9, 2021, at 6:02 PM, Johnny Billquist <mailto:bqt at softjar.se> <bqt at softjar.se> wrote: On 2021-12-09 23:52, Mark J. Blair wrote: So, basically like bang paths in uucp? Maybe I will play with that sometime! Yes. But depending on application, it might be that all machines have to be up and running at the moment you're trying to use it, as opposed to UUCP which was store and forward. Right. Roughly speaking, the sending application sees that there are multiple nodes, and that it uses PMR for this. It connects to the first of the nodes, object 63. It then sends it the rest of the connect information. PMR picks off the next node. If that's the last node, it connects to the requested object, otherwise again to another PMR. VMS has PMR-like capability for network file access because RMS recognizes file names with node name prefixes, so it's an automatic consequence of that feature. RSTS NFT (the application which does network file access) doesn't support PMR as far as I remember. So if you have VMS nodes around you can chain node names in file access, with RSTS-only you cannot. MAIL does it internally I think. Some vague memory says that RSTS network terminal ("set host") has PMR support, I need to look. I'll definitely add PMR to PyDECnet at some point fairly soon. paul --

3 years, 6 months

1
0
0 0

wanted

by supratim＠riseup.net

what is WANTED.TXT? $ type mim::hecnet:wanted.txt VENUS??? ??? Steve Davidson SATURN??? ??? Steve Davidson URANUS??? ??? Steve Davidson LOKI??? ??? John Floren MILRAT??? ??? Allison CESSNA??? ??? Allison GOZER??? ??? Dan Williams MARVIN??? ??? Dan Williams MUMRA??? ??? Dan Williams CAIRO??? ??? Sridhar Ayengar DELHI??? ??? Sridhar Ayengar TOKYO??? ??? Sridhar Ayengar PARIS??? ??? Sridhar Ayengar DALLAS??? ??? Sridhar Ayengar NYC??? ??? Sridhar Ayengar AUSTIN??? ??? Sridhar Ayengar LONDON??? ??? Sridhar Ayengar MADRID??? ??? Sridhar Ayengar OSAKA??? ??? Sridhar Ayengar NAGOYA??? ??? Sridhar Ayengar KOBE??? ??? Sridhar Ayengar MACAU??? ??? Sridhar Ayengar BOMBAY??? ??? Sridhar Ayengar PERTH??? ??? Sridhar Ayengar SYDNEY??? ??? Sridhar Ayengar TUNIS??? ??? Sridhar Ayengar WARSAW??? ??? Sridhar Ayengar MIAMI??? ??? Sridhar Ayengar BERLIN??? ??? Sridhar Ayengar --

3 years, 6 months

3
4
0 0

FW: native Dup sync line revisited --> preliminary tests --> update logging Dup-Dmc communications

by R.Voorhorst＠swabhawat.com

L.S. Testing as it was done on the dup-dmc combination with the dmc side used as kind of proven reference. The initial section is a log (see pdf link: https://drive.google.com/file/d/1-m3h5fpvv3JHHUYWi3zgX_qtfm3g1aRs/view?usp=… as Hecnet seems to disallow pdf attachments) of a dmc-dmc connection that works out of the box and leads to a Decnet adjacency up message. Note that the dmc logging is not exactly time-sequential, therefor it is separated according to time stamp which reveals that xmt and rcv logging is not strictly ordered with respect to flow of time. This snippet shows the exact packets that are exchanged with their correct crc checksums. The dup-dmc logging in the second section below, can be arranged in lockstep with xmt/rcv and reveals an interesting anomaly where it seems somewhere in the beginning in dup two packets are coalesced, that at least is present in the dup logging, although the dmc does see it as two packets. >From there onwards, dup-dmc are getting in a loop. It looks like the dup logging itself is neither consistent or constant (some lines are sometimes present and later on missing). The coalescing probably indicates some error(s) in dup simulation leading to the dmc dancing around with the dup in bad crc error reporting, although the checksums of the packets look ok, until some form of reset takes place and then it starts all over again. Now it may be time to zoom in. Reindert

3 years, 6 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet