- HECnet - lists @ Update

by bqt＠softjar.se

On 2012-06-07 18:11, Kari Uusim ki wrote: On 7.6.2012 5:05, Joe Ferraro wrote: On Wed, Jun 6, 2012 at 7:13 PM, Sampsa Laine <sampsa at mac.com <mailto:sampsa at mac.com>> wrote: I've got a Windows NT 4.0 VM up occasionally too.. Sampsa boy that gives me bad memories of long days ... perhaps you should've gone for NT 3.50 while you were at it... I do have a Win 3.11 box running... perhaps there's a decnet stack for it?!!? There is a DECnet stack for DOS and Windows in the Pathworks V5 or V6 client kit. Those versions were meant to be used on Windows'es before Windows NT4. Then the Pathworks32 kit was released and that could be used on WNT4.0 and Windows 2000. Maybe on XP as well. Don't remember for sure. Some pretty recent version of Pathworks32 works on Windows XP anyway. Johnny

13 years, 1 month

1
0
0 0

User mode DECnet (was Multinet Tunnel Connections to SG1::)

by bob＠jfcl.com

I was meaning as in non-root. Ah, well, but that's good because it means kernel hacks are not required. Bob

13 years, 1 month

1
0
0 0

Size of HECnet

by uusimaki＠exdecfinland.org

On 7.6.2012 5:05, Joe Ferraro wrote: On Wed, Jun 6, 2012 at 7:13 PM, Sampsa Laine <sampsa at mac.com <mailto:sampsa at mac.com>> wrote: I've got a Windows NT 4.0 VM up occasionally too.. Sampsa boy that gives me bad memories of long days ... perhaps you should've gone for NT 3.50 while you were at it... I do have a Win 3.11 box running... perhaps there's a decnet stack for it?!!? There is a DECnet stack for DOS and Windows in the Pathworks V5 or V6 client kit. Those versions were meant to be used on Windows'es before Windows NT4. Then the Pathworks32 kit was released and that could be used on WNT4.0 and Windows 2000. Maybe on XP as well. Don't remember for sure.

13 years, 1 month

1
0
0 0

New bridge.c feedback

by bqt＠softjar.se

On 2012-06-07 17:53, Marc Chametzky wrote: Marc, are you sure ? It means that the assignment gets evaluated as a boolean expression?? Yes... you've got "port == DPORT" with two equal signs. That's not an assignment. That is going to evaluate to see whether it's true or false. Since DPORT = 0 by default, then it's evaluating "port == 0" which is true, thus its value is 1. So, you've got a statement which is: 1; Essentially, it's a no-op. With DPORT = 0, it doesn't make any difference, save for a compiler warning. If you were to set DPORT to some other number, though, the assignment wouldn't take place as would otherwise be expected. The assignment never took place, as it should have, since there was no assignment. If you changed DPORT to something else, you'd just get a if (port == 0) 0; which is just as meaningless as the result of DPORT was set to 0, which gave if (port == 0) 1; Johnny

13 years, 1 month

1
0
0 0

New bridge.c feedback

by bqt＠softjar.se

On 2012-06-07 17:50, hvlems at zonnet.nl wrote: Marc, are you sure ? It means that the assignment gets evaluated as a boolean expression?? No, he's right. The *original* code (not what I wrote further down), is (was): if (port == 0) port == DPORT; Johnny -----Original Message----- From: Marc Chametzky<marc at bluevine.net> Sender: owner-hecnet at Update.UU.SE Date: Thu, 07 Jun 2012 11:44:31 To:<hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] New bridge.c feedback 1171 cc: WARNING File = bridge.c, Line = 684 The indicated expression has no effect. if (port == 0) port == DPORT; ^ Apart from putting in a conditional? DPORT is a constant that I intended for users that compile to be able to change, if they want to. By default is't zero, thus the compiler sees: if (port == 0) port = 0; No, that's not what the compiler is seeing. Instead, it's seeing this: if (port == 0) 1; That's because you have "port == DPORT" (a conditional, not an assignment statement). which is pretty meaningless, and thus something to warn about. But how should I change the code to avoid that? I could (of course) add a check to the if, but that makes it look more complicated, and silly. Oh well, checking if DPORT have been defined to something non-zero is a pretty reasonable solution I think. --Marc

13 years, 1 month

1
0
0 0

New bridge.c feedback

by bqt＠softjar.se

On 2012-06-07 17:44, Marc Chametzky wrote: 1171 cc: WARNING File = bridge.c, Line = 684 The indicated expression has no effect. if (port == 0) port == DPORT; ^ Apart from putting in a conditional? DPORT is a constant that I intended for users that compile to be able to change, if they want to. By default is't zero, thus the compiler sees: if (port == 0) port = 0; No, that's not what the compiler is seeing. Instead, it's seeing this: if (port == 0) 1; That's because you have "port == DPORT" (a conditional, not an assignment statement). Jeeeez. When the f* did that sneak in there??? I'm way too tired today (obviously). That was totally meaningless. (Maybe just my brain, knowing what it should say just managed to ignore that extra equal sign.) Thanks for pointing out the obvious. Fixed now. Johnny

13 years, 1 month

1
0
0 0

New bridge.c feedback

by marc＠bluevine.net

Marc, are you sure ? It means that the assignment gets evaluated as a boolean expression?? Yes... you've got "port == DPORT" with two equal signs. That's not an assignment. That is going to evaluate to see whether it's true or false. Since DPORT = 0 by default, then it's evaluating "port == 0" which is true, thus its value is 1. So, you've got a statement which is: 1; Essentially, it's a no-op. With DPORT = 0, it doesn't make any difference, save for a compiler warning. If you were to set DPORT to some other number, though, the assignment wouldn't take place as would otherwise be expected. --Marc

13 years, 1 month

1
0
0 0

New bridge.c feedback

by hvlems＠zonnet.nl

Marc, are you sure ? It means that the assignment gets evaluated as a boolean expression?? -----Original Message----- From: Marc Chametzky <marc at bluevine.net> Sender: owner-hecnet at Update.UU.SE Date: Thu, 07 Jun 2012 11:44:31 To: <hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] New bridge.c feedback 1171 cc: WARNING File = bridge.c, Line = 684 The indicated expression has no effect. if (port == 0) port == DPORT; ^ Apart from putting in a conditional? DPORT is a constant that I intended for users that compile to be able to change, if they want to. By default is't zero, thus the compiler sees: if (port == 0) port = 0; No, that's not what the compiler is seeing. Instead, it's seeing this: if (port == 0) 1; That's because you have "port == DPORT" (a conditional, not an assignment statement). which is pretty meaningless, and thus something to warn about. But how should I change the code to avoid that? I could (of course) add a check to the if, but that makes it look more complicated, and silly. Oh well, checking if DPORT have been defined to something non-zero is a pretty reasonable solution I think. --Marc

13 years, 1 month

1
0
0 0

New bridge.c feedback

by hvlems＠zonnet.nl

Wouldn't an #ifndef DPORT statement solve that? Hans (And I'm an algol programmer, not very well versed in C magic ;-) ------Origineel bericht------ Van: Johnny Billquist Afzender: owner-hecnet at Update.UU.SE Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] New bridge.c feedback Verzonden: 7 juni 2012 17:18 On 2012-06-07 16:32, Marc Chametzky wrote: cc-1171 cc: WARNING File = bridge.c, Line = 684 The indicated expression has no effect. if (port == 0) port == DPORT; ^ Blech! Well, DPORT is by default set to 0. See the documentation of the define in the sources... This one will stay. I saw your second message about putting this in a conditional, but out of curiosity, why wouldn't you want to fix it? You don't have an assignment statement here, so if you do define DPORT, it won't take effect the way you want with the code like this. Apart from putting in a conditional? DPORT is a constant that I intended for users that compile to be able to change, if they want to. By default is't zero, thus the compiler sees: if (port == 0) port = 0; which is pretty meaningless, and thus something to warn about. But how should I change the code to avoid that? I could (of course) add a check to the if, but that makes it look more complicated, and silly. Oh well, checking if DPORT have been defined to something non-zero is a pretty reasonable solution I think. Johnny

13 years, 1 month

1
0
0 0

New bridge.c feedback

by marc＠bluevine.net

1171 cc: WARNING File = bridge.c, Line = 684 The indicated expression has no effect. if (port == 0) port == DPORT; ^ Apart from putting in a conditional? DPORT is a constant that I intended for users that compile to be able to change, if they want to. By default is't zero, thus the compiler sees: if (port == 0) port = 0; No, that's not what the compiler is seeing. Instead, it's seeing this: if (port == 0) 1; That's because you have "port == DPORT" (a conditional, not an assignment statement). which is pretty meaningless, and thus something to warn about. But how should I change the code to avoid that? I could (of course) add a check to the if, but that makes it look more complicated, and silly. Oh well, checking if DPORT have been defined to something non-zero is a pretty reasonable solution I think. --Marc

13 years, 1 month

1
0
0 0

New bridge.c feedback

by bqt＠softjar.se

On 2012-06-07 16:32, Marc Chametzky wrote: cc-1171 cc: WARNING File = bridge.c, Line = 684 The indicated expression has no effect. if (port == 0) port == DPORT; ^ Blech! Well, DPORT is by default set to 0. See the documentation of the define in the sources... This one will stay. I saw your second message about putting this in a conditional, but out of curiosity, why wouldn't you want to fix it? You don't have an assignment statement here, so if you do define DPORT, it won't take effect the way you want with the code like this. Apart from putting in a conditional? DPORT is a constant that I intended for users that compile to be able to change, if they want to. By default is't zero, thus the compiler sees: if (port == 0) port = 0; which is pretty meaningless, and thus something to warn about. But how should I change the code to avoid that? I could (of course) add a check to the if, but that makes it look more complicated, and silly. Oh well, checking if DPORT have been defined to something non-zero is a pretty reasonable solution I think. Johnny

13 years, 1 month

1
0
0 0

User mode DECnet (was Multinet Tunnel Connections to SG1::)

by bqt＠softjar.se

On 2012-06-07 16:15, Bob Armstrong wrote: Johnny Billquist wrote: Are you actually talking now about implementing a DECnet stack on a machine in user mode? That is definitely not doable. Is that really true? I don't believe it. How about an Einstein style "gedanken experiment" - put simh on a machine (which is an entirely user mode program), load VMS on it. Bingo - a user mode implementation of a DECnet stack. I was meaning as in non-root. Sigh. I don't know how I managed to screw up terminology that way... I don't mean this as a practical solution to DECnet on Linux, but it's clearly possible to get all the Ethernet access you need to implement DECnet in a user mode program. N.B. "user mode" is not the same as "run as root". Promiscuous mode requires root privilege, but that's still a user mode program. Correct. For some reason I screwed up at that point. Johnny

13 years, 1 month

1
0
0 0

Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-07 15:55, Mark Benson wrote: On 7 Jun 2012, at 13:44, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote: If I've understood it correctly, the idea is to replace the (dying) kernel support for DECNet under linux by userland code, so it the current module dies definitely due to kernel ABI changes we could still use decnet in the Linux boxes. As Johnny pointed out, some root access is required for a daemon to play with the ethernet but with that in place the rest would be userland, yes. The key is no kernel module or kernel support is necessary because it's going away. I guess it might be worth pointing out that running as root still means it's in user mode. There is nothing that needs to be in the kernel itself. You can do all of it from userland. But you need parts to be running as root. That is potentially a security problem, yes. No helping that. But carefully written code is always a good idea. I'd add as an additional benefit that moving decnet out of the kernel would make possible to port it to other unix flavours, like the BSDs and Mac OSX. That was also part of my modus operandi. It would port to prettymuch and OS that supports libpcap and MAC address spoofing (possibly Windows?). Actually an interesting point. Johnny

13 years, 1 month

1
0
0 0

Introducing myself... and my little network

by hvlems＠zonnet.nl

The 20 VUPS rating listed for the -60 comes from my own website. It was measured with a homegrown vups tool and its accuracy is ummm, limited. One can argue that is true for all vups ratings ... (The M in MIPS stands for meaningless :-) However I find a model 90A with 128MB memory a lot faster than any of my model 60's. It just shows that speed, like beauty only exists in the eye of the owner. I always considered a Vax 8550 faster than a 6410 or an 8650 . Perception eh. Hans -----Original Message----- From: Mark Wickens <mark at wickensonline.co.uk> Sender: owner-hecnet at Update.UU.SE Date: Thu, 7 Jun 2012 15:08:24 To: hecnet at Update.UU.SE<hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Introducing myself... and my little network Just consulted a few online VPUs comparisons and it looks like we're both slightly wrong, although I'm happy to be corrected: VAXstation 4000 model 60: 12 VUPS VAXstation 4000 model 90: 32 VUPS VAXstation 4000 model 90A: 40 VUPS VAXstation 4000 model 96: 45 VUPS However as I've said apart from CPU intensive tasks the '60 doesn't 'feel' much slower than the '90. Regards, Mark. Sent from my iPad On 7 Jun 2012, at 14:12, hvlems at zonnet.nl wrote: The Vaxstation 4000 model 60 is rated at approx 20 VUPS, the 90A at 40 VUPS. I don"t own a model 90. The 90A's are very fast compared to other Vaxes I worked with. Two exceptions, the 4705A and the 4108 (4105?, the one that cames in a plastic PC style cabinet) were also quite fast. The Vaxstation 4000 model 96 is faster than the 90A (45 VUPS). I certainly would like one for my collection! Hans ------Origineel bericht------ Van: Mark Benson Afzender: owner-hecnet at Update.UU.SE Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] Introducing myself... and my little network Verzonden: 7 juni 2012 13:41 On 7 Jun 2012, at 10:33, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote: Hello list, I've just joined HECnet under the area 7, and I wanted to introduce myself and my little puppies :) Hello! I am interested to know how you find the performance of the VAXstation 4000/60 compared to others. Good to see someone with such great skills on old iron join us. I know very little outside vasics and simple DECnet setup :) -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson

13 years, 1 month

1
0
0 0

Multinet Tunnel Connections to SG1::

by md.benson＠gmail.com

-- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson On 7 Jun 2012, at 15:38, Chrissie Caulfield <christine.caulfield at googlemail.com> wrote: Depending on the OS, it's perfectly doable. I wrote LAT for Linux in this exact way - because I didn't want to mess around inside the kernel. It's not ideal, and performance will probably be awful, but if you can get access to raw ethernet packets it's not not even especially hard :) ... and thus she didst spake (or something). :)That's what made me think it must be possible. -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson

13 years, 1 month

1
0
0 0

User mode DECnet (was Multinet Tunnel Connections to SG1::)

by md.benson＠gmail.com

On 7 Jun 2012, at 15:15, Bob Armstrong <bob at jfcl.com> wrote: Johnny Billquist wrote: Are you actually talking now about implementing a DECnet stack on a machine in user mode? That is definitely not doable. Is that really true? I don't believe it. How about an Einstein style "gedanken experiment" - put simh on a machine (which is an entirely user mode program), load VMS on it. Bingo - a user mode implementation of a DECnet stack. I don't mean this as a practical solution to DECnet on Linux, but it's clearly possible to get all the Ethernet access you need to implement DECnet in a user mode program. N.B. "user mode" is not the same as "run as root". Promiscuous mode requires root privilege, but that's still a user mode program That's what made me peopose that it may be possible. SimH already implements the underlying ethernet wizardry to allow DECnet and other ethernet-based protocols to operate inside the simulator. -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson

13 years, 1 month

1
0
0 0

Multinet Tunnel Connections to SG1::

by christine.caulfield＠googlemail.com

On 07/06/12 13:32, Johnny Billquist wrote: On 2012-06-07 14:22, Johnny Billquist wrote: On 2012-06-07 12:37, Sampsa Laine wrote: On 7 Jun 2012, at 11:29, Dave McGuire wrote: Howabout starting it as a daemon (running as root) via the boot scripts, and have non-root users's programs access it via a socket? Cool idea - you could even have multiple hosts connect this way but export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes to Box B, and MAIL to Box C :) Are you trying to suggest something like NAT for DECnet? I'm not sure how easy that would be to do in DECnet, as it works in some different ways than IP that might cause problems doing this. Reading through things a little more... Are you actually talking now about implementing a DECnet stack on a machine in user mode? That is definitely not doable. Depending on the OS, it's perfectly doable. I wrote LAT for Linux in this exact way - because I didn't want to mess around inside the kernel. It's not ideal, and performance will probably be awful, but if you can get access to raw ethernet packets it's not not even especially hard :) Chrissie

13 years, 1 month

1
0
0 0

New bridge.c feedback

by marc＠bluevine.net

cc-1171 cc: WARNING File = bridge.c, Line = 684 The indicated expression has no effect. if (port == 0) port == DPORT; ^ Blech! Well, DPORT is by default set to 0. See the documentation of the define in the sources... This one will stay. I saw your second message about putting this in a conditional, but out of curiosity, why wouldn't you want to fix it? You don't have an assignment statement here, so if you do define DPORT, it won't take effect the way you want with the code like this. --Marc

13 years, 1 month

1
0
0 0

User mode DECnet (was Multinet Tunnel Connections to SG1::)

by bob＠jfcl.com

Johnny Billquist wrote: Are you actually talking now about implementing a DECnet stack on a machine in user mode? That is definitely not doable. Is that really true? I don't believe it. How about an Einstein style "gedanken experiment" - put simh on a machine (which is an entirely user mode program), load VMS on it. Bingo - a user mode implementation of a DECnet stack. I don't mean this as a practical solution to DECnet on Linux, but it's clearly possible to get all the Ethernet access you need to implement DECnet in a user mode program. N.B. "user mode" is not the same as "run as root". Promiscuous mode requires root privilege, but that's still a user mode program. Bob

13 years, 1 month

1
0
0 0

Introducing myself... and my little network

by mark＠wickensonline.co.uk

Just consulted a few online VPUs comparisons and it looks like we're both slightly wrong, although I'm happy to be corrected: VAXstation 4000 model 60: 12 VUPS VAXstation 4000 model 90: 32 VUPS VAXstation 4000 model 90A: 40 VUPS VAXstation 4000 model 96: 45 VUPS However as I've said apart from CPU intensive tasks the '60 doesn't 'feel' much slower than the '90. Regards, Mark. Sent from my iPad On 7 Jun 2012, at 14:12, hvlems at zonnet.nl wrote: The Vaxstation 4000 model 60 is rated at approx 20 VUPS, the 90A at 40 VUPS. I don"t own a model 90. The 90A's are very fast compared to other Vaxes I worked with. Two exceptions, the 4705A and the 4108 (4105?, the one that cames in a plastic PC style cabinet) were also quite fast. The Vaxstation 4000 model 96 is faster than the 90A (45 VUPS). I certainly would like one for my collection! Hans ------Origineel bericht------ Van: Mark Benson Afzender: owner-hecnet at Update.UU.SE Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] Introducing myself... and my little network Verzonden: 7 juni 2012 13:41 On 7 Jun 2012, at 10:33, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote: Hello list, I've just joined HECnet under the area 7, and I wanted to introduce myself and my little puppies :) Hello! I am interested to know how you find the performance of the VAXstation 4000/60 compared to others. Good to see someone with such great skills on old iron join us. I know very little outside vasics and simple DECnet setup :) -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson

13 years, 1 month

1
0
0 0

Introducing myself... and my little network

by ian＠platinum.net

I told my wife many years ago that if I ever found an 11/750 or 11/780 it's coming to live in our garage. It was the first real computer I ever used. The largest VAX in my collection so far is only the size if a bar fridge so I think that's all she's expecting. I guess it's probably best that I haven't actually found an 11/780 yet... Ian Sent from my iPad On 2012-06-07, at 5:35 AM, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote: Jordi Guillaumes i Pons Barcelona - Catalunya - Europa El 07/06/2012, a les 13:46, Dave McGuire <mcguire at neurotica.com> va escriure: On 06/07/2012 07:26 AM, Jordi Guillaumes i Pons wrote: According to this: http://h71000.www7.hp.com/openvms/os/openvms-release-history.html Support for the 4000/90 came in version 5.5-2 (1992). The 3300 was supported in 5.0-2 and the 4000 mod. 2000 in 5.4-2. So none of my real boxen can run 4.7. Well you've gotta find yourself some more machines! 11/750s are probably the most common of the 4.x-capable machines, though there don't seem to be many left floating around. Heh, then I would have to find also a new home and probably an attorney to handle de divorce demand ;) -Dave -- Dave McGuire, AK4HZ New Kensington, PA --- Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=ECEB3FF8B09C11E18…

13 years, 1 month

1
0
0 0

Multinet Tunnel Connections to SG1::

by md.benson＠gmail.com

On 7 Jun 2012, at 13:44, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote: If I've understood it correctly, the idea is to replace the (dying) kernel support for DECNet under linux by userland code, so it the current module dies definitely due to kernel ABI changes we could still use decnet in the Linux boxes. As Johnny pointed out, some root access is required for a daemon to play with the ethernet but with that in place the rest would be userland, yes. The key is no kernel module or kernel support is necessary because it's going away. I'd add as an additional benefit that moving decnet out of the kernel would make possible to port it to other unix flavours, like the BSDs and Mac OSX. That was also part of my modus operandi. It would port to prettymuch and OS that supports libpcap and MAC address spoofing (possibly Windows?). -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson

13 years, 1 month

1
0
0 0

Multinet Tunnel Connections to SG1::

by md.benson＠gmail.com

On 7 Jun 2012, at 13:32, Johnny Billquist <bqt at softjar.se> wrote: Are you actually talking now about implementing a DECnet stack on a machine in user mode? That is definitely not doable. You need atleast one part that talks raw ethernet, if you want access to the local ethernet. No. What we are trying to work out is if (as it seems to be) it is possible to implement a functional DECnet stack without having to directly alterbthe kernel code (as is currently required) because doing so limits portability and compatibility due to ever-shifting sands of Linux kernel development. And that part needs to run as root. No way around that. We established that, yes. That's where my idea of using pcap and running the interface in promicuous mode came out of. Normal user programs should of course not need to be running as root, nor much around in the kernel, but there is nothing tricky about this. The DECnet stack is one process. Any other program talking DECnet needs to talk to the DECnet stack. That can be done in a number of ways. Unix sockets, TCP/IP sockets, shared memory, named pipes... Just pick something. So with the daemon running as root it is possible to access it from 'userland' without root access. Excellent. The ugly part is that you'll need to write all the software to handle all the protocols that sits on top of DECnet, such as a FAL listener, a FAL user client, CTERM listener and client, NICE, PHONE, MAIL... The list goes on... You'll probably want to write a library with all the DECnet library primitives so that you have a nice API for the user level code to use. If you are lucky, the API in the current implementation can be adapted to your new implementation, which will make it possible to reuse a lot of code. I have not looked at how the current DECnet API looks like in Linux. That seems like a sound idea to me. If the code already exists there's no point on duplicating the effort unless it's required. Anyway, this is a different story than any potential problems with promiscuous mode... As I explained, my thinking was to use promiscuous mode to created a DECnet stack that wasn't kernel dependant. That's where Dave and I got hung up on potential small issues. All clear there now, we can move on! And you still need to be root to play with ethernet. Indeed. -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson

13 years, 1 month

1
0
0 0

Introducing myself... and my little network

by hvlems＠zonnet.nl

A vaxstation 2000 and a microvax 2000 run V4.7 too. With VWS instead of Motif at a reasonable speed. Hans -----Original Message----- From: Dave McGuire <mcguire at neurotica.com> Sender: owner-hecnet at Update.UU.SE Date: Thu, 07 Jun 2012 07:46:10 To: <hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Introducing myself... and my little network On 06/07/2012 07:26 AM, Jordi Guillaumes i Pons wrote: According to this: http://h71000.www7.hp.com/openvms/os/openvms-release-history.html Support for the 4000/90 came in version 5.5-2 (1992). The 3300 was supported in 5.0-2 and the 4000 mod. 2000 in 5.4-2. So none of my real boxen can run 4.7. Well you've gotta find yourself some more machines! 11/750s are probably the most common of the 4.x-capable machines, though there don't seem to be many left floating around. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 1 month

1
0
0 0

Introducing myself... and my little network

by hvlems＠zonnet.nl

The Vaxstation 4000 model 60 is rated at approx 20 VUPS, the 90A at 40 VUPS. I don"t own a model 90. The 90A's are very fast compared to other Vaxes I worked with. Two exceptions, the 4705A and the 4108 (4105?, the one that cames in a plastic PC style cabinet) were also quite fast. The Vaxstation 4000 model 96 is faster than the 90A (45 VUPS). I certainly would like one for my collection! Hans ------Origineel bericht------ Van: Mark Benson Afzender: owner-hecnet at Update.UU.SE Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] Introducing myself... and my little network Verzonden: 7 juni 2012 13:41 On 7 Jun 2012, at 10:33, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote: Hello list, I've just joined HECnet under the area 7, and I wanted to introduce myself and my little puppies :) Hello! I am interested to know how you find the performance of the VAXstation 4000/60 compared to others. Good to see someone with such great skills on old iron join us. I know very little outside vasics and simple DECnet setup :) -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson

13 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet