HDTenEightyP/NetNews huggingface dataset:
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: BINARY mode FTP
From: Peter Kobe <system@pib1.physik.uni-bonn.de>
Date: Thu, 12 Nov 1992 08:34:42 MEZ
Reply-To: Peter Kobe <system@PIB1.physik.uni-bonn.de>
Organization: The Internet
Return-Path: <SYNFUL@CMUTEK.CC.CMU.EDU>
Errors-To: SYNFUL@CMUTEK.CC.CMU.EDU
X-Listname: CMU-TEK TCP/IP Mailing list <CMU-TEK-TCP@CMUTEK.CC.CMU.EDU>

Bob Marshall
marshall@force.ssd.lmsc.lockheed.com
has difficulties to do binary mode ftp

>    FTP> binary
>    FTP> put dmgfx.o
>
>fails.  I get an error message about an "unimplemented STRU type".
>I also tried:
>
>    FTP> send/type=image dmgfx.o
>
>This transferred the file, but it seems to "chop off" the final few
>bytes.  The file is 819,415 bytes in size, but only 819,200 bytes are
>actually downloaded.

Try to get an updated version from Henry Miller
HENRYM@SACUSR.MP.USBR.GOV
It does all you want in a perfect way.

Peter
=====================================================================
Peter Kobe			Internet: system@pib1.physik.uni-bonn.de
Physikalisches Institut	          HEPNET: 13562::SYSTEM
Universitaet Bonn	             Tel: (49) 228 73 3222
D 53 Bonn		             FAX: (49) 228 73 7869
Nussallee 12
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Info on purchasing VMS copy of TCP/IP package
From: Michael Vilain <vilain@apple.com>
Date: Mon, 9 Nov 92 11:22:55 PST
Reply-To: Michael Vilain <vilain@apple.com>
Organization: The Internet
Return-Path: <SYNFUL@CMUTEK.CC.CMU.EDU>
Errors-To: SYNFUL@CMUTEK.CC.CMU.EDU
X-Listname: CMU-TEK TCP/IP Mailing list <CMU-TEK-TCP@CMUTEK.CC.CMU.EDU>
X-Mailer: ELM [version 2.3 PL11]

Hello,

Our is interested in obtaining a license and copy of the most
current release of your TCP/IP package for use on our VMS systems.

Please e-mail me the particulars (e.g. where to mail the check).

Thanks,

/MeV/
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: BINARY mode FTP
From: bob Marshall Org 6792 Bldg 561 x65737
Date: Wed, 11 Nov 1992 11:27:59 EST
Reply-To: Bob Marshall Org 6792 Bldg 561 x65737
Organization: The Internet
Return-Path: <SYNFUL@CMUTEK.CC.CMU.EDU>
Errors-To: SYNFUL@CMUTEK.CC.CMU.EDU
X-Listname: CMU-TEK TCP/IP Mailing list <CMU-TEK-TCP@CMUTEK.CC.CMU.EDU>

One of my users posed the following question to me. I was unable to answer it :

------------
We have files that we build on the VAX using a cross-compiler and linker
which are transferred via FTP to a target machine which has an MC68020
processor.  The transfer must be byte for byte: no padding on 512 byte
boundaries, no alteration of the data, etc.

When we use Excelan's FTP, where the "binary" mode supports a pure
"image" transfer it works fine.

I do not know how to get CMU/Tek's FTP to support an image transfer from
your VAX system (NEBULA) to our system (IES).  The following:

    FTP> binary
    FTP> put dmgfx.o

fails.  I get an error message about an "unimplemented STRU type".
I also tried:

    FTP> send/type=image dmgfx.o

This transferred the file, but it seems to "chop off" the final few
bytes.  The file is 819,415 bytes in size, but only 819,200 bytes are
actually downloaded.

I also tried getting the file from the IES.  The following:

    FTP> binary
    FTP> get dmgfx.o dmgfx.nebula

(given a correct "dmgfx.o" on the IES) results in the final 512 byte
block being padded.  Of course, this makes it impossible to reproduce
a checksum.

We need to be able to do a "real" image transfer of files to and from
the IES workstation, with no data lost or added (we have to be able to
reproduce checksums).  Do you have any ideas?
------------

I am running v6.6-5A of CMU/Tek. I am not sure of what is running on the
user's system; I suspect it is a Sun workstation, but I'm not sure. Any ideas?

Bob Marshall
marshall@force.ssd.lmsc.lockheed.com
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: FTPSRV going into MUTEX state
From: "Goovaerts Paul" <goovaerts@mble.philips.be>
Date: Mon,  9 Nov 92 12:25:31 MEWT
Reply-To: "Goovaerts Paul" <goovaerts@mble.philips.be>
Organization: The Internet
Return-Path: <SYNFUL@CMUTEK.CC.CMU.EDU>
Errors-To: SYNFUL@CMUTEK.CC.CMU.EDU
X-Listname: CMU-TEK TCP/IP Mailing list <CMU-TEK-TCP@CMUTEK.CC.CMU.EDU>
X-Vms-Mail-To: UUCP%"cmu-tek-tcp@andrew.cmu.edu"
X-Vms-Mail-Cc: GOOVAERTS


Context:

	heavily loaded microVAX 3300 running VMS 5.4-2 & CMU 6.5-3
	PC running PCNFS 4.0

We are experiencing problems with the FTPSRV process going into a MUTEX state.
This is the visible part of the iceberg. Other effects are incomplete transfers
when uploading from the PC to the VAX by means of FTP.
These incomplete transfers and MUTEX states only seem to occur when the
combination PCNFS/CMU is used. FTP's between a SUN running SUN OS 4.1 and
the same VAX are OK. A user written server process also never causes troubles.

Did anybody already encounter the same problem?


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Paul Goovaerts
N.V. MBLE S.A.			   Domain: Goovaerts@mble.philips.be
82 Twee Stationsstraat 82          Voice:  +32/2/5256311
B-1070 Brussel                     Fax:	   +32/2/5256600
Belgium                            SERI:   goovaerts:mox
                                   DECnet: mox::goovaerts
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Additional plea fr help with NAMRES
From: "Kenneth J. Hoover" <ken@psuedvax.psu.edu>
Date: Wed, 11 Nov 1992 08:40:46 EST
Reply-To: "Kenneth J. Hoover" <ken@psuedvax.psu.edu>
Organization: The Internet
Return-Path: <SYNFUL@CMUTEK.CC.CMU.EDU>
Errors-To: SYNFUL@CMUTEK.CC.CMU.EDU
X-Listname: CMU-TEK TCP/IP Mailing list <CMU-TEK-TCP@CMUTEK.CC.CMU.EDU>


>NAMRES doesn't seem to be talking to the Domain Name Server. All IPNCP HOSTNM
>requests result in UNKNOWN HOST responses.
>The NAMRES process exists and is not RWAST. I try to turn on logging with
>IPNCP NAMRES LOG %x0FF but I don't get anything in NAMRES$LOG. We have a uVax
>sitting right next to the Vax running very happily with an identical
>NAMRES$CONFIG.

  I've been fighting the same problem for a couple of weeks now.  I want to
know why it does this.  It seems that "ipncp hostnm" can't find the name
server to get the address.  I can cure this by stopping and restarting the
IPACP, but this requires that I stop all of my mail stuff too (MX and JNET)
which is tedious.  I'm running 6.6-5.

  When this goes down, my JNET link via cmu-tek goes down too.

  So, I will add to Richard's plea...

>Help?

  Help!

  (BTW, I need the Telnet pause fix too.  When is 6.6-5A going to be out?)

						- Ken Hoover
--
Kenneth J. Hoover               | Warning : sys$itch needs sys$scratching!
ITSS Supervisor of Sys & Ops    | Disclaimer : I disclaim dis.
Penn State College of Education | ken@psuedvax.psu.edu - kjh6@psuvm.psu.edu
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: <None>
From: srlnicv@lhn.gns.cri.nz
Date: Mon, 09 Nov 1992 18:45:13 NZST
Reply-To: srlnicv@lhn.gns.cri.nz
Organization: The Internet
Return-Path: <SYNFUL@CMUTEK.CC.CMU.EDU>
Errors-To: SYNFUL@CMUTEK.CC.CMU.EDU
X-Listname: CMU-TEK TCP/IP Mailing list <CMU-TEK-TCP@CMUTEK.CC.CMU.EDU>

Hi there

We have been trying to set up an anonymous FTP server using
CMU-Tek (6.6-5a) under VMS 5.3-1.  All works OK except that
we cannot get FTP to allow users to upload files.  When issuing
a send command, the following message results:

FTP> Send test.txt
550 Requested action not taken. No access.
Requested action not taken. File unavailable.

We have granted W:REW to the ANONYMOUS directory and all
subdirectories in the UPLOADS path as well as ACL's to user
ANONYMOUS, but still get the same result.

We would appreciate any ideas on how to set this up or
information on Anonymous FTP which may point us in the right
direction (preferably by EMAIL).

Yours in extremis

*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--**
  Ian Vickridge              |      SRLNICV@LHN.GNS.CRI.NZ            *
  IGNS Ltd                   | "If we look at a glass of wine closely *
  P.O. Box 31312             |    enough we see the entire universe"  *
  Lower Hutt                 |               (R.P. Feynman)           *
  New Zealand                |  FAX: (+64 4) 5690 657 Phone 5690 615  *
**-**-**-**-**-**-**-**-**-**-**-**-**-**-**-**-**-**-**-**-**-**-**-**
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Alpha Migration plan of cmu-tek ip ???
From: "Takashi Ichihara <ichihara@rikvax.riken.go.jp>"
Date: Fri, 13 Nov 1992 12:52:50 JST
Reply-To: "Takashi Ichihara <ichihara@rikvax.riken.go.jp>"
Organization: The Internet
Return-Path: <SYNFUL@CMUTEK.CC.CMU.EDU>
Errors-To: SYNFUL@CMUTEK.CC.CMU.EDU
X-Listname: CMU-TEK TCP/IP Mailing list <CMU-TEK-TCP@CMUTEK.CC.CMU.EDU>

  Hello folks,

  Does anyone have a migration plan of CMU-TEK TCP/IP to
ALPHA/VMS ?

----------------------------------------------------------------------
   Takashi Ichihara
   RIKEN (The Institute of Physical and Chemical Research)
      (Internet/Bintet)  Ichihara@rikvax.riken.go.jp
      (HEPnet/span)       RIKEN::ICHIHARA (41910::Ichihara)
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
From: rrb@nch.norasia.COM (R.R.Buonanno)
Subject: IP device is Offline mounted
Reply-To: rrb@nch.norasia.COM
Organization: Norasia Shipping Services SA
Date: Fri, 6 Nov 1992 14:19:19 GMT

Hi netters,
I'm a poor lost Unix hacker trying to figure out something which is VERY
VMSish. We're running CMU-Tek 6.6-5A (fresh off the tape) on VMS 5.4.
When we installed CME-Tek the first time it ran for quite a while with no
problems. Then one day out of the blue (after a reboot) the IP: device went
into this weird state (Offline mounted) and we couldn't get it back. After
lots of fiddling we just re-installed the whole thing and lo and behold it
all worked fine again ... for a while. One fine day we shut down CMU-Tek
and it went back into said weird state. The other symptom we've noted is
that the IPCACP process hangs around forever and can't be STOPped and even
reboots (with no subsequent IP startup) don't get rid of it.

So what am I doing wrong? Be gentle, I'm VMS illiterate but I do have a
VMS system manager available for abuse :-). What does an installation do
get this thing out of it's comatose state? I'd like to revive it without
reinstalling it every time. I need a resolution quick or we're going to
have to go to something (eeegad!) more expensive.

Thanks much...

-- 
Richard R. Buonanno					rrb@nch.norasia.COM
Chief Hack and Window Washer				mcsun!chsun!nch!rrb
Norasia Shipping Services SA   PO Box 560   1700 Fribourg Switzerland
From: leesw@logica.co.uk
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re: Additional plea fr help with NAMRES
Date: 12 Nov 92 17:20:24 GMT

In article <00963725.71AA4420.11368@psuedvax.psu.edu>, "Kenneth J. Hoover" <ken@psuedvax.psu.edu> writes:
> know why it does this.  It seems that "ipncp hostnm" can't find the name
> server to get the address.  I can cure this by stopping and restarting the
> IPACP, but this requires that I stop all of my mail stuff too (MX and JNET)
> which is tedious.  I'm running 6.6-5.
> 
>   When this goes down, my JNET link via cmu-tek goes down too.
> 
>   So, I will add to Richard's plea...
> 
>>Help?
> 
>   Help!
> 

I had the same problem, but it *seems* to have gone now that I have added
the following lines to NAMRES$CONFIG.  The lines have been posted here
a few times, so you have probably seen them and tried them anyway, but here
they are, just in case they are new to you:

Variable:RECURSE:1
Variable:TIMEOUT:5
Variable:REFMAX:10

I found that the problem occurred if NAMRES tried to contact the DNS and
couldn't.  As I said my problem seemed to be cured by the above lines, but
an alternative would be to make sure that the link to the DNS is as reliable
as possible.  Specify lots of ,domain servers in NAMRES$CONFIG.  With any luck
at least one of them will be contactable...

William
 
---------------------------------------------------
William Lees,  Logica International Ltd,  London UK
Internet: leesw@logica.co.uk  CompuServe: 75300,250
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
From: rrb@nch.norasia.COM (R.R.Buonanno)
Subject: RE: IP device is Offline mounted
Reply-To: rrb@nch.norasia.COM
Organization: Norasia Shipping Services SA
Date: Mon, 9 Nov 1992 08:31:40 GMT

Hi folks it's me again, announcing my stupidity to the world.

OK. Let me clarify a bit.

I found out IPCAPC didn't belong to CMU-Tek about 5 minutes after I posted.
And I got 6.6-5A via ftp but had to make a tape out of it to be able to
read it onto our Vax (for those of you who thought it was a release tape).
Now here's where I'm at... When we do a NETEXIT or otherwise shut down
CMU-Tek (as in System Reboots) it goes away as expected. However when we do
an IP_STARTUP, it doesn't start up. Nor does it seem to print an error
message.

So where do I look to find the fatal error?

My VMS guy was in on Sunday and re-installed again. So I can't check this
thing immediately but I want to know what to look for if it goes south
again.

Again, I apologize for my lack of knowledge and debugging skills, however
I'm not the VMS system manager. Most of this I have to report second-hand
according to what he tells me is wrong (or thinks is wrong). Thanks a
million for your collective help.

-- 
Richard R. Buonanno					rrb@nch.norasia.COM
Chief Hack and Window Washer				mcsun!chsun!nch!rrb
Norasia Shipping Services SA   PO Box 560   1700 Fribourg Switzerland
From: MyTH@ucx.lkg.dec.com (M. T. Hollinger)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Re: Host: IP is not Host: DOMAIN.NAM.  Why?
Keywords: IP domain
Date: 10 Nov 92 03:26:02 GMT
Reply-To: MyTH@ucx.lkg.dec.com (M. T. Hollinger)
Organization: Digital Equipment Corporation
Originator: MyTH@hageln.ucx.lkg.dec.com


In article <1dn5qqINNmth@crcnis1.unl.edu>, Russell Mosemann writes:
>    We are running UCX 1.3.  When I do a show users/full, it displays
> some of the Host:'s with IP numbers instead of host and domain name.
> Why?  When I get into UCX and do a SHOW HOSTNM IP, it returns the domain
> name just fine, so it can find it.

From these symptoms I would guess that the reverse hostname translation
is simply taking a long time to complete.  UCX attempts to determine the
hostname for a connection before acting on it (in this case, presenting
a login prompt).  If the network or the nameservers are slow, the lookup
can take a long time.  Rather than keep the user waiting, UCX times out
and records the numeric address.

When you later query your local nameserver with the SHOW HOST command,
it still has the translation in its cache from the aborted attempt at
hostname lookup before login.  Therefore, the command completes right
away.  However, the system does not retry the resolution for the
now-already-established session, and so the numeric address remains
for the duration.

Partly for this reason, the default behavior under V2.0 is to not even
attempt address-to-name translation.  At least that way, the remote
host identification is always shown consistently (as an IP address).

         - MyTH
From: silverm@bcstec.ca.boeing.com (Jeff Silverman)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Re: Q: UCX proxies for rlogin (inbound? dup recs?)
Date: 8 Nov 92 00:34:49 GMT
Organization: Boeing Computer Services, Seattle

MyTH@ucx.lkg.dec.com (M. T. Hollinger) writes:


>an "ND" next to them in the SHOW PROXY output (NFS, Dynamic).  Watch
>the OPCOM messages when you try to mount or access the relevant
>filesystem; they often provide a strong clue.

>           - MyTH

Right.  One of the advantages of UCX over other implementations of TCP/IP is 
the wealth of diagnostic information you are given.  Unfortunately, it isn't 
always easy to find.  For example, OPCOM has to be enabled for NETWORK messages
in order to see the diagnostics (REPLY/ENABLE=NETWORK).

Jeff Silverman, Boeing
From: sysop@robot.nuceng.ufl.edu (Shawn A. Clifford)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Q: UCX proxies for rlogin (inbound? dup recs?)
Date: 6 Nov 92 17:30:00 GMT
Reply-To: sysop@robot.nuceng.ufl.edu
Organization: Nuclear Engineering Sciences - Univ. of Florida
News-Software: VAX/VMS VNEWS 1.41

This may be a RTFM question, but I get UCX through the CSLG, so I don't have
a FM.

I have rlogin working fine outbound from the VAX to both a Sun and a
Silicon Graphics (eg:  rlogin/user="user"/terminal_type="vt100"/lower node)
but I can't get inbound rlogins to work.  The VAX always asks for a username
and password.  I saw someone else post the same problem, and he (M. Berman)
had tried using dup records with lower case to test for possible solutions.
I HAD NFS proxies working ok, but now it doesn't seem to work either.

Can anyone tell me how to correctly define the proxies for inbound rlogins,
how to make dup records (because I have more than one account on the VAX that
I would like to rlogin into), and perhaps shed some light on the NFS proxy
SNAFU?  Remember, I don't have a FM.

Thanks.
From: rmcewen@ccs1.bbn.com (Regis McEwen)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Setting up RSH proxies
Keywords: RSH
Date: 11 Nov 92 17:16:29 GMT
Reply-To: rmcewen@ccs1.bbn.com (Regis McEwen)
Organization: Bolt Beranek and Newman, Inc., Cambridge, MA
NNTP-Posting-Host: ccs1.bbn.com



	I trying to test UCX's RSHD and I'm running into some problems that
	I'm hoping someone can help me with.

	On an Un*x box I'm issuing the commands:

		rsh vax "sh process"

	VAX is a VAX 3500 running UCX 2.0

	On the proxy on the VAX looks like:

UCX> sh proxy

VMS User_name     Type     User_ID     Group_ID   Host_name

VMSUSER           CD       un*xuser                un*x.bbn.com

	Where VMSUSER is a valid VMS user on the VAX, un*xuser is a valid
	username on the un*x box which is issuing the RSH commands, and
	un*x.bbn.com is the un*x box it's comming from.

	I'm getting the following errors:
	
INTERnet ACP RSH Connection Request on - client user name not found - from Host: 128.89.0.18  Port: 1022
INTERnet ACP RSH Reject Request - client user name not found - from Host: 128.89.0.3  Port: 1023
UCX$RSHD - permission denied - client user:un*xuser


	What is the proper way to setup the equivalence of the .rhost file
	on the VAX (ADD PROXY ...)?


							-Regis
From: craa79@ccsun.strath.ac.uk ("R.B.Rodger")
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Re: Host: IP is not Host: DOMAIN.NAM.  Why?
Keywords: IP domain
Date: 10 Nov 92 11:56:23 GMT
Organization: University of Strathclyde

I write:
>Has anyone come up with a fix for the problem where UCX 
>gets the translation of the ip address of the calling site wrong?

About half an hour after I posted this, CSC phoned me - the problem is known
to UCX engineering, and they're working on it. They didnt give a timescale.

Bruce.


-- 
R.B. Rodger                       |R.B.Rodger@strath.ac.uk
Computer Centre                   |
Strathclyde Univ                  | +44 (0)41 552 4400 x3460
Glasgow G4 0LN, Scotland.         |
From: MyTH@ucx.lkg.dec.com (M. T. Hollinger)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Re: Q: UCX proxies for rlogin (inbound? dup recs?)
Date: 7 Nov 92 03:25:49 GMT
Reply-To: MyTH@ucx.lkg.dec.com (M. T. Hollinger)
Organization: Digital Equipment Corporation
Originator: MyTH@hageln.ucx.lkg.dec.com


In <6NOV199212304913@robot.nuceng.ufl.edu>, Shawn A. Clifford writes:
> I have rlogin working fine outbound but I can't get inbound rlogins to
> work.  The VAX always asks for a username and password.  I saw someone
> else post the same problem, and he (M. Berman)...

That's good.  Did you see my answer?  It was rather long-winded, so I've
mailed you a copy rather than reposting.

> Can anyone tell me how to ... make dup records (because I have more
> than one account on the VAX that I would like to rlogin into), and
> perhaps shed some light on the NFS proxy SNAFU?

You can't currently have two different proxies for the same remote
host and user.  This restriction made sense when NFS proxies were the
only proxies supported.  Now that communication proxies are provided,
the restriction should be eased.  This should be fixed in a future
version of UCX.

As for your NFS proxy problems, you didn't include enough information
for me to be sure, but for starters, you might try cleaning out any
invalid proxies you added while experimenting with RLOGIN.  Note that
communication proxies (for use with RSH) don't require a UID or GID,
just a remote username.  Make sure the relevant remaining proxies have
an "ND" next to them in the SHOW PROXY output (NFS, Dynamic).  Watch
the OPCOM messages when you try to mount or access the relevant
filesystem; they often provide a strong clue.

           - MyTH
From: TEWKSBURY@BUDSGA.BU.EDU (Chip Tewksbury)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: SNMP is shot
Date: 10 Nov 92 00:35:03 GMT
Organization: BOSTON UNIVERSITY, OFFICE OF INFORMATION TECHNOLOGY
X-News-Reader: VMS NEWS 1.24

Looks like you can forget about getting SNMP to work properly in V2.0. I
logged a call with the CSC regarding the apparent misrepresentation of the
net mask by SNMP  (it sends 0.0.0.0 as the net mask rather than whatever you
see with the UCX SHO INTERFAC command).   Here's an excerpt from the
response of the CSC support engineer:

  SNMP currently does not work correctly. Indeed you will probably find that
  the counters reported by SNMP are not the same as doing show commands at
  the ucx> prompt.

  As of now Engineering is working on the whole SNMP problem base and has
  not released any information on when it will be completed....

  At this point the only solution is to not use SNMP for any critical needs.


Not very comforting.   I remember talking to the product manager of DEC
TCP/IP  (Jerry something-or-other) about the product's delay in shipment.
His response was that they wanted to put V2.0 through exhaustive and
thorough testing before it was shipped.  So much for that plan, I guess :-}

		Chip Tewksbury.
From: craa79@ccsun.strath.ac.uk ("R.B.Rodger")
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Re: Host: IP is not Host: DOMAIN.NAM.  Why?
Keywords: IP domain
Date: 10 Nov 92 10:04:56 GMT
Organization: University of Strathclyde

Has anyone come up with a fix for the problem where UCX 
gets the translation of the ip address of the calling site wrong?

This caused a minor panic here, when I noticed that SYSTEM was apparently
logged in from a workstation at the far side of the campus........

Bruce.

-- 
R.B. Rodger                       |R.B.Rodger@strath.ac.uk
Computer Centre                   |
Strathclyde Univ                  | +44 (0)41 552 4400 x3460
Glasgow G4 0LN, Scotland.         |
Newsgroups: vmsnet.networks.tcp-ip.ucx
From: a866700@hp9000.csc.cuhk.hk (Wong Siu To)
Subject: UCX 2.0 with VMS 5.5, info wanted
Organization: The Chinese University of Hong Kong
Date: Fri, 13 Nov 1992 10:38:53 GMT

Hi all,

We're running VMS 5.3-1 on a VAXcluster consists of MicroVAX 3400,
MicroVAX II, and 3 x MicroVAX 2000.  They also have PMDF 4.0, Jnet 3.5,
and UCX 1.3a running on.  We'll upgrade to VMS 5.5 and UCX 2.0 (TCP/IP
for VMS) shortly, but I wonder if there's any incompatibility with these
software after the upgrade, and if there's any problem with the system
after the upgrade.

Would anyone please advise ?

Thank you very much !

Regards,

-- 
ST Wong				       
Computer Services Centre 
The Chinese University of Hong Kong               
Shatin, N.T., Hong Kong
From: mosemann@unlinfo.unl.edu (Russell Mosemann)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Host: IP is not Host: DOMAIN.NAM.  Why?
Date: 10 Nov 1992 02:12:42 GMT
Organization: University of Nebraska--Lincoln	
Distribution: world
Reply-To: mosemann@unl.edu
NNTP-Posting-Host: unlinfo.unl.edu
Summary: Why isn't Host: IP Host: DOMAIN.NAM instead?
Keywords: IP domain

   We are running UCX 1.3.  When I do a show users/full, it displays
some of the Host:'s with IP numbers instead of host and domain name.
Why?  When I get into UCX and do a SHOW HOSTNM IP, it returns the domain
name just fine, so it can find it.
--
Russell
mosemann@unl.edu
Newsgroups: vmsnet.networks.tcp-ip.ucx