HDTenEightyP/NetNews huggingface dataset:
From: drewo@dcatlas.dot.gov (Andrew R. Orndorff)
Subject: FAQ for this list/group?
Organization: U.S Dept. of Transportation
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 15 Oct 1992 12:45:25 GMT


	I'd like to obtain more information on the CMU-TEK TCP/IP
software and have been looking for some kind of FAQ for this list/group,
but have not been able to find one.

	Where might I locate this kind of information? And if there is
no FAQ, then where might I obtain detailed information on the software
and how to obtain the software?

	Thanks for the help.

	Andrew Orndorff

	NHTSA Data Center

	Internet:	dcatlas!zeus.dot.gov!drewo@uunet.uu.net
	UUCP:		uunet!dcatlas!zeus.dot.gov!drewo
From: dean@rdcalr.realdec.com (Dean S. Banfield)
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Multiple IP addresses and SLIP
Date: 15 Oct 92 12:47:55 GMT
Reply-To: "Dean S. Banfield" <DEAN@RDCALR.REALDEC.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: Pegasus Mail v2.3 (R2).

Hi,

We are using CMUTEK 6.6-1 on our MVAX 3100 at VMS 5.4-2.  I'm happily
functional on my Ethernet, with an IP address for my MVAX within my
local sub-net.  Along comes another organization which would like
connectivity to our MVAX.

We have settled on a SLIP connection, which is poorly documented in
the Joy of TEK, but I think I've got the basic idea of how to set it
up.  The questions are:

    Should I assign an additional IP address to the SLIP device link?

    If yes, what does it mean to have two IP addresses on the MVAX?

    How does TCP/IP traffic find its way from my Ethernet across the
    SLIP link?  Does the MVAX serve as a 'GATEWAY'?

A brief primer on SLIP + Ethernet configuration would be much
appreciated.  Please include any details about routing and
nameservers.  I'm not running the TEK nameserver, just a vanilla UNIX
one elsewhere on my Ethernet.


Thanks for any assistance in advance.

-Dean
Dean Banfield
Real Decisions Corp         Voice: 203.656.1500
22 Thorndal Circle            FAX: 203.656.1659
Darien, CT 06820            Email: dean@rdcalr.realdec.com
From: miller@tgv.com
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: FTP - sending many files
Date: 8 Oct 92 18:41:12 GMT
Reply-To: <MILLER@tgv.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>
CC: CMU-TEK-TCP+@andrew.cmu.edu
Mail-System-Version: <MultiNet-MM(327)+TOPSLIB(156)@TGV.COM>


>This is a problem inside the IPACP.  Essentially when a connection closes
>it keeps it open for 1 minute before finally killing it.

This is *NOT* a problem in the IPACP.  The TCP RFC states that you must
keep the connection available for reconnection for two times the
maximum segment lifetime (2*MSL).  I would have loved to have removed
that restriction but I didn't want to violate the specs.

The solution is to remove the limit on the number of connections allowed.
I did that at one point, but I disabled the code because I didn't trust it.

-bruce
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: FTP - sending many files
From: "John Clement-Rice U. (713)527-8101x2037" <clement@physics.rice.edu>
Date: Fri, 09 Oct 1992 12:39:14 CDT
Reply-To: "John Clement-Rice U. (713)527-8101x2037"
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>
CC: clement@physics.rice.edu

>   Would the connection limit also apply to a CMU-TEK VAX system
>_receiving_ a large number of small files?

Essentially when FTP sends many files it opens a connection for each file.
Since there is a delay in finally closing the connection, the total number
of connections increases with each small file, until the connection limit
is reached.

At present the only solution is to limit the number of transfers or increase
the connection limit.  It will be possible to decrease somewhat
the time that the connection is kept up, in a future release.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
John M. Clement		Hepnet:		UTSPAN::RIPHYS::CLEMENT
PO Box 1892		Internet:	CLEMENT@PHYSICS.RICE.EDU
Rice University		Bitnet:		CLEMENT@RICEVM1
Houston, Tx. 77251	BellTel:	(713)527-8181 x2037
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: generation of abundant sys$error and sys$output files
From: "Bryan G. Peterson" <peterson@physc1.byu.edu>
Date: Mon, 12 Oct 1992 15:34 MDT
Reply-To: "Bryan G. Peterson" <PETERSON@PHYSC1.BYU.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>
X-Envelope-To: cmu-tek-tcp@cmutek.cc.cmu.edu
X-Vms-To: IN%"cmu-tek-tcp@cmutek.cc.cmu.edu"

I am currently running CMU-TEK TCP/IP 6.6-5 on VMS 5.5-1.  For a long time I
have been getting a collection of files named SYS$OUTPUT. and SYS$ERROR. in
SYS$MANAGER and SYS$SYSTEM.  These files seem to proliferate at an exteremly
variable rate and the two most recent ones are generally currently open with
the IPACP as the owner process.  The system with the most activity is now up
to version 18000 (give or take a few) and over the weekend these things
had proliferated to the point that it caused a header full error on the
system disk.  It appears to me that this is a bug since these files are all
completely empty (but they each still take up a header block).  Is there a
way to shut off these files?  Or at least to slow down the rate of production?

Any hints will be greatly appreciated.

Bryan Peterson (peterson@physc1.byu.edu)
Brigham Young University, Department of Physics and Astronomy
Provo, UT  84602
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: FTP - sending many files
From: henrym@sacusr.mp.usbr.gov
Date: Thu, 8 Oct 1992 20:31:18 PDT
Reply-To: HENRYM@SACUSR.MP.USBR.GOV
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-Original-To: INET%"cmu-tek-tcp@cmutek.cc.cmu.edu"


Bruce,

|>This is a problem inside the IPACP.  Essentially when a connection closes
|>it keeps it open for 1 minute before finally killing it.
|
|This is *NOT* a problem in the IPACP.  The TCP RFC states that you must
|keep the connection available for reconnection for two times the
|maximum segment lifetime (2*MSL).  I would have loved to have removed
|that restriction but I didn't want to violate the specs.
|
	There is a minor problem in the code.  I tracked it down this
morning during a bout with insomnia.  (hackers block).  After the connection
graduates from the TIME-WAIT state to the "INACTIVE" state, it waits
again for (MSL / 2)!  Not sure if that was a typo in  the code or not.
I did not track down the transition state for TIME-WAIT though.

	The RFC's suggests that you can play with the timeout, but at the risk
of losing functionality with other TCP's.
|The solution is to remove the limit on the number of connections allowed.
|I did that at one point, but I disabled the code because I didn't trust it.
|
	That is the ideal solution, but I'm afraid I've broken it, sorta.
Many sites were seeing problems with excessive memory fragmentation causing
crashes due to quota exceeded or insufficient virtual memory.  I got around
this by pre-allocating the memory required for each connection during IPACP
initialization.  This is going to put a limit on the number of active
connections one can have, but I'll try to uncomment your code and bang on
it.  Ideally, I guess IPACP should block, not bomb, when it needs more
memory and can't get it right away.  It should know in it's little heart
that memory will be available shortly.  This should be totally fixed, one
way or another, by 7.0.

-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: CMU/TEK-IP AND NOVELL LAN WORKPLACE FOR DOS
From: lawren01@vax.kvcc.edu
Date: Tue, 13 Oct 1992 11:55:15 EDT
Reply-To: lawren01@vax.kvcc.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>

Kalamazoo Valley Community College is experiencing difficulty establishing
communication between our MicroVax running Ver. 6.6 CMU/Tek-IP and our LAN
running Ver 4.01 Novell Lan Workplace for DOS.  We are hoping that some site
that has been successful in doing this would be willing to share knowledge
of same.  Novell tech support not familiar with CMU/Tek-IP.  Or is there a
site that runs CMU/Tek-IP that would allow us to try to connect to them
directly from our LAN to aid diagnosis of problem.
Thanks...C.A. Lawrence, KVCC Computer Center
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: FTP - sending many files
From: "John Clement-Rice U. (713)527-8101x2037" <clement@physics.rice.edu>
Date: Wed, 07 Oct 1992 10:45:04 CDT
Reply-To: "John Clement-Rice U. (713)527-8101x2037"
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>
CC: clement@physics.rice.edu

>When I attempt to send many (more than about 30) files from a uVAX II to a
>Sparc IPC running SunOS 4.1.2, I observe that the first 30 or so transfers
>are OK and then FTP on the VAX/VMS system reports
>
>425 Can't build data connection: Connection refused.
>%FTP-E-CANT_OPEN_DATA, Can't open data connection.
>
>IPNCP NETSTAT shows lots of open connections.  Clearly the connections
>built for each file transfer aren't being torn down expeditiously.  In a
>few minutes they time out and I can transfer another 30 files.  Any
>suggestions?  Thanks.
>
>Ken Johnson
>Meridian Technology Corporation

This is a problem inside the IPACP.  Essentially when a connection closes
it keeps it open for 1 minute before finally killing it.  If you transfer
a bunch of small files you can easily open more connections than CMU is
configured to handle.

The "ultimate" solution is to modify the ACP to shorten or eliminate this wait.

A workaround is to either:
1.	Increase the number of allowed connections.
	Add to INET$CONFIG where nnn is the max number of connections:
	Variable:MAX_CONN:nnn

2.	Transfer less than 30 files, wait 1 minute and then transfer more.

	John Clement


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
John M. Clement		Hepnet:		UTSPAN::RIPHYS::CLEMENT
PO Box 1892		Internet:	CLEMENT@PHYSICS.RICE.EDU
Rice University		Bitnet:		CLEMENT@RICEVM1
Houston, Tx. 77251	BellTel:	(713)527-8181 x2037
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: please remove from mailing list
From: Kjeld Hvatum <postmaster@draper.com>
Date: 13 Oct 1992 13:39:41 -0400 (EDT)
Reply-To: Kjeld Hvatum <postmaster@draper.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-Vms-To: IN%"cmu-tek-tcp@cmutek.cc.cmu.edu"
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT

Please remove <cmutcp@draper.com> from your mailing list.  We now
get the Usenet with the vmsnet.networks.tcp-ip.cmu-tek newsgroup.
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: re:Help: problem in configuring UCX 1.3 
From: ASM@ECLX.PSU.EDU (Aravind Melligeri)
Date: Thu, 15 Oct 92 02:08:19 GMT
Organization: Penn State Engineering Computer Lab
X-News-Reader: VMS NEWS 1.24

The previous problem i had posted has been fixed. 
The problem was with the default route setting. I don't know when it was
changed. I belive it was changed when i stopped dynamic routing during
reconfigruation of ucx.
Newsgroups: vmsnet.networks.tcp-ip.ucx,comp.os.vms
From: ORAKEL@rzmain.rz.uni-ulm.de (Framstag)
Subject: Re: 8 bit won't work on ucx-telnet
Organization: University of Ulm, Germany
Date: Sun, 11 Oct 1992 21:59:40 GMT
X-Copyright1: Fuer Veroeffentlichungen AUSSERHALB des Newssystemes gelten MEINE Geschaeftsbedingungen.
X-Copyright2: Nichtbeachtung wird in der Regel zivil- und strafrechtliche Folgen nach sich ziehen.
X-News-Reader: VMS NEWS 1.24

In <1992Oct11.214327.22201@wega.rz.uni-ulm.de> ORAKEL@rzmain.rz.uni-ulm.de writes:

> ucx3.0 telnet  doesn't have this bug.

ooops.. should be ucx 1.3
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Terminal type problems
From: oursler@kenyon.edu
Date: 15 Oct 92 11:34:01 -0500
Organization: Kenyon College

Hullo,

	This is a stab in the dark, but I'm having a problem
	with UCX and QVTNET (telnet for windows package).

	Whenever, I connect to a VAX running UCX (1.3 or 2.0) the
	terminal type negotiation results in setting the terminal
	to a VT102 rather than a VT220.  This does not occur when I
	connect to VAX hosts running Multinet or Unix hosts of
	various flavors.

	The problem is either with UCX or QVTNET, but the QVTNET folks
	don't seem to recognize there's a problem with their product.
	So I'm trying to attack the problem from the UCX end.  If
	Multinet can manage it, why can't UCX?

	Is there anything I can do about this?  It so happens that the
	host I connect to most often is a VAX running UCX and I am
	tired of changing the term type and then doing a SET TERM /INQ
	every time I log in.

	Thanks for any help anyone can provide.

							- Miles -

	-------------------------------
	Miles Oursler
	Manager of Networks and Systems
	Kenyon College
	oursler@kenyon.edu
	-------------------------------

Newsgroups: vmsnet.networks.tcp-ip.ucx
From: zorn@gumby.dsd.trw.com (Marc Zorn)
Subject: Having trouble opening window from SUN to UCX 2.0
Organization: TRW INC., Redondo Beach CA
Distribution: ca
Date: Sat, 17 Oct 1992 01:38:18 GMT


I just installed UCX v2.0 and I'm trying to port a window from my Sun Sparc 2. 
I have had limited success setting up the X service on the VAX, but I think I'm
missing a file or some vital piece of information, and I'm not sure where to
get it.  I've set up the proxies and security fields and such for DEC windows 
Motif, and I can fake out the UCX 'SET SERVICE' command by specifying a newly
created account and command procedure. When I do that I get and XIO error on
the Sun instead of simply 'Can't open display' error.  I feel I'm frightfully
close, but I don't know what to do next.  Does anyone have any ideas? 

			thanks in advance,
			Marc
From: gareth@lucifer.latrobe.edu.au (Chief Smeghead)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: %SYSTEM-F-PROTOCOL, network protocol error
Date: 8 Oct 92 00:45:50 GMT
Organization: La Trobe University

PMDF Guru's.

I have this anoying problem with the UCX/PMDF server. I have searched
the UCX manuals and the PMDF manuals but cannot find the answer.

Upon shutting down my VAX's (VAXstation 3100's) I get the following OPCOM
message...

%%%%%%%%%%%  OPCOM   5-OCT-1992 09:00:33.60  %%%%%%%%%%%
Message from user SYSTEM on ATR1
UCX/PMDF server, UCX_SMTPD exit with: %SYSTEM-F-PROTOCOL, network protocol error


Software:
         VMS V5.4
         UCX V1.3A
         PMDF V4.1

Any help appreciated.

Many thanks,

Gareth.


-- 
gareth@lucifer.latrobe.edu.au
Newsgroups: vmsnet.networks.tcp-ip.ucx
From: MyTH@ucx.lkg.dec.com (M. T. Hollinger)
Subject: Re: Proxy setup for UCX LPD
Organization: Digital Equipment Corporation, Littleton, MA
Date: Fri, 9 Oct 1992 04:16:42 GMT

In the referenced article, mzagsaa@v4.cgu.mcc.ac.uk (Tony Arnold) writes:
>I've configured a local printer using UCX$LPRSETUP and entered
>into  /etc/printcap of a Unix machine and then tried doing an lpr. I get
>an error message saying User arnold not authorised to print on this
>host, followed by a system message saying network object not known.

The quickest way to avoid proxy problems is to simply turn off LPD proxy
checking (by disabling the APPLICATION_PROXY flag on the LPD service).
That should get you up and running.  If you then want to re-enable proxy
checking, note that the remote username specified in a proxy must match
the local username (except for case).  This is necessary because unlike
the RSH protocol, the LPD protocol does not include a mechanism for
specifying a username on the target machine.

I consider this restriction (matching usernames) unfortunate and am
looking for ways to eliminate it.  In an update to the LPD facility now
available from the Customer Support Centers (which, incidentally, also
contains a number of bug fixes), I have added a second proxy check: if
no proxy is found where the local username matches the remote one, LPD
will now look for a proxy into the UCX_LPD account.  This way, you at
least don't have to create dummy VMS accounts to match all the remote
usernames, and wildcard proxies into UCX_LPD will work.

        - MyTH
Newsgroups: vmsnet.networks.tcp-ip.ucx
From: randy@kean.ucs.mun.ca
Subject: Re: Wanted: TN3270 for VAX
Organization: Memorial University. St.John's Nfld, Canada
Date: Thu, 8 Oct 1992 18:59:12 GMT

In article <cslee.34.718044479@pds.nchu.edu.tw>, cslee@pds.nchu.edu.tw (Lee Chee Siong) writes:
> Hi everone,
>   Is there any anonymous ftp site that I can get tn3270 packages for
> VAX machine? I had try to search by archie but fail.
>   Thanks for your response.

For some strange reason DEC choose to not work on such things as TN3270
for UCX 2.0 instead saying (at last DECUS) that it would follow around
December (I believe) but since UCX 2.0 was late and buggy it may be some
time yet before we see it. 

Its a bit of a bother sometimes to force a VMS user to use an Ultrix box
in order to use TN3270 but that's what I've had to do for the past several
YEARS while awaiting a UCX TN3270. Oh, there might be one from one of the
other TCP vendors but since UCX is free for me ...

             
          
Newsgroups: vmsnet.networks.tcp-ip.ucx
From: DAVISM@kcgl1.eng.ohio-state.edu (Michael T. Davis)
Subject: Re: Terminal identification to remote host
Organization: The Ohio State University
Date: Wed, 7 Oct 1992 11:43:59 GMT


In article <15927@umd5.umd.edu>, dmatthews@uap.umd.edu writes:

>When TELNETing to certain unix systems, our system tells theirs that our
>terminal is a "dec-vt200"; this string is not recognized by the remote host,
>with varying consequences.  The remote systems would have been happy with
>"vt200". I'm running UCX 2.0 on VMS 5.4-3. The response is generated by UCX,
>depending on SET TERMINAL/DEVICE=. If I change DEVICE to VT100, for example,
>it says it's a "dec-vt100".  In UCX 1.3 this problem did not arise. I find
>nothing in the manuals, at least in the indexes. Anyone else had this
>experience?  Any suggestions?  Respond by email; I'll post a summary if it
>seems to be of any interest.

	I just made a modification to my U*IX login scripts to strip off the
"dec-" from $term and/or $TERM before invoking tset.  In csh, the variable
editing looks something like this:

if ( $?term ) then
    set dec_term = `echo "$term" | tr "-" " "`
    if ( "$dec_term[1]" == "dec" ) then
	set term = "$dec_term[2]"
    endif
    unset dec_term
endif

							Mike

>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
--
 Internet: davism@KCGL1.eng.ohio-state.edu |
            -or- DAVISM+@osu.edu           |   These Thoughts, They Be Mine
   BITNET: DAVISM+@OHSTMAIL.BITNET         |
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Unsupported UCX patches (was Re: Terminal identification to remote host
Date: 8 Oct 92 01:51:59 GMT
Organization: St. Peter's College, US

In article <1992Oct7.085537.10547@ccsun.strath.ac.uk>, craa79@ccsun.strath.ac.uk ("R.B.Rodger") writes:
> The long term solution is to add entries for dec-vt100 etc to the termcap 
> database on the unix host. I find it rather surprising that the UCX developers
> claim that this is the "correct" behaviour, yet I have still not found a
> Unix system (including the latest release of Ultrix) which supports this...

  Yup. I ran into something similar where UCX's `rlogin' truncates usernames
to 8 characters before passing them along to the other side of the connection.
Rather obnoxious, actually - if it's thought to be useful, it ought to be a
command line switch (like /lowercase). I guess they've not seen any Unix boxes
that allow usernames > 8 characters.

  If you're having this problem as well, the following (for UCX V2.0 as found
on the September '92 ConDist) might prove useful:

$ patch ucx$rlogin.exe
%PATCH-I-NOLCL, image does not contain local symbols
%PATCH-I-NOGBL, some or all global symbols not accessible
PATCH>repl/inst 4a1e
OLD>  "clrb b^8(r4)"
OLD>  exit
NEW>  "nop"
NEW>  "nop"
NEW>  "nop"
NEW>  exit
old:	00004A1E:  CLRB    B^08(R4)
new:	00004A1E:  NOP     
new:	00004A1F:  NOP     
new:	00004A20:  NOP     
PATCH>repl/instr 4a40
OLD>  "clrb b^8(r4)"
OLD>  exit
NEW>  "nop"
NEW>  "nop"
NEW>  "nop"
NEW>  exit
old:	00004A40:  CLRB    B^08(R4)
new:	00004A40:  NOP     
new:	00004A41:  NOP     
new:	00004A42:  NOP     
PATCH>set eco 97
PATCH>update
%PATCH-I-WRTFIL, updating image file USER6:[SYSPROG.TERRY.JUNK]UCX$RLOGIN.EXE;2
PATCH>exit

  Likewise, if you're distressed that `traceroute' times are off by an order
of magnitude, you might want the following:

$ patch traceroute.exe
%PATCH-I-NOGBL, some or all global symbols not accessible
PATCH>repl/inst 3a43
OLD>  "pushl r3"
OLD>  exit
NEW>  "mull2 #0a,r3"
NEW>  "pushl r3"
NEW>  exit
old:	00003A43:  PUSHL   R3
old:	00003A45:  PUSHAL  W^02C0(R9)
new:	00003A43:  JMP     L^PAA
new:	PAA:  MULL2   #0A,R3
new:	00011003:  PUSHL   R3
new:	00011005:  PUSHAL  W^02C0(R9)
new:	00011009:  JMP     L^00003A49
PATCH>set eco 97
PATCH>update
%PATCH-I-WRTFIL, updating image file USER6:[SYSPROG.TERRY.JUNK]TRACEROUTE.EXE;3
PATCH>exit

  REMEMBER: These patches are not supported by Digital. Replace the original
images before applying DEC patches / updates. Contents may have settled dur-
ing shipment. Void where inhibited. Etc. 8-)

	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
From: karin@zach.fit.edu (Karin Nicholson)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Re: %UCX-E-TELNET_GETHST, Error in getting host name
Summary: karin@zach.fit.edu
Date: 13 Oct 92 20:49:00 GMT
Followup-To: vmsnet.networks.tcp-ip.ucx
Distribution: usa
Organization: Florida Institute of Technology, Melbourne USA

In article <4322@winnie.fit.edu> karin@zach.fit.edu (Karin Nicholson) writes:
>
>What have I not done.  It's probably blatantly obvious to all of you, but
>I am not making any progress no matter how much I read TFM.  Please, give
>me a clue!  Thanks alot, in advance.
>
It turns out that the bind server address was incorrectly defined.  Please
forgive the oversight and accept my humblest apologies, please.....

-- 

 .-.|     |    |     | |    /------------------\   Karin Nicholson
 |  |-..-.|/.-.|-..-.|*|/  < karin@zach.fit.edu >  VAX Sys Mgr @ Florida Tech 
 `-'| |`-'|\`-'| |`-'|||\   \------------------/   Florida Space Coast LUG Chair