HDTenEightyP/NetNews huggingface dataset:
From: wayne@kean.ucs.mun.ca
Subject: Re: <None>
Organization: Memorial University. St.John's Nfld, Canada
Date: Sat, 23 Jan 1993 12:52:36 GMT

In article <9301222007.AA07173@charm.gandalf.ca>, <dhuddles@charm.gandalf.ca> writes:
> In vmsnet.networks.tcp-ip.cmu-tek you write:
> 
> 
>>	o  Buy a real TCP/IP package.  I don't want to advertise here, but
>>	   the pre-eminent seller of TCP/IP packages for VMS is offering a
>>	   70% discount to licensed CMUTEK sites through Feb 28.  This will
>>	   resolve many problems and boost performance (measured by file
>>	   transfer rates) by 2000% (20+ times the xfer rate).  I cannot
> 
> Thanks for the insight your message has instilled in me. We too are now
> trying to use this TCP package on a production system and now realise the
> problems that are appearing. Please let me know what package you are suggesting as we are in a "look" mode right now to find a "robust" TCP/IP package
> for our VAX systems.
> 
> David Huddleson
> 
> --
> dhuddles@gandalf.ca   David J. Huddleson   Gandalf Data Ltd., Nepean, Ontario
>                       (613) 723-6500 Days  (613) 822-1315 Otherwise

I too am getting 'killed' with cmu 6.6-5. I am seriously considering moving
to a commercial version of tcp. However, I am reluctant to do so for 
economical reasons, and also because of the success I have had in the
past using cmu's implementation. 

However, I am relying more and more on tcpip as a means of communication
and it is now crucial that it behave properly.

If I could get the 6.6-5 update that corrects the 'hogging' problem,
I would try it first. Otherwise, I suppose the '70%' route is possible.

Is the 6.6-5a fix available anywhere ?

Wayne Hann
wayne@fac.cabot.nf.ca
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: Vms 5.5 and Cmutek 6.6 ??
From: "Henry W. Miller" <henrym@sacto.mp.usbr.gov>
Date: Tue, 26 Jan 1993 05:00: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: henrym@sacto.mp.usbr.gov
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

tnuug@alyssa.rsinet.tn (TN.U.U.G) writes:

|Hello,
|we have used CMUTEK V6.6 package with VMS 5.4. It works but not very well
|because sometimes some process dies. But now we have installed VMS 5.5,
|CMUTEK V6.6 still works with UNIX machines but doesn't work with PC's .
|I don't know why ? can you explain me the bug please ?
|Is there any solution ?
|your help will be very appreciated.

	Can you be a little more specific?  What portion does not work PC's?

-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@sacto.mp.usbr.gov"

"I've fallen, and I can't get up!"
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re: Help me please!!!
From: Tom Allebrandi - Inland Steel Research Labs <allebrandi@inland.com>
Date: Mon, 25 Jan 93 00:24:36 CST
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-Mail-To: CMU-TCP
X-Vms-Mail-Cc: ALLEBRANDI

The reason that you do this:

        DEF/SYSTEM/TRANS=(TERMINAL,CONCEAL)/EXEC UTIL SYS$SYSDEVICE:[UTIL]

is because you cannot do this:

	192.147.210.23:sys$sysdevice:[util] /util nfs rw 0 0

The "$" is likely getting in your way. Since you exported that path as
/util, you should mount it that way

	192.147.210.23:/util /util nfs rw 0 0

--- Tom
Tom Allebrandi             | Mail guru   - DECUS UUCP Development Team
Inland Steel Research Labs | NFS grunt   - CMU/Tek-IP
East Chicago, IN           | Chairperson - VMSnet Working Group, DECUS VAX SIG
219 399 6306               | Internet:  allebrandi@inland.com
DECUServe: allebrandi      | UUCP:      ...!uunet!inland!allebrandi
From: judson@girtab.usc.edu (Tom Judson)
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: complete version of CMU-IP...
Date: 26 Jan 1993 13:29:48 -0800
Organization: University of Southern California, Los Angeles, CA
Distribution: world
NNTP-Posting-Host: girtab.usc.edu

In article <torppa.728078157@mits> torppa@mits.mdata.fi (Jarkko Torppa) writes:
>I'm trying to find complete CMU-Open VMS/IP preferably by ftp. I already
>know SACWMS.MP.USBR.GOV but the set is far from complete there.
>
>tcpip+@andrew.cmu.edu said that until 15 of january I could have ftp:d it
>from one of their machines, after that I should contact decus.
>--
> Jarkko Torppa |        torppa@mits.mdata.fi |  Uh huh 

I also need a "complete" version.  Is it available from anywhere else
besides decus?  If decus is controlling it, why don't they have an ftp
site?

I have the executable files from SACWMS.MP.USBR.GOV, could someone mail
me the installation instructions and any documentation that they have.
I would like to give this a try as soon as possible.

Thanks,
-TJ Judson
judson@usc.edu
judson@hac2arpa.hac.com
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re: <None>
From: "Tim McKee, 803-366-2620" <mckeetr@cvse.cortex.prospect.com>
Date: Sat, 23 Jan 1993 21:40:30 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

The 6.6-5A version is available via ftp from SACUSR.MP.USBR.GOV
or SACWMS.MP.USBR.GOV in directory [.TEKIP] saveset TEKIP0665A.SAVE.

I am using it with no problems under vms 5.5-2 (other than TALK
giving a strange PASCAL string truncation error).

tim
================================================================================
Timothy R. McKee                        |  Senior Consultant - VAX/VMS Internals
Cortex Corp. - SouthEast Field Office   |       mckeetr@cvse.cortex.prospect.com
Phone: (803) 366-2620                   |                    FAX: (803) 366-6517
================================================================================
From: newsmgr@logica.co.uk
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: IPACP hogging CPU
Date: 22 Jan 93 14:09:48 GMT

Since I posted my message 'IPACP goes wild' a week ago, nobody has come back
with any ideas as to what the problem might be, or how to start diagnosing
it - BUT I have had mailings from two other people who are encountering
the same thing.

So if you have ANY light to shed on why IPACP should suddenly start hogging
99.999% of the CPU for large periods of time, or ANY ideas about how to start
diagnosing the problem, there are at least three of us who would be very glad
to hear from you.

Thanks for listening.

William
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
From: rudy@avila.aero.org (Don Rudy)
Subject: LPR queueing problem
Organization: The Aerospace Corporation; El Segundo, CA
Date: Thu, 21 Jan 1993 17:27:27 GMT

Hi,
  I have, what I hope is a relatively simple problem.  I'm trying to print from
a unix box (SVR4, I think) to a vax running VMS5.4-2 with CMUIP6.6-5a ("open
cmuip with the ETHER patch).  On the vax I have running the script printer
software CPS v4.0. (whew!)  Anyway the problem is that the lpr daemon sends some
info (the node and file name) and the lpd symbiont on the vax puts that info
into the /PARAM qualifier.  Unfortunately, the script printer software will
only allow keyword=value types of parameters.  If the keyword is not one it
recognizes, it won't print the file.  My question is: Is there someway, on
either machine to suppress this "feature"?  The name of the file is already
present as is the host and username (in the /NOTE) so its really superfluous
information.  Or does someone have a work around?  I'd like to be able to use 
the scriptprinter software because of the "data_type=(ansi | postscript | tek)"
feature, and therefore don't really want to create a "vanilla" queue.   Any
suggestions? Thanks in advance.						Don


Generic printer queue SYS$PRINT
    /GENERIC=(CPS) /OWNER=[SYSTEM] /PROTECTION=(S:E,O:D,G:R,W:W)
    /SCHEDULE=(NOSIZE)

  Jobname         Username     Entry  Blocks  Status
  -------         --------     -----  ------  ------
  test.txt        rudy           548       1  Pending (check execution queues)
    Submitted 21-JAN-1993 08:37 /FORM=DEFAULT /NOTE="rudy on seal"
    /PARAM=("DATA_TYPE=ANSI","","","","","test.txt","","seal") /PRIORITY=100
    File: _DUA0:[VENDOR.CMUIP.SYSMGR.SPOOL]DFA004SEAL.;1 /DELETE

-----------------------------
donald.rudy@mve.aero.org
-----------------------------
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re: IPACP quotas
From: "Henry W. Miller" <henrym@sacto.mp.usbr.gov>
Date: Tue, 26 Jan 1993 03:28:45 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: henrym@sacto.mp.usbr.gov
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

FRASER_H@eismv3.dofasco.ca (Hugh Fraser) writes:

|In article <289@moretonp.demon.co.uk> Peter S Moreton <peter@moretonp.demon.co.uk> writes:
|>Hey, you say that the IPACP starts from the SYSTEM account and it
|>has EXQUOTA. Bear in mind that EXQUOTA allows an account to exceed
|>diskquota limits and has nothing to do with normal process quotas
|>such as pgflquo etc. If your problem is a virtual memory thing, I
|>would double PGFLQUO, double VIRTUALPAGECNT in Modparams.dat and
|>AUTOGEN the system. (maybe extend pagefile.sys also, but autogen should
|>do this).
|
|Thank's for reminding me of that. I'll try adjusting the sysgen parameters.
|We already have VIRTUALPAGECNT quite high (120000) for other reasons, so I'll
|play with PGFLQUO.
|
	AUTOGEN should attempt to resize the PAGE and SWAP files UNLESS you
have the parameters in MODPARAMS.DAT:

pagefile=0
swapfile=0

	Better yet, in IP_STARTUP.COM, adjust the value in the "/BUFFER_LIMIT="
parameter to a value between 120000-130000.  This should solve the problem
without having to adjust other system parameters.  This is caused by the way
the memory allocation routines were rewritten for 6.6, to avoid excessive
memory fragmentation and crashing.  This issue needs to be readdressed and the
memory allocation routines will be redesigned for the next major release.

-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@sacto.mp.usbr.gov"

"I've fallen, and I can't get up!"
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: More telnet problems
From: "Henry W. Miller" <henrym@sacto.mp.usbr.gov>
Date: Tue, 26 Jan 1993 02:59:13 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: henrym@sacto.mp.usbr.gov
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

dhuddles@gandalf.ca (David Huddleson) writes:

|We are running CMU-TEK 6.6-3 and MX 3.1C on a VAX 6510. We have not yet
|announced the inbound telnet service to our user community yet, as I have
|seen similar problems to those described by Ian Leonard. There are two
|major symptoms (a) lockups or terminal "hung", user must break out and
|(2) users cannot change their VMS password, message is "illegal password
|syntax" (some sort of telnet parity problem??)
|
|Sorry, more info... (VMS is A5.5-1)
|

David,
	I don't know if A5.5-a has any bearing on it, and MX has no effect
on TELNET, but what the heck are you doing with 6.6-3?  That's been obsolete
for a year, and I think that this version was the version with a very bad
TELNET server bug.  I was attempting to fix the server to work with one vendor's
brain-damaged (more so than usual) UNIX variant, and fixed it so it did.
Unfortunately, I broke just about the rest of the universe.  This is the reason
why very few CMUTEK'ers have my home phone number...

|
|I see some mentions of version 6.6-5A in the few messages that I was able
|to access. Can someone comment any further... should I upgrade?
|
	6.6-5A fixes a multitude of problems, and should fix this TELNET
problem.  If not, let us know.  Believe me, you certainly be better off with
6.6-5A then with 6.6-3.

|I also have problems with LPR, but later.....
|
	John Clement has overhauled LPR and we'll have a kit up soon...

-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@sacto.mp.usbr.gov"

"I've fallen, and I can't get up!"
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: CMU-OpenVMS-IP status
From: <roes@phcoms.seri.philips.nl>
Date: Mon, 25 Jan 93 18:34:26 MET
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>
Return-Path: roes@phcoms.seri.philips.nl
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu
X-Mailer: ELM [version 2.3 PL11]


   Hello CMU-ers

I've been following the discussion on CMU-OpenVMS-IP for quite a while and
I am getting a bit worried. I know that people out there are working hard to
improve and enhance the code and by no means I want to offend them.

A lot of problems are solved and available via the 6.6-5A saveset from
Henry Miller (SACWMS.MP.USBR.GOV). But these patches don't seem to make
it into an 'official' version. I've also seen messages of new functionality
under its way like the R* utilities, a new and better version of NFS and
other things. But when will these enhancements be available?
A third thing I notice is that the same questions keep coming back partly
because the bugs are still in the official release but what also seems to be
lacking is a FAQ.
Look at what we've achieved so far since CMU 'put the product in the public
domain'. WE CANNOT EVEN DECIDE UPON A NEW NAME!!!

My company has CMU-OpenVMS-IP installed on more then 20 sites. Our group is
acting as distribution point and internal support contact point. We promote
it for non-critical installations (for critical applications we recommend
commercially available products which provide full support). So we are
VERY interested in the future of the product. But unless somethings changes
I'm afraid we may have to advise our 'customers' to look at alternatives.

What I think that this product needs is a central contact. Someone
responsible for coordination of a FAQ, software bundling and possibly
replying to mails. If nobody will accept this responsibility I'm afraid the
CMU-OpenVMS-IP product will soon die. Is that what we want???

I'm I volunteering for this job? No, no, no. There are a number of reasons
why I cannot do it, the most important being that I'm located in Europe and
that would cause enormous delays in responses to the mailing list since the
vast majority of the mails is USA/Canada originated. Of
course I can list a lot of other obstructions like 'too busy', 'no bliss
compiler/knowledge, 'I'm incompetent', etc..

The important thing here is that I feel that somebody needs to accept this
task. And it needs to be done within a reasonable time. The first thing that
person may do is, decide upon is the new name (what a privilege!)

Volunteers? Any other thoughts how to stimulate this product? Or am I just
plain wrong and is everything ok? Reactions please!

     Aloys Roes
--
Aloys Roes,                           <>    Email: roes@seri.philips.nl
Philips SERI-MPN,                     /\    SERI : roes:phcoms
P.O.Box 218, Bldg VN-513,             \/    Tel. : + 31 (0)40 784 899
5600 MD  Eindhoven, The Netherlands.  <>    Fax. : + 31 (0)40 782 900
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: RE: 6.6-5A has problems too
From: "Henry W. Miller" <henrym@sacto.mp.usbr.gov>
Date: Thu, 28 Jan 1993 02: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: henrym@sacto.mp.usbr.gov
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

Chris Higgins - System Administrator <chris@csvax1.ucc.ie> writes:

|Just a vote for CMU.
|I've had 6.6-5A running here for quite a while, and I've had NO problems with
|MX that I've had to blame CMU for..  ( there was one MAJOR problem, but that
|was with a change in configuration of my main mail router that was not supposed
|to affect me..... but did, and no one there told me about the changes....)
|
|6.6-5A has been running for quite a while with two crashes, both of which were
|attributable to other system activities... ( A routine I was writing to
|do hostname lookup caused the NAMRES process to die.... Further rewrites of my
|code caused a full crash...)
|I sat down and actually looked at what my code should be doing, and discovered
|loads of errors.... My code sucked... :-)
|Basically what I'm trying to say is that CMU has not died on me, nor caused any
|problems with other applications....
|
	Writing interface routines like that can be interesting.  However, I
would not expect NAMRES to belly up over it.  I'd like to take a look at
your sample code.  It may give a clue as to why NAMRES bellies up from time
to time, although the various NAMRES parameters I've suggested here from
time to time (and which have been suggested to me by numerous folks, and
others I've determined emperically) plus the new NAMRES included with 6.6-5A
have eliminated about 95% of the NAMRES crashes.  NAMRES and IPACP should
protect themselves from, pardon the expression, Chris, but "programmer
stupidity".  No offense meant.  But a routine that does not range check
it's input or perform other validity checks before jumping off into the
unknown is not very robust, like the old example of calling a C string
routine with the destination parameter being NULL.  Nice way to spend half
a day looking at core dumps.

|Welcome back Henry... (I know that you haven't been anywhere.... but I was
|wondering why things were so quiet :-)
|
	I've been lurking in the background.  I've had a lot of various and
sundry issues to take care of in many areas the past couple of months.  But,
as you said, "I'm baaaacckkkk..."

-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@sacto.mp.usbr.gov"

"I've fallen, and I can't get up!"
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
From: dhuddles@gandalf.ca (David Huddleson)
Subject: Re: VERSION 6.6-5 AND.....BUGS!!!
Organization: Gandalf Data Ltd.
Date: Thu, 21 Jan 1993 14:10:48 GMT

It seems that there is more than one of us that wants feedback on
CMU 6.6-5 since we are running previous versions. Could someone please
post up a summary on the value of us moving to that release. Some of
us do rely on others' experiences before we jump in with both feet and
perform upgrades of this type.

Thanks,
David

-- 
dhuddles@gandalf.ca   David J. Huddleson   Gandalf Data Ltd., Nepean, Ontario
                      (613) 723-6500 Days  (613) 822-1315 Otherwise
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Telnet problem
From: <mdelisle@edupac.qc.ca>
Date: Mon, 25 Jan 93 12:05:12 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 would like to know if someone has a fix that I could try regarding
the Telnet delay (I have to typein some characters to see the last part
of the text sent by telnet).

Thanks!

Marc Delisle, Sherbrooke College
(mdelisle@edupac.qc.ca)
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re: More telnet problems
From: <dhuddles@charm.gandalf.ca>
Date: Thu, 28 Jan 93 09:11:48 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

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

>David,
>	I don't know if A5.5-a has any bearing on it, and MX has no effect
>on TELNET, but what the heck are you doing with 6.6-3?  That's been obsolete
>for a year, and I think that this version was the version with a very bad
>TELNET server bug.  I was attempting to fix the server to work with one vendor

Henry,

Thanks for your reply. I will attempt to get 6.6-5a soon. The 6.6-3 was
installed about a year back, but not really in use until about 2 months
ago (hidden from users!). Not having realised about the Newsgroups available
about VMS until recently, I am just now finding that I ought to get off 6.6-3.

Again thanks for the reply,

David
--
dhuddles@gandalf.ca   David J. Huddleson   Gandalf Data Ltd., Nepean, Ontario
                      (613) 723-6500 Days  (613) 822-1315 Otherwise
From: TEWKSBURY@BUDSGA.BU.EDU (Chip Tewksbury)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Re: UCX V2.0 FTP get TT: problem ?
Date: 22 Jan 93 15:34:29 GMT
Organization: BOSTON UNIVERSITY, OFFICE OF INFORMATION TECHNOLOGY
X-News-Reader: VMS NEWS 1.24

In <1993Jan22.094144.1@kean.ucs.mun.ca> randy@kean.ucs.mun.ca writes:

>... 
> Before, 'GET file.ext TT:' was used to preview a file before transferring it
> [in pre-UCX V2.0].  Now, the same command returns %noname-e-nomsg, 
> Message number 030AC082

	Try "FTP> GET file.ext SYS$OUTPUT".

		Chip Tewksbury.
Newsgroups: vmsnet.networks.tcp-ip.ucx
From: randy@kean.ucs.mun.ca
Subject: UCX V2.0 FTP get TT: problem ?
Organization: Memorial University. St.John's Nfld, Canada
Date: Fri, 22 Jan 1993 12:11:44 GMT

I've just upgraded to UCX V2.0 (with patches 904-907) and have noticed
a problem with FTP. 

Before, 'GET file.ext TT:' was used to preview a file before transferring it. 
Now, the same command returns %noname-e-nomsg, Message number 030AC082

Anyone else seen this problem ?
From: mzagsaa@v4.cgu.mcc.ac.uk (Tony Arnold)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Zoning & default gateways in UCX 2.0
Date: 21 Jan 93 14:54:49 GMT
Reply-To: A.C.Arnold@mcc.ac.uk
Organization: Manchester Computing Centre


Has anyone tried configuring a ZONE or alternate/general_purpose gateway
for SMTP under UCX 2.0 (with patches)?

What I want to do is route all mail except that destined for the 
domain mcc.ac.uk via nessie.mcc.ac.uk

I've used the command:

   SET CONFIG SMTP/ZONE=mcc.ac.uk/GATEWAY=ALTERNATE=nessie.mcc.ac.uk

but mail sent to v3.ph.man.ac.uk, gets bounced with NOSUCHNODE error
from SMTP.

I should add that the said machine does exist in the DNS and runs UCX 1.3a,
however, our gateway machine should be able to convert to another
mail protocol that this machine does understand (Coloured Book Software).
It seems a connection is made, the SMTP request is rejected and SMTP then
gives up instead of trying a gateway.

Any help much appreciated.

Tony Arnold.
From: dmatthews@uap.umd.edu
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Re: UCX V2.0 FTP get TT: problem ?
Date: 22 Jan 93 15:26:32 GMT
Reply-To: dmatthews@uap.umd.edu
Organization: IPST, U. of Maryland, College Park

In article <1993Jan22.094144.1@kean.ucs.mun.ca>, randy@kean.ucs.mun.ca writes:
>I've just upgraded to UCX V2.0 (with patches 904-907) and have noticed
>a problem with FTP. 
>
>Before, 'GET file.ext TT:' was used to preview a file before transferring it. 
>Now, the same command returns %noname-e-nomsg, Message number 030AC082
>
>Anyone else seen this problem ?

Yes, it's the result of the patching process; unpatched v2.0 gave no problem 
here.  Unfortunately I can't say which patch created the problem.

Anyone got a fix for this?  This former feature was very convenient.


Dr. David L. Matthews, IPST, Univ. of Maryland, College Park MD 20742-2431 
Telephone  (301)405-4830	Internet   dmatthews@uap.umd.edu
FAX 	   (301)314-9363	NSI/SPAN   UMDUAP::DMATTHEWS