On Fri, 30 May 2014, Bob Armstrong wrote:
vi is, well, evil. The only command I know is :quit! (gotta have the
bang!) for the few times I accidentally get into it :-)
You mean eVIl. Personally...I often stick with pico/nano as a true heretic.
Emacs is just way too heavyweigh with unnecessary features.
You mean "gnu emacs..." and with that I absolutely agree, but I don't know
any other emacs alternative that's been ported to VMS.
Bob
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
There's always TECO.
How do you think I've been fixing the emacs problems??? :-)
It's a bit tedious, though, and I find that I've forgotten a lot of TECO
commands. I used to be really good at it, but that was around 1978...
Bob
El 30/05/2014, a les 21.16, <Paul_Koning at Dell.com> <Paul_Koning at Dell.com> va escriure:
On May 30, 2014, at 3:08 PM, Bob Armstrong <bob at jfcl.com> wrote:
...
EDT (and EVE) are really only useful to me if I have a real VTxxx
keyboard. My right hand knows all the keypad sequences, and can't be
reprogrammed for any PC key layout.
vi is, well, evil. The only command I know is :quit! (gotta have the
bang!) for the few times I accidentally get into it :-)
There s always TECO.
Or SUMSLP. Batch editing rules!
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
On May 30, 2014, at 3:08 PM, Bob Armstrong <bob at jfcl.com> wrote:
...
EDT (and EVE) are really only useful to me if I have a real VTxxx
keyboard. My right hand knows all the keypad sequences, and can't be
reprogrammed for any PC key layout.
vi is, well, evil. The only command I know is :quit! (gotta have the
bang!) for the few times I accidentally get into it :-)
There s always TECO.
paul
Doesn't MicroEMACS run under VMS?
Dunno - I have never used that version. I use JOVE on a PDP-11 (under
2.11bsd), but that's never been ported to VMS AFAIK.
I have emacs 18.51 running just fine on VAX VMS; I didn't think Alpha
would be that hard! Hmm - maybe I should try to find the sources for that
version.
Thanks,
Bob
On 05/30/2014 03:08 PM, Bob Armstrong wrote:
Emacs is just way too heavyweigh with unnecessary features.
You mean "gnu emacs..." and with that I absolutely agree, but I don't know
any other emacs alternative that's been ported to VMS.
Doesn't MicroEMACS run under VMS?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
the stupid CONFIGURE brain damage.
I saw that - a 500 block DCL script is kinda scary, but at least it
doesn't crash.
Personally, I'm happy with vi on unix and EDT on VMS.
EDT (and EVE) are really only useful to me if I have a real VTxxx
keyboard. My right hand knows all the keypad sequences, and can't be
reprogrammed for any PC key layout.
vi is, well, evil. The only command I know is :quit! (gotta have the
bang!) for the few times I accidentally get into it :-)
Emacs is just way too heavyweigh with unnecessary features.
You mean "gnu emacs..." and with that I absolutely agree, but I don't know
any other emacs alternative that's been ported to VMS.
Bob
"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.
