HDTenEightyP/NetNews huggingface dataset:
From: system@pib1.physik.uni-bonn.de (Peter Kobe)
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: BINARY mode FTP
Date: 26 Dec 92 03:22:27 GMT
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: Re:  Domain Name Server
From: Bruce Orchard <orchard@eceserv0.ece.wisc.edu>
Date: Wed, 30 Dec 1992 11:48:25 -0600
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

If you are not connected to the internet, declare yourself a
primary server for the root domain and put SOA and NS records
for the root in the zone for the root.  I have never tried
this, but I think the server is returning server failure
(DOMAIN/LOOKUP will tell you the status if you use /FULL
on the LOOKUP command) because it cannot contact the
root servers.

Bruce Orchard
From: aurelio%ufpa.br@bitnet.cc.cmu.edu
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re: Help me!!!!
Date: 24 Dec 92 08:39:07 GMT
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu
Content-Transfer-Encoding: 7BIT
X-Mailer: ELM [version 2.3 PL11]

> Dear friend
>
> I am trying to get the version of CMU-TEK that would run on VMS
> V5.5. I read in your message that you posted on the newsgroup
> vms ... cmu-tek that you have installed the version on VAXs.
>
> Can you tell me the site at CMU where I can get this version.
>
> Any help will be greatly appreciated
>

        You can get it at DRYCAS.CLUB.CC.CMU.EDU (FTP anonymous)

        DIRECTORY: [.CMUIP.VMS-V?] where ?= 4 or 5

-----
Aurelio Henrique de Oliveira Ramalho                     aurelio@secom.ufpa.br
Universidade Federal do Para' - SECom                    aurelio@yara.ufpa.br
Systems Manager - UFPa.Br Domain                         aurelio@saci.ufpa.br
-----
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
From: wayne@kean.ucs.mun.ca
Subject: CMUIP066 INSTALLATION GUIDE ? 
Organization: Memorial University. St.John's Nfld, Canada
Date: Mon, 4 Jan 1993 00:49:11 GMT

I have obtained CMUIP066.A thru .D . I have looked thru the savesets
but cannot find the installation guide file.

There is a documentation save set. Do I have to install the product
( or at least the .DOC saveset ) to get the installation guide ?

Will it permit me to install just the doc's if that is the case ?

Your response is appreciated.

Wayne Hann
From: srlnicv@lhn.gns.cri.nz
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: <None>
Date: 25 Dec 92 00:28:00 GMT
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: <None>
From: Jey Kumar <jkumar@fac.cabot.nf.ca>
Date: Mon, 21 Dec 1992 10:26:17 EST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
CC: jkumar@fac.cabot.nf.ca
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

subscribe
From: rudy@moonlight.aero.org (Don Rudy)
Subject: Two Guys and their Vax
Organization: The Aerospace Corporation; El Segundo, CA
Date: Wed, 23 Dec 1992 18:35:00 GMT

Hi,  I'm not sure of the correct "netiquette" for advertising, but since I'm 
not an interested party, I hope its okay.  And I'm not sure this hasn't been
posted already.  But here goes;  I was reading one of the industry rags when I
came across an article which said that TGV will sell Multinet to any CMU-tcp
user for up to 70% off list.  They consider this a migration and the offer is
valid only for 90 days beginning 1 dec.   You can write to them at 
603 MIssion St. 
Santa Cruz, CA 95060  (408) 427-4366

I know this may seem like mutiny to many 'Communally Maintained by Users IP"
followers, but some people might like to know.

---------------------------------------------
donald.rudy@mve.aero.org

"My opinions are my own despite what the Jungians think."
From: aurelio%ufpa.br@bitnet.cc.cmu.edu
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Help me!!!!
Date: 22 Dec 92 14:43:22 GMT
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu
Content-Transfer-Encoding: 7BIT
X-Mailer: ELM [version 2.3 PL11]


        I'm still getting the messages:

        on Sun:

        Access denied


        on Vax:

        %%%%%%%%%%%%%%%%%%%%%  OPCOM ......... %%%%%%%%%%%%%%%%%
        Message from user SYSTEM
        RPC: User 0 (group 1) from host SECOM (192.147.210.1) failed
authentication

        And now ????

-----
Aurelio Henrique de Oliveira Ramalho                     aurelio@secom.ufpa.br
Universidade Federal do Para' - SECom                    aurelio@yara.ufpa.br
Systems Manager - UFPa.Br Domain                         aurelio@saci.ufpa.br
-----

Aurelio Henrique de Oliveira Ramalho                     aurelio@secom.ufpa.br
Universidade Federal do Para' - SECom                    aurelio@yara.ufpa.br
Systems Manager - UFPa.Br Domain                         aurelio@saci.ufpa.br
-----
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: gopher server
From: brian.t.carcich@cuspif.tn.cornell.edu
Date: 23 Dec 1992 13:21:26 EST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu
X-Vms-Original-To: INET%"cmu-openvms-ip@drycas.club.cc.cmu.edu"


ok, i packed up what i have and put it on moe.tn.cornell.edu (128.84.242.72)
in files pub/gopher*.

i don't think it's working yet so you may want to also get the files
pub/inet_cmutil* which is the socket package i am using.

-brian
From: jkumar@fac.cabot.nf.ca (Jey Kumar)
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: VMS, PCs, Kermit & Bootp...HELPPPP!
Date: 21 Dec 92 20:25:55 GMT
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu


We are running CMU TCP on a VAX/VMS system. We have PCs with ethernet
boards at our local campus and the 4 remote campus connected via remote
ethernet bridges.  All these PCs telnet to this VAX using Kermit 3.11
( which has built-in telnet ).

Many times pc users copy the kermit files from their pc around to other
machines. One of the files they copy is mskermit.ini that has the tcp
address of the person's pc. When that file is copied, the receiving machine
also gets the tcp address of the other machine. And on it goes. Sometimes
a whole lab of pc's gets the same tcp address. The network dies a slow
death.

My question is as follows:
1)"Is there a way to prevent a pc from accessing the network
   if there is already a pc on the network at that moment with the same tcp
   address as the one attempting access?" and,
2)"Is there a way to dynamically assign the pc with an IP address from
   the VAX running VMS and CMU TCP"

We know that Kermit 3.11 and higher on the PC will work with the BOOTP
protocol.  Is there a BOOTP server solution that will run on a VAX running
VMS and CMU TCP?  As this would be ideal.

Any help would be greatly appreciated.
Thank you and Merry Christmas,

--------------------------------------------------------------------------
Jey Kumarasingam	CA*Net  jkumar@fac.cabot.nf.ca
Cabot College
St. John's, NF
--------------------------------------------------------------------------
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: Name resolver difficulties with CMUTEK
From: "Jonathan E. Hardis" <hardis@garnet.nist.gov>
Date: Wed, 23 Dec 1992 11:05:23 EST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
CC: hardis@garnet.nist.gov
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

> Normally the name resolver works fine.  Once in a while (and somewhat
> spuriously) if I try to resolve a name which I know doesn't exist,
> eg by misspelling part of the node name, I get back an error "maximum
> referral limit exceeded" and then the UDP port for the name resolver
> closes itself.  I can do an IPNCP NAMRES START to get things working
> again, but the name resolver seems even more fragile after that and
> may cease to function after the next bad name.  The process named
> NAMRES is still around even if the name resolver itself no longer
> seems to work.

In the oldies but goodies department:

	There are some problems in the NAMRES program, but for the most
part they are fixed in 6.6.5-A.  There are also a few things you can do
to make NAMRES run more reliabily:

	First, make sure MAXBUF is greater than 2400.  Fortunately, this
parameter can be adjusted while the system is running.

	Second, include the Internet root servers in NAMRES.CONFIG:

DOMAIN_SERVER:.:kava.nisc.sri.gov.:192.33.33.24:53
DOMAIN_SERVER:.:AOS.BRL.MIL.:192.5.25.82:53
DOMAIN_SERVER:.:C.NYSER.NET.:192.33.4.12:53
DOMAIN_SERVER:.:TERP.UMD.EDU.:128.8.10.90:53
DOMAIN_SERVER:.:NS.NASA.GOV.:192.52.195.10:53
DOMAIN_SERVER:.:NIC.NORDU.EDU.:192.36.148.17:53
DOMAIN_SERVER:.:ns.nic.ddn.mil.:192.112.36.4:53

	Third, add these lines to your NAMRES.CONFIG:

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

	Fourth, if NAMRES goes out to lunch, you can kill it via the following
command:

IPNCP>NAMRES EXIT

	and restart it via a little command file like this:

$	 RUN 			 SYS$SYSTEM:NAMRES.EXE	/NOACCOUNTNG	-
	/NOAUTHORIZE		/QUEUE_LIMIT=100 	/DUMP		-
	/BUFFER_LIMIT=65535	/IO_BUFFERED=65535	/PRIORITY=6	-
	/IO_DIRECT=32767	/AST_LIMIT=200		/DETACHED	-
	/PRIVILEGES=(CMKRNL,SYSPRV)			/UIC=[1,4]	-
	/MAXIMUM_WORKING_SET=3000					-
	/PAGE_FILE=80000	-
	/process_name=NAMRES
$	exit



-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!"
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re: Gopher server
From: Henny Bekker <henny.bekker@cc.ruu.nl>
Date: Wed, 23 Dec 1992 01:45:36 +0100
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

In vmsnet.networks.tcp-ip.cmu-tek you write:

>yes, i did it once, it was very slow though.  i could package up what i have
>if anyone is interested.  Also, i don't know if it had all the fnality it
>was supposed to, but i was just making the cmu socket side work.
>
Hello, could you send it to me (in VMS-shar format) or make it available by
anonymous FTP..

Cheers, Henny

---------------------------------------------------------------------------
E-Mail: Henny.Bekker@cc.ruu.nl      INTERNET      ! Disclaimer:
        ruusur::henny               DECnet        !    The main obstacle to
        henny@hutruu50              EARN/BITnet   !    progress is not
        012911028100::henny         PSI           !    ignorance, but the
Voice:  (+31) (30) 536971                         !    illusion of knowledge
X400:   G=Henny;S=Bekker;OU=cc;O=ruu;PRMD=surf;ADMD=400net;C=nl     o
Paper:  H.J.Bekker, University of Utrecht, Computer Centre      _  /- _
        Po Box 80011, 3508 TA  Utrecht  Nederland              (_) > (_)
----------------------------------------------------------------------------
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: looking for a Gopher server
From: System Manager -- UCD Geology <waterstraat@garnet.ucdavis.edu>
Date: Tue, 22 Dec 1992 09:58:58 PST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
CC: waterstraat@garnet.ucdavis.edu
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

Greetings,

Just wondering if any one out there has adapted a Gopher server to work
with CMU-OpenVMS/IP? Thought I'd ask before embarking on the project
myself.

Thank you for your attention.

--
Paul Waterstraat       Internet: waterstraat@geology.ucdavis.edu
Department of Geology  BITNET:   epwaters@ucdavis
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Name resolver difficulties with CMUTEK
From: system@talvax.physics.mcmaster.ca
Date: Tue, 22 Dec 1992 20:04:49 EST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

Hi,

I'm running CMUTEK 6.6-5 with MX 3.1c on VMS 5.4-2 on a MicroVAX 3100.
Normally the name resolver works fine.  Once in a while (and somewhat
spuriously) if I try to resolve a name which I know doesn't exist,
eg by misspelling part of the node name, I get back an error "maximum
referral limit exceeded" and then the UDP port for the name resolver
closes itself.  I can do an IPNCP NAMRES START to get things working
again, but the name resolver seems even more fragile after that and
may cease to function after the next bad name.  The process named
NAMRES is still around even if the name resolver itself no longer
seems to work.

So far the only pattern I've been able to establish is that the re-
solver works for three to five days after an @IP_STARTUP with a clean
message queue, then craps out.  If I clear the message queue and do
a NAMRES START, it may crash on the next bad name.  If I do another
@IP_STARTUP, it's good for another few days.

Any suggestions?  I've set it up by the book with the suggested values
for SYSGEN parameters and everything else is default.

Cheers....G. Hackman, system@talvax.physics.mcmaster.ca
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: FTP server
From: Ed Bates <ebates@vms1.cc.uop.edu>
Date: Mon, 21 Dec 1992 09:13:59 PST
Reply-To: ebates@uop.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
Resent-Date: Mon, 21 Dec 1992 09:13:59 PST
X-MX-Warning: Warning -- Invalid "Resent-From" header.
Resent-From: @andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu
Resent-Message-ID: <9212211718.AA10956@depot.cis.ksu.edu>
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu
Resent-Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu

On Mon, 21 Dec 92 09:54:36 CDT, johnson@magic.meridiantc.com writes:
>We observe that using FTP mget from clients with different file naming
>conventions from VMS doesn't work the way we would like.  For example,
>mget *.* using NCSA Telnet/FTP from an MS-DOS system gives you filenames
>like a.c1, b.c4, c.c2 derived from names a.c;1, b.c;4, and c.c;2 respectively.
>Using mget *.* from Windows/NT flat out fails, when the client is unable
>to open a local file with a ";" in the name.  Are there any clever ways
>to avoid these problems?  Currently we first run the FTP client on VMS
>to push the files to a Sun, and then transfer to the actual target system.

What we've found is that most systems cannot handle VMS version numbers.
However, CMU??? handles them favorably.  My suggestion is to log onto
the VMS host and FTP using mputs.

-- Ed

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Edwin J. (Ed) Bates		VAX Administrator/Postmaster	. .  _   _
 Technical Support Specialist	Internet:  ebates@uop.edu	| | / \ | \
 Office of Computing Services	AppleLink: U1441		| | | | |_/
 University of the Pacific	Telephone: (209) 946-2251	| | | | |
 Stockton, CA  95211		Fax:       (209) 946-2898	\_/ \_/ |


%MAIL-W-NOFNCYQTE, no fancy quote or joke found in signature file
Newsgroups: vmsnet.networks.tcp-ip.ucx
From: houseman@Turing.ORG (Carl Houseman)
Subject: Re: UCX SMTP problems
Organization: The Turing Project, Public Access Internet Host
Date: Tue, 22 Dec 1992 17:25:18 GMT

In article <1992Dec22.095640.4741@spcvxb.spc.edu> terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes:
>  There are patches available from CSC for FTP, SNMP, SMTP, LPR, and some
>other things. With the patches it's a lot better.

Not necessarily.  Even with the 2nd FTP patch, FTP won't transfer STREAM_LF
binary files correctly.  On a Unix client, copy a file to a UCX NFS server.
Now FTP it in binary back to the client and compare.  This has supposedly
been escalated to our local office & UCX Engineering.

>	Terry Kennedy		Operations Manager, Academic Computing
>	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
>	terry@spcvxa.spc.edu	+1 201 915 9381

Carl Houseman
GENICOM Engineering
houseman@turing.org
From: ccdarg@dct.ac.uk (Alan Greig)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Re: UCX SMTP problems
Date: 22 Dec 92 10:19:12 GMT
Organization: Dundee Institute of Technology

In article <1992Dec21.194307.4732@spcvxb.spc.edu>, terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes:
> In article <1992Dec21.153357.2222@ccsvax.sfasu.edu>, system@ccsvax.sfasu.edu writes:
>> I have checked for a patch on DSNLink without success.  Any information would
>> be appreciated.
> 
>   For some reason, the DSIN/DSNlink folks who handle UCX don't write any
> databse articles, nor do they announce patch kits. You should place a
> voice call and ask for the complete set of patches. If you think this pol-
> icy is a disservice to customers such as yourself, you might want to men-
> tion that as well.

From my own experience, UCX 2 is positively dangerous as shipped. I checked
DSN before installing and found nothing critical. Installed it and came
in the following day to find 500,000 blocks eaten up on the system
disk and the SMTP symbiont with 18 hours of cpu time. The patch already existed
to fix this but nowhere was it officially documented.

As for the lpr/lpd stuff. Well I find 60 odd lines of output on a hard copy
console a bit much every time someone prints a file and short of turning
off OPCOM logging of printer class you can't stop it. DEC's response is that
this will be fixed in a future release.

Another gotcha happens if you start the UCX stuff up from an account other
than SYSTEM. It appears to work but incoming ftp tend to fall over
with some obscure (and incorrectly spelled) OPCOM message regarding
protection violation; of what it doesn't say.

BTW, what's the command that turns on translation of Internet number
to Internet name in commands such as show users? I'm sure I saw it
but have forgotten now. 

Did this product undergo *any* field testing I wonder? I find it impossible
to believe it did (at least in shipped form).

-- 
Alan Greig                            Janet: Alan@UK.AC.DUNDEE-TECH
Dundee Institute of Technology	   Internet: Alan@DCT.AC.UK
Tel: (0382) 308810                 Int: +44 382 308810
              -- There is only one true conspiracy --
From: system@ccsvax.sfasu.edu
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: UCX SMTP problems
Date: 21 Dec 92 15:33:57 CST
Organization: Stephen F. Austin State University

I am trying to set up Eudora to work with UCX and IUPOP3.  The pop
client/server retrieval works very well, but when Eudora tries to send mail
via SMTP, I get the following exchange:

------------------------------------------------------------------------------- 
Eudora attempts to send a  "Mail From:<user_name@sfaadm.sfasu.edu>"

                           and then reports

There has been an error transferring your mail, I said:
    MAIL FROM:<user_name@sfaadm.sfasu.edu>

and then the SMTP server said:

  501 Syntax error in parameters or arguments

-------------------------------------------------------------------------------

I can simulate this error if I telnet to sfaadm on port 25 and place a space
between "Mail From:" and "<user_name@sfaadm.sfasu.edu>".  If I type it with no
spaces, the transaction completes without generating an error.  My local
network guru advises me that either form is legal.  Is this a bug in UCX SMTP?
I have checked for a patch on DSNLink without success.  Any information would
be appreciated.

George Schoenemann
Programmer/Analyst - Systems Group
Stephen F. Austin State University
Nacogdoches, TX 75961
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Re: UCX SMTP problems
Date: 22 Dec 92 00:43:07 GMT
Organization: St. Peter's College, US

In article <1992Dec21.153357.2222@ccsvax.sfasu.edu>, system@ccsvax.sfasu.edu writes:
> I have checked for a patch on DSNLink without success.  Any information would
> be appreciated.

  For some reason, the DSIN/DSNlink folks who handle UCX don't write any
databse articles, nor do they announce patch kits. You should place a
voice call and ask for the complete set of patches. If you think this pol-
icy is a disservice to customers such as yourself, you might want to men-
tion that as well.

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381