On Feb 22, 2013, at 12:45 PM, Cory Smelosky <b4 at gewt.net> wrote:
--
Cory Smelosky
Sent from a mobile device
On 22 Feb 2013, at 13:37, Julian Wolfe <julian at twinax.org> wrote:
HI all,
Registered on HECnet many years ago, but was never able to get on for long or at all in the past. Now it seems this problem plagues me yet again in a different form.
I've got a PDP-11/23+ running RSTS/E 10.1 and DECnet/E 4.1 behind a DD-WRT router in my basement (WRT54GS, DD-WRT build 13064), and this is behind an AT&T U-Verse router. Something is going on with the packet source ports - they are being marked with a randomized source port.
My questions are: Does the source port matter, when using Johnny's bridge, and he knows my port?
If the port does matter, has anyone experienced this issue (specifically on AT&T U-Verse or otherwise) and solved it?
Is this something I can fix myself, or do I need to look for another solution?
The wierd part is, I used the bridge successfully for 2 days with the bridge installed on a Mac running Mac OS X 10.8. This machine was also talking through a different WRT54GS with DD-WRT build 13064 and identical settings to the other router (client bridged mode). I then moved the PDP to the basement with the rest of my servers, had it go through the linux box for the bridge, and suddenly the packets have this mangles source port. I tried switching it back to the Mac, and now this problem has cropped up there too.
Phew! Help! I just want to hang out with yous guys :)
I can't speak for Johnny's bridge, but you can use a virtual Cisco to join up if all else fails...assuming you can forward GRE.
Julian
On Feb 22, 2013, at 12:45 PM, Cory Smelosky <b4 at gewt.net> wrote:
--
Cory Smelosky
Sent from a mobile device
On 22 Feb 2013, at 13:37, Julian Wolfe <julian at twinax.org> wrote:
HI all,
Registered on HECnet many years ago, but was never able to get on for long or at all in the past. Now it seems this problem plagues me yet again in a different form.
I've got a PDP-11/23+ running RSTS/E 10.1 and DECnet/E 4.1 behind a DD-WRT router in my basement (WRT54GS, DD-WRT build 13064), and this is behind an AT&T U-Verse router. Something is going on with the packet source ports - they are being marked with a randomized source port.
My questions are: Does the source port matter, when using Johnny's bridge, and he knows my port?
If the port does matter, has anyone experienced this issue (specifically on AT&T U-Verse or otherwise) and solved it?
Is this something I can fix myself, or do I need to look for another solution?
The wierd part is, I used the bridge successfully for 2 days with the bridge installed on a Mac running Mac OS X 10.8. This machine was also talking through a different WRT54GS with DD-WRT build 13064 and identical settings to the other router (client bridged mode). I then moved the PDP to the basement with the rest of my servers, had it go through the linux box for the bridge, and suddenly the packets have this mangles source port. I tried switching it back to the Mac, and now this problem has cropped up there too.
Phew! Help! I just want to hang out with yous guys :)
I can't speak for Johnny's bridge, but you can use a virtual Cisco to join up if all else fails...assuming you can forward GRE.
Julian
On Feb 22, 2013, at 12:45 PM, Cory Smelosky <b4 at gewt.net> wrote:
--
Cory Smelosky
Sent from a mobile device
On 22 Feb 2013, at 13:37, Julian Wolfe <julian at twinax.org> wrote:
HI all,
Registered on HECnet many years ago, but was never able to get on for long or at all in the past. Now it seems this problem plagues me yet again in a different form.
I've got a PDP-11/23+ running RSTS/E 10.1 and DECnet/E 4.1 behind a DD-WRT router in my basement (WRT54GS, DD-WRT build 13064), and this is behind an AT&T U-Verse router. Something is going on with the packet source ports - they are being marked with a randomized source port.
My questions are: Does the source port matter, when using Johnny's bridge, and he knows my port?
If the port does matter, has anyone experienced this issue (specifically on AT&T U-Verse or otherwise) and solved it?
Is this something I can fix myself, or do I need to look for another solution?
The wierd part is, I used the bridge successfully for 2 days with the bridge installed on a Mac running Mac OS X 10.8. This machine was also talking through a different WRT54GS with DD-WRT build 13064 and identical settings to the other router (client bridged mode). I then moved the PDP to the basement with the rest of my servers, had it go through the linux box for the bridge, and suddenly the packets have this mangles source port. I tried switching it back to the Mac, and now this problem has cropped up there too.
Phew! Help! I just want to hang out with yous guys :)
I can't speak for Johnny's bridge, but you can use a virtual Cisco to join up if all else fails...assuming you can forward GRE.
Julian
On Feb 22, 2013, at 12:45 PM, Cory Smelosky <b4 at gewt.net> wrote:
--
Cory Smelosky
Sent from a mobile device
On 22 Feb 2013, at 13:37, Julian Wolfe <julian at twinax.org> wrote:
HI all,
Registered on HECnet many years ago, but was never able to get on for long or at all in the past. Now it seems this problem plagues me yet again in a different form.
I've got a PDP-11/23+ running RSTS/E 10.1 and DECnet/E 4.1 behind a DD-WRT router in my basement (WRT54GS, DD-WRT build 13064), and this is behind an AT&T U-Verse router. Something is going on with the packet source ports - they are being marked with a randomized source port.
My questions are: Does the source port matter, when using Johnny's bridge, and he knows my port?
If the port does matter, has anyone experienced this issue (specifically on AT&T U-Verse or otherwise) and solved it?
Is this something I can fix myself, or do I need to look for another solution?
The wierd part is, I used the bridge successfully for 2 days with the bridge installed on a Mac running Mac OS X 10.8. This machine was also talking through a different WRT54GS with DD-WRT build 13064 and identical settings to the other router (client bridged mode). I then moved the PDP to the basement with the rest of my servers, had it go through the linux box for the bridge, and suddenly the packets have this mangles source port. I tried switching it back to the Mac, and now this problem has cropped up there too.
Phew! Help! I just want to hang out with yous guys :)
I can't speak for Johnny's bridge, but you can use a virtual Cisco to join up if all else fails...assuming you can forward GRE.
Julian
On Feb 22, 2013, at 12:45 PM, Cory Smelosky <b4 at gewt.net> wrote:
--
Cory Smelosky
Sent from a mobile device
On 22 Feb 2013, at 13:37, Julian Wolfe <julian at twinax.org> wrote:
HI all,
Registered on HECnet many years ago, but was never able to get on for long or at all in the past. Now it seems this problem plagues me yet again in a different form.
I've got a PDP-11/23+ running RSTS/E 10.1 and DECnet/E 4.1 behind a DD-WRT router in my basement (WRT54GS, DD-WRT build 13064), and this is behind an AT&T U-Verse router. Something is going on with the packet source ports - they are being marked with a randomized source port.
My questions are: Does the source port matter, when using Johnny's bridge, and he knows my port?
If the port does matter, has anyone experienced this issue (specifically on AT&T U-Verse or otherwise) and solved it?
Is this something I can fix myself, or do I need to look for another solution?
The wierd part is, I used the bridge successfully for 2 days with the bridge installed on a Mac running Mac OS X 10.8. This machine was also talking through a different WRT54GS with DD-WRT build 13064 and identical settings to the other router (client bridged mode). I then moved the PDP to the basement with the rest of my servers, had it go through the linux box for the bridge, and suddenly the packets have this mangles source port. I tried switching it back to the Mac, and now this problem has cropped up there too.
Phew! Help! I just want to hang out with yous guys :)
I can't speak for Johnny's bridge, but you can use a virtual Cisco to join up if all else fails...assuming you can forward GRE.
Julian
On Feb 22, 2013, at 12:45 PM, Cory Smelosky <b4 at gewt.net> wrote:
--
Cory Smelosky
Sent from a mobile device
On 22 Feb 2013, at 13:37, Julian Wolfe <julian at twinax.org> wrote:
HI all,
Registered on HECnet many years ago, but was never able to get on for long or at all in the past. Now it seems this problem plagues me yet again in a different form.
I've got a PDP-11/23+ running RSTS/E 10.1 and DECnet/E 4.1 behind a DD-WRT router in my basement (WRT54GS, DD-WRT build 13064), and this is behind an AT&T U-Verse router. Something is going on with the packet source ports - they are being marked with a randomized source port.
My questions are: Does the source port matter, when using Johnny's bridge, and he knows my port?
If the port does matter, has anyone experienced this issue (specifically on AT&T U-Verse or otherwise) and solved it?
Is this something I can fix myself, or do I need to look for another solution?
The wierd part is, I used the bridge successfully for 2 days with the bridge installed on a Mac running Mac OS X 10.8. This machine was also talking through a different WRT54GS with DD-WRT build 13064 and identical settings to the other router (client bridged mode). I then moved the PDP to the basement with the rest of my servers, had it go through the linux box for the bridge, and suddenly the packets have this mangles source port. I tried switching it back to the Mac, and now this problem has cropped up there too.
Phew! Help! I just want to hang out with yous guys :)
I can't speak for Johnny's bridge, but you can use a virtual Cisco to join up if all else fails...assuming you can forward GRE.
Julian
Open <conference_name>
The open only requires the name to be unique so if you are lazy about
typing, and who isn't, type the minimum at the open statement to be
unique. As I said earlier try the NOTES$SAMPLE conference first for the
overview and then the help from within NOTES.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Jordi
Guillaumes i Pons
Sent: Sunday, February 24, 2013 12:25
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] NOTES system?
El 24/02/2013, a les 18:22, Steve Davidson <jeep at scshome.net>
va escriure:
Providing you have the correct platform, I would try a new kit. I
will place the VAX kit on GORVAX:: in the [FAL$SERVER]
directory and
the Alpha kit on RHESUS:: in the [FAL$SERVER] directory.
I tried two kits, and I have actually got it installed in
another machine. I think the problem is the machine where it
failed has both UCX and MULTINET installed (although UCX is
not started). I'm cleaning it up and I'll try it again.
OTOH, how does one "join" a remote NOTES conference? Or is it
necessary to actually log on the hosting system?
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
make it language sensitive. This is what I am after.
TPU -- Text Processing Utility. It's an entire language for handling any
sort of text processing needs.
<http://h71000.www7.hp.com/doc/73final/documentation/pdf/OVMS_73_DEC_TPU_REF…>
The editor is EVE (Extensible Versatile Editor) written with TPU. The LSE
would look EVE-ish. ;)
<http://h71000.www7.hp.com/doc/73final/documentation/pdf/OVMS_73_EVE.PDF>
TPU procedures can be invoked from other compiled languages available and
supported on VMS!
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
You need a kit for AXP or VAX?
(To Sampsa)
Alpha.
Thanks,
Fred
----
Lets call it for what it is - "legacy" is a term that people use in a
polite but derogatory manner to imply that the future direction they
prefer is not that which they view as the current direction.
manager. It offers two options cde and xdm.
cde gives me the correct logon panel and then xterm.
xdm gives the "classic" DECwindows login screen (like VAX/VMS does) and also
xterm.
I'm studying the manuals now. If you like I can get you access to the
system.
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Kari Uusim ki
Verzonden: vrijdag, februari 2013 7:15
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Tru64 question
Quite right, Hans. Finland is at UTC+2.
On 15.2.2013 0:15, hvlems at zonnet.nl wrote:
Same for me Kari, on both topics!
You're one hour ahead, right?
We're at UTC+1.
Hans
------Origineel bericht------
Van: Kari Uusim ki
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Tru64 question
Verzonden: 14 februari 2013 23:03
Well, have to test myself. It's so long a time since I've been working
with Tru64 that I've forgotten many details. It's late now so I have to
test tomorrow.
Kari
On 14.2.2013 23:58, H Vlems wrote:
The session options give me Failsafe and another one (name forgotten),
but that last one was selected.
I end up in a single xterm window whether logged on as root or as hans,
makes no difference.
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Kari Uusim ki
Verzonden: donderdag, februari 2013 22:54
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Tru64 question
There is probably the last used desktop selection "xterm".
Try to select from the session options the CDE desktop before you log in.
Kari
On 14.2.2013 19:27, H Vlems wrote:
Logging in on the console of a Tru64 V5.0 machine
I ended up in an xterm terminal and nothing else.
The usual "new DECwindows" desktop was gone.
Any ideas where to look for a fix?
The system is an AlphaServer 800 that had been power
off for a year now.
Hans
.
.
