HDTenEightyP/NetNews huggingface dataset:
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Dropping Future Segs
From: Don Walter <walter@uvax2.sebac.jsu.edu>
Date: Mon, 23 Nov 1992 19:49:46 CST
Reply-To: walter@sebac.jsu.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>

>        I last saw this behavior with CMU-TEK 6.3.  It was tracked to its
>lair by Chuck Lane and fixed long ago.  If the same thing has recurred, it
>should show in the output of:

>$ IPNCP NETSTAT /STAT

>as an unduly large number of "Future Segments" being dropped.

>        The workaround was to increase the value of Variable:FQ_MAX in
>INTERNET.CONFIG.  My recollection is that a value of 10 or 15 worked well.
>(YMMV) Just keep jacking it up until the number of dropped future segments
>decreases to something "reasonable".

     What if every "Future Segment" is dropped?  I tried upping FQ_MAX
to 50 and still every Future Seg showed up as a dropped seg.

     We're running VMS 5.3-1 and CMU-TEK 6.6-5.  Our internet link
is via a Vitalink bridge (56K baud).  Performance does not seem to be
any better for short files than long ones.  Generally we get 2000-4000
bytes per second. Is this normal?  Should I just leave FQ_MAX at 5?

Don Walter
walter@sebac.jsu.edu
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: mailing list
From: 4chris@gsf.fi
Date: Mon, 23 Nov 1992 10:15:50 -0500
Reply-To: 4chris@gsf.fi
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>


	To whom it may concern!

As a proud and "satisfied " owner of your extremely fine product, (in case
you don't know what i'm referring to it's the CMU TCP/IP V6.6) I'm hereby
sending a request to you good folks at CMU to include me in your mailing list.
Since I'm every now and then running into trouble (beeing a novice) with this
product of yours, I thought it might be of great help if my mailbox would
start filling up with useful hints and suggestions.


	Thanks in advance

	Christian Buss


	        GEOLOGICAL SURVEY of FINLAND
	        Christian Buss
	        Systen Manager
	        4chris@otavax.gsf.fi
		christian.buss@rudge.gsf.fi
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: puts to anonymous ftp
From: "Stanley J. McCaslin" <mccaslin@psccs1.peru.edu>
Date: Sat, 21 Nov 1992 08:43:44 EST
Reply-To: "Stanley J. McCaslin" <mccaslin@PSCCS1.PERU.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>

I have just set up an anonymous ftp account on our VAX, VMS 5.4 using
CMU-TEK 6.6.  We would like to be able to accept files sent to it, but
I can't figure out what rights to give it.  All directories in the
tree have w:rwe protection, but I still get access not allowed messages
when I try to put a file to it.  Does anonymous ftp allow puts, and if
so what do I need to do to enable them?

Stanley J. McCaslin			Inet: mccaslin@psccs1.peru.edu
Assistant Professor, Computer Science	Phone:402/872-2208
Peru State College, Peru, Nebraska      Home: 402/872-7595
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: BINARY mode FTP
From: henrym@sacusr.mp.usbr.gov
Date: Sun, 15 Nov 1992 18:40:26 PST
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%"SYNFUL@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
|
	I must point out that the majority of the new features in FTP were
provided by John Clement at Rice University.  I have made some minor fixes
as well.


-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: patches
From: thomas.placzek@fzg.mw.tu-muenchen.dbp.de
Date: Sun, 15 Nov 92 18:14:26 +0100
Reply-To: Thomas.Placzek@fzg.mw.tu-muenchen.dbp.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>
X400-Received: by /PRMD=TU-MUENCHEN/ADMD=DBP/C=DE/ ; Relayed ; Sun, 15 Nov 92
X400-Received: by mta MTALRZTU ; Relayed ; Sun, 15 Nov 92 18:14:27 +0100
P1-Message-Id: DE*DBP*TU-MUENCHEN; 921115180711791-MTALRZTU
Ua-Content-Id: 921115180711791-
Autoforwarded: FALSE

Does anyone know where to obtain patches and new versions of CMUTEK? Some
time ago there has been an ANONYMOUS server at hal.cc.cmu.edu but this one
has been disabled. It seems that I have trouble with the NAMRES process and
I suppose it might be based on a bugged version of the 6.6-NAMRES.
Thanks

Thomas Placzek, Technical University Munich/Germany
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
From: drewo@dcatlas.dot.gov (Andrew R. Orndorff)
Subject: sorry
Organization: U.S Dept. of Transportation
X-Newsreader: TIN [version 1.1 PL6]
Date: Fri, 20 Nov 1992 12:09:17 GMT


	Sorry, my mistake - a previous posting from me regarding
problems with an LPD print client was related to TGV's Multinet
product, not CMU-TEK.

	I apologize profusely - waiting to receive our CMU-TEK
distribution in the mail :)

	Andrew Orndorff
	NHTSA Data Center
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re : Solution to name service problem
From: "Kenneth J. Hoover" <ken@psuedvax.psu.edu>
Date: Thu, 19 Nov 1992 07:51:51 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>

"Szymon Sokol" <SZYMON@ucinvl.uci.agh.edu.pl> writes in response to my message:

>> 	Anyway, just for you bug followers, I could provoke a permanent death
>> of CMUTEK's ability to resolve names (under 6.6-5) by asking for an address
>> for a bogus name (i.e. xxxxx.yyy.zzz).  Any request made to resolve a
>> name after a non-resolvable request will fail as an unknown host.  I had to
>> stop the network services (ipncp netexit) and restart them to be able to
>> resolve names again.
>
>We have exactly the same sort of problems. I have 6.6-5A, Telnet works,
>the first incorrect name destroys NAMRES (and in addition, NFS does not work
>since I upgraded 6.6-5 to 6.6-5A...). So, you succeeded to fix the NAMRES
>problem? I will try to do the MAXREF=100 and see if it helps... What are your
>other settings in NAMRES.CONFIG ?

  I think what really cured it was adding as many backup name servers as I
could find addresses for here on campus.  It appears that NAMRES doesn't like
to take "no" for an answer.  :-)

  I would like to know, however, what CMUTEK does when it has a list of name
servers in the NAMRES$CONFIG file.  Which does it contact first?  Is there a
way to specify the order of attempts to contact?

  The other variables that I am using are:

  NS_RETRANS -- 3
  REFMAX     -- 100
  TIMEOUT    -- 5
  RECURSE    -- 1

  I should note that the only one that I have changed since I noticed this
problem is that I increased TIMEOUT from 3 to 5 (which didn't help on its own).

>Regards,
>                                   Szymon Sokol
>                                   Network Manager


						- Ken Hoover
--
Kenneth J. Hoover               | Warm fuzzy word for the day : Peace
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: install
From: "KIRK::MOOTS" <moots%kirk.decnet@hsdp1.brooks.af.mil>
Date: 20 Nov 92 09:03:00 CST
Reply-To: "KIRK::MOOTS" <MOOTS%KIRK.decnet@hsdp1.brooks.af.mil>
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>

I just install TEKIP verison 6.5 and the documentation did not get installed.
During that phase I got the following message:
"The docs have been left in the tekip065.d saveset."
"Dunno exactly where to put them..."

Is there a way to install them without a complete reinstall or do I have
a problem?

Other than that I look good.   Thanks for a fine product.

Basil Moots
Armstrong Laboratory
Brooks AFB TX
(210) 536 - 3811
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: puts to anonymous ftp
From: "John Clement-Rice U. (713)527-8101x2037" <clement@physics.rice.edu>
Date: Sat, 21 Nov 1992 14:17:16 CST
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

In general anonymous FTP does not allow puts.  In particular CMU will not
allow puts to the anonymous FTP account.  At present there is no way to
disable this restriction.

To have an account that allows puts, you must define a separate guest account,
with appropriate password etc.

	John Clement
	Rice University

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
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: Problem with LPD and DEC PS print symbiont parameters
From: Bill Norton <norton@eisner.decus.org>
Date: 20 Nov 1992 16:50:14 -0500 (EST)
Reply-To: Bill Norton <NORTON@Eisner.DECUS.Org>
Organization: Digital Equipment Computer Users Society
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-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

We're having trouble with LPD printing files from a Silicon Graphics Indigo
to a DEC LN03R being run by CPS$SMB V4.1.

Is there an easy way to have LPD *not* put the file list and remote node name
into parameters 7 and 8 when queueing the job to the DEC printer?  That would
disable the display of the file list and node name by subsequent lpq's, but
CPS$SMB seems to care about every little parameter it gets now.
From: leesw@logica.co.uk
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Desparately seeking FTP docs
Date: 23 Nov 92 16:45:37 GMT

Where can I fina description of the steps necessary to configure the FTP server
to provide anonymous login to a restricted set of directories?

I did see that someone mentioned an archive on nic.ddn.mil: I've been
rooting around there but I can't see anything likely.  Apologies if I have
missed something obvious.

Thanks

William
 
---------------------------------------------------
William Lees,  Logica International Ltd,  London UK
Internet: leesw@logica.co.uk  CompuServe: 75300,250
From: ken@psuedvax.psu.edu (Kenneth J. Hoover)
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Resolution to my name service woes...
Date: 18 Nov 92 17:53:09 GMT
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>


	Well, I don't know exactly which one of these solved the problem,
but together I have a stable name resolution mechanism (at least for the last
several days).

	I did the following:

	1)  Get v6.6-5A and install it.  This did cure the telnet hang problem,
	   but didn't, on its own, cure the name resolution problem.

	2)  I added three backup name servers to my NAMRES.CONFIG file.  This
	   seems to be the thing that did the trick.  However, it's not clear
	   in the manual if there is a priority structure for name servers
	   (i.e. which to try first, second, third, etc).

	3)  I increased REFMAX to 100 and TIMEOUT to 5.

	4)  I found out that the name server was acting goofy during SOME of the
	    times that I needed it.

	And now it works fine.  Figures.  :-(

	Anyway, just for you bug followers, I could provoke a permanent death
of CMUTEK's ability to resolve names (under 6.6-5) by asking for an address for
a bogus name (i.e. xxxxx.yyy.zzz).  Any request made to resolve a name after a
non-resolvable request will fail as an unknown host.  I had to stop the
network services (ipncp netexit) and restart them to be able to resolve names
again.

						- Ken Hoover
--
Kenneth J. Hoover               | Warm fuzzy word for the day : Peace
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: Re:  puts to anonymous ftp
From: <miller@tgv.com>
Date: Sat, 21 Nov 1992 14:20:40 -0800 (PST)
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(331)+TOPSLIB(156)@TGV.COM>


>In general anonymous FTP does not allow puts.  In particular CMU will not
>allow puts to the anonymous FTP account.  At present there is no way to
>disable this restriction.

This is a fairly arbitrary restriction, if I recall the code correctly.
It's a one-line change to remove it.  The problem is in making sure that
the anonymous account is restricted to it's own subtree and can't write
to just any world writeable directory/file.  I think there's already
code in there to do that too.

-bruce
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: SHRing an IP device
From: Marc Shannon <synful@drycas.club.cc.cmu.edu>
Date: Fri, 20 Nov 1992 17:52 EST
Reply-To: Marc Shannon <SYNFUL@DRYCAS.CLUB.CC.CMU.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-Vms-To: IN%"cmu-tek-tcp@cmutek.cc.cmu.edu"

For reasons that will become clear soon, I can't say much about future releases
of CMU-Tek, but I can say that there may be a new function for the IPACP which
permits channels to be "reassigned" from one process to another.

It should be noted, however, that SHARE privilege will be required to $ASSIGN
to the existing IP device.  This is a simple security matter as you wouldn't
want Joe Average User popping in on your TELNET session.

--Marc
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
From: adelman@tgv.com (Kenneth Adelman)
Subject: Re: LPD print client help
Summary: wrong newsgroup
News-Software: VAX/VMS VNEWS 1.41    
Organization: TGV, Incorporated (Santa Cruz, CA, USA)
X-Lunar-Date: 0 days, 22 hours, 8 minutes since the last quarter of the moon
Date: Fri, 20 Nov 1992 04:58:00 GMT

In article <1992Nov19.154221.19644@dcatlas.dot.gov>, drewo@dcatlas.dot.gov (Andrew R. Orndorff) writes...
>
>	We're using the LPD client to provide print services from our
>cluster to printers available via a Novell server running Novell's NFS
>product. So far, things have been working fairly well, with the following
>exceptions:

    Wrong newsgroup; you've got MultiNet, not CMU/TEK. The newsgroup
vmsnet.networks.tcp-ip.multinet was created to discuss MultiNet.

>	a) We're able to turn off burst pages, trailers, and flag
>	pages on the Novell side of the connection, but do not
>	seem to be able to do so from the VMS side.
>
>	We've tried altering the way in which the queues are
>	initialized, tried 'setting' the '/separate' and
>	'/default' options after the queue has been initialized,
>	and have even looked at the USER_LPD_CLIENT.C code in
>	the [.Examples] directory, but to no avail.
>
>	Is there some straightfoward way that we can enable the
>	control of burst/flag/trailers from the VMS side - or
>	turn them off altogether?

    Are you getting VMS format pages or something generated by
Novell server? If VMS format pages, then you need to turn them
off by the way you invoke $ PRINT (/NOFLAG/NOBURST) or by changing
the /DEFAULT properties of the VMS queue. The VMS manuals should
be of help here -- the MultiNet print symbiont uses the standard
VMS symbiont parts to format the job and just spools the resulting
lines of text over LPD.

    If you're getting a Novell-generated page that could be suppressed
by the use of a UNIX print option, you could use the USER_LPD_CLIENT.C
module to map some equivalent VMS print qualifier into the same UNIX
option.

>	b) Similary, I understand that LPD relies on the print server
>	performing all of the filtering and other print options, but
>	are there any plans to extend the MULTINET LPD client services
>	beyond their current capabilities?

    Actually, there is some filtering done by VMS prior to spooling
over the network. There are no plans to add other filtering
functionality.

								Ken
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re:  Request for technical assistance in CMU/Tek programming
From: "tom Allebrandi - Inland Steel Research Labs"
Date: Fri, 20 Nov 92 10:47:45 CST
Reply-To: "Tom Allebrandi - Inland Steel Research Labs"
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@cmutek.cc.cmu.edu"
X-Vms-Mail-Cc: ALLEBRANDI

> When you perform the NET$OPEN, you don't get a new name of the device.
> The only device name that you have is "IP0", which is used by all
> TCP/UDP/etc connections.

No, when you open IP0, VMS creates a new IPsomething device on the fly
and return you an assigned channel to the freshly created device. This
is the template (cloned) device concept that is used for mailboxes,
decnet remote terminals, lat terminals, etc.

Note that you can find out the device name from the channel number
using SYS$getdvi(). (Or, for this purpose, LIB$getdvi().)


	#include	descrip

	#define	NULL	((void*) 0)

	static	$DESCRIPTOR(ip0,"IP0:");

	main()
	{
		struct dsc$descriptor_s	device_name =
					{0,DSC$K_DTYPE_T,DSC$K_CLASS_D,NULL};
		long	status;
		short	channel;

	/*
	 * Open a channel to IP
	 */
	status=SYS$assign(&ip0,&channel,0,NULL);

	/*
	 * Get the device name
	 */
	{
	long item = DVI$_TT_PHYDEVNAM;
	status=LIB$getdvi(&item,&channel,NULL,NULL,&device_name,NULL);
	}

	... etc ...

	/*
	 * Be nice and clean up
	 */
	if (device_name.dsc$a_pointer != NULL)
		STR$free1_dx(&device_name);
	}

Now having said that, I just did a "show device ip/full" on my system
and I don't see any of the devices being shown as sharable. And, in fact

	$ show dev ip

	Device                  Device           Error
	 Name                   Status           Count
	IP0:                    Mounted              0
	IP91:                   Mounted              0
	$ write sys$output f$getdvi("ip91","shr")
	FALSE
	$

So,  you may still be in trouble. I guess you could pop into kernel
mode and poke the SHR bit in the UCB....


--- 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: rick%qucdnee.bitnet@bitnet.cc.cmu.edu (Rick Pim)
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: 6.6-5A?
Date: 18 Nov 92 19:38:00 GMT
Reply-To: Rick Pim <RICK%QUCDNEE.BITNET@BITNET.CC.CMU.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-Vms-To: IN%"cmu-tek-tcp%cmutek.cc.cmu.edu@CARNEGIE.BITNET"
Content-Transfer-Encoding: 7BIT


> are  "Kenneth J. Hoover" <ken%psuedvax.psu.edu@CARNEGIE.BITNET>

>Subject: Resolution to my name service woes...

>        I did the following:
>
>        1)  Get v6.6-5A and install it.  This did cure the telnet hang problem,
>           but didn't, on its own, cure the name resolution problem.

  i asked this a while back and got no answer: does this mean that 6.6-5A
is "real"? i checked the cmu ftp site recently and didn't see it. i'm
running 6.5, which is fairly robust, and i've been dithering about
installing 6.6 until it looks at least as solid: what IS the status with
6.6-5A?

rp
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rick Pim                                            bitnet:rick@qucdnee
Department of Electrical Engineering         rick@qucdnee.ee.queensu.ca
Queen's University, Kingston                             (613) 545-6772
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"We're aimed the wrong way to be going home, Gumby."
"Home...?  We're on an express elevator to HECK!"
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Please remove my old address from this list
From: Ed Bates <ebates@vms1.cc.uop.edu>
Date: Mon, 23 Nov 1992 08:47:08 PST
Reply-To: ebates@uop.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>

We have replaced our old VAX with a new one, and I did
not remove my old address from the list before the old
computer was dismantled.

Please remove the entry for:

	{ebates|system}@madvax.uop.edu

Thank you in advance (and sorry for taking up the
bandwidth for this message to everyone).

-- 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.cmu-tek
Subject: RE: install
From: "Jonathan E. Hardis" <hardis@garnet.nist.gov>
Date: 20 Nov 1992 14:24:03 -0500 (EST)
Reply-To: "Jonathan E. Hardis" <hardis@garnet.nist.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>
CC: cmu-tek-tcp@cmutek.cc.cmu.edu, hardis@garnet.nist.gov
Content-Transfer-Encoding: 7BIT

> "The docs have been left in the tekip065.d saveset."
> "Dunno exactly where to put them..."
>
> Is there a way to install them without a complete reinstall or do I have
> a problem?

$ COPY tape_drive:TEKIP065.D  disk_drive:
$ BACKUP TEKIP065.D/SAV [.put_it_here]

(or something like that.  See the BACKUP Utility manual for details.)