On 2012-06-09 23:13, Mark Benson wrote:
As per subject:
6.3 ITANIC (OpenVMS 8.4 I64)
6.11 BGATES (Windows XP Pro / Pathworks32)
Done. Thanks.
I notice that there are a bunch of nodes seen from MIM that I don't know about right now... Others... 'fess up. ;-)
Johnny
On 11 Jun 2012, at 12:24, Mark Wickens <mark at wickensonline.co.uk> wrote:
My comments are probably completely useless, but I'll say it anyway.
I've seen this behaviour in a box with multiple network adapters where one (or more) are not connected to a network segment.
Yes, the same happened to me when I installed OpenVMS on my Integrity
box with GBit connected and not the 10/100 MBit. However if it's not
connected on a LAN it does it every 10-30 seconds. It was so annoying
I purged the EIW-0 circuit on mine (probably never use it for DECnet
in the native OS anyway).
If it is indeed the same behaviour then it's possibly a break in the
tunnel link, the timeouts seem to be pretty strict.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On Fri, 08 Jun 2012 21:46:26 +0200, you wrote:
1) Defining the permanent node database for both TOPS10 and TOPS20. NCP
rejects the DEFINE NODE commands. I guess there is some sort of utility
like the one in RSX (CFE) to define the "permanent" node list, but I've
not been able to find that one. There is a NIPGEN in TOPS-10 to build a
CMD file with the SET NODE commands, but no NIPGEN in TOPS-20 that I've
been able to find...
Please, note that I'm really not versed in TOPS-20 configurations so I shall
write about TOPS-10 only. :)
As Peter Lothberg has already pointed out, there is no permanent database in
TOPS-10 DECnet, but just the volatile one that has to be reloaded after every
reboot. If I'm not wrong, NIPGEN was used only when setting up front-end-based
DECnet, i.e. DDCMP links and such, but not Ethernet. The official way to pass
node definitions to NCP should be to feed it with a SET NODE command for every
node to be defined, but that would be noticeably slow, in particular with long
node lists. So NODNAM was born, which uses a faster method to load the DECnet
database reading from INI:NODNAM.INI, and then optionally starts MX.
If your INI: device points to a non-existant [5,34] directory, you may use
CREDIR to create it, like this:
| .R CREDIR
| Create directory: INI:
| Created DSKB1:[5,34].UFD/PROTECTION:775
| Create directory: ^Z
Then, to have NODNAM automatically started by the monitor, just add NODNAM at
the end of SYS:SYSJOB.INI without preceding it with LOG (or LOGIN). That's
because NODNAM does not "stick" but starts, does its thing, then exits.
More details can be found in NODNAM.HLP:
http://pdp-10.trailing-edge.com/tops10_tools_bb-fp64b-sb/01/10,7/decnet/nod…
2) LAT. LAT works fine in TOPS-20. In TOPS-10 LCP tells me LAT is
active, but it does not work (does not even announce itself). How do I
enable LAT in TOPS-10?
Well, I'm using a homemade LAT-enabled monitor and I have the following in my
SYS:SYSTEM.CMD file (among other things):
| LCP SET GROUPS 0
| LCP SET SERVICE-NAME xxxxxx /RATING: DYNAMIC
| LCP SET SERVICE-NAME xxxxxx /IDENT: "Xxxxxx blah blah blah"
| LCP START
Moreover, I had to modify SYS:TTY.INI like this:
| ALL: KSYS CHECK:DEFAULT NORUN TEXT NONOTICE EDITOR
| CTY: GALOPR NOREMOTE ACCOUNT:"SYSTEM"
| APC:LAT NOCHECK TYPE:VT100
| STOMP ACCOUNT:"SYSTEM"
(Notice the NORUN parameter!)
4) A few minutes after startup of TOPS-10. I get the following message
at the console:
CCPOEF Output error on DSKB:SER001.EXE[10,1], status=40017
It does not seem to have any advert effect, but I'd like to know what's
wrong. I've not seen such a message in my KS-based TOPS-10 running under
SIMH.
That message is from the crash dump copy program (CRSCPY, message prefix CCP).
Whenever the monitor crashes and is reloaded or encounters a continuable error
for which a memory dump is taken, it then calls CRSCPY to copy the dump from
SYS:CRASH.EXE to XPN:xxxxxx.EXE (XPN: is [10,1]). The first three characters
of the copied dump file are the stopcode for which the dump was taken or SER
if the stopcode is not available or is a six-character stopcode.
Status 40017 might be "Block too large" (I'm not sure at all): a quick lookup
in alt.sys.pdp10 suggests that CRSCPY may complain with that message when some
filesystem parameters are not sized as expected.
Anyway you'd still have to discover why your monitor has crashed... You can
see a log of your dumps by running CRSCPY interactively and giving it the
REPORT command at the CRSCPY> prompt.
HTH,
G.
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark Wickens
Sent: Monday, June 11, 2012 07:24
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] netowrk flapping....
On 10/06/12 21:53, Marc Chametzky wrote:
I have increased the timeout values on the router that is
attached
to SG1::. Hopefully this improves matters.
I may have missed something, but I saw that you increased the TCP
timeouts. By default, DECnet-over-IP uses UDP packets, so that'd be
the timeout you'd want to increase.
The uplink port is a gigabit port connected to my FiOS ONT
(connected at
100 Mbps).
What does it speak to the fios NT (I knew nothing about
what strange
things local phone compnies manage to do..) Is it just DHCP or
exoting things like pppoe?
The ONT simply presents itself as a regular, routed
100Base-TX network
interface. There's no special protocol used between the
SonicWALL and
the ONT. The SonicWALL specifies 71.182.147.1 as its default route,
which is either the ONT itself or something upstream from
it. I don't
know where the fiber's IP router actually lives.
I have five static IP addresses that I manually configure,
so I'm not
using DHCP on my WAN segment.
Now, getting back to the UDP versus TCP, MultiNet does
support setting
up DECnet circuits using TCP. It's not available via MULTINET
CONFIGURE/DECNET from what I could see, but it is listed in
the online
help for MULTINET SET/DECNET as /TCP=[CONNECT|LISTEN]. TCP
connections
may prove to be more reliable under some circumstances.
--Marc
My comments are probably completely useless, but I'll say it anyway.
I've seen this behaviour in a box with multiple network
adapters where one (or more) are not connected to a network segment.
Mark.
--
http://www.wickensonline.co.ukhttp://declegacy.org.uk
SG1:: only has 1 adapter. It is a VAXstation 4000-30 (VLC). It is
connected directly to the Netgear FVS318.
-Steve
On 10/06/12 21:53, Marc Chametzky wrote:
I have increased the timeout values on the router that is attached to
SG1::. Hopefully this improves matters.
I may have missed something, but I saw that you increased the TCP timeouts. By default, DECnet-over-IP uses UDP packets, so that'd be the timeout you'd want to increase.
> The uplink port is a gigabit port connected to my FiOS ONT (connected at
> 100 Mbps).
What does it speak to the fios NT (I knew nothing about what strange
things local phone compnies manage to do..) Is it just DHCP or exoting
things like pppoe?
The ONT simply presents itself as a regular, routed 100Base-TX network interface. There's no special protocol used between the SonicWALL and the ONT. The SonicWALL specifies 71.182.147.1 as its default route, which is either the ONT itself or something upstream from it. I don't know where the fiber's IP router actually lives.
I have five static IP addresses that I manually configure, so I'm not using DHCP on my WAN segment.
Now, getting back to the UDP versus TCP, MultiNet does support setting up DECnet circuits using TCP. It's not available via MULTINET CONFIGURE/DECNET from what I could see, but it is listed in the online help for MULTINET SET/DECNET as /TCP=[CONNECT|LISTEN]. TCP connections may prove to be more reliable under some circumstances.
--Marc
My comments are probably completely useless, but I'll say it anyway.
I've seen this behaviour in a box with multiple network adapters where one (or more) are not connected to a network segment.
Mark.
--
http://www.wickensonline.co.ukhttp://declegacy.org.uk
I have increased the timeout values on the router that is attached to
SG1::. Hopefully this improves matters.
I may have missed something, but I saw that you increased the TCP timeouts. By default, DECnet-over-IP uses UDP packets, so that'd be the timeout you'd want to increase.
> The uplink port is a gigabit port connected to my FiOS ONT (connected at
> 100 Mbps).
What does it speak to the fios NT (I knew nothing about what strange
things local phone compnies manage to do..) Is it just DHCP or exoting
things like pppoe?
The ONT simply presents itself as a regular, routed 100Base-TX network interface. There's no special protocol used between the SonicWALL and the ONT. The SonicWALL specifies 71.182.147.1 as its default route, which is either the ONT itself or something upstream from it. I don't know where the fiber's IP router actually lives.
I have five static IP addresses that I manually configure, so I'm not using DHCP on my WAN segment.
Now, getting back to the UDP versus TCP, MultiNet does support setting up DECnet circuits using TCP. It's not available via MULTINET CONFIGURE/DECNET from what I could see, but it is listed in the online help for MULTINET SET/DECNET as /TCP=[CONNECT|LISTEN]. TCP connections may prove to be more reliable under some circumstances.
--Marc
I'm still seeing issues with STUPI:: though...
The other Multinet Tunnel connections seem to be quiet (for now...).
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Bob Armstrong
Sent: Sunday, June 10, 2012 12:08
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] netowrk flapping....
... considering creating a static route to your end and to Sampsa's
end because those constitute the US backbone into Europe.
I'm not quite sure what you have in mind - in the FVS338 I
already have an inbound rule that forwards all inbound UDP
packets addressed to 64.142.52.93:700 (that's the WAN address
of decnet.jfcl.com) to 10.1.1.13:700 (that's the IP of LEGATO
on my internal network). I think that's as much of a static
route as is possible in this case.
So far, SG1 hasn't "flapped" since 7:28AM PDT.
Bob
The timeout is currently set to 2 billion seconds. This "should" not be
a problem for most people. :-)
I may reduce it to a week if this timeout causes me any grief.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Peter Lothberg
Sent: Sunday, June 10, 2012 17:02
To: hecnet at Update.UU.SE
Cc: hecnet at Update.UU.SE
Subject: RE: [HECnet] netowrk flapping....
I have increased the timeout values on the router that is
attached to
SG1::. Hopefully this improves matters.
Can you make the timer multiple days or weeks?
(Anyone trying to use HECnet traveling over that link will be very
frustrated....)
-P
I have increased the timeout values on the router that is attached to
SG1::. Hopefully this improves matters.
Can you make the timer multiple days or weeks?
(Anyone trying to use HECnet traveling over that link will be very
frustrated....)
-P
