"Bob Armstrong" <bob at jfcl.com> writes:
I've been trying for a day now to build the emacs21_2 that's on the
FREEWARE v8 CD. It's a joke - I don't think it ever worked on VMS. The MMS
files don't work with MMS anymore - you must use MMK. There's some elisp
file called p4 missing - don't know what that's for. The termcap doesn't
contain ANY vtxxx terminals (talk about a major bummer!). The image is
linked with /TRACEBACK and therefore can't be installed privileged (which is
exactly what their setup script does).
I persevered and fixed all those, but now emacs crashes with an ACCVIO
whenever I try to read a file. That's gonna limit its usefulness as a text
editor J
I really don't want to debug this thing. Please!
Thanks,
Bob
FYI, 19.28 (IIRC) was the last Emacs that would build on OpenVMS. I was
tasked, at one time, to try porting 21.something but I gave up because of
the stupid CONFIGURE brain damage.
Newer efforts of the GNV group might offer an environment that's better
suited for building later emacs. However, if the open source community
would cease with the "all-the-world's-a-unix" mentality, things such as
emacs might stand a chance on VMS.
Personally, I'm happy with vi on unix and EDT on VMS. Emacs is just way
too heavyweigh with unnecessary features.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Nobody has emacs running on an Alpha on HECnet??
I ve been trying for a day now to build the emacs21_2 that s on the FREEWARE v8 CD. It s a joke I don t think it ever worked on VMS. The MMS files don t work with MMS anymore you must use MMK. There s some elisp file called p4 missing don t know what that s for. The termcap doesn t contain ANY vtxxx terminals (talk about a major bummer!). The image is linked with /TRACEBACK and therefore can t be installed privileged (which is exactly what their setup script does).
I persevered and fixed all those, but now emacs crashes with an ACCVIO whenever I try to read a file. That s gonna limit its usefulness as a text editor J
I really don t want to debug this thing. Please!
Thanks,
Bob
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Bob Armstrong Sent: Thursday, May 29, 2014 8:20 PM To: hecnet at Update.UU.SE Subject: [HECnet] OVMS AXP emacs?
Does anybody have a ready to run copy of emacs for the Alpha and OVMS 8.3 that I could copy? Building it can be a struggle that I d rather skip right now.
FWIW, I need the plain old fashioned terminal, NOT DECwindows, version.
Thanks,
Bob
With help from Bob Armstrong and Peter Lothberg, I have a reverse engineered Python implementation of the Multinet tunnel over TCP working now.
Peter forwarded an old HECnet message that roughly describes the protocol, but some details were missing and some were not quite accurate. For the benefit of anyone else who wants to implement this, here is the protocol description plus some implementation notes.
paul
Multinet protocol for DECnet
A Multinet tunnel runs the Point to Point mode of the DECnet protocol. Traffic may be carried over a TCP connection, or over UDP packets. The operation is nearly the same for both.
In TCP mode, one end is designated the connecting end and the other the listening end. In UDP mode, operation is symmetric since there are no connections. In either case, the port number may be configured; the default is 700.
Multinet puts a 4 byte header on each DECnet packet. For TCP, the first two bytes are the DECnet packet length, little endian. The TCP data stream consists of these packets with headers.
For UDP, the first two byte are a sequence number, little endian. The next two bytes appear to be unused and were observed to contain zero. Each DECnet packet, with its header, is sent as a separate UDP packet. Some Multinet implementations can be configured to check the sequence number in UDP mode; it is not clear how this works (in particular, how it is initialized). Linux does not, and things seem to work fine without this extra check.
Multinet tunneling does not obey many of the requirements that the DECnet Routing architecture imposes on point to point datalinks. The most obvious issue is that routing layer point to point init messages (control packet, type code 0) may appear unexpectedly. This happens even in TCP mode where it might be expected that the TCP connection would be closed and re-established before the init message.
A conforming DECnet implementation reacts to such an unexpected init message by restarting the circuit, sending an init message, and expecting one in return. Multinet does not expect this, and if the peer operates according to the standard, initialization may require many cycles before it finally succeeds. As a workaround, the response to an unexpected init should be to set the routing initialization sublayer state machine to the DS state (without restarting the TCP connection, if any), and processing the unexpected init message as if it had been received in that state.
In testing with a DECnet/VMS system, it was observed to send an Init message requesting verification even though verification was not called for in the circuit parameters. It may be that this was due to the routing architecture requirement to use verification in areas other than area 1. A null verification message (empty FCNVAL field) was accepted by the VMS system in that test.
On Fri, 30 May 2014, Brian Hechinger wrote:
On Sat, May 24, 2014 at 12:28:59PM -0400, Cory Smelosky wrote:
Oh, and that Cory guy. His tunnel is still broken. *shakes fist at Cory*
Hey! I've been busy! And quite frankly I have no idea what the hell is wrong.
Can you get me ssh access to your router so I can poke around and maybe
see what's going on?
Which one? The Cisco or the edge BSD box?
The Cisco is old enough to only be telnet...;)
-brian
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Fri, May 30, 2014 at 05:12:38PM +0200, Johnny Billquist wrote:
On 2014-05-30 17:10, Brian Hechinger wrote:
On Sun, May 25, 2014 at 09:49:26AM -0400, Cory Smelosky wrote:
On Sun, 25 May 2014, Brian Hechinger wrote:
Well, it won't boot on an 11/23 or 11/23+. It also won't initially
offer to do AUTOCONFIGURE. It seems an inbetween baseline executive
was made before distribution.
So as long as I look to emulate a /70 I should be fine?
Yes.
Ok, cool.
The 11/70 normally came in a configuration that requires 3-phase.
However, the actual machine do not need it, it's just a load
balancing thing...
Ah, mine didn't. It was pure 110v.
Maybe it's a cabinet thing?
-brian
On 2014-05-30 17:10, Brian Hechinger wrote:
On Sun, May 25, 2014 at 09:49:26AM -0400, Cory Smelosky wrote:
On Sun, 25 May 2014, Brian Hechinger wrote:
Well, it won't boot on an 11/23 or 11/23+. It also won't initially
offer to do AUTOCONFIGURE. It seems an inbetween baseline executive
was made before distribution.
So as long as I look to emulate a /70 I should be fine?
Yes.
Now that I have space, I should. :)
Enough for an 11/70? ;)
Yes actually. :)
Cool! You've got three-phase service right? :D
What do I need three-phase for?
And no, no I don't.
The 11/70 normally came in a configuration that requires 3-phase. However, the actual machine do not need it, it's just a load balancing thing...
Johnny
On Sat, May 24, 2014 at 12:28:59PM -0400, Cory Smelosky wrote:
Oh, and that Cory guy. His tunnel is still broken. *shakes fist at Cory*
Hey! I've been busy! And quite frankly I have no idea what the hell is wrong.
Can you get me ssh access to your router so I can poke around and maybe
see what's going on?
-brian
On Sun, May 25, 2014 at 09:49:26AM -0400, Cory Smelosky wrote:
On Sun, 25 May 2014, Brian Hechinger wrote:
Understandable. It's a lot simpler than IDLE.
IDLE could be interesting though. I might still give it a go anyway. :)
Well, it won't boot on an 11/23 or 11/23+. It also won't initially
offer to do AUTOCONFIGURE. It seems an inbetween baseline executive
was made before distribution.
So as long as I look to emulate a /70 I should be fine?
Now that I have space, I should. :)
Enough for an 11/70? ;)
Yes actually. :)
Cool! You've got three-phase service right? :D
What do I need three-phase for?
And no, no I don't.
-brian
On 2014-05-30 15:18, Bob Armstrong wrote:
The ethernet bridge would, in my eyes be preferred to two or three reliable
PTP links.
In your eyes the bridge program between two nodes, communicating via
psilo, would be preferred to one reliable PtP link between the same two
nodes?
No. Direct links are almost always preferrable. But you scenario would be equally well solved using 3,4,5 as costs. Using 10,20,30 makes several hops over ptp links be preferred over the (one or) two hops on the bridge.
I'd say that the one or two hops on the bridge is better than two ptp links, and might be as good as one hop on a ptp link as well.
Johnny
The ethernet bridge would, in my eyes be preferred to two or three reliable
PTP links.
In your eyes the bridge program between two nodes, communicating via
psilo, would be preferred to one reliable PtP link between the same two
nodes?
Bob
