T.R | Title | User | Personal Name | Date | Lines |
---|
164.1 | | VAXUUM::DYER | | Fri Oct 04 1985 23:48 | 7 |
| It seems to me that the last thing could be done simply by
doing this:
$ MAIL NL: node::SYS$SYSDEVICE
Or do some systems (clustered?) not use SYS$SYSDEVICE?
<_Jym_>
|
164.2 | | RANI::LEICHTERJ | | Sat Oct 05 1985 12:06 | 2 |
| SYS$SYSDEVICE is always there.
-- Jerry
|
164.3 | | VAXUUM::DYER | | Wed Oct 09 1985 03:30 | 28 |
| After playing with this a bit, I've come up with a few
things:
o Before auto-forwarding came along, it was possible
to use system-wide logicals to forward mail (and it
still is). If I were to do this:
$ define/system DYER KEN::OLSEN
OLSEN on node KEN would get my mail. I don't know
if this was done on purpose (bug or feature?), but
I don't think it's needed anymore.
o MAIL to TT: instead of NL: - If there is, for some
reason, a username identical to the logical you're
peeking at, sending mail to NL: will send an empty
and perhaps incriminating message to that username.
Sending it to TT: gives you a chance to ^C out of it.
o Another good logical is LUSERS$REMOTE_ALLOW.
o Sometimes sending to NODE::SYS$WELCOME will reveal
interesting things. For some strange reason, if you
send it to your own node, and SYS$WELCOME points to
a file, it will give you a NOSUCHUSR message for each
record in the file; but if you send it to another node
using the network (including your own node if you
specify it as 0::), you'll only get the first record.
Anyone else playing with this?
<_Jym_>
|
164.4 | Electronic atlas anyone? | OCKER::PUCKETT | Farmer Giles of Ham | Thu May 22 1986 21:59 | 20 |
| -< determining remote time zones >-
RE: .0:
>The following dcl trickery will reveal what time zone a remote node is in:
>
> $ MAIL NL: node::MAIL$TIMEZONE
> or
> $ MAIL NL: node::NOTES$TIMEZONE
>
> $ MAIL NL: node::SYS$SYSTEM
Doesn't always work if the logical name isnt defined on the node (obvious),
and instead of SYS$SYSTEM one should use SYS$SYSROOT.
My interest derives from trying to figure out where all these @##$%%^*! nodes
actually ARE! Does a list exist showing where they are, who is connected to
whom, etc? Just curious...
- Giles
|
164.5 | ANCHOR:: might help | EVER11::HAMPTON | | Fri May 23 1986 09:01 | 3 |
| There's a couple of files in ANCHOR::NET$NODES that give node names,
location codes, system manager, type of system, .... They are
MININODE.LST and SITENODE.LST.
|
164.6 | Wanna read a Telephone book... | POTARU::QUODLING | It works for me.... | Fri May 23 1986 20:25 | 13 |
| > My interest derives from trying to figure out where all these @##$%%^*! nodes
> actually ARE! Does a list exist showing where they are, who is connected to
> whom, etc? Just curious...
Who is Connected to whom? With over 10,000 nodes! I hope you
have better things to do with your time. Try the suggestion of
.5 ( Better Still, I keep an up-to-date copy of those on my Vax
here in Sydney - Save the Net traffic ). Also
Anchor""::net$maps:* has Maps of the areas and area routers,
but I think that they may be dated as they were being done by
Stan Rabinowitz who has since left Digital.
q
|
164.7 | | 8587::S_BINGHAM | Scott Bingham, CSC/CS TBU | Sun May 25 1986 00:52 | 12 |
| 10,000 nodes? Last I heard it was ~7500.
To determine what or where a remote node might be, I generally do
a SET HOST. If there is an announce, it often tells. Sometimes NCP
TELL [node] SHOW EXEC will have something useful in the ID field (or else
it will tell you the CPU type). These will create LOGFAIL accounting
entries, if that bothers you, or if you plan to be malicious.
If you have a username (from a Notes entry or a MAIL message) then
sometimes ELF can locate that person.
_Scott
|
164.8 | 10,000 | DSSDEV::STANSBURY | Jack | Sun May 25 1986 20:30 | 49 |
| RE: .-1
Something I got recently:
Message-class: DECMAIL-MS
From: NAME: MCCAULEY
INITLS: BOB
FUNC: DT/EASYNET MGT.
ADDR: VRO5-2/C10
TEL: 273-3063 <70002@DECMAIL@DONJON@VRO>
Posted-date: 20-May-1986
(long distribution list removed)
Subject: EASYnet Milestone
A few years ago (1978) we had to split up our internal DECsystem-10
network because the ANF-10 networking products didn't work reliably on
a network of 50 nodes. That wasn't considered surprising because not
many people had envisioned networks that "large" when the products
were designed.
Last Wednesday, the EASYnet, Digital's corporate computer network,
registered its 10,000th system and nobody even noticed. Measured in
terms of number of nodes, that makes EASYnet the WORLD'S LARGEST
PRIVATE COMPUTER NETWORK. We are currently adding over 100 new
systems per week, so we don't expect to be overtaken for a while.
The 10,000th node is a MicroVAX in MKO2, a system named PLANIT. A
small memento and ceremony is planned to recognize this milestone in
the growth of EASYnet.
The fact that the network functions so well in this complex and
dynamic environment is a tribute to the quality of the Digital product
set (hardware and software, particularly DECnet) and the support teams
in Digital Telecommunications (both headquarters and field) and Field
Service. We have every confidence that the network will continue to
operate smoothly as we move forward to our next target of 20,000
nodes. At the present rate of growth, we expect to be there around
the end of FY87.
The significance of this event is two fold. First, as the largest
user of Digital's products our experience operating a large corporate
network can provide insight into future customer requirements and
provides a "stress test" for the products. Secondly, we serve as a
reference account and an example of how Digital's networking products
and services can be used to solve real business problems - in all
parts of the corporation, every day - another example of how "Digital
has it now".
|
164.9 | TRACER | SKYLAB::FISHER | Burns Fisher 381-1466, ZKO1-1/D42 | Tue May 27 1986 12:54 | 8 |
| Somewhere around (the Tools clearinghouse?) there is a tool called
TRACER which figures out what the path is between two nodes. One
can figure out topology that way. One can also do things like
TELL xxx SHOW KNOWN CIRC, although that gets rather wordy on ethers.
Burns
|
164.10 | VMSmail as a snoop | MDVAX3::COAR | A wretched hive of bugs and flamers. | Wed Nov 11 1987 11:33 | 37 |
| .0>These strike me as mild security holes.
I agree. I think MAIL should return the NOSUCHUSR error WITHOUT
remote translation. Translation should only be performed locally.
Comments?
.3> o Before auto-forwarding came along, it was possible
> to use system-wide logicals to forward mail (and it
> still is). If I were to do this:
> $ define/system DYER KEN::OLSEN
> OLSEN on node KEN would get my mail. I don't know
> if this was done on purpose (bug or feature?), but
> I don't think it's needed anymore.
Actually, it is still useful in cases such as
MAIL X.TXT MY_UNIT/SUBJECT="Hooey"
where
MYUNIT = "COAR,JONES,WILSON,PETERSON,FOO,BAR"
or
MY_UNIT = "@MAIL$:STLC_DELIVERY.DISTRIBUTION"
.3> o Another good logical is LUSERS$REMOTE_ALLOW.
What is this all about?
.9> Somewhere around (the Tools clearinghouse?) there is a tool called
> TRACER which figures out what the path is between two nodes.
There's one called NETPATH as well; are these actually the same
thing under different names?
#ken :-)}
|
164.11 | | ERIS::CALLAS | I like to put things on top of things | Wed Nov 11 1987 13:35 | 5 |
| re .10:
The bug mentioned in .0 is supposed to be fixed in V5.
Jon
|
164.12 | Timezones revisited.... | SPIDER::BURKE | Andy Burke, MLO21-3 DTN 223-9923 | Tue Dec 22 1987 09:11 | 23 |
|
>re : Note 164.0 determining remote time zones 2-OCT-1985 16:27
>
>The following dcl trickery will reveal what time zone a remote node is in:
>
> $ MAIL NL: node::MAIL$TIMEZONE
> or
> $ MAIL NL: node::NOTES$TIMEZONE
>
I realize the original note is somewhat dated, but......
How does a 'hacker' determine system time on a remote node??
I am considering an application that must provide international
clocks. With all the 'mumblemumble' standard times out there there
is no fixed relationship to local time in all time zones.
(BTW NOTES/MAIL$TIMEZONE don't seem to be defined anymore)
All help/ideas appreciated --
|
164.13 | one way is to .... | MANTIS::BURKE | Andy Burke, MLO21-3 DTN 223-9923 | Wed Dec 23 1987 14:03 | 22 |
|
Well, here's one answer. It uses the creation date and time of
a file created in the default DECNET directory.
Note: This will not work if the default DECNET user's directory
does not exist, and there are some nodes out there like this.
.
.
.
$ if p1 .eqs. "" then inquire p1 "Node "
$ node = p1
$
$ open/write tempfile 'node'::timestamp.log
$ close tempfile
$ rem_time = f$file_attributes("''node'::timestamp.log","cdt")
$ delete/nolog 'node'::timestamp.log;*
$
$ say "Time on node ''node' is ''rem_time'"
$
$
|
164.14 | LISP Logicals may tell | QED::EVANS | Robert N. Evans DTN-291-8341 @DLB5-1/E2 | Wed Dec 23 1987 18:34 | 7 |
| Another possibility is to use the LISP logicals which may be defined if
VAX LISP is installed on the remote node. eg. on QED:
(LNM$SYSTEM_TABLE)
"LISP$DAYLIGHT_SAVING_TIME_P" = "YES"
"LISP$TIME_ZONE" = "5"
|
164.15 | thanx | BEES::BURKE | Andy Burke, MLO21-3 DTN 223-9923 | Mon Dec 28 1987 13:17 | 3 |
|
Thanks, I appreciate your quick, accurate, and hack of a response.
|