> (since the file system is different -- most systems used the one first done in DOS-11).
That don't make sense. You only write a device driver for the TU56. File system issues are handled at another level. With VMS, you use EXCHANGE if you want to access something with DOS-11 format.
The same is true in RSX as well, except there you use FLX. But it worked perfectly fine to create an ODS-1 formatted TU56 tape. Although it wasn't the fastest disk... :-)
Also, as I recall, he added some things that were previously done only on the PDP-10:
"overlapped seek" (set the tape moving, read a block number, calculate the time to get
to the right block, then select the other drive to do some I/O) and the "flap" operation
(unmounts the tape by doing a reverse read and deselect, allowing the tape to be wound
all the way onto the reel and off the other spindle).
I have a multiuser OS for the PDP-8 which do the same thing. Works pretty ok. Well, almost the same thing anyway. It just does it for seeks on the tape, but not allowing concurrent operations on another tape. But you don't want to have a polling driver do a seek on a multiuser OS, and one of the interfaces for the DECtape on a PDP-8 was so stupid and simple that you could only do polling work.
I never actually saw it in action but the above is what I recall being told.
I wonder what Andy Goldstein is doing now? I have no doubt that he probably did those things anyway. He was also responsible for TECO being included with VMS, including porting it to native code for VAX (and I believe Alpha), as well as creating a callable version of TECO in VMS.
Lovely attitude. :-)
Johnny
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of hvlems at zonnet.nl
Sent: Tuesday, August 23, 2011 2:00 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Can we hook this up to a VAX or something?
Interesting, that a TU56 was supported by VMS. How did that become possible? Is it because the driver for the TU58 also happened to work for the TU56, possibly assisted by some SYSGEN magic to configure UB vector and addresses?
------Origineel bericht------
Van: Paul_Koning at Dell.com
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] Can we hook this up to a VAX or something?
Verzonden: 23 augustus 2011 19:48
I can't remember whether the RK05 was supported by VMS?
No, not AFAIK but the RL02 (either on an RL11 or the RB730) was.
But did it work? There were some strange old devices that worked on VMS even though not "supported" -- the TU56 (real DECtape) comes to mind.
paul
Verzonden vanaf mijn draadloze BlackBerry(r)-toestel
--
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
I never actually saw it in action but the above is what I recall being told.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of hvlems at zonnet.nl
Sent: Tuesday, August 23, 2011 2:00 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Can we hook this up to a VAX or something?
Interesting, that a TU56 was supported by VMS. How did that become possible? Is it because the driver for the TU58 also happened to work for the TU56, possibly assisted by some SYSGEN magic to configure UB vector and addresses?
------Origineel bericht------
Van: Paul_Koning at Dell.com
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] Can we hook this up to a VAX or something?
Verzonden: 23 augustus 2011 19:48
I can't remember whether the RK05 was supported by VMS?
No, not AFAIK but the RL02 (either on an RL11 or the RB730) was.
But did it work? There were some strange old devices that worked on VMS even though not "supported" -- the TU56 (real DECtape) comes to mind.
paul
Verzonden vanaf mijn draadloze BlackBerry(r)-toestel
I never actually saw it in action but the above is what I recall being told.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of hvlems at zonnet.nl
Sent: Tuesday, August 23, 2011 2:00 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Can we hook this up to a VAX or something?
Interesting, that a TU56 was supported by VMS. How did that become possible? Is it because the driver for the TU58 also happened to work for the TU56, possibly assisted by some SYSGEN magic to configure UB vector and addresses?
------Origineel bericht------
Van: Paul_Koning at Dell.com
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] Can we hook this up to a VAX or something?
Verzonden: 23 augustus 2011 19:48
I can't remember whether the RK05 was supported by VMS?
No, not AFAIK but the RL02 (either on an RL11 or the RB730) was.
But did it work? There were some strange old devices that worked on VMS even though not "supported" -- the TU56 (real DECtape) comes to mind.
paul
Verzonden vanaf mijn draadloze BlackBerry(r)-toestel
Hans
Verzonden vanaf mijn draadloze BlackBerry -toestel
-----Original Message-----
From: Paul Koning <paul_koning at dell.com>
Sender: owner-hecnet at Update.UU.SE
Date: Sat, 16 Jul 2011 17:46:09
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] DECnet et al
On Jul 16, 2011, at 5:40 PM, <hvlems at zonnet.nl> wrote:
Ok, so the convention that the output of the SHO NET command always lists the area router with the highest address is just a display rule. It has nothing to do with an "active" area router then?
I can't find the rule for what L2 adjacent router to pick if you're an L1 router going out of area. It may be that this is where "highest" kicks in.
For non-adjacent L2 routers, the L1 router doesn't have any idea which router is represented by the "nearest L2 router" pseudo-address zero. It can't know that.
paul
------Origineel bericht------
Van: Paul Koning
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] DECnet et al
Verzonden: 16 juli 2011 23:25
On Jul 16, 2011, at 3:42 PM, Johnny Billquist wrote:
On 2011-07-16 19.18, hvlems at zonnet.nl wrote:
I'm not sure what the router rules are. There are 63 areas, each with
one actove area router. There may be more routers configured as an area
router in one area; the one with the highest (?) DECnet address is
selected as the active one.
As far as I know, there can be more than one active area router. Just look at what the next hop are for different nodes in your node list... :-)
The way it works is that address 0 in the level 1 routing data corresponds to "nearest L2 router". Any L2 router contributes to that. The L1 routers don't know or care who is the nearest L2 router, they only care which direction to send to get there.
paul
Verzonden vanaf mijn draadloze BlackBerry -toestel
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On 13 Jul 2011, at 12:05, Sampsa Laine <sampsa at mac.com> wrote:
On 12 Jul 2011, at 21:34, Mark Benson wrote:
Don't buy an AS400. Buy an RS/6000 - you can pick up a decent one for anywhere between 50GBP and 5000 GBP :D
The RS/6000 is just a AIX / random Unix box, whereas the AS/400 is WEIRD.
I like weird.
Sampsa
Also, if google starts doing Evil Stuff with my mail, I just point the
MX records at my mail server and do some small reconfigurtions.
Main benefit: If the line(s) to my server are down, Google's servers
store my mail for me until the next fetchmail run.
Sampsa
OK,
I've gone with Sampsa's suggestions and have subscribed to google to
manage hecnet.eu's mail. Can I now pull that mail down into a local
archive on my VAX/VMS box - what program would I need to use (a
fetchmail equivalent for VMS)? Or can I transfer the mail into a local
IMAP server?
I will probably do the same for the linux box, but I'd prefer to have
access from my VMS box as this is my main external facing box.
Regards, Mark.
Also, if google starts doing Evil Stuff with my mail, I just point the
MX records at my mail server and do some small reconfigurtions.
Main benefit: If the line(s) to my server are down, Google's servers
store my mail for me until the next fetchmail run.
Sampsa
OK,
I've gone with Sampsa's suggestions and have subscribed to google to
manage hecnet.eu's mail. Can I now pull that mail down into a local
archive on my VAX/VMS box - what program would I need to use (a
fetchmail equivalent for VMS)? Or can I transfer the mail into a local
IMAP server?
I will probably do the same for the linux box, but I'd prefer to have
access from my VMS box as this is my main external facing box.
Regards, Mark.
Main benefit: If the line(s) to my server are down, Google's servers store my mail for me until the next fetchmail run.
Sampsa
On 5 Aug 2010, at 21:23, Joe Ferraro wrote:
As much as I can't stand Big Brother -- eh hem -- Google... if you're not talking a hobbyist solution, its just downright difficult to beat their imap / pop3 / web email solution -- especially when blasted SPAM is considered.
If you have trouble with the fact that google aggressively analyzes, stores and sells your data trends -- you might want to look at `exim` for linux.
Joe
On Thu, Aug 5, 2010 at 1:06 PM, Fred <fcoffey at thrifty.misernet.net> wrote:
On Thu, 5 Aug 2010, Mark Wickens wrote:
standard email clients but would also like to be able to ssh into a
local box and read mail via a character terminal.
I do both. I run Linux/Postfix and OpenVMS/PMDF. I can SSH into my Linux box and then check my mail with (al)pine (like I am doing now) and also telnet into my Alpha and read the mail with MAIL or PINE that is included with PMDF.
Fred
would like to use. If Multinet's DECnet-over-IP can be used, why
couldn't DEC's implementation be similarly usable? I know DECnet-
plus well and would like to stick to it as far as possible.
The second choice would be Cisco tunneling which is familiar to me
also.
The bridge software would be the third choice if the others don't
work.
In that case I would build it on Tru64unix. I guess it is doable.
Haven't tried though.
I really would like to have my own area - for a couple of reasons.
First, I do possess over 60 VMS systems which have their own DECnet
addresses and I wouldn't like to change them when I want to use them.
Second, the area routing is set up already and it would be a lot
easier to add an area than to reconfigure the whole routing.
Third, it is easy to add nodes to the area when it is needed if the
area is self managed.
I understand that Johnny is a busy man. Maybe he has time to give
me some advise about the (area) routers to which I should try to
connect (by DECnet-over-IP).
When I'm done with the connection and have it up and running, I'll
be happy to share my experiences with all of you.
Hi, Kari. I thought I had replied to you in the past. Maybe the mail
got lost somewhere.
Anyway, to try to answer your questions:
Your own area: no problem.
DECnet+ over IP: I have no idea if it is doable, but if it is, feel
free. HECnet as such is totally connection-agnostic. Anything that
works is acceptable. My experience (both from myself, and others) is
that DECnet+ is more of an headache than a win, but that's more from
an adminitrative point of view. Technically, it works just fine.
I'm uncertain if DECnet+ can act as an area router though, so you
might need to have atleast one DECnet node, in order to have your
own area.
Bridge on Tru64: I have no idea, but I think it should be possible.
What is required isn't that exotic. You need the normal packet
filter functionality in the system (I believe Tru64 have this), and
you need libpcap. Your hardware also needs to allow you to create
raw ethernet packets with different source address than what the
ethernet controller itself have. Apart from that, it's a simple C
program.
How to go about things: first you decide on how to connect, and find
someone that can be the other end of your connection. If you decide
on a bridge, then you can connect to me. For DECnet over IP in any
form, you'll have to find someone else around here who can do that
(I can't). Cisco requires that you find someone else with a Cisco box.
Once that is done, create the connection. Renumber your machines to
the right area, and away we go.
The other part you might want to do is sync up nodenames with me. I
have a master database for DECnet nodenames here, which people
normally copy, which helps us having a uniform view of the
nodenames. Not requires, but nice.
Johnny
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.830 / Virusdatabase: 271.1.1/2966 - datum van uitgifte: 06/27/10
08:35:00
The second choice would be Cisco tunneling which is familiar to me also.
The bridge software would be the third choice if the others don't work.
In that case I would build it on Tru64unix. I guess it is doable. Haven't tried though.
I really would like to have my own area - for a couple of reasons. First, I do possess over 60 VMS systems which have their own DECnet addresses and I wouldn't like to change them when I want to use them.
Second, the area routing is set up already and it would be a lot easier to add an area than to reconfigure the whole routing.
Third, it is easy to add nodes to the area when it is needed if the area is self managed.
I understand that Johnny is a busy man. Maybe he has time to give me some advise about the (area) routers to which I should try to connect (by DECnet-over-IP).
When I'm done with the connection and have it up and running, I'll be happy to share my experiences with all of you.
Hi, Kari. I thought I had replied to you in the past. Maybe the mail got lost somewhere.
Anyway, to try to answer your questions:
Your own area: no problem.
DECnet+ over IP: I have no idea if it is doable, but if it is, feel free. HECnet as such is totally connection-agnostic. Anything that works is acceptable. My experience (both from myself, and others) is that DECnet+ is more of an headache than a win, but that's more from an adminitrative point of view. Technically, it works just fine.
I'm uncertain if DECnet+ can act as an area router though, so you might need to have atleast one DECnet node, in order to have your own area.
Bridge on Tru64: I have no idea, but I think it should be possible. What is required isn't that exotic. You need the normal packet filter functionality in the system (I believe Tru64 have this), and you need libpcap. Your hardware also needs to allow you to create raw ethernet packets with different source address than what the ethernet controller itself have. Apart from that, it's a simple C program.
How to go about things: first you decide on how to connect, and find someone that can be the other end of your connection. If you decide on a bridge, then you can connect to me. For DECnet over IP in any form, you'll have to find someone else around here who can do that (I can't). Cisco requires that you find someone else with a Cisco box.
Once that is done, create the connection. Renumber your machines to the right area, and away we go.
The other part you might want to do is sync up nodenames with me. I have a master database for DECnet nodenames here, which people normally copy, which helps us having a uniform view of the nodenames. Not requires, but nice.
Johnny
