Oleg,
an endnode is fairly ignorant about the area it lives in.
The output of $ SHOW NET /OLD (or just plain $ SHOW NET on older systems)
is a lot more interesting on a level 1 router than on an endnode.
So since the actual overhead is minimal (given available bandwidth today)
why not mc ncp def exec type routing IV in stead?
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Oleg Safiullin
Verzonden: donderdag, januari 2012 17:35
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Router for area 1
This happens because when there are multiple routing nodes for the same
area, DECnet uses the one with the highest address. The obvious solution
would be for Johnny to renumber MIM as, say, 1.1023.
Hmm.
CTAKAH is set to lower router priority than MIM. I thought this is enough to
tell that MIM is preffered router...
There's no need for CTAKAH to be and area router, so I'll downgrade it to
endnode...
On 05/01/12 22:35, Paul_Koning at Dell.com wrote:
DAP support remote queuing, so this should be a standard capability in VMS (and other systems that have the necessary DAP support).
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark Wickens
Sent: Thursday, January 05, 2012 5:33 PM
To: hecnet at Update.UU.SE
Subject: [HECnet] Printing across HECnet
Hi guys,
Just wondering whether there is a 'standard' mechanism for queueing print jobs across DECnet areas (for example from an arbitrary node to SLAVE via HECnet)?
I've acquired a PSI PP404 high speed wide carriage printer as well as a large quantity of 11x14 paper, so was wondering if there would be any interest in an 'occasional' printing service for the cost of postage for those who either don't have a printer connected to their DEC machines or more likely who'd like wide continuous listings.
From a VMS perspective I'd need to be able to queue up print jobs for batch printing by automating turning on the printer once a day, clearing the print queue, and then turning the printer off. I've got the facility to programmatically turn the power on and off. The printer would be connected to a DECserver 90M.
Any ideas?
Regards, Mark
DAP - Data Access Protocol
OK, so I should have googled first! Thanks for the pointers.
Thanks, Mark.
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens Bob
Armstrong
Verzonden: donderdag, januari 2012 17:21
Aan: hecnet at Update.UU.SE
Onderwerp: [HECnet] Router for area 1
I wrote-
OpenVMS Network status for local node 2.1 LEGATO on 5-JAN-2012
08:11:19.43
Area Cost Hops Next Hop to Area
1 4 1 QNA-1 -> 1.300 CTAKAH
....
It bugs me, although I can't point at an actual problem that it causes,
that the routing node for area 1 is seen as CTAKAH, rather than MIM. Since
CTAKAH is not actually local to Uppsula (I think that's where MIM is) but is
rather at the other end of yet another bridge, this means that any traffic
for area one, no matter what its ultimate destination, has to make an extra
round trip to Russia.
This happens because when there are multiple routing nodes for the same
area, DECnet uses the one with the highest address. The obvious solution
would be for Johnny to renumber MIM as, say, 1.1023.
Bob
-------------------------------------------------------------------------
Or make CTAKAH a circuit router since that is all it really does.
The "loops" in the Hecnet topology ought to be avoided but running area
routers where a circuit router would suffice is second on my list of
things I'd prefer to avoid.
Hans
On 05/01/12 22:35, Paul_Koning at Dell.com wrote:
DAP support remote queuing, so this should be a standard capability in VMS (and other systems that have the necessary DAP support).
Paul,
Sorry for the ignorance, but what is DAP?
Regards, Mark.
DAP support remote queuing, so this should be a standard capability in VMS (and other systems that have the necessary DAP support).
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark Wickens
Sent: Thursday, January 05, 2012 5:33 PM
To: hecnet at Update.UU.SE
Subject: [HECnet] Printing across HECnet
Hi guys,
Just wondering whether there is a 'standard' mechanism for queueing print jobs across DECnet areas (for example from an arbitrary node to SLAVE via HECnet)?
I've acquired a PSI PP404 high speed wide carriage printer as well as a large quantity of 11x14 paper, so was wondering if there would be any interest in an 'occasional' printing service for the cost of postage for those who either don't have a printer connected to their DEC machines or more likely who'd like wide continuous listings.
Hi guys,
Just wondering whether there is a 'standard' mechanism for queueing print jobs across DECnet areas (for example from an arbitrary node to SLAVE via HECnet)?
I've acquired a PSI PP404 high speed wide carriage printer as well as a large quantity of 11x14 paper, so was wondering if there would be any interest in an 'occasional' printing service for the cost of postage for those who either don't have a printer connected to their DEC machines or more likely who'd like wide continuous listings.
On 05/01/12 16:21, Mark Benson wrote:
What is the INFO.TXT you guys are talking about? Should I have one on STAR69 with my node list in?
Mark,
The HECNET INFO.TXT files is located in the default directory for the FAL$SERVER account, which is referenced from other nodes using <NODENAME>::INFO.TXT - for example SLAVE::INFO.TXT
[MSW]SLAVE$ type slave::info.txt
Marks Office, Windermere, UK
(a working set of computers - definitely not a 'collection' ;)
BUBBLE and SLAVE serve the HECnet.eu website via WASD
BUBBLE has a captive account, NETHACK, password NETHACK for playing, you guessed it, nethack.
http://www.hecnet.eu
- HECnet.eu website
http://www.wickensonline.co.uk
- My personal website
http://blog.wickensonline.co.uk
- My BLOG
.BEGIN-HECNET-INFO
ADDR |NAME |OWNER |EMAIL |HARDWARE |OS |LOCATION |NOTES
4.249|SLAVE |Mark Wickens|mark_at_hecnet.eu|AlphaServer 1000A |OpenVMS 8.3 |Windermere,UK|WASD
4.250|ORAC | | |VAXstation 4000/90 |OpenVMS 7.3 | |ALLIN1
4.251|ZX6000| | |HP IA64 ZX6000 |OpenVMS 8.3.1-H1| |16GB RAM
4.252|NODE3 | | |DEC 3000/600 AXP |OpenVMS 8.3 | |
4.253|NODE2 | | |Compaq DS10L |OpenVMS 8.3 | |
4.254|ZEN | | |VAXstation 4000/60 |OpenVMS 7.3 | |Clustered
4.255|X60 | | |IBM X60 Thinkpad |Ubuntu,WinXP | |
4.256|BUBBLE| | |VAXstation 4000/90 |OpenVMS 7.3 | |Nethack,WASD
4.257|ELLEN | | |DEC 3000/600 AXP |DUnix 4.0G | |
4.258|TIGER | | |Alpha 300 4/266 |DUnix 5.1 | |
4.259|ALEPH | | |VAXstation 4000/VLC|OpenVMS 7.3 | |Clustered
.END-HECNET-INFO
Arbitrary text before the text: .BEGIN-HECNET-INFO
The the format as specified followed by: .END-HECNET-INFO
I've been meaning to do something with these for ages and add some more info to hecnet.eu, but I held off because I wasn't sure whether people wanted this level of information available across the internet.
Regards, Mark.
And now I'm seeing quite a bit more traffic on my router!
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of Bob Armstrong
Sent: Thu 1/5/2012 11:14
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Multinet circuit costs
where DECnet *might* get confused.
Well, this is easy enough to test experimentally. I've disabled the
redundant Multinet links on LEGATO, so in theory there should be no
redundancy now at least as far as LEGATO goes.
This means not only disabling the direct links from LEGATO to other bridge
nodes (e.g. GORVAX, SG1) but _also_ the links from LEGATO to other nodes
that in turn have Multinet links to bridge nodes (STUPI, FRUGAL, ROOSTA).
In theory I suppose the latter step is excessive since we can assume that a
two hop path would always cost more than a one hop path, but there's no
guarantee of that. So just to be safe this absolutely eliminates redundant
paths.
I think that leaves me with area 54, CIERE, as the only machine that
_only_ gets its connectivity thru LEGATO. That link I've left turned on.
Now LEGATO sees the path to everything except CEIRE as being thru the
bridge (QNA-1), which is what we'd expect.
OpenVMS Network status for local node 2.1 LEGATO on 5-JAN-2012
08:11:19.43
Area Cost Hops Next Hop to Area
1 4 1 QNA-1 -> 1.300 CTAKAH
2 0 0 (Local) -> 2.1 LEGATO
3 7 2 QNA-1 -> 19.41 SG1
4 4 1 QNA-1 -> 4.249 SLAVE
5 14 4 QNA-1 -> 19.41 SG1
6 4 1 QNA-1 -> 6.1 STAR69
8 7 2 QNA-1 -> 19.41 SG1
11 4 1 QNA-1 -> 11.2 MAISA
19 4 1 QNA-1 -> 19.41 SG1
20 14 2 QNA-1 -> 19.41 SG1
33 7 2 QNA-1 -> 19.41 SG1
42 4 1 QNA-1 -> 42.1 CANADA
52 10 3 QNA-1 -> 19.41 SG1
54 2 1 TCP-0-54 -> 54.59 CEIRE
59 7 2 QNA-1 -> 19.41 SG1
Try your file copies again and see if anything changes...
Bob
Works for me!
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of Oleg Safiullin
Sent: Thu 1/5/2012 11:35
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Router for area 1
This happens because when there are multiple routing nodes for the same
area, DECnet uses the one with the highest address. The obvious solution
would be for Johnny to renumber MIM as, say, 1.1023.
Hmm.
CTAKAH is set to lower router priority than MIM. I thought this is enough to tell that MIM is preffered router...
There's no need for CTAKAH to be and area router, so I'll downgrade it to endnode...
