Circuit TX-1-7, Line synchronization lost
My setup is as follows:
7.92 (experimental machine):
sim> show vh
VH address=20000140-2000017F*, vector=2C8-2E4*, lines=32, 4 units
VH0 attached to 32011,Line=15,Connect=192.168.0.8:32024;notelnet,32024;notelnet, DHV mode, 1 connection
VH1 DHV mode
VH2 DHV mode
VH3 DHV mode
BITXOO:
sim> show vh
VH address=2013E140-2013E14F*, vector=E8-EC*, lines=16
attached to 32023,Line=15,Connect=192.168.0.2:32024;notelnet,32024;notelnet, DHU mode, Modem
Hangup, 2 connections
sim>
BITXOO is running VMS 4.7, and it is a simulated 780. The other machine is running 7.3 and it is a virtual 3900...
Anyone has been succesful setting this thing up?
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
I was able to find DECNET-20 documentation which is unfortunately not what you're looking for. ;(
(BTW the "buffered console" feature in 4.0 is also awesome, specially to run headless simulators. Now if we could do an unattended RSX boot it would be wonderful!).
Yes, an unattended RSX boot WOULD be nice. ;)
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
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
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
.
.
TZ86 = DLT-II (6GB)
TZ87 = DLT-III/DLT2000 (10/20GB) or DLT2000XT (15/30GB)
Quantum bought the rights to the technology way back in 1994 and sold the drives to other people as well as DEC AFAIK, so if anyone sees and old DLT-II or DLT-2000 drive float by at a low price GRAB IT :)
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
last PL/I compiler on Multics. As for where EPL came from, I'm not
sure off the top of my head, although www.multicians.org would
probably hold the answer.
Freiburghouse built his compiler after he left Multics/Honeywell and
was the basis for most other non-IBM PL/I compilers. It was developed
using techniques very different from those used with the Multics
compiler, although the intermediate language did share a lot.
[...snip...]
Frankly, having lived that era, you will never convince me otherwise.
BLISS was cool, but for some marketing mistakes it would have beaten
C no doubt - although the syntax in hindsight was a mistake (and I
heard Wulf admits that - we all had a long chat about it in the late
1980s/early 1990s at Stellar and Bill was as "Jr Programmer" helping
with the code generator for the Stellar box).
I'm definitely in the BLISS camp, it is my favourite language.
Personally, I don't mind the syntax. I appreciate the '.' operator.
The stuff I didn't like was thankfully weeded out with the development
of Common BLISS. My only gripe is the way structures were handled.
I think something could have been done differently there.
Regards, Tim.
The problem is MOP isn't routed so a connection to the router would
have to happen from something local.
Urrrrrr...no, I don't think so. It's done by MAC address.
Hmmmmm.
Hello!
I thought it was by using that old commodity dumb luck? Seriously, it
might definitely be using MAC addresses.
It is; see the command examples I sent earlier in this thread.
Now why are those snowmen throwing things at your place?
Because I had chili for lunch, and they're trying to put out the
resultant fires.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
The problem is MOP isn't routed so a connection to the router would
have to happen from something local.
Urrrrrr...no, I don't think so. It's done by MAC address.
Hmmmmm.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Hello!
I thought it was by using that old commodity dumb luck? Seriously, it
might definitely be using MAC addresses.
Now why are those snowmen throwing things at your place?
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
The problem is MOP isn't routed so a connection to the router would
have to happen from something local.
Urrrrrr...no, I don't think so. It's done by MAC address.
Hmmmmm.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Ian
Sent from my iPad
On 2013-01-07, at 10:02 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 01/08/2013 12:53 AM, Ian McLaughlin wrote:
The problem with ssh is it's "out of band" as far as hecnet is
concerned. It would be nice if the discovery was purely decnet.
True.
Well, if one can define access lists using DECnet addresses as filter
terms, I'd be ok with that, for nonprivileged access.
I've just verified that a MOP console request works from Linux using
locally-stored authentication on the IOS side to establish a
nonprivileged IOS CLI session on a 7206VXR running IOS 12.3(22), like so:
$ moprc -v <MAC address>
...and like this from NCP under VMS:
NCP> connect node gw physical address <MAC address> via <circuit-name>
Note that the MAC address must have its octets delimited by colons
under Linux, and hyphens under VMS.
-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=0AB18D20595911E28…
Would it be a part of the NT distribution set I already have and I'm missing it, or would I need to find it for netware/VMS?
Thanks!
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
Would it be a part of the NT distribution set I already have and I'm missing it, or would I need to find it for netware/VMS?
Thanks!
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
