HECnet

hecnet@lists.dfupdate.se

4 participants
15583 discussions

Another sillyness. More information in the nodename database on MIM.

by b4＠gewt.net

On Sat, 18 May 2013, Ian McLaughlin wrote: (I may be too late answering this, because I'm mobile and there's a billion messages in this thread that I haven't read yet...) I'd really like to see a Hecnet-based solution - like a set host to a captured account on mim or something would be nice. A web page kind of breaks the illusion of an antique network :). Limiting access to hecnet methods sort of self-polices just by itself. A "captured" account? ;) Ian (Trying to keep up with the tread while at my son's birthday party) Sent from my iPhone On 2013-05-18, at 9:58 AM, Johnny Billquist <bqt at softjar.se> wrote: On 2013-05-18 18:52, Cory Smelosky wrote: On Sat, 18 May 2013, Dave McGuire wrote: On 05/18/2013 12:45 PM, Johnny Billquist wrote: I like the idea of giving us all write access. Maybe you can set up regular dumps of the database for restoration in case someone screws up. I can certainly do that. It just becomes a question of people might need to reenter information in case a rollback has to go far. Also trickier to realize if "corruption" actually have happened perhaps. On the other hand, I could atleast have permissions that only allowed random people to modify data, not add new, nor delete. That's a really good idea. I second this. How flexible is Datatrieve's permissions system? You can identify users either by UIC, or by entity-specific passwords. And for each type of thing in there you have Read, Write, Modify, Extend, and Control. And the access is a list, with the first match being the permissions used. So I could either make sure all people who might want to modify this have their own account on MIM, or else I could just create password protected access, and we could have shared or private passwords. 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 --- Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=2C48D1D4BFDC11E2A… -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments

12 years, 5 months

Another sillyness. More information in the nodename database on MIM.

by ian＠platinum.net

(I may be too late answering this, because I'm mobile and there's a billion messages in this thread that I haven't read yet...) I'd really like to see a Hecnet-based solution - like a set host to a captured account on mim or something would be nice. A web page kind of breaks the illusion of an antique network :). Limiting access to hecnet methods sort of self-polices just by itself. Ian (Trying to keep up with the tread while at my son's birthday party) Sent from my iPhone On 2013-05-18, at 9:58 AM, Johnny Billquist <bqt at softjar.se> wrote: On 2013-05-18 18:52, Cory Smelosky wrote: On Sat, 18 May 2013, Dave McGuire wrote: On 05/18/2013 12:45 PM, Johnny Billquist wrote: I like the idea of giving us all write access. Maybe you can set up regular dumps of the database for restoration in case someone screws up. I can certainly do that. It just becomes a question of people might need to reenter information in case a rollback has to go far. Also trickier to realize if "corruption" actually have happened perhaps. On the other hand, I could atleast have permissions that only allowed random people to modify data, not add new, nor delete. That's a really good idea. I second this. How flexible is Datatrieve's permissions system? You can identify users either by UIC, or by entity-specific passwords. And for each type of thing in there you have Read, Write, Modify, Extend, and Control. And the access is a list, with the first match being the permissions used. So I could either make sure all people who might want to modify this have their own account on MIM, or else I could just create password protected access, and we could have shared or private passwords. 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 --- Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=2C48D1D4BFDC11E2A…

12 years, 5 months

TOPS-10 and DECnet Progress Update

by b4＠gewt.net

On Sat, 18 May 2013, Paul_Koning wrote: On May 18, 2013, at 1:28 PM, Cory Smelosky wrote: On Sat, 18 May 2013, G. wrote: ... If you use the CTERM protocol, it will be always slow and sluggish, no matter how much you'll try to tweak it. Try SET HOST /APP=R and appreciate speed :) It's MUCH more usable when using RTERM. Thank you. Why is CTERM so slow on TOPS-10? Because CTERM was designed, in essence, as a remote procedure call representation of the VMS terminal driver features. The ones in TOPS-10 are entirely different -- just consider the way carriage return echoes. So TOPS-10 is forced to do its terminal I/O through a protocol that doesn't come close to matching what it really wants to see. I suspect it simply runs things in single character mode, since that's about the only way to guarantee that you get what you want. Ahhhh. Yeah. That would explain it. Come to think of it, TOPS-10 RTERM mode may well be just that, but it's a very lightweight protocol so it's fast. It also has the nice benefit that it exists on systems that don't do CTERM -- like RSTS. Yup. Very beneficial on systems without CTERM. ;) paul -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments

12 years, 5 months

Another sillyness. More information in the nodename database on MIM.

by b4＠gewt.net

On Sat, 18 May 2013, Cory Smelosky wrote: On Sat, 18 May 2013, Dave McGuire wrote: On 05/18/2013 01:49 PM, Cory Smelosky wrote: On Sat, 18 May 2013, h vlems wrote: Unfortunately not Cory, 0.22 euro per kWhr. No way I can leave even one (real) system on line all day long. That's more expensive than here, surprisingly. What are you paying over there? It's $0.095/kWh here, was $0.135/kWh down in Florida. (that was a major factor in my decision to move up here) They don't give a proper breakdown of costs per kwh...but my (likely incorrect) calculations showed it to be about $0.12/kwh. 55kwh/day at $7.02/day. Due to some odd plan account budget thing, it amounts to much less than that in reality. Save for the month or so where you make up the difference. There's also this line on the bill: "In order to save you money, a new supplier must offer you a price lower than 7.6 cents per KWH for the same usage that appears on this bill" -Dave -- Dave McGuire, AK4HZ New Kensington, PA -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments

12 years, 5 months

TOPS-10 and DECnet Progress Update

by Paul_Koning＠Dell.com

On May 18, 2013, at 1:28 PM, Cory Smelosky wrote: On Sat, 18 May 2013, G. wrote: ... If you use the CTERM protocol, it will be always slow and sluggish, no matter how much you'll try to tweak it. Try SET HOST /APP=R and appreciate speed :) It's MUCH more usable when using RTERM. Thank you. Why is CTERM so slow on TOPS-10? Because CTERM was designed, in essence, as a remote procedure call representation of the VMS terminal driver features. The ones in TOPS-10 are entirely different -- just consider the way carriage return echoes. So TOPS-10 is forced to do its terminal I/O through a protocol that doesn't come close to matching what it really wants to see. I suspect it simply runs things in single character mode, since that's about the only way to guarantee that you get what you want. Come to think of it, TOPS-10 RTERM mode may well be just that, but it's a very lightweight protocol so it's fast. It also has the nice benefit that it exists on systems that don't do CTERM -- like RSTS. paul

12 years, 5 months

Another sillyness. More information in the nodename database on MIM.

by b4＠gewt.net

On Sat, 18 May 2013, Dave McGuire wrote: On 05/18/2013 01:49 PM, Cory Smelosky wrote: On Sat, 18 May 2013, h vlems wrote: Unfortunately not Cory, 0.22 euro per kWhr. No way I can leave even one (real) system on line all day long. That's more expensive than here, surprisingly. What are you paying over there? It's $0.095/kWh here, was $0.135/kWh down in Florida. (that was a major factor in my decision to move up here) They don't give a proper breakdown of costs per kwh...but my (likely incorrect) calculations showed it to be about $0.12/kwh. 55kwh/day at $7.02/day. Due to some odd plan account budget thing, it amounts to much less than that in reality. Save for the month or so where you make up the difference. -Dave -- Dave McGuire, AK4HZ New Kensington, PA -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments

12 years, 5 months

Another sillyness. More information in the nodename database on MIM.

by mcguire＠neurotica.com

On 05/18/2013 01:49 PM, Cory Smelosky wrote: On Sat, 18 May 2013, h vlems wrote: Unfortunately not Cory, 0.22 euro per kWhr. No way I can leave even one (real) system on line all day long. That's more expensive than here, surprisingly. What are you paying over there? It's $0.095/kWh here, was $0.135/kWh down in Florida. (that was a major factor in my decision to move up here) -Dave -- Dave McGuire, AK4HZ New Kensington, PA

12 years, 5 months

Another sillyness. More information in the nodename database on MIM.

by b4＠gewt.net

On Sat, 18 May 2013, h vlems wrote: Unfortunately not Cory, 0.22 euro per kWhr. No way I can leave even one (real) system on line all day long. That's more expensive than here, surprisingly. Van: Cory Smelosky Verzonden: zaterdag 18 mei 2013 19:28 PM Aan: h vlems Beantwoorden: hecnet at Update.UU.SE Cc: hecnet Onderwerp: Re: [HECnet] Another sillyness. More information in the nodename database on MIM. On Sat, 18 May 2013, h vlems wrote: > It doesn't happen too often but when they all run in th winter there's no snow on the roof! > Given that my town has a certain reputation for growing marihuana that is a mixed blessing... > No police yet however :-) Power must be cheap there. > > Van: Cory Smelosky > Verzonden: zaterdag 18 mei 2013 18:45 PM > Aan: H Vlems > Beantwoorden: hecnet at Update.UU.SE > Cc: hecnet > Onderwerp: RE: [HECnet] Another sillyness. More information in the nodename database on MIM. > > > On Sat, 18 May 2013, H Vlems wrote: > > > > > A list of my systems: > > > > 44.1 HELIUM VAXstation 3100-M48 VMS 7.2 > > 44.2 XENON VAXstation 4000-60 VMS 7.2 > > 44.3 ARGON VAXstation 4000-90A VMS 7.3 > > 44.4 NEON Asus Eee pc Fedora 14 > > 44.5 ZILVER VAXstation 4000-60 VMS 7.3 > > 44.6 JODIUM VAXstation 2000 VMS 5.5-1 > > 44.7 RADON VAXstation 3100 VMS 5.5-1 > > 44.8 ASTAAT DECserver 100 > > 44.9 OSMIUM Digital Server 5305 5/533 VMS 8.3 > > 44.10 CHLOOR VAXstation 4000-90A VMS 7.2 > > 44.11 ZWAVEL microVAX 3100-10e VMS 6.1 > > 44.12 INDIUM VXT2000+ > > 44.13 ERBIUM AlphaServer 800 5/500 Tru64 5.0 > > 44.14 BROOM AlpaServer 1200 5/400 VMS 7.3-2 > > 44.15 FOSFOR VAXstation 4000-60 VMS 7.3 > > 44.16 COBALT VAXstation 4000-60 VMS 7.3 > > 44.17 KOPER VAXstation 2000 VMS 5.5-1 > > 44.18 CERIUM VAX 4000-100A VMS 7.3 > > 44.19 IJZER Compaq XP1000 6/500 VMS 8.3 > > 44.20 CHROOM VAX 4000-100A VMS 7.3 > > 44.21 NIKKEL VAXstation 4000-90A VMS 7.3 > > 44.22 ZINK VAXstation 4000 VLC VMS 7.3 > > 44.23 LOOD microVAX 3100-30 VMS 7.3 > > 44.24 CURIUM Multia VX42 4/233 VMS 7.3 > > 44.25 KWIK VAXstation 4000-60 VMS 7.3 > > 44.26 AURUM Integrity rx2600 VMS 8.4 > > 44.27 RADIUM HP dc5000 sff Windows XP > > 44.28 TIN AlphaServer 1200 5/533 VMS 8.3 > > 44.29 FLUOR AlphaServer 1000A 5/333 VMS 7.3-2 > > 44.30 BOOR VAXstation 4000-60 VMS 7.1 > > 44.31 SELEEN microVAX 3100-20e VMS 6.1 > > 44.32 ARSEEN microVAX 3100-20e VMS 6.1 > > 44.33 CARBON DEC AXP 3000-300X VMS 1.5-1H1 > > 44.34 OXYGEN DEC AXP 3000-300X VMS 6.1 > > 44.35 TITAAN AlphaServer DS20E 6/666 VMS 8.3 > > 44.36 URAAN AlphaServer 1000A 5/333 VMS 8.3 > > 44..37 BARIUM AlphaServer 1200 5/533 VMS 8.3 > > 44.38 CESIUM Digital Server 5305 5/533 VMS 8.3 > > 44.39 KALIUM AlphaServer 300 Tru64 5.1a > > 44.40 SODIUM Digital Server 5305 5/533 VMS 8.3 > > 44.41 AZOTE <not in use> > > 44.42 VISMUT AlphaServer 800 5/333 Tru64 5.1a > > 44.43 OZON AlphaServer DS10 6/466 VMS 8.4 > > 44.1023 A44RTR simh VAXserver 3900 VMS 6.1 > > > > Now that's quite a few systems! > > > -----Oorspronkelijk bericht----- > > Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens > > Sampsa Laine > > Verzonden: zaterdag, mei 2013 16:00 > > Aan: hecnet at Update.UU.SE > > Onderwerp: Re: [HECnet] Another sillyness. More information in the nodename > > database on MIM. > > > > My boxes: > > > > London based boxes: > > > > 8.401 CHIMPY: DS10, OpenVMS 8.3 > > 8.400 GORVAX: SIMH, OpenVMS 7.3 > > 8.403 RHESUS: rx2600, OpenVMS 8.4E (also offers a variety of services, see > > http://rhesus.sampsa.com/) > > > > > > 47.100 HILANT Cluster in Hila, Finland, composed of: > > > > 47.556 KUHAVX SIMH running VMS 7.3 > > 47.555 LABVAX - = - > > 47.727 SHAMS - = - > > 47.559 HPIVAX - = - (Raspberry Pi) > > 47.113 SIIRI MicroVAX 3400, VMS 7.3 > > 47.700 K4VX1 VAXstation 4000/90, VMS 7.3 > > 47.701 K4VX2 VAXstation 4000/60, VMS 7.3 > > > > > > > > > > On 17 May 2013, at 17:03, Johnny Billquist <bqt at softjar.se> wrote: > > > >> On 2013-05-17 16:18, Bob Armstrong wrote: > >>>> On 2013-05-16 18:28, Johnny Billquist wrote: > >>>> This is a totally volontary thing. I've finally come to the point > >>>> where I think that there are a few more pieces of data on nodes > >>>> that would be nice/useful to have from time to time. > >>> > >>> Much of the information you want (all of it, I think) is already in the > >>> INFO.TXT file - > >>> > >>> $ type legato""::info.txt > >>> .... > >>> ADDR |NAME |OWNER |EMAIL |HARDWARE |OS > >>> |LOCATION |NOTES > >>> 2.1 |LEGATO|Bob Armstrong |bob at jfcl.com |simh |OpenVMS > >>> 7.3|Milpitas, CA, US|DCN Multinet Ro > >>> uter > >>> 2.2 |POCO | | |MicroVAX-2000 | > >>> | |6MB, RD54, TK50 > >>> 2.4 |MEZZO | | |PDP-11/53 |RSTS > >>> | |3.5MB, 2xRA73,TK70, SCSI > >>> 2.6 |LARGO | | |VAX-11/730 |VMS 4.7 > >>> | |R80, 2xRA81, RL02, RX02, TU80 > >>> 2.7 |CODA | | |DS20E |OpenVMS > >>> 8.3| | > >>> 2.9 |DIVISI| | |VAX-8350 |VMS > > 5.5-2 > >>> | |16MB, RA81, RA82, TU81+ > >>> 2.10 |ADAGIO| | |VAXserver 3900 |VMS 6.0 > >>> | |RA81, RX50, 2xRD54, Kennedy 9610, RRD50, RF31, 2xRF71, > >>> RF72, SQ703, Exabyte 8505 > >>> 2.11 |LENTO | | |PDP-11/73 |RSX-11M+ > >>> | |2xRD32, RX50, RL02, Kennedy 9600 > >>> 2.12 |JENSEN| | |DEC 2000 axp |OpenVMS > >>> 7.3| | > >>> 2.13 |ZITI | | |eBox-3310 |Ubuntu > >>> | | > >>> 2.14 |MULTIA| | |Multia UDB |OpenVMS > >>> 7.3| | > >>> 2.15 |PAVANE| | |DECstation 3100 |Ultrix > >>> | |MIPS box w/DECnet-Ultrix > >>> 2.16 |SKETTI| | |HP ProLiant ML110G4 |Ubuntu > >>> | | > >>> 2.18 |DSRVB1| | |DECserver-200/MC | > >>> | | > >>> 2.19 |DSRVB2| | |DECserver-200/MC | > >>> | | > >>> > >>> FWIW, keeping a central database up to date is going to be a nightmare > > - > >>> that's why we invented the INFO.TXT files; so each sysadmin could locally > >>> update his own information. > >> > >> Yes. I know... :-) > >> > >> Which I said this is all voluntary and so on. I've just felt that the > > INFO.TXT is not really working that well either. At least not from my point > > of view. I'm willing to try different things.. I could consider some > > automatic scraping and population of the nodename database from some > > distributed sources as well, if we can come up with something that seems > > reasonable. > >> > >> Oh, and thanks. > >> > >> Johnny > >> > > > > > > -- > Cory Smelosky > http://gewt.net/ Personal stuff > http://gimme-sympathy.org Experiments > > -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments

12 years, 5 months

Another sillyness. More information in the nodename database on MIM.

by hvlems＠zonnet.nl

Unfortunately not Cory, 0.22 euro per kWhr. No way I can leave even one (real) system on line all day long. Van: Cory Smelosky Verzonden: zaterdag 18 mei 2013 19:28 PM Aan: h vlems Beantwoorden: hecnet at Update.UU.SE Cc: hecnet Onderwerp: Re: [HECnet] Another sillyness. More information in the nodename database on MIM. On Sat, 18 May 2013, h vlems wrote: > It doesn't happen too often but when they all run in th winter there's no snow on the roof! > Given that my town has a certain reputation for growing marihuana that is a mixed blessing... > No police yet however :-) Power must be cheap there. > > Van: Cory Smelosky > Verzonden: zaterdag 18 mei 2013 18:45 PM > Aan: H Vlems > Beantwoorden: hecnet at Update.UU.SE > Cc: hecnet > Onderwerp: RE: [HECnet] Another sillyness. More information in the nodename database on MIM. > > > On Sat, 18 May 2013, H Vlems wrote: > > > > > A list of my systems: > > > > 44.1 HELIUM VAXstation 3100-M48 VMS 7.2 > > 44.2 XENON VAXstation 4000-60 VMS 7.2 > > 44.3 ARGON VAXstation 4000-90A VMS 7.3 > > 44.4 NEON Asus Eee pc Fedora 14 > > 44.5 ZILVER VAXstation 4000-60 VMS 7.3 > > 44.6 JODIUM VAXstation 2000 VMS 5.5-1 > > 44.7 RADON VAXstation 3100 VMS 5.5-1 > > 44.8 ASTAAT DECserver 100 > > 44.9 OSMIUM Digital Server 5305 5/533 VMS 8.3 > > 44.10 CHLOOR VAXstation 4000-90A VMS 7.2 > > 44.11 ZWAVEL microVAX 3100-10e VMS 6.1 > > 44.12 INDIUM VXT2000+ > > 44.13 ERBIUM AlphaServer 800 5/500 Tru64 5.0 > > 44.14 BROOM AlpaServer 1200 5/400 VMS 7.3-2 > > 44.15 FOSFOR VAXstation 4000-60 VMS 7.3 > > 44.16 COBALT VAXstation 4000-60 VMS 7.3 > > 44.17 KOPER VAXstation 2000 VMS 5.5-1 > > 44.18 CERIUM VAX 4000-100A VMS 7.3 > > 44.19 IJZER Compaq XP1000 6/500 VMS 8.3 > > 44.20 CHROOM VAX 4000-100A VMS 7.3 > > 44.21 NIKKEL VAXstation 4000-90A VMS 7.3 > > 44.22 ZINK VAXstation 4000 VLC VMS 7.3 > > 44.23 LOOD microVAX 3100-30 VMS 7.3 > > 44.24 CURIUM Multia VX42 4/233 VMS 7.3 > > 44.25 KWIK VAXstation 4000-60 VMS 7.3 > > 44.26 AURUM Integrity rx2600 VMS 8.4 > > 44.27 RADIUM HP dc5000 sff Windows XP > > 44.28 TIN AlphaServer 1200 5/533 VMS 8.3 > > 44.29 FLUOR AlphaServer 1000A 5/333 VMS 7.3-2 > > 44.30 BOOR VAXstation 4000-60 VMS 7.1 > > 44.31 SELEEN microVAX 3100-20e VMS 6.1 > > 44.32 ARSEEN microVAX 3100-20e VMS 6.1 > > 44.33 CARBON DEC AXP 3000-300X VMS 1.5-1H1 > > 44.34 OXYGEN DEC AXP 3000-300X VMS 6.1 > > 44.35 TITAAN AlphaServer DS20E 6/666 VMS 8.3 > > 44.36 URAAN AlphaServer 1000A 5/333 VMS 8.3 > > 44..37 BARIUM AlphaServer 1200 5/533 VMS 8.3 > > 44.38 CESIUM Digital Server 5305 5/533 VMS 8.3 > > 44.39 KALIUM AlphaServer 300 Tru64 5.1a > > 44.40 SODIUM Digital Server 5305 5/533 VMS 8.3 > > 44.41 AZOTE <not in use> > > 44.42 VISMUT AlphaServer 800 5/333 Tru64 5.1a > > 44.43 OZON AlphaServer DS10 6/466 VMS 8.4 > > 44.1023 A44RTR simh VAXserver 3900 VMS 6.1 > > > > Now that's quite a few systems! > > > -----Oorspronkelijk bericht----- > > Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens > > Sampsa Laine > > Verzonden: zaterdag, mei 2013 16:00 > > Aan: hecnet at Update.UU.SE > > Onderwerp: Re: [HECnet] Another sillyness. More information in the nodename > > database on MIM. > > > > My boxes: > > > > London based boxes: > > > > 8.401 CHIMPY: DS10, OpenVMS 8.3 > > 8.400 GORVAX: SIMH, OpenVMS 7.3 > > 8.403 RHESUS: rx2600, OpenVMS 8.4E (also offers a variety of services, see > > http://rhesus.sampsa.com/) > > > > > > 47.100 HILANT Cluster in Hila, Finland, composed of: > > > > 47.556 KUHAVX SIMH running VMS 7.3 > > 47.555 LABVAX - = - > > 47.727 SHAMS - = - > > 47.559 HPIVAX - = - (Raspberry Pi) > > 47.113 SIIRI MicroVAX 3400, VMS 7.3 > > 47.700 K4VX1 VAXstation 4000/90, VMS 7.3 > > 47.701 K4VX2 VAXstation 4000/60, VMS 7.3 > > > > > > > > > > On 17 May 2013, at 17:03, Johnny Billquist <bqt at softjar.se> wrote: > > > >> On 2013-05-17 16:18, Bob Armstrong wrote: > >>>> On 2013-05-16 18:28, Johnny Billquist wrote: > >>>> This is a totally volontary thing. I've finally come to the point > >>>> where I think that there are a few more pieces of data on nodes > >>>> that would be nice/useful to have from time to time. > >>> > >>> Much of the information you want (all of it, I think) is already in the > >>> INFO.TXT file - > >>> > >>> $ type legato""::info.txt > >>> .... > >>> ADDR |NAME |OWNER |EMAIL |HARDWARE |OS > >>> |LOCATION |NOTES > >>> 2.1 |LEGATO|Bob Armstrong |bob at jfcl.com |simh |OpenVMS > >>> 7.3|Milpitas, CA, US|DCN Multinet Ro > >>> uter > >>> 2.2 |POCO | | |MicroVAX-2000 | > >>> | |6MB, RD54, TK50 > >>> 2.4 |MEZZO | | |PDP-11/53 |RSTS > >>> | |3.5MB, 2xRA73,TK70, SCSI > >>> 2.6 |LARGO | | |VAX-11/730 |VMS 4.7 > >>> | |R80, 2xRA81, RL02, RX02, TU80 > >>> 2.7 |CODA | | |DS20E |OpenVMS > >>> 8.3| | > >>> 2.9 |DIVISI| | |VAX-8350 |VMS > > 5.5-2 > >>> | |16MB, RA81, RA82, TU81+ > >>> 2.10 |ADAGIO| | |VAXserver 3900 |VMS 6.0 > >>> | |RA81, RX50, 2xRD54, Kennedy 9610, RRD50, RF31, 2xRF71, > >>> RF72, SQ703, Exabyte 8505 > >>> 2.11 |LENTO | | |PDP-11/73 |RSX-11M+ > >>> | |2xRD32, RX50, RL02, Kennedy 9600 > >>> 2.12 |JENSEN| | |DEC 2000 axp |OpenVMS > >>> 7.3| | > >>> 2.13 |ZITI | | |eBox-3310 |Ubuntu > >>> | | > >>> 2.14 |MULTIA| | |Multia UDB |OpenVMS > >>> 7.3| | > >>> 2.15 |PAVANE| | |DECstation 3100 |Ultrix > >>> | |MIPS box w/DECnet-Ultrix > >>> 2.16 |SKETTI| | |HP ProLiant ML110G4 |Ubuntu > >>> | | > >>> 2.18 |DSRVB1| | |DECserver-200/MC | > >>> | | > >>> 2.19 |DSRVB2| | |DECserver-200/MC | > >>> | | > >>> > >>> FWIW, keeping a central database up to date is going to be a nightmare > > - > >>> that's why we invented the INFO.TXT files; so each sysadmin could locally > >>> update his own information. > >> > >> Yes. I know... :-) > >> > >> Which I said this is all voluntary and so on. I've just felt that the > > INFO.TXT is not really working that well either. At least not from my point > > of view. I'm willing to try different things. I could consider some > > automatic scraping and population of the nodename database from some > > distributed sources as well, if we can come up with something that seems > > reasonable. > >> > >> Oh, and thanks. > >> > >> Johnny > >> > > > > > > -- > Cory Smelosky > http://gewt.net/ Personal stuff > http://gimme-sympathy.org Experiments > > -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments

12 years, 5 months

TOPS-10 and DECnet Progress Update

by b4＠gewt.net

On Sat, 18 May 2013, G. wrote: On Sat, 18 May 2013 06:14:27 -0000, you wrote: SET HOST to MARLEY (9.10) (It's a bit slow to respond only via DECnet. I might need to play with buffers) If you use the CTERM protocol, it will be always slow and sluggish, no matter how much you'll try to tweak it. Try SET HOST /APP=R and appreciate speed :) It's MUCH more usable when using RTERM. Thank you. Why is CTERM so slow on TOPS-10? Credentials are guest and the password is guest. Still need to install some stuff for language support. If you like it more, there is a way to have a user with no password (and/or with the ability to actually change password disabled). Just play with REACT and look for the right incantation, because I do not remember it anymore... It's related to requirements I believe. G. :) -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments

12 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet