HECnet

hecnet@lists.dfupdate.se

15559 discussions

A USNO GPS network time server is now in operation at Digital Equipment Corporation, Palo Alto, CA

by supratim＠riseup.net

"A USNO GPS network time server is now in operation at Digital Equipment Corporation, Palo Alto, CA. This is an open-access stratum-1 for the Pacific Timezone: usno.pa-x.dec.com??? ?204.123.2.72 (CNAME ntp-dec.usno.navy.mil)" 204.123.2.72 still returns time as stratum 1. usno.pa-x.dec.com and ntp-dec.usno.navy.mil do not resolve. Ref: March 1997 revision of: http://gisweb.massey.ac.nz/topic/webreferencesites/gps/usnavy/ntp.html

3 years, 6 months

*** Very important information ***

by bqt＠softjar.se

Hi, all. This mail contains some very important information that affects a fair number of people and services on HECnet. So please read through it, and if you need to take action, please do this in a timely manner. I'm here to help with whatever, but I can only work on things from my end of things. Background: Update is a computer club at Uppsala University. As such, it has enjoyed a lot of support from the University over a long time. However, recent development have now led us to a point where the University is no longer willing to support Update. The main way the support have been provided is through a computer room where machines have been running, electricity, and network connectivity. All of this is now going away. Basically, and the end of this year, Update will have to have moved out of their current location. This means that any machine Update currently have running will need to move. Update have found a location of their own that they now started to rent, and most things will be moving in a few weeks from now. There are also unfortunately a need to reduce the size of Update's collection of hardware since the size of the collection is just too big for Update to afford to keep. You might hear more on that separately, but I'm not going to go into that any further than saying that Magica and other large iron is currently safe, and will be moved. But it's going to be difficult to run these machines for the time being. Primary effects: Mim.Update.UU.SE, Psilo.Update.UU.SE and any other resources used by HECnet will go offline. I'm not sure about the exact date, but expect this to happen in a couple of weeks from now. This means any Multinet links to MIM will go down, and will not come back up. Any bridge connections to Psilo will also go away. Also, the HECnet mailing list will stop working. Update is working on getting services back up and running in their new location, but exactly in which form we are able to is unclear, and it is also unclear what network capacity there will be, or when anything will be back. Changes happening on HECnet: Because of the things mentioned above, there is a plan in place to keep HECnet up and running. Thanks to Peter Lothberg, a lot of functions and services currently at Update will move to Stupi. MIM:: (Mim.Update.UU.SE) has already moved to Stupi, and is now known as Mim.Stupi.NET. Still the same nodename on HECnet. The old Mim (Mim.Update.UU.SE) is still up for the time being, as XMIM:: Any Multinet links to Mim.Update.UU.SE are going to have to move. There will be two alternatives: . HECnet-1-1023.Stupi.NET is a PyDECnet router which I intend to be a major hub for HECnet. Located in Stockholm with good network capacity. . Mim.Stupi.NET, which is just the same machine, and can accept the same links. Any bridge connection to Psilo.Update.UU.SE are going to have to move. There is one alternative: . HECnet-1-1023.Stupi.NET. Same router that takes Multinet links. As mentioned above, I aim for this to be a major hub going forward. XMIM:: will be around for a few weeks, but will go down in the not distant future. All current Multinet bridges to it will have to migrate in order to keep working. Else those links will soon stop. MIM:: will continue service HECnet with the nodename database, just like before. It also will continue to act as a mail gateway for anyone using that feature. Mail from inside HECnet to the Internet will continue to be handled as MIM::<user at internet.host> Mail from Internet to HECnet will need to be addressed as <node>::<user>@Mim.Stupi.Net Web services at Mim will continue as well, but obviously at Mim.Stupi.NET. Same with ftp, rpm, and all other things. In order to reduce the number of issues that might pop up, I am going to try and get Mim.Update.UU.SE setup as a CNAME to Mim.Stupi.NET, so that most things will continue to work even using the old hostname, but there might be hiccups here. Be aware. The mailing list I'm still looking into how to handle. I'll get back on that soon. Next steps: I want that people have have links to Update to contact me, and we can move the links over to new endpoints. Keep in mind that I might take a day or two to respond to each individual. But I'll try to move fast as I don't know when things will stop operating in the current setup. Also, any issues, problems, funny stuff, or whatever, please reach out to me. I'm also going to keep an eye open for routing becoming odd in the face of things here, and will poke people when I see things that just look wrong. Of course, I have no insight into any Cisco equipment, so there I will just have to hope and trust that each person running such gear have things set up in a reasonable way. Well, that's about all I can think of right now. Now you all know what is happening, and anyone having links to Update will need to take action. Anyone using other services from machines at Update might also see problems as this all happens. And once more, many thanks to Peter Lothberg, who have been very helpful in finding a solution to this problem. (And yes, I wish Uppsala University had done things differently, but that is not anything I am in any position to affect, or make much comments on.) 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

Support Update?

by bqt＠softjar.se

Hi. Since people have asked about the future of Update, if there are anything people can do to help, and so on. One simple thing you all can do is to become members. Update is nowadays open to membership for anyone. Admittedly, if you are not around Uppsala, Sweden, you might not enjoy some of the activities, or be able to play with the collection. But there are talks about getting something more museum-like running. And of course, just keeping much of what Update have collected over the years have value for the future as well. You can find more information at https://www.update.uu.se/en/ 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

ANF10 network --> software for DN60xxx Rje to IBM

by R.Voorhorst＠swabhawat.com

For DN60 variants software look in the trailing edge Pdp10 archives for tape BB-J845A-SM; it is called TOPS-20 IBM 2780/3780/HASP E/T for the DECSYSTEM-2020. Contrary to what I thought, the hardware platform and software is similar to Anf10 and should run on a simh pdp11 properly throttled but with added interfaces. In this case It is specified for Tops20 V4 on 2020. There also exists tapes for older Pdp10 systems with dte type interfaces and Tops10. As we have Tops20 V4.1 there is a base to work upon. Reindert -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Robert Armstrong Sent: Friday, 19 November, 2021 17:33 To: hecnet at Update.UU.SE Subject: RE: [HECnet] ANF10 network --> DN200 (RJE, Decnet) --> should be Ddcmp --Re3 > <dave.g4ugm at gmail.com> <dave.g4ugm at gmail.com> wrote: > It might be worth looking at how Hercules encapsulates SDLC as that > will do TOPS-10 had an IBM HASP communication FE product; I think it was called a DN60. I used it long ago - you could submit card decks to JES2 under OS/VS2 from files on the -10 and get the resulting print out back as another disk file on the -10. Beats a keypunch and a line printer by miles... It'd be kind of neat, although a total waste of time, to hook up a simh TOPS10 to a Hercules and try to get that working. Bob

3 years, 6 months

ANF10 network --> DN200 (RJE, Decnet) --> should be Ddcmp --Re3

by R.Voorhorst＠swabhawat.com

No, the Dup is only simulated as Kdp/Dup combo, hence the Ddcmp characteristics of the pair. Reindert -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Friday, 19 November, 2021 00:31 To: hecnet at Update.UU.SE Subject: Re: [HECnet] ANF10 network --> DN200 (RJE, Decnet) --> should be Ddcmp --Re2 Fair enough. But DUP11 is a sync character based interface. So that one too requires that you do DDCMP in software. But I didn't think simh simulated a DUP11? Johnny On 2021-11-18 23:33, R. Voorhorst wrote: > Yes, but they are async lines and these are indeed character based with software determining the protocol, not so the sync liness. Async decnet ddcmp behaves slightly differently from sync decnet ddcmp in number of characters used. Look at the packet contents in used characters and in between. > > Reindert > > -----Original Message----- > From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On > Behalf Of Johnny Billquist > Sent: Thursday, 18 November, 2021 23:23 > To: hecnet at Update.UU.SE > Subject: Re: [HECnet] ANF10 network --> DN200 (RJE, Decnet) --> should > be Ddcmp --Re > > Well... RSX for example can talk DDCMP over DZ11 or DL11 lines just as well, which are plain simple serial lines existing in simh. > Hopefully such lines can be connected with interfaces doing DDCMP in hardware (simulated in simh of course), and it should all work. > > And any software running in RSX just have an interface that gives the DDCMP packet layer. The actual serial lines are not accessible as such by any other software than the DDCMP driver. > > Johnny > > On 2021-11-18 23:01, R. Voorhorst wrote: >> Point in this case is that the ddcmp is handled in Simh and not in system software so software can only deal with packets/messages; there is need for a simh sync line where the software itself will be able to communicate in bytes/characters and synthesize the packets/messages as the next higher organization. >> >> Reindert >> >> -----Original Message----- >> From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On >> Behalf Of Johnny Billquist >> Sent: Thursday, 18 November, 2021 22:39 >> To: hecnet at Update.UU.SE >> Subject: Re: [HECnet] ANF10 network --> DN200 (RJE, Decnet) --> >> should be Ddcmp >> >> Well, a serial line over which DDCMP is running is purely a packet based interface. >> >> Johnny >> >> On 2021-11-18 21:46, R. Voorhorst wrote: >>> Indeed it is Ddcmp, but the meaning is the difference between >>> packet/message oriented and character oriented and the latter should also exist. >>> >>> Reindert >>> >>> -----Original Message----- >>> From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] >>> On Behalf Of Robert Armstrong >>> Sent: Thursday, 18 November, 2021 21:11 >>> To: hecnet at Update.UU.SE >>> Subject: RE: [HECnet] ANF10 network --> DN200 (RJE, Decnet) >>> >>>> Paul Koning <paulkoning at comcast.net> wrote: >>>> They speak DDCMP, yes, but not DECnet. Any protocol layered over >>>> DDCMP >>> should work. >>> >>> Indeed, and we just proved that with ANF10 which uses the DMCs >>> and DUPs but is not DECnet. >>> >>> Bob >>> >>> >>> >> > -- 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

VMS progtram for real tape -> TAP --> VMS copying through clustering --> tenvax rtc

by R.Voorhorst＠swabhawat.com

As far as I know here are programs on Vax Vms that also read Tops10 tapes; on the 10/20-Vax integration tools there was tenvax: decsystem-10 to Vax to do something like that. Just google around and you find something. Intergaration tools are on pdp10 archive. Reindert From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Robert Armstrong Sent: Friday, 19 November, 2021 21:30 To: hecnet at Update.UU.SE Subject: Re: [HECnet] VMS progtram for real tape -> TAP --> VMS copying through clustering Thanks, but it's a TOPS10 tape that I want to read, on a simulated KS10 with TOPS10. Bob On 11/19/21 12:06 PM, R. Voorhorst wrote: Use the real vax Vms Ethernet clustered with a simh Vax, enable Mscp disk and tape serving and you can use the Vms commands like copy, dump and backup and specific programs to read tapes to move contents onto simh device files whether disk or tape. 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 Robert Armstrong Sent: Friday, 19 November, 2021 20:23 To: hecnet at Update.UU.SE <mailto:hecnet at Update.UU.SE> Subject: [HECnet] VMS progtram for real tape -> TAP Can someone point me to a program for VMS that will read a real, physical, 9-track tape into a simh compatible TAP or TPC file? I was sure I already had one, but I can't seem to find it anymore. Thanks, Bob _______________________________________________ Hecnet-list mailing list Hecnet-list at lists.sonic.net <mailto:Hecnet-list at lists.sonic.net> https://lists.sonic.net/mailman/listinfo/hecnet-list

3 years, 6 months

ANF10 network --> DN200 (RJE, Decnet) --> should be Ddcmp --> MarkP

by R.Voorhorst＠swabhawat.com

I updated the remark by Bob with this in my update and could not find that back in your copy of the mail transcript: Before I get a storm this from Pdp11_dup.c should accompany it: The wire protocol implemented is native DDCMP WITHOUT the DDCMP SYNC characters both initially and between DDCMP packets. Reindert -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark Pizzolato - Info Comm Sent: Friday, 19 November, 2021 21:18 To: R. Voorhorst <R.Voorhorst at swabhawat.com>; hecnet at Update.UU.SE Subject: RE: [HECnet] ANF10 network --> DN200 (RJE, Decnet) --> should be Ddcmp --> Re:4 --> Cryptic -->Dup11 simh only for Ddcmp --> update On Friday, 19 November, 2021 at 20:42, Reindert wrote: > Yes, that is how Pdp10 KS10 and Vax and Rsx and Rsts all interface to > the Dmc/Dmr offered layer and for Anf10 on Pdp10 as well. > But trying Decnet on bare Dup11 will reveal all. > > However this will fail on simh: look at the comment in Pdp11_dup.c > from > Bob: > > dup DUP11 Unibus/DPV11 Qbus bit synchronous interface > > This module implements a bit synchronous interface to support DDCMP. > Other > synchronous protocols which may have been supported on the > DUP11/DPV11 > bit > synchronous interface are explicitly not supported. > > So the 0,01 % rises to 100% that it will not work as bare sync device I don't see what you're saying will fail. The comments very explicitly say that DDCMP will work. Other possible uses of the DUP11/DPV11 will not work. The reason they wouldn't work when this pdp11_dup.c was written was due to the lack of software on the PDP11 side and something on the other end of a conversation to talk to. If such a useful test case existed the functionality in the pdp11_dup.c code could be extended to support it. - Mark > -----Original Message----- > From: owner-hecnet at Update.UU.SE [mailto:owner- hecnet at Update.UU.SE] On > Behalf Of Paul Koning > Sent: Friday, 19 November, 2021 17:23 > To: hecnet at update.uu.se > Subject: Re: [HECnet] ANF10 network --> DN200 (RJE, Decnet) --> should > be Ddcmp --> Re:4 --> Cryptic > > I assume it means that RSX (and RSTS too) lets you use a DMC directly > from an application as an I/O device you can open. If so, you get a > packet service that lets you transmit whatever packets you want, which > will be sent encapsulated in DDCMP protocol. In the RSX case I'd > assume that includes support for maintenance mode (in RSTS that isn't supported). > > paul > > > On Nov 19, 2021, at 11:14 AM, R. Voorhorst > <R.Voorhorst at swabhawat.com> > wrote: > > > > Please can you explain your second sentence somewhat? I read: "... > > the > Ddcmp layer ... it does present it as a device ...". I do not perceive > the connotation. > > > > > > Reindert > > > > -----Original Message----- > > From: owner-hecnet at Update.UU.SE [mailto:owner- > hecnet at Update.UU.SE] On > Behalf Of Johnny Billquist > > Sent: Friday, 19 November, 2021 14:46 > > To: hecnet at Update.UU.SE > > Subject: Re: [HECnet] ANF10 network --> DN200 (RJE, Decnet) --> > > should > be > Ddcmp --> Re:4 > > > > RSX definitely can use a DUP11 standalone through DECnet. In which > > case > it's software side DDCMP. > > > > Heck, you can also use the DDCMP layer yourself, without involving > DECnet. > It does present it as a device to the system on which you can > send/receive packets. > > > > Johnny

3 years, 6 months

VMS progtram for real tape -> TAP --> VMS copying through clustering

by R.Voorhorst＠swabhawat.com

Use the real vax Vms Ethernet clustered with a simh Vax, enable Mscp disk and tape serving and you can use the Vms commands like copy, dump and backup and specific programs to read tapes to move contents onto simh device files whether disk or tape. Reindert From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Robert Armstrong Sent: Friday, 19 November, 2021 20:23 To: hecnet at Update.UU.SE Subject: [HECnet] VMS progtram for real tape -> TAP Can someone point me to a program for VMS that will read a real, physical, 9-track tape into a simh compatible TAP or TPC file? I was sure I already had one, but I can't seem to find it anymore. Thanks, Bob

3 years, 6 months

ANF10 network --> DN200 (RJE, Decnet) --> should be Ddcmp --> Re:4 --> Cryptic -->Dup11 simh only for Ddcmp --> update

by R.Voorhorst＠swabhawat.com

Before I get a storm this from Pdp11_dup.c should accompany it: The wire protocol implemented is native DDCMP WITHOUT the DDCMP SYNC characters both initially and between DDCMP packets. -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of R. Voorhorst Sent: Friday, 19 November, 2021 20:42 To: hecnet at Update.UU.SE Cc: Mark at infocomm.com Subject: RE: [HECnet] ANF10 network --> DN200 (RJE, Decnet) --> should be Ddcmp --> Re:4 --> Cryptic -->Dup11 simh only for Ddcmp Yes, that is how Pdp10 KS10 and Vax and Rsx and Rsts all interface to the Dmc/Dmr offered layer and for Anf10 on Pdp10 as well. But trying Decnet on bare Dup11 will reveal all. However this will fail on simh: look at the comment in Pdp11_dup.c from Bob: dup DUP11 Unibus/DPV11 Qbus bit synchronous interface This module implements a bit synchronous interface to support DDCMP. Other synchronous protocols which may have been supported on the DUP11/DPV11 bit synchronous interface are explicitly not supported. So the 0,01 % rises to 100% that it will not work as bare sync device -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul Koning Sent: Friday, 19 November, 2021 17:23 To: hecnet at update.uu.se Subject: Re: [HECnet] ANF10 network --> DN200 (RJE, Decnet) --> should be Ddcmp --> Re:4 --> Cryptic I assume it means that RSX (and RSTS too) lets you use a DMC directly from an application as an I/O device you can open. If so, you get a packet service that lets you transmit whatever packets you want, which will be sent encapsulated in DDCMP protocol. In the RSX case I'd assume that includes support for maintenance mode (in RSTS that isn't supported). paul > On Nov 19, 2021, at 11:14 AM, R. Voorhorst <R.Voorhorst at swabhawat.com> wrote: > > Please can you explain your second sentence somewhat? I read: "... the Ddcmp layer ... it does present it as a device ...". I do not perceive the connotation. > > > Reindert > > -----Original Message----- > From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist > Sent: Friday, 19 November, 2021 14:46 > To: hecnet at Update.UU.SE > Subject: Re: [HECnet] ANF10 network --> DN200 (RJE, Decnet) --> should be Ddcmp --> Re:4 > > RSX definitely can use a DUP11 standalone through DECnet. In which case it's software side DDCMP. > > Heck, you can also use the DDCMP layer yourself, without involving DECnet. It does present it as a device to the system on which you can send/receive packets. > > Johnny

3 years, 6 months

ANF10 network --> DN200 (RJE, Decnet) --> should be Ddcmp --> Re:4 --> Cryptic --> Rsx-11S

by R.Voorhorst＠swabhawat.com

Hi Mark, The Dn20 is Rsx-11S with Decnet layered on it in phase-III/IV forms; however the Decnet layer is only offered on pdp10 software and mainly without source code. It will not run (yet). Maybe the Cex layer could be tinkered onto an Rsx-11M 3.1 base system that has (some) source code available. Reindert -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark Matlock Sent: Friday, 19 November, 2021 19:06 To: hecnet at Update.UU.SE Subject: Re: [HECnet] ANF10 network --> DN200 (RJE, Decnet) --> should be Ddcmp --> Re:4 --> Cryptic All, This discussion has been quite interesting! Back in the 1982, I did programming for a large RSX11M/DECnet based system that input commodity trading data from around eight different commodity exchanges (CBOT, COMEX, Mercantile, etc.) as well as commodity news service and distributed it to over 200 VT100s located all over the U.S. The host system was an 11/44 connected to the development 11/44 via DMCs and they shared a DT07 bus with box. In the DT07 was a couple DZ11s for data input from the exchanges and a DV11 with 16 synchronous serial ports that were connected to twelve remotely located 11/23s running RSX11S & DECnet. The 11/23s were downloaded RSX11S via their DUV11s and the re-entrant RSX tasks received DECnet task to task data packets about trades and then displayed individualized data to ~20 VT100s on DZV11s and DLV11-Js. A DUP11 on one of the 11/44s also did RJE jobs to an IBM mainframe. A watch-dog timer ran between the 11/44s so that a semi-hot fail over could occur and the DT07 would move the I/O to the development system if the primary had hardware issues. Later I had an 11/24 that connected into this network via the CPUs 2nd DL11 port that was often used for a TU58. I don?t remember exactly what it connected to on the 11/44 side. All the network connections were 9600 baud point to point lease lines from AT&T. If anyone out there has a DECnet distribution for RSX11S, I?d love to get a copy to experiment with today. Best, Mark > On Nov 19, 2021, at 10:50 AM, Johnny Billquist <bqt at softjar.se> wrote: > > Well, I meant this in the context of a DUP11, but sure, it's also true with DMC. > > But basically, in RSX, DECnet is just a component of something called the communications executive, or CEX. CEX provides its own environment in which multiple processes run, and provide services. > > CEX then provides an interface to its drivers from RSX, which means that any RSX program can make use of the services and protocols that CEX have, without have DECnet in the picture. > > So for example, CEX provides communication lines, which are packet based. If that is over asynch lines it utlizes DDCMP over async serial. Any application in RSX can make use of this. If you instead have a synch line, like a DUP11, or DMC, that is another interface inside CEX. From the outside it makes no difference if it is a DUP or a DMC. Bottom side is synch serial, using DDCMP. With DMC this is all done in the hardware. With a DUP11, CEX is doing the DDCMP layer in software. > > For the user program this is all invisible. You just communicate over the DUP11, and it will be doing DDCMP. > > If you actually want to use the DUP11 *whithout* DDCMP, then you'd go for the DUP11 device driver instead of accessing it through CEX. > > And talking to a device using CEX in RSX means you talk to the "direct line access" interface, or DLX. That is just one interface, independent of what underlying hardware you are going to access. In the DLX, you start by opening the link, and for that you use the name, which is the same as the line name you see for DECnet. But you are in fact then just talking at the line level, using whatever protocol layer is used for that line. DDCMP, for example. > > Anything using DDCMP is always in packets. Don't matter how the hardware looks. > > DLX is also used to access ethernet, by the way. And that is how I coexist with DECnet in RSX, since ethernet can allow multiple channels on the same hardware. > > I hope this makes sense. Else I can try to explain it more. > > Johnny

3 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet