HECnet

hecnet@lists.dfupdate.se

15586 discussions

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

by gerry77＠mail.com

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

3 years, 11 months

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

by R.Voorhorst＠swabhawat.com

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

3 years, 11 months

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

by bqt＠softjar.se

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

3 years, 11 months

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

by R.Voorhorst＠swabhawat.com

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

3 years, 11 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet