HDTenEightyP/NetNews huggingface dataset:
Date: 11 SEP 92 06:02:32 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From:    mahan @ TGV.COM (Patrick L. Mahan)
From: mahan@TGV.COM
Subject: Re: DECwindows & TCPIP transport load failure
Organization: The INFO-MULTINET Community

# Help!
# 
# I am having problems with the TCP/IP transport for DECwindows.
# On a VAXstation 4000-VLC, VMS V5.5 and MultiNet V3.1 Rev A,
# it refuses to attach to the TCP/IP transport and gives a rather
# odd (IMO) error in the DECW$SERVER_0_ERROR.LOG file.
# 
# From the error log:
# 
# 	10-SEP-1992 22:37:16.6 Hello, this is the X server
# 	This is the VMS DECwindows Motif server V1.1-911012
# 			compiled on Oct 12 1991 at 08:55:08
# 	Dixmain address=1732c
# 	Server is running in bug-compatible mode
# 	Now attach all known txport images
# 	%DECW-I-ATTACHED, transport DECNET attached to its network
# 	%DECW-W-ATT_FAIL, failed to attach transport TCPIP
# 	-SYSTEM-W-ENDOFFILE, end of file
# 
# 	[it then goes on with the the usual font loading, etc.]
# 

This error is caused by the value pointed to by the logical 
UCX$INET_HOST not being in MULTINET:HOSTS.LOCAL.  Add it to HOSTS.LOCAL,
recompile host tables, re-install the database, restart the master
server and then restart the X server.  It should clear up the problem.

Patrick L. Mahan

--- TGV Window Washer ------------------------------- Mahan@TGV.COM ---------

Waking a person unnecessarily should not be considered  - Lazarus Long
a capital crime.  For a first offense, that is            From the Notebooks of
							  Lazarus Long
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: DECwindows over IP problem and an FDDI problem.
From: "Lawrence P Macintyre" <macintyrelp@ornl.gov>
Date: 10 SEP 92 19:57:34 GMT
Organization: The INFO-MULTINET Community
X-Gateway-Source-Info: INTERNET
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: "Lawrence P Macintyre" <macintyrelp@ornl.gov>

[This message is converted from WPS-PLUS to ASCII]


X-Gateway-Source-Info: INTERNET
Date: 11 SEP 92 06:02:28 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From:    SYSTEM@GERGE.TAMU.EDU
From: SYSTEM@GERGE.TAMU.EDU
Subject: DECwindows & TCPIP transport load failure
X-Vmsmail-To: SMTP%"info-multinet@TGV.COM"
Organization: The INFO-MULTINET Community

Help!

I am having problems with the TCP/IP transport for DECwindows.
On a VAXstation 4000-VLC, VMS V5.5 and MultiNet V3.1 Rev A,
it refuses to attach to the TCP/IP transport and gives a rather
odd (IMO) error in the DECW$SERVER_0_ERROR.LOG file.

From the error log:

	10-SEP-1992 22:37:16.6 Hello, this is the X server
	This is the VMS DECwindows Motif server V1.1-911012
			compiled on Oct 12 1991 at 08:55:08
	Dixmain address=1732c
	Server is running in bug-compatible mode
	Now attach all known txport images
	%DECW-I-ATTACHED, transport DECNET attached to its network
	%DECW-W-ATT_FAIL, failed to attach transport TCPIP
	-SYSTEM-W-ENDOFFILE, end of file

	[it then goes on with the the usual font loading, etc.]

This system is, as far as I can tell, configured nearly identicaly
to another VAXstation 4000-VLC in the same cluster which does not have
this problem. The MultiNet startup and configuration files are the same,
excepting the network addresses and that the VS with the problem is
now running NFS and the other one isn't (although it had the problem
under MultiNet V3.0, before V3.1 and NFS were installed which rules that
out). The startup files for DECwindows are the same.

Any ideas as to what the actual problem could be?  Hints, even?

Thanks,

Carl Perkins		InterNet: carl@gerga.tamu.edu  /  system@gerga.tamu.edu
GERG VAXmanager		THEnet:   gerga::carl          /  gerga::system
Texas A&M University

Newsgroups: vmsnet.networks.tcp-ip.multinet
From: pyron@skndiv.dseg.ti.com (Dillon Pyron)
Subject: Re:  Re: Logical disk on Sun for microVAX ??
Reply-To: pyron@skndiv.dseg.ti.com
Organization: TI/DSEG VAX Support
Date: Tue, 15 Sep 1992 13:55:02 GMT


In article <2C200ADE14SEP92221640@TGV.COM>, adelman@TGV.COM writes:
>> At our site we have a DEC MicrovaxII (running VAX/VMS 5.5, MultiNet 3.1) linked over ethernet to a Sun SPARCserver 4/490 (running SUNOS 4.1.1). We are having trouble with Multinet working between these machines to our specific requirements.
>
>> What we require is to have a directory mounted from the Sun server onto the Microvax using NFS Client. This directory will not be used from the Sun side (unix), but will be used exclusively as another "device" on the Microvax.
>
>> We have mounted the SUN directory with the following command:
>> NFSMOUNT/SEMANT=NOSTR/VOL=R76DISK cruiser::"/usr6/r76disk" R76DISK
>
>> There are some differences in behaviour between r76disk and a physical Vax disk, which we are trying to resolve.
>
>> 1.  files copied or restored from a backup to r76disk lose their creation dates.
>
>    NFS doesn't have a concept of a true creation date.  Our NFS
..
>
>> 2.  files restored from backups to r76disk get execute permission
>> for system added to their file protection.
>
>    NFS doesn't have a concept of system access. As such we display the
..
>
>> 3.  files copied to r76disk always get default file permissions
>> regardless of what file permissions they had to start with.
>
>    What is happening here is that the create request comes across
..
>
>							    Ken
>
What Ken is trying to say is that NFS and RMS don't play by the same rules. 
Sometimes, I'm not sure they are playing the same game.  And sometimes, it
doesn't look like playing.   :-)

We've quit trying to treat our NFS filesystems like VMS disks.  They are Unix
filesystems that we are lucky enough to have access to.  Since I hate vi, I
consider that a blessing!
--
Dillon Pyron                      | The opinions expressed are those of the
TI/DSEG Lewisville VAX Support    | sender unless otherwise stated.
(214)462-3556 (when I'm here)     |
(214)492-4656 (when I'm home)     |"Do something different, DISAPPEAR"
pyron@skndiv.dseg.ti.com          |  "DISAPPEAR"
                                     _A Day On Earth_
                                     Brave Combo

X-Gateway-Source-Info: INTERNET
Date: 10 SEP 92 15:54:59 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: "I am only an egg." <JOHNSON@northeastern.edu>
From: "I am only an egg." <JOHNSON@northeastern.edu>
Subject: Re: Ultrix backups.
X-Envelope-to: info-multinet@tgv.com
X-VMS-To: IN%"info-multinet@tgv.com"
X-VMS-Cc: JOHNSON
Organization: The INFO-MULTINET Community

     Well ... I've been informed that I'm doing things the hard way 
again.  * sigh *


Eric C Loyd writes;
   >Tapes are accessible via networks through the RMT server.  MULTINET supports
   >this protocol, as well as the rdump command which allows you to use remote
   >tapes as though they were local dump devices under Unix.  In fact, you could
   >Rdump your files to a remote VMS machine without NFSing the file systems.

and;

   >Also, under VMS 5.5, the TMSCP server will serve MU devices to all
   >machines in a cluster.  So, I suppose you could say that you're wrong. 

   >Eric C. Loyd                            ecldco@ritvax.isc.rit.edu
   >Operations Coordinator                  ecldco@ritvax.BITNET
   >ISC/Data Center Operations              Phone: (716) 475-7320
   >Rochester Institute of Technology       FAX:   (716) 475-5306
   >Rochester, NY  14623  USA               All-In-One: LOYD EC (@a1.isc.rit.edu)

     So I guess I'll see if I can get RMT to work next.

     Thank you Eric.

Chris Johnson
Northeastern University.
X-Gateway-Source-Info: INTERNET
Date: 14 SEP 92 18:14:44 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: Telnet problems when using gopher
Organization: The INFO-MULTINET Community

> When using a gopher client from a unix host, the telnet connection
> to a gopher hole I have on my node fails with a termunknow error
> and resets the connection. I did'nt have this problem with UCX.
> Is anyone experiencing the same problem and/or have a suggestion
> on who to overcome it?

    The difference could be that MultiNet supports the TERMINAL-TYPE
option negotiation and sends your VMS terminal type across to the
TELNET server, while UCX does not. It sounds like a problem with
Gopher; if it doesn't recognize the terminal type it should just
assume the same behavior it has when you don't specify one.

							   Ken

X-Gateway-Source-Info: INTERNET
Date: 09 SEP 92 07:41:48 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: "L. Stuart Vance" <VANCE@TGV.COM>
From: "L. Stuart Vance" <VANCE@TGV.COM>
Subject: Re:  MM expunge improvement
Organization: TGV, Incorporated
X-Phone: 408/427-4366 (work); 408/427-4365 (fax)
X-Address: 603 Mission Street; Santa Cruz, CA  95060 (work)

>I don't know what you guys did, but expunges in MM (v3.1) seem to run
>an order of magnitude faster!  

We found a hook into the VAX C RTL that DEC documented starting with VMS V5.5
that improves file I/O drastically.  I'm quite happy about it too!  Saves a lot
of time for me...

Regards!
-----Stuart
X-Gateway-Source-Info: INTERNET
Date: 11 SEP 92 02:01:34 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: Regis McEwen <RMCEWEN@ccs1.bbn.com>
From: Regis McEwen <RMCEWEN@ccs1.bbn.com>
Subject: Re: DECwindows over IP problem and an FDDI problem.
X-VMS-To: IN%"R.E.Sonneveld%research.ptt.nl@TGV.COM"
X-VMS-Cc: IN%"info-multinet@tgv.com"
Organization: The INFO-MULTINET Community

Rolf,

> 1. The first problem is related to the opening of a DECwindows window
>   over TCP/IP on  a  Multinet  host.  We  get  the  following  error
>   message. I can't find it neither in the Multinet  manual,  nor  in
>   the DECwindows User Guide.
>
>> dectermport failed to find language, XOpenDisplay("") returned NULL
>> %DECW-F-CANT_OPEN_DISPL, Can't open display
>
> Anyone triggered?

	The most common occurrance of this is that the node name in
	SET DISPLAY/NODE=xxxx is not valid, i.e. non-existant or can't
	be looked up, when the transport in non LOCAL.

	To be sure, use:

		$ multinet x11debug

	to print out some diagnostics.

	(Excellent program to debug X11 transport connectivity; best I've
	seen by far !!  Kudos to the author !!)

							-Regis


X-Gateway-Source-Info: INTERNET
Date: 15 SEP 92 18:25:38 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: Error Messages from Print server
Organization: The INFO-MULTINET Community

> %%%%%%%%%%%  OPCOM  10-SEP-1992 18:01:07.23  %%%%%%%%%%%
> Message from user SYSTEM on MOLENG
> Printer Server: Failure to create VMS print job = %X48694

> I have looked for error messages in the manuals and find few, and not
> this one.  What does it mean, what can be wrong?

    It means that the LPD server received an error from the VMS job
queue manager (JOB_CONTROL) when it tried to submit a job to be
printed. Error 48694 translates to the meaningless:

%JBC-F-NOMSG, Message number 00048694

    Which means that you're pretty much have to call DEC on this one
and ask them why SYS$SNDJBCW() is returning that error code. I'd
recommend that you re-initialize your job queue manager by deleting
the queue files, rebooting, and reinitializing all your queues. Usually
this fixes "weird things" like this.

							    Ken
X-Gateway-Source-Info: INTERNET
Date: 07 SEP 92 07:13:42 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: RCP and LOGIN.COM problem
Organization: The INFO-MULTINET Community

> This may be a FAQ but ...

> When the MultiNet 'rcp' server calls any Unix 'rcp' client, everything works.
> However, the Unix 'rcp' server bombs out when talking to MultiNet 'rcp' client
> because the first line of the user's login.com is always sent back to the
> server.

>	  unix$ rcp junk.txt vms.node
>	  $! first line from login.com even if it is '$ set noverify'

>	  vms$ dir junk.txt
>	  %DIRECT-W-NOFILES, no files found

>	  vms$ rcp unix::"junk.txt" []/log
>	  %RCP-I-COPIED, UNIX::junk.txt copied to VMS:[DIR]JUNK.TXT;1 (1 block)

> Is there any way to avoid this (other than have no login.com)?

    Yes, if the first line of your login com turns off verify:
$ verify = 'f$verify(0)

							    Ken
X-Gateway-Source-Info: INTERNET
Date: 04 SEP 92 23:32:23 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: "Bruce R'. Miller" <MILLER@TGV.COM>
From: "Bruce R'. Miller" <MILLER@TGV.COM>
Subject: Re:  TGV's port to Alpha
Organization: The INFO-MULTINET Community

>I noted the ad in DEC Professional by TGV about MultiNet being Alpha-ready. 
>Excellent job guys.  Bruce Miller is quoted as saying that the changes to the
>code could fit on one printout page.  Now, I wouldn't want you folks to give
>away any trade secrets, but is there any chance you could put together a
>document/presentation/summary of what it took to port your stuff to alpha and
>what coding techniques you used to avoid needing massive changes?  After all,
>the DEC engineers claim that 90% would need no changes and you seem to have
>bettered that tremendously.  Are you planning a Symposium session on this,
>perhaps?  A white paper maybe?

There are really no special techniques we used.  The DEC engineers did a
great job of making Alpha/VMS look like VAX/VMS.  I we had to do was
change a few structure definitions (ie. the PTE) and watch out for compiler
peculiarities.  When we write code we always try to consider how the
machine or OS might change in the future (or in the past).  Just common
sense, really.

>We expect to be going to Alpha middle of next year and I'd sure like to be able
>to benefit from your experiences!  That is unless I get the job as the unix
>administrator for our new rs/6000 and HP boxes and stop dealing with VMS :-).

It's all fairly straight forward.  The whole port took about three weeks
with two people working on it.  Just check out the Migrating Applications
To Alpha/VMS manual for details.  The only useful bit of advise I could
give is this:  compile your code /LIST/MACHINE and get used to reading
Alpha machine code.  That's not required 99.44% of the time, but it helps
it you're going to try anything tricky (like loading and unloading C
code into the kernel).

-bruce
From: rankin@eql.caltech.edu (Pat Rankin)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: RCP and LOGIN.COM problem
Date: 7 Sep 92 06:42:00 GMT
Organization: California Institute of Technology
News-Software: VAX/VMS VNEWS 1.41

In article <1992Sep7.130219.1@deco.ucc.su.oz.au>,\
 stanley@deco.ucc.su.oz.au writes...
> When the MultiNet 'rcp' server calls any Unix 'rcp' client, everything works.
> However, the Unix 'rcp' server bombs out when talking to MultiNet 'rcp'
> client because the first line of the user's login.com is always sent back
> to the server.
>	$! first line from login.com even if it is '$ set noverify'
> Is there any way to avoid this (other than have no login.com)?

     Yes, use the lexical function f$verify() to turn verification off.
You can use the tick mark (',apostrophe,single quote) to force the function
to be evaluated before DCL decides whether or not to echo the line.

|$ v = 'f$verify(0)'    !turn verification off, remember whether it was on
|
|... rest of login.com here (should probably start with ``$ set noon'') ...
|
|$ if v then set verify !nothing after this line

     Several variations are possible, but this one is the most straight-
forward.

		Pat Rankin, rankin@eql.caltech.edu
Newsgroups: vmsnet.networks.tcp-ip.multinet
From: richard@raet-sh.UUCP (Richard van Denzel)
Subject: Unable to run application
Organization: RAET Industrie & Handel, Utrecht
Date: Thu, 10 Sep 1992 11:47:16 GMT

Hello netlanders,

I have a problem running an application from my HP Unix system on my VAXstation
3100 with Multinet 3.0 rev G.
I have setup the security according to what the manuals tell me to do and 
defined a display using the follwing command:


$ set display/create/transport=tcpip
$ show display

    Device:    WSA7:  [super]
    Node:      0
    Transport: TCPIP
    Server:    0
    Screen:    0

Also on the unix machine I have setup the environment variable DISPLAY:

# export DISPLAY=vs3100:0.0

When I run my application I get the following message:

Xlib:  connection to "vs3100:0.0" refused by server
Xlib:  Client is not authorized to acce
ERROR open_xwindow: can't open display
 

Has anyone got an idea to what is going wrong? Please help!

Richard.
-- 
--
Richard van Denzel	richard%raet-sh!relay.nluug.nl via internet backbone
RAET Industrie & Handel	uucp: ..!{uunet,sun4nl}!raet-sh!richard
Eendrachtlaan 10,
X-Gateway-Source-Info: INTERNET
Date: 10 SEP 92 17:56:20 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: DECwindows over IP problem and an FDDI problem.
Organization: The INFO-MULTINET Community

> 1. The first problem is related to the opening of a DECwindows window
>    over TCP/IP on  a	Multinet  host.  We  get  the  following  error
>    message. I can't find it neither in the Multinet  manual,  nor  in
>    the DECwindows User Guide.

>> dectermport failed to find language, XOpenDisplay("") returned NULL
>> %DECW-F-CANT_OPEN_DISPL, Can't open display

    This is a DECwindows error; unfortunately the application doesn't
tell you anything except that there was one. The best way to debug
these problems is to try:
$ multinet x11debug
which will make its own connection to the display, but give you more
information about the failure.

> 2. On our Multinet host we've both an ethernet and an FDDI interface.
>    The default route is via ethernet. Changing the default  route  to
>    FDDI gives me a lot of unreachable systems on the ehternet  behind
>    our cisco. Hope someone can tell me  how  to  make  the  FDDI  the
>    default route?

    Assuming that you're using different network or subnetwork numbers
for our FDDI and Ethernet, is the cisco connected to both as an IP
gateway? If so, then the default route of the cisco should get you to
the machines behind the Ethernet, assuming that the cisco itself has
routes to those machines (and that they have routes throughthe cisco
to the FDDI network). If the cisco is not connected to both, then
you'll need to put specific network or subnetwork routes in your
tables to point at the machines which are behind the Ethernet, while
leaving the default route at the cisco.

>    Another  problem is, that the fddi interface is not reachable from
>    other  systems.  However,	if  I first do a ping from the multinet
>    host  towards such a system, than that system (if it's on fddi) is
>    placed  in  the  ARP  table,  and	then  the  fddi  interface *is*
>    reachable	from  that  system.  This  trick  doesn't  work from an
>    ethernet  host,  because  the ethernet cisco interface is the only
>    (default)	route  in  the	ARP table. What should I do to make the
>    FDDI interface available towards any system on our LAN?

    Not reachable from other systems on the FDDI? I'm confused.

							Ken
Newsgroups: vmsnet.networks.tcp-ip.multinet
From: pyron@skndiv.dseg.ti.com (Dillon Pyron)
Subject: DECnet security (not MultiNet)
Followup-To: vmsnet.networkds.tcp-ip.multinet
Keywords: arrgh
Reply-To: pyron@skndiv.dseg.ti.com
Organization: TI/DSEG VAX Support
Date: Tue, 8 Sep 1992 15:30:45 GMT


I recently made some comments about undetectable logins, but choose not to
reveal too much.  Given the amount of traffic my poor little machine has seen,
I need to be a little more specific.

If TASK=0 does nothing for you, call your DEC support person.  Hopefully, most
people have closed this hole, but since I find it from time to time, I wanted
to be careful.  Security by obscurity.

Now, back to the tightly written, throughly tested, bug free, bank vault secure
MultiNet.
--
Dillon Pyron                      | The opinions expressed are those of the
TI/DSEG Lewisville VAX Support    | sender unless otherwise stated.
(214)462-3556 (when I'm here)     |
(214)492-4656 (when I'm home)     |"Do something different, DISAPPEAR"
pyron@skndiv.dseg.ti.com          |  "DISAPPEAR"
                                     _A Day On Earth_
                                     Brave Combo

X-Gateway-Source-Info: INTERNET
Date: 14 SEP 92 18:14:35 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: Re:  HELP WITH SYSADM NETWORKING PROBLEMS .....
X-Envelope-to: INFO-MULTINET@TGV.COM
Organization: The INFO-MULTINET Community

>I am an Administer for unix based machines on a local network. A professor
>has put a vax station onto the network. I do not know much about vms administra
>tion, any help would be great.
>
>I am using ucx (sp?) and can do a telnet 146.186.xx.xx, which file(s) allow
>me to use the name of the machine instead of the numerical address? Also, if
>I try to telnet outside our local net, I get "network unreachable". Which file
>do I need to look at to show gateways & routes?

Ken,
  Suggest you back up a step or two, take a deep breath, and understand
what you are asking about.
  For VMS, as distinct from U**X, there are a lot of different TCP/IP
implementations.  They are *very* different.  The answers to questions
like the ones you ask are different for Multinet, CMU-TEK (the two lists
to which you sent your inquiry), and UCX (which is what you are
running).  The products (these are not the only ones, by a long shot) 
range in quality and maintainability from "brain-damaged, pre-broken,
and very hard to get to work and keep working" to Multinet.  The latter,
speaking as a user who was somewhat influential in the evaluation that
finally led to MIT's switchover from unmentionable other products, is
the absolute best of the lot (and several other lots) in both product
quality and support.
   To oversimplify, you have two choices with this, depending on the
value you and your university place on your time and/or on reasonable
network interoperability:
  Choice 1:  Try to run UCX and get it working properly.  You will
mostly have to rely on DEC for support.  Some of the people who
"support" it show no signs of understanding how to spell "TCP/IP", but
adequately smart people with an adequate understanding of TCP/IP and
enough patience have gotten it to work moderately well.  You might be
equally sucessful.
  Choice 2: Go buy something decent that comes with sufficiently good
documentation and automatic configuration tools to eliminate the sorts
of questions you ask (and problems you are having) at installation time. 
If "decent" is construed as "better than UCX" in this regard, there are
several choices--it doesn't take a whole lot.  If "decent" is considered
in the more usual sense, and you put any value on your time at all, take
some free advice and just get Multinet and put it up.  It is also, if 
I recall, very cheap for VAXStations, so this might be fairly painless
advice.  If you decide to look elsewhere, make sure that you get
something that, like Multinet, supports sufficiently good UCX emulation
and/or interoperation that any tools that run on the VAXStation that 
expect UCX will think that they are finding it.

    john
    klensin@infoods.mit.edu


X-Gateway-Source-Info: INTERNET