HDTenEightyP/NetNews huggingface dataset:
Date: 20 NOV 92 21:03:41 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
Subject: Re: Alternate UIC for MULTINET_SERVER?
X-RFC822-From: simon@internode.com.au  (Simon Hackett)
From: simon@internode.com.au
Organization: The INFO-MULTINET Community


> We are trying to develop a local application to provide weather data to 
> a group of observatories here in Hawaii. There is no problem getting the 
> MultiNet ser ver to spawn off a process to get the data, however, due to 
> the way in which the weather station data we need is used by our 
> telescope control systems, the data resides in a Group global section 
> and is therefore unreadable by the spawned process. Is it possible to 
> modify the RUN command in START_SERVER.COM so that the server is started 
> by a (fully-privileged) UIC in the proper group? Will anything else 
> break if we do this?
> 
> (For various reasons, it is not possible to rewrite the weather software 
> to use a system global section.)
> 

There are two other alternatives that might work for you:

#1: run your server independently to the MULTINET_SERVER process (See
the standalone examples in the back of the MultiNet documentation and
in the MultiNet examples directory for some starting points for this)

#2: write a program which reads the global section (and which runs
with the right group id), and have that program "publish" the weather
data to anyone who wants it by using some other mechanism (e.g.
reading the contents of the global section via a system wide mailbox,
or some similar mechanism).

Simon


X-Gateway-Source-Info: INTERNET
Date: 20 NOV 92 21:05:28 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: "Kevin V. Carosso" <KVC@SUMMER.INNOSOFT.COM>
From: "Kevin V. Carosso" <KVC@SUMMER.INNOSOFT.COM>
Subject: Re: NFSMOUNT in a cluster
X-VMS-To: IN%"Adelman@TGV.COM"
X-VMS-Cc: IN%"info-multinet@TGV.COM"
Organization: The INFO-MULTINET Community

>> What is possible and will we run in trouble with shared writes in case the
>> clusterworde mounting does not exist ?
>
>   Record locking doesn't work across NFS, but file locking will if
> the NFS Server supports a lock manager.

I don't think the original question was in reference to shared writes
between VMS and UNIX.  I think it was coordination between members of a
cluster writing to NFS client files that they all can see.  Since the
cluster members don't see the same device (apparently you cannot mount
NFS devices cluster-wide?) you probably don't get cluster-wide distributed
lock-manager locking to coordinate shared writes amongst cluster members,
right?  In other words, it doesn't act like a physical disk with multiple
paths or a single-path disk device served to the cluster and mounted
cluster-wide.

Would be neat if I'm wrong.

	/Kevin Carosso
	 Innosoft



X-Gateway-Source-Info: INTERNET
Date: 20 NOV 92 21:05:35 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From:     adelman (Kenneth Adelman) @ TGV.COM
From: adelman@TGV.COM
Subject:  Re: Unnecessary host routing in addresses resent by this list
Organization: The INFO-MULTINET Community

> I've noticed a strange (well, perhaps not:-) phenomenon about the headers of
> mail resent by this list.  Please excuse the appearance within what follows of
> addresses given in the UK's "big-endian" format: the Internet-Janet relay,
> nsfnet-relay.ac.uk performs this reversal on all entities that it recognizes as
> possibly forming the name of a host, and it's too much effort for me to
> [attempt to] re-reverse them into what I conjecture would have been their
> original format.

> Anyway, the phenomenon is that mail from some senders, in particular [I think],
> those outside the "original" Internet (com, gov, mil, edu, etc.) gain a
> source-routing address such that any reply would be sent through tgv.com.  Here
> is an example coming from the University of Turku, Finland:

    Someone want to remind me about where I can find a list of current
top-leval domains so I can update my list? I've added .FI to the list, so
the rewriting on those addresses should stop.

							    Ken
From: mcmahon@TGV.COM (At the end of the long, dark tunnel)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: FYI: News/Mail Gateway Change
Date: Fri, 20 Nov 92 12:25:45 PST
Organization: Info-Multinet<==>Vmsnet.Networks.Tcp-Ip.Multinet Gateway
X-Gateway-Source-Info: Mailing List

For some time we have been gatewaying Info-MultiNet to the VMSnet.* newsgroup 
with two "half" gateways.  E-mail to News was handled at TGV.COM (by me), and 
News to E-mail was handled by Mark Berryman at SAIC.COM

As of today, all gatewaying will occur at SAIC.COM.  The TGV "half" gateway has 
been shut down, most likely for good...  

As always, please report any issues or problems to 
INFO-MULTINET-REQUEST@TGV.COM.

And kudos to Mark for picking up the rest of the gateway job!

John 'Fast-Eddie' McMahon    ()
TGV, Incorporated            () "Any networking problem can be solved by
603 Mission Street           ()  the application of 33 miles of Unshielded 
Santa Cruz, California 95060 ()  Twisted Pair (UTP)"   
408-427-4366 or 800-TGV-3440 ()                      [InterOp Spring 1992]
E-Mail: MCMAHON@TGV.COM      ()



X-Gateway-Source-Info: INTERNET
Date: 20 NOV 92 21:05:15 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From:    HENRYM@SACUSR.MP.USBR.GOV (Henry W. Miller)
From: HENRYM@SACUSR.MP.USBR.GOV
Subject: T-Shirt ECO
X-Vmsmail-To: SMTP%"info-multinet@tgv.com"
Organization: The INFO-MULTINET Community

>> >I recently washed my new Alpha Ready TGV T-shirt from Interop and most of the
>> >printing went right down the drain. The reds were especially bad.
>
>> We are using an identical T-shirt in-house and can not reproduce the
>> problem.  Have you tried contacting your washing machine manufacturer?
>
>    Actually, I was able to reproduce the problem using my Maytag.
>I'm pretty sure it was the washer that did it because I generally
>don't dry my tshirts in the dryer, although I didn't look at it when
>it came out of the washer. I'm going to forward my Tshirt to Stu
>to examine when he gets back next week.
>
>							    Ken
>
	Thanks to the assitance of my wife, Susan Miller, I believe I
can provide an ECO for the T-Shirt problem.

	To eliminate the problem of running, soak the T-Shirt in a solution
of 1/2 cup of Vinegar mixed with 1 Gallon (US) of cold water for 30 minutes.
Then use the washing machine.  However, wash the T-Shirt in warm, not hot
water.

	To eliminate the problem with the red portions that have already
run, use a 50/50 mixture of water and bleach (or bleach and water) in
a squirt bottle and soak the afflicted areas for five minutes then use
the washing machine.

	Unfortunately, this ECO cannot be retrofitted into a VMSINSTAL kit.

-HWM
----------
Henry W. Miller
Assistant Systems and Network Manager
U.S. Bureau of Reclamation
Mid Pacific Region
2800 Cottage Way MP1100
Sacramento, CA 95825
(916) 978-5108 / FTS - Same as commercial
Inet:	"henrym@sacwms.mp.usbr.gov"
BITNET:	"hmiller@scu"

"I've fallen, and I can't get up!"

X-Gateway-Source-Info: INTERNET
Date: 20 NOV 92 21:04:55 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
Subject: Need help getting gopher client to fire up on VMS and Multinet
X-RFC822-From: Tad Macy <macy@polar.bowdoin.edu>
From: Tad Macy <macy@polar.bowdoin.edu>
X-Mts: smtp
Organization: The INFO-MULTINET Community



I am trying to port the gopher client and server to our VMS host running
Multinet 3.0 and VMS v5.4-3.  The server is up but I am having trouble with
the client (v06b).  Since I am just beginning to look into the problem, I
thought I'd see if anyone else has run into it.  Do not know if it is gopher
or my system configuration (or me ;-).

--
Tad Macy
System Manager
Bowdoin College

X-Gateway-Source-Info: INTERNET
Date: 20 NOV 92 21:04:38 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: "George D. Greenwade" <bed_gdg@SHSU.edu>
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Subject: Dates on files when using NFS client
Organization: The INFO-MULTINET Community

We've run into a glitch which I hope can be easily solved.  We want to
transparently keep our anonymous ftp archives accessible from our VMS
machine on our HP-UX, with the TGV NFS client pointing to the device. 
Then, define the MULTINET_ANONYMOUS_FTP_DIRECTORY to a directory tree on
the device defined by the logical created with NFSMOUNT.  So far, so good
(or so it seems -- if this is a bad idea, please let me know).

When this is done, a DIR command in an ftp session to the VMS machine gives
today's date as the file date.  In fact, doing a DIRECTORY/DATE at the VMS
level within that tree gives today's date.  A VMS DIRECTORY/DATE=MODIFIED
on the NFS mounted device at the VMS level shows dates which are in
accordance with our Unix machine (which is what we'd prefer to broadcast on
the VMS host, as well).

Is there any way to achieve this (i.e., what didn't we read in the manuals
that we should have)?

Regards and thanks in advance,   George
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D.                            Bitnet:  BED_GDG@SHSU
Department of Economics and Business Analysis         THEnet: SHSU::BED_GDG
College of Business Administration                    Voice: (409) 294-1266
P. O. Box 2118                                        FAX:   (409) 294-3612
Sam Houston State University              Internet:        bed_gdg@SHSU.edu
Huntsville, TX 77341                      bed_gdg%SHSU.decnet@relay.the.net
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
From: AWPSYS@ritvax.isc.rit.edu (Andrew Potter, Assoc. Dir, ISC DCO&TS)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: FInger
Date: 20 Nov 1992 18:41:45 -0400 (EDT)
Organization: Info-Multinet<==>Vmsnet.Networks.Tcp-Ip.Multinet Gateway
X-Gateway-Source-Info: Mailing List

>
>>Now your usual commands such as SHOW PROC and SHOW SYS don't do funny
>>things with this situation, but CONTROL-T does ring your bell.

>and delete all your files except for some directories.  Please note that
>putting special characters in your process name IS SOMETHING THAT YOU DO TO
>YOURSELF.  You can't screw up someone else's terminal that way; only your own.

The DCL command SHOW uses $FAO to filter non printing characters from process
names.  Finger does not.

I personnally believe that any system wide utility that displays individual
user specified fields should give the systems manager a mechanism to
filter non printing characters.    With numerous terminals today it is still
possible to do nasties with letter bombs.  

- Andy
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: Finger
Date: 21 Nov 1992 04:23:57 GMT
Organization: HST Wide Field/Planetary Camera
Distribution: world
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <01GRE2AV0WPE0000EV@techno.isc.rit.edu>, ECLDCO@techno.isc.rit.edu (Eric Loyd - Data Center Operations, x7320) writes:
>	2)  The plan file that finger prints _could very well_ contain
>		nasties that wreak havoc with terminals that are looking
>		for the right thing.  I believe that filtering _this_
>		information is what would be useful.

MULTInet finger already does this:
$ DUMP/RECORD=COUNT=1 .PLAN

Dump of file $1$DIA0:[CARL].PLAN;3 on 20-NOV-1992 20:07:11.93
File ID (10597,15,0)   End of file block 1 / Allocated 3

Record number 1 (00000001), 63 (003F) bytes

 69746163 69666964 6F4D4A5B 1B485B1B .[H.[JModificati 000000
 206F7420 474B4350 544D2066 6F206E6F on of MTPCKG to  000010
 66206465 656E2065 74616E69 6D696C65 eliminate need f 000020
   2E7669 7270204F 495F5948 5020726F or PHY_IO priv.. 000030

$ FINGER CARL
CARL     Carl J Lydick       20605E8C NEWSRDR        txc1  

Plan:

.[H.[JModification of MTPCKG to eliminate need for PHY_IO priv.
Modification of 370PLOTS to provide better margins.

Now, FINGER doesn't filter the information passed to it by other systems. 
Neither does TELNET.  Neither does FTP.  It's up to the administrator of the
remote system to make sure that the finger daemon there does the filtering.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
X-Gateway-Source-Info: INTERNET
Date: 20 NOV 92 21:05:06 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: Brian McKeever <MCKEEVER@VAX2.CSTP.UMKC.EDU>
From: Brian McKeever <MCKEEVER@VAX2.CSTP.UMKC.EDU>
Subject: Re: TCPDUMP and the ETHERS file.
X-Envelope-to: Adelman@TGV.COM, info-multinet@tgv.com
X-VMS-To: IN%"Adelman@TGV.COM"
X-VMS-Cc: IN%"info-multinet@tgv.com"
Organization: The INFO-MULTINET Community

   [...]

>> It obediently translates Cecil's Ethernet address into the name Cecil when
>> it displays the packets.  Anybody know what's going on?

>     The name is case-sensitive. Put it in lower case.

oops...  I should have guessed that since it is probably written in C.

Thanks,

--Brian
From: HOLDREGE+_MP%A1%PacifiCare@mcimail.com (Matthew Holdrege)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: RE: FWD: RE: NNTP server for VMS?
Date: Sat, 21 Nov 92 00:18 GMT
Organization: Info-Multinet<==>Vmsnet.Networks.Tcp-Ip.Multinet Gateway
X-Gateway-Source-Info: Mailing List


I read John's list of newsreaders. I have one other question. Could someone 
help me find out how to get a newsfeed to our site? We are new on the 
Internet and since we don't yet have usenet I'm not sure where to ask 
this.

Thanx!
Matt Holdrege               5156065@mcimail.com
Pacificare Health Systems   holdrege@eisner.decus.org
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: Finger
From: Stafford@Vax2.Winona.MSUS.EDU (John Stafford)
Date: 23 Nov 92 13:01:08 -0600
Followup-To: vmsnet.networks.tcp-ip.multinet
Distribution: world
Organization: MSUS

In article <01GRHM6CVI6A0000EV@techno.isc.rit.edu>,
ECLDCO@techno.isc.rit.edu (Eric Loyd - Data Center Operations, x7320)
wrote:
> 
> >
> >Curious.  Why do you put that info there to begin with?  I suspect
> >it is for some record-keeping function.  Unfortunate because SYSUAF.DAT
> >has a free area which you can use for such purposes.
> 
> Please inform me.  What "free area" is this?  In looking in the AUTHORIZE
> facility, I was unable to find any qualifier on the ADD command.  The OWNER
> field is used for billing purposes and for automated system authorization
> functions.  With over 16,000 accounts, it can get to be quite a headache.
> 
Whoops, it is not available through AUTHORIZE.  It is simply an area
of the uaf record and you have to program to get at it.  If this is not
a feasible approach, then an alternative is to build a simple indexed
sequential file (easily read/written via DCL) to associate records with
SYSUAF.  Even this may not be feasible, depending upon what you want to
do.  If you would like to share these needs, perhaps via EMail, maybe
we can work something out.  Many of us have similar problems and are
coping in various ways.  (hey, digital -- how about making this area
a user-accessible one through Authorize?)
From: HEGE@finabo.abo.fi (Kaj H{ggman DC)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: Finger
Date: 17 Nov 92 07:10:12 GMT
Organization: Abo Akademi University, Finland
X-News-Reader: VMS NEWS 1.23

In <Keith.W.Johnson.22.721965538@tek.com> Keith.W.Johnson@tek.com writes:
> I'm not sure what you mean by "lighter".  I use FINGER locally on my VMS 
> machine with no arguments so it shows all current users.  It used to work 
> fine then suddenly became very "heavy", taking two or three minutes before 
> I control-Y'ed out of it.  Later I discovered that with version 3.1 it 
> now does a cluster-wide search, which was slows it down unless you specify 
> the /NOCLUSTER option.  Just type "$ FINGER /NOCLU".  I'm not sure how you 
> control that for incoming requests over the net, though.

It has "always" consumed quite a lot of CPU-time, especially compared to the 
PD-finger provided by Terry Kennedy, but - just as it says above - the 
(default) clusterwide finger is even slower. 

I was getting a little concerned when I found out that finger was a TOP-3 
CPU-consumer, mostly because people from our u*ix-environment seem to check 
what the vms-users are doing...

So, maybe only the excellent Multinet guys can provide me with some patched
magic images :-) If incoming request to finger could be forced to do /NOCLU,
well, that would only help a little, but sure better than nothing!

Kaj Haggman             Internet: Hege@abo.fi     Phone:   +358-21-654467
Abo Akademi University  Bitnet:   Hege@finabo     FAX:     +358-21-654497
Computing Center        PSImail:  22101410::HEGE
SF-20500 Abo, FINLAND   X.400:    s=hege o=abo prmd=inet admd=fumail c=fi  
X-Gateway-Source-Info: INTERNET
Date: 20 NOV 92 21:03:53 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From:    mcmahon @ TGV.COM (At the end of the long, dark tunnel)
From: mcmahon@TGV.COM
Subject: RE: DECwindows Motif 1.1 and creation of DECterms with RSHELL
Organization: The INFO-MULTINET Community

> Under DECwindows Motif 1.0 there was a problem if windows were created from 
> another node by doing an RSHELL, along the lines of:
> 
> $ set disp/create/tran=tcpip/node='p1'
> $ create/terminal/detach
>
> If this was used several times, only the *first* window would be created.

Well, the original problem was that the SET DISPLAY/CREATE command would create 
a new WS device (DECW$DISPLAY) for each invocation of the command procedure.  
The problem was that only the first WS device would stick around to be used by 
the created DECterm.  The reason the first hung around was that the DECterm 
controller held a channel open to it.  What the REUSE-DISPLAY command procedure 
did was find that original WS device and use that, instead of creating a new 
one.

And then Motif 1.1 came along...

The DECterm Controller process no longer assigns a channel to the WS device.  
The result is that every WS device created by the invocation of this command 
procedure disappears.  So when you do a SHOW DISPLAY in your DECterm windows, it 
comes back with DECW$DISPLAY being defined to a non-existant WS device.

I worked out a quick and dirty solution, which can be found below.  This 
requires that the newly created DECterm assign a channel to the DECW$DISPLAY 
device (e.g. OPEN $SAVE_THE_WS_DEVICE$ DECW$DISPLAY: in the LOGIN.COM file or 
somesuch).  It's a crude hack, but it will work.

Cheers!
John McMahon

$! P1 is the /NODE qualifier (default MULTINET_RSHELL_ADDRESS or 0)
$ if p1 .eqs. "" then p1 = f$trnlnm("MULTINET_RSHELL_ADDRESS")
$ if p1 .eqs. "" then p1 = "0"
$! P2 is the /TRANSPORT qualifier (default TCPIP)
$ if p2 .eqs. "" then p2 = "TCPIP"
$! P3 is the /SERVER qualifier (default 0)
$ if p3 .eqs. "" then p3 = "0"
$! P4 is the /SCREEN qualifier (default 0)
$ if p4 .eqs. "" then p4 = "0"
$ write sys$output "Node=",p1," Transport=",p2," Server=",p3," Screen=",p4
$ DeviceLoop:
$	next = F$DEVICE("_WS*")
$	if next .eqs. "" then goto endloop
$	define/user sys$output nl:
$	show display/symbol 'next'
$	if ( (p1 .eqs. DECW$DISPLAY_NODE)      .and. -
             (p2 .eqs. DECW$DISPLAY_TRANSPORT) .and. -
             (p3 .eqs. DECW$DISPLAY_SERVER) .and. -
             (p4 .eqs. DECW$DISPLAY_SCREEN) )
$	Then
$		Write Sys$Output "Using Device ''next'"
$		Define Decw$Display 'Next'
$		Goto The_Big_Exit
$	EndIf
$	goto deviceloop
$ endloop:
$ SET DISPLAY /CREATE /NODE='P1' /TRANSPORT='P2' /SERVER='P3' /SCREEN='P4'
$ Write Sys$Output "Creating New Device ",F$TRNLNM("DECW$DISPLAY")
$ The_Big_Exit:
$ Create/Terminal/Detach
$ Open $SAVE_THE_WS_DEVICE$ DECW$DISPLAY:
$ BaseRefCnt = f$getdvi("DECW$DISPLAY","REFCNT")
$ WaitLoop:
$	RefCnt = f$getdvi("DECW$DISPLAY","REFCNT") 
$	If RefCnt .Gt. BaseRefCnt Then Exit
$	Write Sys$Output "Open a channel to DECW$DISPLAY in the new DECterm."
$	Wait 00:00:15
$	Goto WaitLoop




X-Gateway-Source-Info: INTERNET
Date: 20 NOV 92 21:05:23 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From:     adelman (Kenneth Adelman) @ TGV.COM
From: adelman@TGV.COM
Subject:  Re: Another TCPDUMP question...
Organization: The INFO-MULTINET Community

> Why, when I do a MU TCPDUMP ETHER HOST CECIL I get dumps like this:

> 19:42:10.14 cecil cecil loopback 46:
>		   0000 0100 0100 4361 796d 616e 2053 7973 ......Cayman Sys
>		   7465 6d73 2047 6174 6f72 426f 7820 6c6f tems GatorBox lo
>		   6f70 6261 636b 2070 6163 6b65 742e	   opback packet.
> 19:42:10.36 cecil AppleTalk-Multicast 0024 28:
>		   0001 809b 0604 0003 0000 8901 a1ac 0000 ................
>		   025d 0000 0000 0000 0000 025d	   .].........]
> 19:42:11.07 arp who-has eos.cstp.umkc.edu tell cecil

    This means that cecil sent an ARP request for the host eos,
probably because it wants to send a packet to it (perhaps eos is a
default router and we're trying to send a query to the DNS or somesuch).

> 19:42:11.08 arp reply eos.cstp.umkc.edu is-at aa:0:4:0:2c:4

    EOS replies to the request with its Ethernet address.

    The odd thing here is that we would next expect to see a packet
from EOS to cecil, but don't.

> 19:42:11.08 vax2.cstp.umkc.edu.nfs > eos.cstp.umkc.edu.9f1f062b:
>	  reply ok OK 96
>   [...]
> 19:42:11.41 vax2.cstp.umkc.edu.nfs > eos.cstp.umkc.edu.a11f062b:
>	  reply ok OK 128
> 19:42:11.45 vax2.cstp.umkc.edu.nfs > eos.cstp.umkc.edu.a01f062b:
>	  reply ok ENOENT 28
> 19:42:11.59 vax2.cstp.umkc.edu.nfs > eos.cstp.umkc.edu.a21f062b:
>	  reply ok OK 128
> 19:42:11.65 vax2.cstp.umkc.edu.nfs > eos.cstp.umkc.edu.a31f062b:
>	  reply ok ENOENT 28

    Either VAX2 or EOS has the same ETHERNET address if we're
seeing these packets. Try repeating the trace with the /ETHER
switch so we can see the Ethernet address as well as the IP address.

							    Ken
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: Finger
Date: 19 Nov 1992 03:35:56 GMT
Organization: HST Wide Field/Planetary Camera
Distribution: world
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <3664@mitech.com>, gjc@mitech.com (George J. Carrette) writes:
>Of course, even standard VMS is not entirely immune to that sort of attack.
>e.g.
>
>  $ BELL[0,8] = 7
>  $ SET PROCESS/NAME="''BELL'FOO''BELL'"
>
>Now your usual commands such as SHOW PROC and SHOW SYS don't do funny
>things with this situation, but CONTROL-T does ring your bell.

Sure.  And the filesystem isn't entirely bulletproof either.  You can, after
all:
	$ SET DEFAULT SYS$LOGIN:
	$ SET PROTECTION=O=RWED [...]*.*.*
	$ DELETE [...]*.*.*
and delete all your files except for some directories.  Please note that
putting special characters in your process name IS SOMETHING THAT YOU DO TO
YOURSELF.  You can't screw up someone else's terminal that way; only your own.

SHEESH!  You'd think that people would be content with REAL problems with
computers rather than making up problems that don't exist!
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
X-Gateway-Source-Info: INTERNET