- HECnet - lists @ Update

Suits and old software. (was RE: Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective)

by Keith Halewood

If only one could get into contact with the relevant 'suit' seeking old software. A while back I mentioned Algol68RS and the VAX/VMS version of the compiler I used during my university days... And how I wish I knew where that TK50 was containing a backup I made in... 1987? Ah well. The RS version of the compiler was the work of RSRE Malvern (a Ministry of Defence unit) and the VAX code generator was written at University of Oxford. Significant bits of the RS compiler were released to the public domain as part of Ella and there's a transliterator to C available. It isn't the RS compiler though. Moreover, it is the VAX/VMS version of the compiler. I've been in contact with the two (or is it three) companies, Oxford University, Liverpool University (where I last used that compiler) and in each case, the conversation (if such a word could be used) has dwindled to nothing pretty quickly. In the case of the companies, I can only assume the suits saw no potential profit in it, assuming they knew what 'compiler', VAX, VMS or Algol68 meant. My communication with Oxford may not have gone beyond their 'call management system' and Liverpool's archives in that area don't go back that far and/or the tapes are unreadable.... or Sandra the operator burned the toast again causing halon and sprinkler damage some time in the past. Blah -----Original Message----- From: Johnny Billquist [mailto:bqt@softjar.se] Sent: 01 February 2022 02:39 To: hecnet(a)lists.dfupdate.se Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective On 2022-02-01 03:10, Dave McGuire wrote: > On 1/31/22 8:28 PM, Johnny Billquist wrote: >>>> Because for some people, that "near zero risk" is maybe not so >>>> "near zero", and that have actual implications for actual people. >>> >>> Yes, but they've been poorly (and selfishly) prioritized. >> >> Yeah. Tell that to their kids when they are thrown into the street. > > I do see your point, but it's an increasingly hypothetical point. That might be. And I probably agree with it. But each person has to do his own assessment on that point. And it might not look the same for all. >>>> You seem to really just treat it as "there is no risk, so why >>>> aren't people just doing whatever I think they should do", without >>>> considering that for others the situation might actually look very >>>> different. >>> >>> You've jumped to a conclusion about what I think, and (with >>> respect) you're incorrect. I think risking some suit in a glass >>> building getting angry with me, or even filing a lawsuit against me, >>> is not, and will never be, more important than a piece of history >>> that stands to be lost forever. >> >> Seems you just described exactly what I tried do describe above. So >> how did I get it wrong? > > What I'm saying is that it's better to do something for the greater > good, than to "play it safe" with some hypothetical "risk" that some > suit at HPE (or whomever) will somehow come after you about > decades-old software that they've never even heard of. > > I mean, come on. Yes, the potential consequence is huge, but the > risk is vanishingly small. Yes, it has happened, I'm well aware of > that. But the risk is still vanishingly small. Dave obviously was *very* worried about potential risks that he was not willing to take. The amount of papers I had to sign before I got access should tell you something. And he have (had?) information I don't have. So I prefer to not second guess him, but just trust that he made his decisions based on the information he had, and they made sense for him. And I'll just accept that, and respect his decisions. >>>> If you've experienced that recently, then I am a little amazed. >>>> Because that means people have been hanging on to things for a >>>> *long* time, but now they don't care. Which for me sounds like an >>>> unusual situation. >>>> But of course, everything is possible. >>> >>> Then be amazed. It happened most recently just a few months ago, >>> and several times last year. This is a lot more common in the real >>> world than you've assumed. >> >> Hmm. Maybe we're talking about something else than PDP-11 software now? > > Actually it hasn't come up about PDP-11 software; it was VAX > software most recently. Ah. Yes. VAX is a different story. There things are still fresh, so it's a different ballpark. So I apologize. I was very much PDP-11 focused in my responses. VAX, in a way, seems to be falling down into the same pit the PDP-11 is in. But it's far more recent, so a lot of stuff is still around at a different scale. And of course, VMS as such isn't dead, which is kind of a different situation as well. >> Considering that I'm usually even more overlooked than you are, you >> can go with that complaint somewhere else. > > I will (sorry) but everyone who knows what a PDP-11 is knows your > name. ;) Not even that. It's not too uncommon that I get into some discussion and people have no clue. This mailing list and environment isn't exactly representative for people in general out there. Just go check on VCF (or whatever the name is, I can't even remember - vintage computing something...) >> Take PDP-8 stuff for example - I've been around the block, done more, >> seen more, and have more information and stuff than most everyone on >> those lists nowadays. But I don't actually care anymore. They can >> talk and do things as much as they want. I don't need them, and they >> don't even know I exist. Their problem. Not mine. And since it's also >> not a problem for them, it's not a problem at all. > > I'm with you on that. But passing knowledge on is important, and > far too few people do it. The excuse I hear most often is "nobody's > interested in this stuff". From my point, it's more that it's so much a club for internal admiration. People are more interested in their turf than actually finding information. Take the ftp site of Update. It's been around since the early 90s. Still, most people don't know about it. And lots of stuff have been copied out from there elsewhere, and that's where people find various bits and pieces. And a bunch of PDP-8 stuff there are things that I dragged out of numerous disks and DECtapes I have. Most of it done in the 90s. Some of it still totally unknown by others. And various software that I've written as well... >> It's only a problem when you want attention and recognition. > > Or if you just want to be kept in the damn loop once in a while. That mostly happens by accident, unless you are in the center. >> I'm daily facing the same dilemma. I have done so much improvements >> to RSX. I'd like to release V5.0, which I have sitting here. But I can't. >> I signed documents with XX2247 that limits what I can do, and I am >> not willing to break the trust Dave put in me. Even though that >> improved version have lots of stuff that would be really fun to share. >> >> Instead I'm trying to find ways of resolving the problem. Meanwhile >> it's sitting at my place, and nowhere else. > > I will run that within *minutes* of its release. Assuming I'm > still breathing, of course! Who knows when I can do it. I keep hoping... But every year, there will be fewer interested. >>>> Until the day I die... Who knows what happens then. >>> >>> Well, I'm trying to get more (and younger) people interested in >>> PDP-11s, and I'm having pretty good success at that. You could try >>> that too. >> >> I'll leave that to others. I'm busy just fixing things in RSX... >> If someone really interested comes along, I'm happy to help with >> information and guidance, but I'm not trying to enlighten people. > > Well, we do that a lot at LSSM. In particular, there's a teenage > kid who lives in Michigan who is OBSESSED with PDP-11s. He's writing > code in assembler and running it under simh. He doesn't know this > yet, but the next time his parents bring him down here for a visit, > I'm going to give him a PDP-11/73. That should be exciting. :-) Also, will be interesting if it carries over to working on real hardware as compared to simh. 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 _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

3 years, 5 months

1
0
0 0

Unsubscribe

by Rien Timmer

Groeten, Rien Timmer

3 years, 5 months

1
0
0 0

DN60 etc. --> Anf10 family based?

by R. Voorhorst

Thomas, If I recall correctly it is Anf10 related and has it's own runtime and Chk11 for initial testing of hardware. Thus it had to fit in 28 kW; no relations to Rsx11 or even RT11. The code pieces then should be *.P11 etc. Reindert -----Original Message----- From: Thomas DeBellis [mailto:tommytimesharing@gmail.com] Sent: Monday, 31 January, 2022 21:22 To: hecnet(a)lists.dfupdate.se Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective Then we are probably talking apples and pineapples. The product that I'm talking about is exclusively for the 36 bit line, requiring a DTE to get the data to the PDP-10. I think it also needed a KMC to do some offloading, so the 11/34 could keep up, but I wouldn't swear to it. There's code for a KMC, anyway. The software appears to be a complete embedded design: there are no users, no file system, minimum memory management and no task preemption. Thus, I don't believe it has any code basis in either RSX or RSTS. I wouldn't be surprised if part of it got lifted from RT-11, but I don't have an informed opinion on that. The DN60/DN65 spoke 2780, 3780 and HASP. The first two are remote job entry (RJE) 'workstations' that had card readers and line printers (no terminals). HASP is a variant that IBM did not develop, yet adopted. I believe it was wizzy because it allowed multiple concurrent streams. The job of IBMSPL was to fool the remote IBM host that a card deck was being submitted by a timesharing user and to take the resulting print output and to get it to wherever the right place was (printer, file, etc.) I don't recall a 3271, I guess you mean those green screen terminals? What a beast... I do recall using 3270, 3276 and the like when I was hacking the bisync drivers on VM to talk to IBMSPL. There was a product that you could run on Tops-20 to show up as a 3270 on an IBM box, provided the target spoke TCP/IP. I can't remember the name, but it was based on TELNET negotiating some additional options. It's a lot of work; a 3270 is not like anything you ever heard of in ÅSCII land. A number of us swore that IBMSPL was the only reasonable way to use an IBM mainframe as the 3270 was a half-duplex terminal that was all to ready to lock the keyboard if you even thought of typing ahead. The more modern emulators don't lock like that, but you are still effectively in a late 1960's half duplex paradigm. Still. Today. Really. On 1/31/22 3:00 PM, Paul Koning wrote: > What I mentioned is one or several PDP-11 products, available for RSTS and I believe RSX. There definitely is an "RJ2780 emulator" -- the official name may not be quite that. And I think there was also a 3271 emulator, though I'm not sure if that existed on RSTS. > > I have no idea what these things do, since 2780 is something I've never used. Some sort of remote job entry station? Anyway, it is the only RSTS software that uses a KG11. DECnet doesn't because on RSTS DECnet only supported devices with hardware CRC: DMC and friends and later Ethernet. I did an unsupported software DDCMP, but that does CRC in software (8 bits at a time, the classic table driven fast software implementation). That probably outruns a KG11 and in any case I never had access to that hardware. > > paul > >> On Jan 31, 2022, at 2:52 PM, Thomas DeBellis <tommytimesharing(a)gmail.com> wrote: >> >> I wanted to make sure I wasn't getting lost; are you referring to the PDP-11 software that forms part of the Galaxy IBM workstation product? It's called DN60/DN65 and also does 3780 and HASP. Is this what you're referring to? >> >> On 1/31/22 2:48 PM, Peter Allan wrote: >>> Paul Koning wrote ... >>> >>>> Correct, I was not aware it's possible to use it. The only software I have seen that uses the KG11 is 2780 emulation. >>> I am very interested in getting 2780 emulation for a PDP-11. >>> >>> Paul, or anyone else, do you know where I can get it? >>> >>> Cheers >>> >>> Peter Allan >>> _______________________________________________ >>> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send >>> an email to hecnet-leave(a)lists.dfupdate.se >> _______________________________________________ >> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send >> an email to hecnet-leave(a)lists.dfupdate.se > _______________________________________________ > HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an > email to hecnet-leave(a)lists.dfupdate.se _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

3 years, 5 months

1
0
0 0

KG11 emulation probably defective -->diagnostic ZKGAB0 for KG11 runs without complaints.

by R. Voorhorst

L.S. The diagnostics in XXDP for KG11 completes without problems, so far, so good. It limits the scope to interface problems between Decnet11MP and Simh KG11. Reindert -----Original Message----- From: R. Voorhorst [mailto:R.Voorhorst@swabhawat.com] Sent: Sunday, 30 January, 2022 16:18 To: 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se> Subject: [HECnet] Re: native Dup sync line revisited --> KG11 emulation probably defective --> initial exploration L.S. Reviewing the code from J. Dundas reveals it passed a diagnostic ZKGAB0 which is a xxdp component. There are listings of maindecs, no sources and the microfiche listing quality is quite low, so restoration of source code is laborious at best. It also happens to be a component of Anf10 for Tops10 and any image has a quick check for the KG11 if configured to be present. I think for now the chance that the KG11 itself is somehow corrupt is low regarding the well specified design path followed in creation, so probably a mismatch between Rsx11 software and the current KG11 implementation is more probable cause. It also appears the KG11 was used in the Rsts corner for Dup, Dp and Du and the Ibm 2780 interfaces. The docs in simh KG11 does not reveal whether it was tested in a simulated actual software system. Lacking the diagnostics sources except Chk11.P11 which is very limited in scope, XXDP might be the ultimate quickest way to test it. Reindert -----Original Message----- From: R. Voorhorst [mailto:R.Voorhorst@swabhawat.com] Sent: Sunday, 30 January, 2022 09:53 To: 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se> Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> KG11 emulation probably defective Apart from morons with an incurable inclination to the complex difficult thereby shooting in the own feet like me .... ? I do not know, but I suppose on Rsx11 the serial async Decnet lines might use KG11 assisted crc16 generation/checking as well and the problem might be in Rsx11M software itself, less likely, or more likely in KG11 simulation. Johnny might know this. As I have done the KG8 I think I am more predisposed to look at the KG11 excepting the writer of the KG11 simulation, so I will check for the existence of a diagnostic, will see what goes wrong and propose a fix. KG11 is not a complex device. Best regards, Reindert -----Original Message----- From: Mark Pizzolato - Info Comm [mailto:Mark@infocomm.com] Sent: Sunday, 30 January, 2022 01:26 To: R. Voorhorst <R.Voorhorst(a)swabhawat.com>; hecnet(a)lists.dfupdate.se Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective On Saturday, January 29, 2022 at 4:04 PM, R. Voorhorst wrote: > L.S. > > With a bit time on hand and the standstill after Paul's initial test > from dup to pydecnet which appeared to be successful, I now undertook > a test as Mark liked to have it preferably. > So I did a fresh netgen on a simple configuration from simple basic > install Rsx11MP system for only a Decnet end-node with one single Dup > line communicating to a known working Pdp11 Rsx11MP Dmc circuit. > > I saw no difference from what I reported initially and later with > logging, as was to be expected; my complex setup behaves exactly the > same in this respect as it does for years in a complex network setup > for Rsx and Rsts, and > RT11 without network. > > This is on a Windows-2008R2 server and I suspect Paul did his test on > unix/linux , however although it differs, that should be moot as far > as Simh is concerned. > > There could be another difference though. Paul would probably have > taken the default route and used Ddcmp withouth KG11 support: Dup > without Kdp is the only sync line to use it, though async Decnet > DL/DZ/VH might use it as well. > As I prefer the most complex configs possible (any two of a kind where > possible as Dec used to have them), I do also employ the KG11, so for > Dup support it will be used when configured so in Decnet11MP. > On a sim it is not that effective, but in hardware in the past it did > make a difference for fast crc computing. > > So I retested with no KG11 support and indeed, now the Dup works as > expected. > What appears to be strange is, that small packets up to 8 bytes are > not corrupted but the larger ones do. Maybe in Decnet11MP, the small > packets are totally preconfigured in the software program with crc > inclusive and the > KG11 is then bypassed effectively, bu, that should have to be > verified. At least the combination KG11 and Decnet11MP KG11 support is defective. > > So Simh Dup works in software Ddcmp packet generation, but the Simh > KG11 seem to generate bad checksums and/or checks. > For the Pdp8A, I have a functioning KG8 simulation that works in > Rts-8, so there is a test reference to fall back on. > > So I admit and confirm that basic Dup in simh software wise between > Pdp11's and with various counterparts (DMC) indeed works, which would > make it serve as a base for other sync line implementations like DP8-E(A). So, you've proven to yourself that the KG11 is at least somewhat broken. Looking back at the change history for this device, I've made changes relating to how it glues into the PDP11 I/O space, but nothing at all about how the device actually functions. What else uses this device? Is there a diagnostic? - Mark _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

3 years, 5 months

6
13
0 0

Re: KG11 emulation probably defective -->diagnostic ZKGAB0 for KG11 runs without complaints. --> Crc on Rsx11 async lines

by R. Voorhorst

By the way, Johnny, was KG11 also used on serial async Decnet11MP lines or was that always software? Reindert -----Original Message----- From: Johnny Billquist [mailto:bqt@softjar.se] Sent: Monday, 31 January, 2022 08:15 To: hecnet(a)lists.dfupdate.se Subject: [HECnet] Re: KG11 emulation probably defective -->diagnostic ZKGAB0 for KG11 runs without complaints. I agree that it would be nice to confirm that this works in real hardware, but I also find it unlikely that it wouldn't. While DEC was not perfect, I would expect that they actually had tested this before releasing the software. Johnny On 2022-01-31 01:51, R. Voorhorst wrote: > @Dave: > > It would only be worth the time and energy to prove if current > Decnet11MP in combination with KG11 would work in a Dup to Dup or Dmc > connection, which in hardware take a serious effort. > In virtual reality it is far more easy to arrange such things. > Unless I cannot find a bug quickly enough, then it could be helpful to > request you to check on it. > > > Thanks though for the time being. > > Reindert > > -----Original Message----- > From: Dave McGuire [mailto:mcguire@neurotica.com] > Sent: Sunday, 30 January, 2022 18:25 > To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se> > Subject: [HECnet] Re: KG11 emulation probably defective -->diagnostic > ZKGAB0 for KG11 runs without complaints. > > On 1/30/22 12:21 PM, Mark Pizzolato - Info Comm wrote: >> On Sunday, January 30, 2022 at 5:34 AM, Reindert wrote: >>> The diagnostics in XXDP for KG11 completes without problems, so far, >>> so > good. >>> It limits the scope to interface problems between Decnet11MP and >>> Simh > KG11. >> >> We really don't know how robust the diagnostic is and if it exercises >> the same details that are used by the DDCMP implementation. >> >> You could run the DDCMP case with KG11 debugging enabled and identify >> what > it is doing precisely and then go back and see if the diagnostic is > doing the same stuff... > > I have a KG11-A board; if it would be helpful, I can install it in > a > PDP-11 at LSSM perhaps this week. > > -Dave > > -- > Dave McGuire, AK4HZ > New Kensington, PA > _______________________________________________ > HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an > email to hecnet-leave(a)lists.dfupdate.se > > _______________________________________________ > HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an > email to hecnet-leave(a)lists.dfupdate.se -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

3 years, 5 months

2
1
0 0

Re: native Dup sync line revisited --> KG11 emulation probably defective --> initial exploration

by R. Voorhorst

L.S. Reviewing the code from J. Dundas reveals it passed a diagnostic ZKGAB0 which is a xxdp component. There are listings of maindecs, no sources and the microfiche listing quality is quite low, so restoration of source code is laborious at best. It also happens to be a component of Anf10 for Tops10 and any image has a quick check for the KG11 if configured to be present. I think for now the chance that the KG11 itself is somehow corrupt is low regarding the well specified design path followed in creation, so probably a mismatch between Rsx11 software and the current KG11 implementation is more probable cause. It also appears the KG11 was used in the Rsts corner for Dup, Dp and Du and the Ibm 2780 interfaces. The docs in simh KG11 does not reveal whether it was tested in a simulated actual software system. Lacking the diagnostics sources except Chk11.P11 which is very limited in scope, XXDP might be the ultimate quickest way to test it. Reindert -----Original Message----- From: R. Voorhorst [mailto:R.Voorhorst@swabhawat.com] Sent: Sunday, 30 January, 2022 09:53 To: 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se> Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> KG11 emulation probably defective Apart from morons with an incurable inclination to the complex difficult thereby shooting in the own feet like me .... ? I do not know, but I suppose on Rsx11 the serial async Decnet lines might use KG11 assisted crc16 generation/checking as well and the problem might be in Rsx11M software itself, less likely, or more likely in KG11 simulation. Johnny might know this. As I have done the KG8 I think I am more predisposed to look at the KG11 excepting the writer of the KG11 simulation, so I will check for the existence of a diagnostic, will see what goes wrong and propose a fix. KG11 is not a complex device. Best regards, Reindert -----Original Message----- From: Mark Pizzolato - Info Comm [mailto:Mark@infocomm.com] Sent: Sunday, 30 January, 2022 01:26 To: R. Voorhorst <R.Voorhorst(a)swabhawat.com>; hecnet(a)lists.dfupdate.se Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective On Saturday, January 29, 2022 at 4:04 PM, R. Voorhorst wrote: > L.S. > > With a bit time on hand and the standstill after Paul's initial test > from dup to pydecnet which appeared to be successful, I now undertook > a test as Mark liked to have it preferably. > So I did a fresh netgen on a simple configuration from simple basic > install Rsx11MP system for only a Decnet end-node with one single Dup > line communicating to a known working Pdp11 Rsx11MP Dmc circuit. > > I saw no difference from what I reported initially and later with > logging, as was to be expected; my complex setup behaves exactly the > same in this respect as it does for years in a complex network setup > for Rsx and Rsts, and > RT11 without network. > > This is on a Windows-2008R2 server and I suspect Paul did his test on > unix/linux , however although it differs, that should be moot as far > as Simh is concerned. > > There could be another difference though. Paul would probably have > taken the default route and used Ddcmp withouth KG11 support: Dup > without Kdp is the only sync line to use it, though async Decnet > DL/DZ/VH might use it as well. > As I prefer the most complex configs possible (any two of a kind where > possible as Dec used to have them), I do also employ the KG11, so for > Dup support it will be used when configured so in Decnet11MP. > On a sim it is not that effective, but in hardware in the past it did > make a difference for fast crc computing. > > So I retested with no KG11 support and indeed, now the Dup works as > expected. > What appears to be strange is, that small packets up to 8 bytes are > not corrupted but the larger ones do. Maybe in Decnet11MP, the small > packets are totally preconfigured in the software program with crc > inclusive and the > KG11 is then bypassed effectively, bu, that should have to be > verified. At least the combination KG11 and Decnet11MP KG11 support is defective. > > So Simh Dup works in software Ddcmp packet generation, but the Simh > KG11 seem to generate bad checksums and/or checks. > For the Pdp8A, I have a functioning KG8 simulation that works in > Rts-8, so there is a test reference to fall back on. > > So I admit and confirm that basic Dup in simh software wise between > Pdp11's and with various counterparts (DMC) indeed works, which would > make it serve as a base for other sync line implementations like DP8-E(A). So, you've proven to yourself that the KG11 is at least somewhat broken. Looking back at the change history for this device, I've made changes relating to how it glues into the PDP11 I/O space, but nothing at all about how the device actually functions. What else uses this device? Is there a diagnostic? - Mark _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

3 years, 5 months

1
0
0 0

Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> KG11 emulation probably defective

by R. Voorhorst

Apart from morons with an incurable inclination to the complex difficult thereby shooting in the own feet like me .... ? I do not know, but I suppose on Rsx11 the serial async Decnet lines might use KG11 assisted crc16 generation/checking as well and the problem might be in Rsx11M software itself, less likely, or more likely in KG11 simulation. Johnny might know this. As I have done the KG8 I think I am more predisposed to look at the KG11 excepting the writer of the KG11 simulation, so I will check for the existence of a diagnostic, will see what goes wrong and propose a fix. KG11 is not a complex device. Best regards, Reindert -----Original Message----- From: Mark Pizzolato - Info Comm [mailto:Mark@infocomm.com] Sent: Sunday, 30 January, 2022 01:26 To: R. Voorhorst <R.Voorhorst(a)swabhawat.com>; hecnet(a)lists.dfupdate.se Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective On Saturday, January 29, 2022 at 4:04 PM, R. Voorhorst wrote: > L.S. > > With a bit time on hand and the standstill after Paul's initial test > from dup to pydecnet which appeared to be successful, I now undertook > a test as Mark liked to have it preferably. > So I did a fresh netgen on a simple configuration from simple basic > install Rsx11MP system for only a Decnet end-node with one single Dup > line communicating to a known working Pdp11 Rsx11MP Dmc circuit. > > I saw no difference from what I reported initially and later with > logging, as was to be expected; my complex setup behaves exactly the > same in this respect as it does for years in a complex network setup > for Rsx and Rsts, and > RT11 without network. > > This is on a Windows-2008R2 server and I suspect Paul did his test on > unix/linux , however although it differs, that should be moot as far > as Simh is concerned. > > There could be another difference though. Paul would probably have > taken the default route and used Ddcmp withouth KG11 support: Dup > without Kdp is the only sync line to use it, though async Decnet > DL/DZ/VH might use it as well. > As I prefer the most complex configs possible (any two of a kind where > possible as Dec used to have them), I do also employ the KG11, so for > Dup support it will be used when configured so in Decnet11MP. > On a sim it is not that effective, but in hardware in the past it did > make a difference for fast crc computing. > > So I retested with no KG11 support and indeed, now the Dup works as > expected. > What appears to be strange is, that small packets up to 8 bytes are > not corrupted but the larger ones do. Maybe in Decnet11MP, the small > packets are totally preconfigured in the software program with crc > inclusive and the > KG11 is then bypassed effectively, bu, that should have to be > verified. At least the combination KG11 and Decnet11MP KG11 support is defective. > > So Simh Dup works in software Ddcmp packet generation, but the Simh > KG11 seem to generate bad checksums and/or checks. > For the Pdp8A, I have a functioning KG8 simulation that works in > Rts-8, so there is a test reference to fall back on. > > So I admit and confirm that basic Dup in simh software wise between > Pdp11's and with various counterparts (DMC) indeed works, which would > make it serve as a base for other sync line implementations like DP8-E(A). So, you've proven to yourself that the KG11 is at least somewhat broken. Looking back at the change history for this device, I've made changes relating to how it glues into the PDP11 I/O space, but nothing at all about how the device actually functions. What else uses this device? Is there a diagnostic? - Mark _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

3 years, 5 months

1
0
0 0

Re: HECnet Digest, Vol 2, Issue 9

by Wilm Boerhout

I am forwarding all enquiries for the hardware in Zoetermeer. Expect to hear from Tony M. Wilm -----Original Message----- From: hecnet-request(a)lists.dfupdate.se <hecnet-request(a)lists.dfupdate.se> Sent: Saturday, January 29, 2022 5:45 PM To: hecnet(a)lists.dfupdate.se Subject: HECnet Digest, Vol 2, Issue 9 Send HECnet mailing list submissions to hecnet(a)lists.dfupdate.se To subscribe or unsubscribe via email, send a message with subject or body 'help' to hecnet-request(a)lists.dfupdate.se You can reach the person managing the list at hecnet-owner(a)lists.dfupdate.se When replying, please edit your Subject line so it is more specific than "Re: Contents of HECnet digest..."

3 years, 5 months

1
0
0 0

TIMEX3 Error?

by Thomas DeBellis

An XKL monitor can stay up longer than a standard DEC or PANDA monitor. However, there is no way for a program to detect this with the TIME% JSYS. XKL defined a magic value to put into AC1 that is looked for and, if it is not there, the call is failed with a TIMEX3 error. Does anybody either know the definition of TIMEX3 or where I could get it? It's not in the PANDA MONSYM.

3 years, 5 months

1
0
0 0

Re: How long has your 20 been up?

by Thomas DeBellis

[Apologies if this is duplicate, I wasn't sure what list was active and when] Thanks for the URL, I'll put it into the enhancement list. I'm still not sure what I would put into the monitor and what would go into a light weight (or full) NTP client, but I'll have a think about it. Passing on to the Department of Pointless Programming, I 'enhanced' uptime to handle the maximum 70 bit millisecond uptime. It is: VENTI2 up for 37539161 Millennia, 7 Centuries, 2 Decades, 9 Years, 8 Weeks, 2 Days, 11 Hours, 35 Minutes, 3 Seconds and 423 Milliseconds So 37 million millennia is .../umm/... well it's a long time. In fact, at well over two and half times the current age of the universe, it may even be long enough for politicians to evolve into decent, caring, thinking individuals. The math was actually unremarkable, I changed an integer divide instruction into a routine to handle single (IDIV), double (DIV) and quadruple intermediate results (DDIV), picking the fastest divide that wouldn't overflow. The harder part was rewriting the grammatical routines to properly inflect plural noun cases. Once you get past Years, English numerological noun inflection is no longer agglutanive (like Spanish) but rather fusional, being more akin to Latin and Italian (and considered 'irregular'). So the routine did the wrong thing. A little more than half the systems programming staff at Columbia were bi-lingual, some spoke three or more languages. So it bugged us to see Unix cop-outs like "1 item(s) processed". I mean, it's a comparison and conditional transfer; an if statement--barely more than 5 minutes' work. > ------------------------------------------------------------------------ > On 1/20/22 5:21 PM, Peter Lothberg wrote: > > Time.... > >> Not quite. The acronym actually says that it is not solar time, it's >> Greenwich MEAN Time. UTC is merely the new name for GMT, obviously >> adopted to keep the French from fulminating. > > GMT was established by the Greenwich observatory observing the sun. > > When the atomic second was created the target was the year 1900 GMT > second. > > GMT is based on earth position, and it's modern equivalent is UT1, > when UTC and UT1 differs more than 0.92 sec > > we do leap seconds. > > https://www.iers.org/IERS/EN/Science/EarthRotation/UT1LOD.html > > UTC is based on a constant running timescale based on the frequency of > CS133 oscillating between two > > hyper fine states. > > So the difference between GMT and UTC can be almost a second, and > there is no system that > > distributes GMT, BTP, GPS etc are all UTC based. > > -P >

3 years, 5 months

6
20
0 0

PyDECnet T1.1

by Paul Koning

I have created a T1.1 (beta) branch of PyDECnet, which seems to be working well enough to take for a trial run. I currently have it running as the HECnet mapper node (28NH). That's not a major stress test since it's an end node. Assuming things go well I'll switch PYTHON, the area 41 backbone router, to this version in a couple of days. If anyone wants to try this, you can find the code at svn://akdesign.dyndns.org/pydecnet/branches/t1.1/pydecnet -- in other words, same Subversion server but at the branches/T1.1 subtree rather than trunk. Be sure to read CHANGES.txt, there are some small changes to the config files. And if you use the API (HTTP GET or POST to /api, in V1.0) you'll need to make changes; I dropped that approach since it wasn't workable going forward. The replacement is actually much easier and there are some support modules ("connectors") to simplify things further. See doc/api.txt for details. paul

3 years, 5 months

1
0
0 0

Datatrieve-11 and DECnet at the same time in a program in RSX?

by Johnny Billquist

Ok, it's highly unlikely that anyone cares, but just in case I am posting this anyway. When using RSX-11M-Plus, if you write a program that uses the Datatrieve-11 callable interface over DECnet, your program cannot use DECnet itself for anything in parallel. Which sucks. I've just done some changes to the Datatrieve-11 call interface library, so that this is now possible to do. Ping me if you want to know more. I've also written a nice interface from PDP-11 C, which makes it pretty easy to use both Datatrieve-11 and DECnet. The weird things I amuse myself with, 20 years after anyone stopped caring. I should probably start writing somekind of manual with how to do these things that are not obvious, might not be documented, or that I might have fixed over the years... 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, 5 months

6
15
0 0

The new list

by Keith Halewood

Hi, Apologies if I caused some bounces or timeouts with messages. Cassini.dfupdate.se is in the 'Hetzner' 65.108.0.0/15 subnet. Seemingly large swathes of that part of the Internet have a very low reputation in terms of port scanners, spammers, brute force attackers, sources of DOS attacks etc.. I've made exceptions. Keith

3 years, 5 months

1
0
0 0

How long has your 20 been up?

by tommytimesharing＠gmail.com

Check it out: @_uptiME.EXE.2_ TOMMYT up for 1 Year, 2 Days, 16 Hours, 36 Minutes, 26 Seconds and 582 Milliseconds @_timET2.EXE.4 _ Tops-20 was booted on Saturday, January 16, 2021 8:46:38PM-EST. It will crash with an UP2LNG BUGHLT on Friday, February 18, 2022 1:08:57PM-EST. @ UPTIME and TIMET2 are two programs that I wrote several years; ago, UPTIME in 2017 and TIMET2 in 2006.? I wrote them because I found the hours format given by SYSTAT SYSTEM and INFORMATION MONITOR-STATISTICS to be a little opaque and they didn't have the information I wanted, viz: @_sysTAT sySTEM_ ?Tue 18-Jan-2022 13:28:45? Up *8800:42:07!!!!!!!!* ?4+7 Jobs?? Load av?? 0.01?? 0.02?? 0.02 ?No operator in attendance @_iNFORMATION (ABOUT) monITOR-STATISTICS_ ?Up *8800:42:10!!!!!!!!* ?Idle 99%? Waiting 0%? Sched ovh 0%? Pager traps 0% ?Swap reads 28049 Writes 385176? File reads 4643699 Writes 3677925 ?8092 Pages of user memory ?4259771001 Term wakeups? 1255 Term interrupts ?NBAL av?? 0.32? NRUN av?? 0.02 ?Runtime of jobs on sched queues 0-6 (sec) ?? ?143964??? 16409??? 14494??? 1012??? 1756 4846??? 4215 @ I wrote TIMET2 because I needed to know when to set a shutdown. If you don't do that and you hit the uptime limit, then the machine simple crashes with an UP2LNG BUGHLT. This happens because the uptime millisecond counter is a signed 36 bit integer, which will roll over and become negative after 1 Year, 4 Weeks, 5 Days, 16 Hours, 22 Minutes, 18 Seconds and 367 Milliseconds.? You would think the code would self-set a 'graceful' shutdown, but it doesn't...? Maybe I'll do that one of these days; it's easy enough. Since the PDP-10 does not have unsigned compares, fixing this would involve changing a rather large number of comparisons. Assuming you kept the storage at a single word, going unsigned would get you out to 2 Years, 9 Weeks, 4 Days, 8 Hours, 44 Minutes, 36 Seconds and 735 Milliseconds.? That's probably still not that great given today's hardware. Going to an unsigned double word format would obviously get you a far larger uptime.? However, the current arithmetic that I use can 'only'? handle a maximum uptime of 34,359,738,367,999 of milliseconds.? This works out to be 1092 Years, 27 Weeks, 5 Days, 3 Hours, 46 Minutes, 7 Seconds and 999 Milliseconds.? Since the time of day counter expires in 7-Aug-2576 7:59:59 PM EDT, I used a faster instruction...? Otherwise, going over a millennium between reboots seemed reasonable unless you find yourself in a significantly sub-luminal spacecraft going someplace inter-galactic... I know that XKL fixed at least part of the uptime problem, but I don't remember what that limit is.? What are the limits for other systems?

3 years, 5 months

6
12
0 0

KINET by KI Research - DECnet for numerous Unix flavors and OS/2?

by uusimaki＠exdecfinland.org

It runs on later Windows versions as long as they are 32-bit.Kari -------- Original message -------- From: Johnny Billquist <bqt at softjar.se> Date: 1/16/22 02:54 (GMT+02:00) To: hecnet at Update.UU.SE Subject: Re: [HECnet] KINET by KI Research - DECnet for numerous Unix flavors           and OS/2? On 2022-01-15 20:03, Thomas DeBellis wrote:> That jogs a memory about a question I had; I don't suppose there's > anything for Windows 7, 10 or Mac OS X?Have anyone tried DEC Pathworks on newer windows? I have it running on XP.?? Johnny> > On 1/13/22 12:20 PM, Dave McGuire wrote:>> On 1/13/22 5:07 AM, Supratim Sanyal wrote:>>>> Now, that name sounds very familiar! That might have been who I was >>>> talking to.>>>>>> He responded? saying the KiNET build-tree supports 55 vendor >>> platforms and he will look at what needs to be done to make the build >>> tree available.>>>>>> Probably similar response received by Tim.>>>>>> Let?s wait.>>>> ? Thanks for pursuing this.? This is very exciting!>>>> ???????? -Dave>>-- Johnny Billquist????????????????? || "I'm on a bus?????????????????????????????????? ||? on a psychedelic tripemail: bqt at softjar.se???????????? ||? Reading murder bookspdp is alive!???????????????????? ||? tryin' to stay hip" - B. Idol

3 years, 5 months

1
0
0 0

KINET by KI Research - DECnet for numerous Unix flavors and OS/2?

by supratim＠riseup.net

Once upon a time there seems to have been a company called KI Research at Columbia, Maryland. Circa 1994 they had for sale something called KINET DNA which apparently was a user-mode DECnet stack available for numerous Unix flavors and OS/2 (maybe more operating systems). I came across the name looking for a DECnet implementation for HP-UX. Here's one of the threads from 1993 (!) that I am looking at: http://www.verycomputer.com/30_4d016ca71ca3072b_1.htm Does anyone here have pointers to some archive which might have distributions of KINET? Thanks Supratim

3 years, 5 months

9
16
0 0

Announcing TCP/IP V2.9 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.9 of BQTCP/IP. It's been three weeks since the last official update, which is rather short. But there are two significant things that been solved since the last release, which is motivation for a release so shortly after the previous one. Highlights: . Bugfix in name resolved that could cause system crashes under some conditions. . Improvements to DECnet performance. Detailed information on things that have been done since the last release: TCP: . Improved the handling when both sides sends FIN at the same time. DNS: . Bugfix in resolver. Under the wrong conditions, the system could crash. It was a combination of failing DNS, short timeouts on the query itself, and a race condition in the code in this case. So the chances of hitting it were extremely low, but it can happen. MAIL: . Improve handling of hosts with no reverse dns, or giving fake information or trying to do weird commands. Such hosts are not blocked anymore, but are tracked, and only mails to postmaster from such hosts are accepted (this is more in accordance with the relevant RFCs). . Added postmaster sending a warning mail when mail delivery isn't immediately successful, to make people aware that there might be problems. . Improved mail queue processing, making the mail queue not be locked for longer periods. TELNETD: . Improved connection tracking. FTPD: . Add logging of whether transfers completed successfully or not in logs. IPC library: . Bugfix. The _notify() function didn't work right. RSX: . Added patched ECL module for DECnet to improve performance. 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. 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... 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, but drops packets. This is sortof 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. 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, 5 months

1
0
0 0

DDCMP sync line support now in SIMH

by paulkoning＠comcast.net

With help from Mark Pizzolato, I added support to SIMH for my DDCMP sync line interface ("DDCMP framer"). This is a USB device, built around a Raspberry Pico, that implements the lower layers of the DDCMP synchronous line protocol. It allows SIMH (or PyDECnet) to talk to real machines that use those interfaces. My ability to test with real hardware is limited; in particular I don't have any coax cable ("integral modem") devices like the DMC-11/AL. But I did test RS232 mode with my Pro 380. The current SIMH on Github includes the necessary code and documentation to allow the use of this device as an emulated DUP, KMC-DUP, or DMC. The current PyDECnet (on my Subversion server) also supports it, and the two will interoperate as you would expect. The design for the device is open source, it can be found on github: https://github.com/pkoning2/ddcmp . At the moment if you want one of these you'll have to build it; I provide the design files but not boards or devices, and I don't plan to. But of course since it's open others may do so if they wish. I'd be very interested in test results of the coax interface since I could only test that against the device itself and against the documentation. paul

3 years, 6 months

1
0
0 0

Area weirdness on HECnet

by Keith.Halewood＠pitbulluk.org

Hi, Just noticed: ncp tell a1rtr show known circ stat The above shows a circuit ETH-10 adjacent to node 5.1023. It looks like none of the area routers I've looked at actually see the area, ie: a29rt2, a1rtr, python. Needless to say that 5.* is unreachable from my point of view. FYI Keith

3 years, 6 months

3
2
0 0

So…..

by Keith.Halewood＠pitbulluk.org

So, [Happy new year by the way,] How much of the HECnet just went dark? K

3 years, 6 months

7
9
0 0

SIMH TOPS-20 question --> recipe for handling Tops20 install tapes --> MTBOOT --> create new PS: structure

by R.Voorhorst＠swabhawat.com

Actually, come to think about it you should be able to create a new PS in 2 phases: 1. boot tape and create a pristine PS: up to and including DLUSER stuff; see installation manual posted earlier. 2. boot another monitor, mount the pristine PS as another structure on it; skip the tape 7 files and use monitor dumper to restore the savesets on the pristine structure. Point to check is if a bootstrap is written to the pristine structure but the installation manual will make that clear. If I have some time I will checkthe problem out if the tape has a problem or not and how to create a structure from it; meanwhile you still cann retrieve files which was your primary requirement I believe. Reindert -----Original Message----- From: Paul Koning [mailto:paulkoning at comcast.net] Sent: Saturday, 25 December, 2021 22:24 To: Reindert Voorhorst <R.Voorhorst at swabhawat.com> Cc: <hecnet at update.uu.se> <hecnet at Update.UU.SE> Subject: Re: [HECnet] SIMH TOPS-20 question --> recipe for handling Tops20 install tapes --> MTBOOT > On Dec 25, 2021, at 3:21 PM, R. Voorhorst <R.Voorhorst at swabhawat.com> wrote: > > I do not see that problem and I posted it here somewhat earlier: > > Swbx04> att -f tu0 simh > Swbx04> 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! So it is, interesting. What's strange is that -f tpc reports success, while -f simh reports an error: After processing 1159680 bytes of tape data (453 records, 5 tapemarks) Read Tape Record Returned Unexpected Status: invalid record length 19827814 bytes of unexamined data remain in the tape image file but indeed in this format I can boot the tape. paul

3 years, 6 months

3
8
0 0

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

5
8
0 0

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

1
0
0 0

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

2
2
0 0

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