HDTenEightyP/NetNews huggingface dataset:
From: wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke)
Subject: Re: POSIX$SCRATCH world writable?
Organization: Institut f. Arbeitsphysiologie a.d. Uni Dortmund
Date: Mon, 9 Nov 92 07:30:08 GMT

In article <1dee0kINNhpm@usenet.INS.CWRU.Edu> cd382@cleveland.Freenet.Edu (Jim Walker) writes:
>
>In a previous article, brent@uwovax.uwo.ca (Brent Sterner) says:
>
>>   POSIX has installed POSIX$SCRATCH as world writable on my system.
>>
>>a) is this necessary?
>>b) this violates my VMS system managers security sensibility.
>>   Any work-around?  Do you as a POSIX manager accept this?
>
>I as a system manager do not accept any world writable directory.
>In the past we have had problems with people bypassing their disk
>quota by storing the overflow on the system disk where unknown to
>me a software product has created a world writable directory.
>
>I prefer not to enable disk quotas on my system disk.  It's 
>hard enough keeping track of disk quotas on the user disks.
Being a VMS system manager, I do enable disk quota on the system disk
and I give some Accounts (System) unlimited quota. I just don't want to
fill up the disk space of the system disk be used up by users.
Is there a better use of quota than to protect the usability of the
system at all?
>
>Now whenever I install anything I look for world writable files
>and immediately call the manufacturer to ask what will break when
>I protect them properly.
So what does the manufacturer say to the original problem. Is ist 
Don't use VMS-POSIX?
I am quite sure that the functionality of POSIX depends on the world
writability of POSIX$SCRATCH.
-- 
Dipl.-Math. Wilhelm Bernhard Kloke,
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-4600 Dortmund 1, Tel. 0231-1084-257
Newsgroups: vmsnet.vms-posix
From: brent@uwovax.uwo.ca (Brent Sterner)
Subject: Re: POSIX$SCRATCH world writable?
Organization: University of Western Ont, London
Date: Thu, 5 Nov 1992 17:12:50 GMT

In article <1992Nov4.070328.23256@arb-phys.uni-dortmund.de>, wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke) writes:
> In article <1992Nov3.115453.1@uwovax.uwo.ca> brent@uwovax.uwo.ca (Brent Sterner) writes:
>>b) this violates my VMS system managers security sensibility.
>>   Any work-around?  Do you as a POSIX manager accept this?
> I cannot find a reason why this violates security (more than letting
> anything being done on a machine). Files in /usr/tmp are deletable only
> by the creator and root. The blocks allocated are counted in the disk
> quota; therefore the user cannot fill up the disk.

   I had missed the disk quota issue entirely.  Many thanks.  I believe
   this itself resolves my concerns about world writable.

--
Brent Sterner                       Manager, Academic Technical Support
Fast:       <BRENT@uwovax.uwo.ca>   <129.100.2.13>
Telephone:  (519)661-2151 x 6036    Fax:   (519)661-3486
Slow:  Computing & Communications Services, Natural Sciences Building
       The University of Western Ontario, London, Ontario, Canada  N6A 5B7
Newsgroups: vmsnet.vms-posix
From: ORAKEL@rzmain.rz.uni-ulm.de (Framstag)
Subject: Re: strange posix timing bevavior
Organization: University of Ulm, Germany
Date: Sun, 8 Nov 1992 20:14:31 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 <2TN8ZVH@gwdu03.gwdg.de> moeller@gwdgv1.gwdg.de writes:

> If you DEFINE/USER, VAXC I/O will indeed occur; if you DEFINE in supervisor
> mode, I/O to standard output (SYS$OUTPUT) will be re-directed to the
> process-permanent file, which *is* buffered the normal way (typically 8 or
> 16 disk blocks). From the difference in the number of direct I/Os executed,
> the difference in elapsed time can be easily understood.


As a general statement, can one say:

"always use DEFINE SYS$OUTPUT in supervisor-mode than in user-mode (with
 additional DEASSIGN) for C-programs for better performance"
  
Is this correct?


\  Ulli 'Framstag' Horlacher    \    psi%0262450502601::rzmain::orakel  \
 \  Student consultant VAX/VMS and networks   \  orakel@dulruu51.bitnet  \
  \  Rechenzentrum  Universitaet Ulm  Germany  \    orakel@rz.uni-ulm.de  \
   \  "With mainframes you just can do nonsense, with PCs not even that."  \
From: rankin@eql.caltech.edu (Pat Rankin)
Newsgroups: vmsnet.vms-posix
Subject: Re: strange posix timing bevavior
Date: 11 Nov 92 02:58:00 GMT
Organization: California Institute of Technology
NNTP-Posting-Host: eql.caltech.edu
News-Software: VAX/VMS VNEWS 1.41

In article <2TN8ZVH@gwdu03.gwdg.de>, moeller@gwdgv1.gwdg.de writes...
[...]
> I guess this problem is not particular to POSIX:
> 
> The VAXC I/O library has always been famous for doing very inefficient
> I/O to disk, spending 1 I/O per disk block read or written.

     VMS POSIX does not use VAXCRTL at all; it has an entirely separate
C run-time library.  However since the POSIX command itself executes
from the regular VMS environment (from DCL that is), _it_ might be using
VAXCRTL.  POSIX$RUN.EXE is not linked to shareable VAXCRTL, but could be
linked with the object library instead.  The point is moot if it doesn't
use C I/O to write to SYS$OUTPUT.

     How about testing a third case for additional comparison?
 $!test3.com
 $! ignore SYS$OUTPUT
 $ posix posix$bin:uuencode. "test.gif test.gif >test.uue
 $ logout/full
This one would presumeably end up going through the UCX NFS I/O subsystem,
so may be slow too.  On the other hand, NFS probably uses substantial
buffering to cut down on actual I/O.

		Pat Rankin, rankin@eql.caltech.edu
From: cd382@cleveland.Freenet.Edu (Jim Walker)
Newsgroups: vmsnet.vms-posix
Subject: Re: POSIX$SCRATCH world writable?
Date: 6 Nov 1992 18:37:08 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: cd382@cleveland.Freenet.Edu (Jim Walker)
NNTP-Posting-Host: hela.ins.cwru.edu


In a previous article, brent@uwovax.uwo.ca (Brent Sterner) says:

>   POSIX has installed POSIX$SCRATCH as world writable on my system.
>
>a) is this necessary?
>b) this violates my VMS system managers security sensibility.
>   Any work-around?  Do you as a POSIX manager accept this?

I as a system manager do not accept any world writable directory.
In the past we have had problems with people bypassing their disk
quota by storing the overflow on the system disk where unknown to
me a software product has created a world writable directory.

I prefer not to enable disk quotas on my system disk.  It's 
hard enough keeping track of disk quotas on the user disks.

Now whenever I install anything I look for world writable files
and immediately call the manufacturer to ask what will break when
I protect them properly.
From: moeller@gwdgv1.gwdg.de
Newsgroups: vmsnet.vms-posix
Subject: Re: strange posix timing bevavior
Date: 7 Nov 92 03:00:40 GMT
Reply-To: moeller@gwdgv1.gwdg.de
Organization: GWDG Goettingen, F.R.Germany

In article <1992Oct31.003920.17824@wega.rz.uni-ulm.de>, 
ORAKEL@rzmain.rz.uni-ulm.de (Framstag) writes:
>I've found a strange time-behavior in posix 1.1. 
>[...]
>I have two test-programs:
>    $! test1.com
>    $define/user sys$output test.uue
>    $posix posix$bin:uuencode. "test.gif test.gif
>    $logout/full
>and
>    $! test2.com
>    $define sys$output test.uue
>    $posix posix$bin:uuencode. "test.gif test.gif
>    $deass sys$output
>    $logout/full
>[... test1 is *much* slower than test2 ...]

I guess this problem is not particular to POSIX:

The VAXC I/O library has always been famous for doing very inefficient
I/O to disk, spending 1 I/O per disk block read or written.

If you DEFINE/USER, VAXC I/O will indeed occur; if you DEFINE in supervisor
mode, I/O to standard output (SYS$OUTPUT) will be re-directed to the
process-permanent file, which *is* buffered the normal way (typically 8 or
16 disk blocks). From the difference in the number of direct I/Os executed,
the difference in elapsed time can be easily understood.

Wolfgang J. Moeller, GWDG, D-3400 Goettingen, F.R.Germany | Disclaimer ...
PSI%(0262)45050352008::MOELLER      Phone: +49 551 201516 | No claim intended!
Internet: moeller@gwdgv1.dnet.gwdg.de   | This space intentionally left blank.
Xref: sparky vmsnet.networks.tcp-ip.misc:74 vmsnet.misc:990
From: hkb@groucho.cri.dk (Henrik Kim Berle)
Newsgroups: vmsnet.networks.tcp-ip.misc,vmsnet.networks.ucx,vmsnet.misc
Subject: Problems with TCP/IP to DECNET connection
Keywords: TCP/IP,DECNET,SUN,VAX,UCX
Date: 6 Nov 92 09:09:57 GMT
Organization: Computer Resources International A/S

I am developing some programs which communicates between a sun(SUNOS) and 
a vax(VMS), my problem is that my processes which are running on the sun
uses tcp/ip and the processes running on the vax is using decnet, my solution
to this problem was to buy the ultrix connection to the vax and then create
a gateway process on the vax which could read a message from the tcp/ip
domain and route it to a process in decnet domain. This seem to work
until I had about 32 connections and to my big surprise I found that
there is a limit on 32 tcp/ip connections per process. 
Does anybody know of a way to change this or of product which enables 
a process using tcp/ip to communicate with a process using decnet.


Thanks,

Henrik


-- 
+----------------------------------+----------------------------+
|  -  -   Henrik K. Berle           | Email : hkb@spd.cri.dk     |
| / \/ \  CRI A/S                   | Voice : +45 45822100       |
| ------  Bregneroedvej 144         | Fax   : +45 45822620       |
|   ||    DK-3460 Birkeroed         |                            |
| ------  Denmark                   +----------------------------+
|   /\                              | The apple never falls far  |
|  /  \                             | from the tree              |
+-----------------------------------+----------------------------+
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
X-Envelope-to: wintcp-l@ubvm.bitnet
X-VMS-To: in%"wintcp-l@ubvm.bitnet"
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Newsgroups: vmsnet.networks.tcp-ip.wintcp
Date:         Tue, 10 Nov 1992 14:47:48 -0800
From:         Rick Millhollin <RICKM@OREGON.BITNET>
Subject:      How To Shutdown WIN/TCP?

We are having a problem with system shutdown and WIN/TCP.  When up and running,
WIN/TCP processes have files open on the disk where it is installed, which is
actually a shadow set.

$ show device/files sys$netdevice

Files accessed on device DSA62: on 10-NOV-1992 14:29:41.65

Process name      PID     File name
...
enet<->inet     20200121  [WINTCP.V52.OREGON.NETDIST.MISC]ELINKUP.COM;2
enet<->inet     20200121  [WINTCP.V52.COMMON.NETDIST.ETC]ELINK.EXE;1
NAMED           20200122  [WINTCP.V52.OREGON.NETDIST.MISC]NAMEDUP.LOG;98
NAMED           20200122  [WINTCP.V52.COMMON.NETDIST.MISC]NAMEDUP.COM;3
NAMED           20200122  [WINTCP.V52.COMMON.NETDIST.ETC]NAMED.EXE;1
INET_SERVERS    20200123  [WINTCP.V52.COMMON.NETDIST.SERV]SERVER.EXE;2
TALKD           20200124  [WINTCP.V52.COMMON.NETDIST.MISC]TALKDUP.COM;1
TFTP_DAEMON     20200125  [WINTCP.V52.COMMON.NETDIST.SERV]TFTPD.EXE;1
NTP_DAEMON      20200126  [WINTCP.V52.COMMON.NETDIST.MISC]NTPDUP.COM;1
TALKD           20200124  [WINTCP.V52.COMMON.NETDIST.ETC]TALKD.EXE;1
NTP_DAEMON      20200126  [WINTCP.V52.COMMON.NETDIST.SERV]NTPD.EXE;1
NTP_DAEMON      20200126  [WINTCP.V52.COMMON.NETDIST.ETC]NTPD.CONF;2
...

If this system is shut down, the shadow set does not get dismounted properly
because some of these processes do not get stopped so the files do not get
closed.  This causes the shadow set to go into mount verification on the rest of

the cluster, and a shadow merge to take place.

I have put a procedure into SYSHUTDWN.COM to look for the WIN/TCP processes and
STOP them.  However, it appears that frequently enet<->inet holds an
IOC$GL_MUTEX (according to DEC's analysis of a dump we forced) and so can't
stop, thus hanging the shutdown.

What I need is a clean and sure-fire method to shut down WIN/TCP from
SYSHUTDWN.COM.  Is there one?
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: IP device is Offline mounted
From: henrym@sacusr.mp.usbr.gov
Date: Sun, 8 Nov 1992 01:22:18 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%"cmu-tek-tcp@cmutek.cc.cmu.edu"


Richard,

|Hi netters,
|I'm a poor lost Unix hacker trying to figure out something which is VERY
|VMSish. We're running CMU-Tek 6.6-5A (fresh off the tape) on VMS 5.4.
|When we installed CME-Tek the first time it ran for quite a while with no
|problems. Then one day out of the blue (after a reboot) the IP: device went
|into this weird state (Offline mounted) and we couldn't get it back. After
|lots of fiddling we just re-installed the whole thing and lo and behold it
|all worked fine again ... for a while. One fine day we shut down CMU-Tek
|and it went back into said weird state. The other symptom we've noted is
|that the IPCACP process hangs around forever and can't be STOPped and even
|reboots (with no subsequent IP startup) don't get rid of it.
|
	IPCACP has nothing to do with CMUTEK TCP, despite the similarity
of it's name to IPACP.  IPCACP is the daemon for DEC's DTM process, and will
be started up automatically under VMS 5.4 UNLESS the system logical
SYS$DECDTM_INHIBIT is defined as YES.

|So what am I doing wrong? Be gentle, I'm VMS illiterate but I do have a
|VMS system manager available for abuse :-). What does an installation do
|get this thing out of it's comatose state? I'd like to revive it without
|reinstalling it every time. I need a resolution quick or we're going to
|have to go to something (eeegad!) more expensive.
|
	Unless you REALLY have the process IPACP (and NAMRES) running, then
the CMUTEK package has not been started up, and it's very possible that
the IP device would be shown in an offline state.

-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: CMUTEK
From: <joe@igor.tamri.com>
Date: Wed, 11 Nov 92 09:37:49 -0800
Reply-To: <joe@igor.tamri.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>

I was looking for a site of CMU-TEK FAQ and/or installation hints.
Is there a server/site/human available for this? Any anonymous ftp
sites?

thanks
joe carlson UCSF
joe@igor.tamri.com  (or)
jcarlsn@itsa.ucsf.edu

Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
From: madison@tgv.com (Matt Madison)
Subject: Re: <None>
Reply-To: madison@tgv.com
Organization: The Foundation for Dinner Peas
Date: Mon, 9 Nov 1992 19:37:34 GMT

In article <009635E7.8D56EC80.11229@lhn.gns.cri.nz>, srlnicv@lhn.gns.cri.nz writes:
>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.

That's because it's hard-wired into the code that ANONYMOUS is allowed
read access only.  It was done mainly to provide some additional security
when setting up anonymous FTP access.

>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).

You could set up a separate account for uploads.

-Matt
--
Matthew Madison | madison@tgv.com    | +1 408 427 4366
TGV, Inc.       | 603 Mission Street | Santa Cruz, CA 95060 USA
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Long FTP file transfers slow down almost to stop
From: levine%fidler.decnet@sunman.chinalake.navy.mil
Date: Fri, 13 Nov 92 10:57:31 PST
Reply-To: LEVINE%FIDLER.decnet@sunman.chinalake.navy.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 have FTP exhibiting the same problem in 2 different systems
that I manage.
	Configuration 1
		Local isolated ethernet with only the following

		VAX 8800 VMS 5.4 CMU-TEK 6.6_5(patched)
		Silicon Graphics 4D/280 (1),4D/240(2),PI running IRIX 4.0.4
		SUN sparcstation II
		assorted DECSERVER 100/200's
		NCD-14c X-term (1)

	Configuration 2
		Corporate network running DECNET,TCP/IP,Appletalk,etc
		connecting via a SUN gateway to the internet

		uVAX II VMS 5.4 CMU-TEK 6.6_5(patched)

		Hundreds of various UNIX cpus,MAC's,VMS,etc scattered
		over a large navy base.

Symptom:
	When doing an FTP of a large file (6-8k bytes min), the first few
k bytes come accross fast enough, but then the rest just trickle in. Monitoring
with SET HASH ON shows after the initial burst of 4-6 markers, nothing comes
in for 10's of seconds, with maybe 1-4 markers and another long wait for more
to come accross. Large files (like CMUTEKU5066.A_Z) eventually abort

426-Connection closed; transfer aborted.
426 Abort

those that are able to complete give transfer rates of 100-200 bytes/sec.

Is there some setup parameter or SYSGEN paramter that needs to be tweekd, or
any hints as to where to look?

Michael N. LeVine  Naval Air Weapons Station, China Lake, Ca 93555, USA
Internet: levine%fidler.decnet@nwc.navy.mil
(619) 939-2614  avn  437-2614

 "Thirty days hath September, April, June and November. All the rest have
 thirty one except for Gypsy Rose Lee and every one knew what she had"
	- Mel Blanc
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: NAMRES
From: "John F. Sandhoff" <syssand@ccvax.ccs.csus.edu>
Date: Mon, 09 Nov 1992 15:32:21 PST
Reply-To: sandhoff@csus.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>
CC: cmu-tek-tcp@cmutek.cc.cmu.edu, syssand@CCVAX.CCS.CSUS.EDU


> when i try to rlogin, rsh, ftp or ping the vax, the unix computer (SIG, Hp0
> or SUN) does not get through. after some time i get a timeout.
> at first i need to ping the unix computer from the vax. after that
> everything works fine.

You have a BI-based computer, DON'T YOU??
You're running VMS 5.4-3 or greater, AREN'T YOU?
Well, DON'T DO THAT!!!

:-)  :-)  :-)  :-)  :-)

As of VMS 5.4-3 DEC screwed up the ethernet drivers for certain BI
controllers. They don't allow broadcast messages to percolate up to the
driver software, so products like CMU can't learn about ARPs.

The solution is to call DEC and ask for the latest ETDRIVER release.
They should be getting used to the world screaming at them for this :-).

If you're in a hurry you can grab some suitable drivers by FTPing to
TGV.COM and picking up CSCPAT_0543012.A. They're not the latest but they
should get you going.

    John F. Sandhoff, University Network Support
      California State University, Sacramento - USA
        sandhoff@csus.edu
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: SLIP lines
From: David Robison <david@hccw.com>
Date: Tue, 10 Nov 92 07:51:27 PST
Reply-To: David Robison <david@hccw.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>

I am interested in trying to setup TCP/IP over a SLIP line.  What are
the cabling requirements for a SLIP line?
--
David R. Robison
Senior Systems Programmer                      Voice: (702) 364-8633
Health Care Computer Works                       FAX: (702) 364-0776
Las Vegas, NV                               Internet: david@hccw.com
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: NAMRES
From: <hucke@isssys.uucp>
Date: Mon, 09 Nov 1992 16:20:36
Reply-To: <hucke@isssys.uucp>
Organization: The Internet
Return-Path: <SYNFUL@CMUTEK.CC.CMU.EDU>
Errors-To: SYNFUL@CMUTEK.CC.CMU.EDU
X-Listname: CMU-TEK TCP/IP Mailing list <CMU-TEK-TCP@CMUTEK.CC.CMU.EDU>

Hello support !!!

i experience the following problem(?) with the wonderful cmutek software
rel. 6.5.
when i try to rlogin, rsh, ftp or ping the vax, the unix computer (SIG, Hp
or SUN) does not get through. after some time i get a timeout.
at first i need to ping the unix computer from the vax. after that
everything works fine.
so some way the vax seems to be unable to resolve the addresses, even though
they are mentioned in the hosts file on the vax.
when i initiate the communication from the vax there is no problem at all.

do you have some suggestion where this behaviour might come from???

thank you very much in advance

Michael Hucke
                   !-----------------------------------!
                   ! hucke%isssys@mail.germany.eu.net, !
                   ! I.S.S. System Supplies GmbH,      !
                   ! Erichshofer Strasse 77,           !
                   ! 2803 Weyhe-Erichshof, W-Germany   !
                   !-----------------------------------!
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: More on name service dying
From: "Kenneth J. Hoover" <ken@psuedvax.psu.edu>
Date: Wed, 11 Nov 1992 08:40:04 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>


	I've been messing around a little here and it seems that the sudden
inability to find a name server is tied to a negative response from the server.

	For example, I was happily connecting to a few different places when I
made a typo while entering a machine name  As it should, FTP gave its "I can't
find that host" response, but then refused to connect to the corrected address
as well, giving the same response.  I then tried to resolve a nearby host with
"ipncp hostnm", and that drew a blank too!  So there's something about a
negative response from a nameserver that NAMRES doesn't like.

	I shut down and restarted the TCP/IP software, and things are working
again.

	This happens so regularly that I wrote a .COM file to kill and then
restart all of my network services that rely on TCP/IP.  However, I shouldn't
have to do this, right?  What's wrong?

	System : MV3100-30 with VMS 5.5-1
						- Ken Hoover
--
Kenneth J. Hoover               | Warning : sys$itch needs sys$scratching!
ITSS Supervisor of Sys & Ops    | Disclaimer : I disclaim dis.
Penn State College of Education | ken@psuedvax.psu.edu - kjh6@psuvm.psu.edu
From: rrb@nch.norasia.COM (R.R.Buonanno)
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: NAMRES problem
Date: 9 Nov 92 16:12:15 GMT
Reply-To: rrb@nch.norasia.COM
Organization: Norasia Shipping Services SA

It's me again. We now seem to be able to run this baby up and down at will, so
on to the next problem...
NAMRES doesn't seem to be talking to the Domain Name Server. All IPNCP HOSTNM
requests result in UNKNOWN HOST responses.
The NAMRES process exists and is not RWAST. I try to turn on logging with
IPNCP NAMRES LOG %x0FF but I don't get anything in NAMRES$LOG. We have a uVax
sitting right next to the Vax running very happily with an identical
NAMRES$CONFIG.

Help?
-- 
Richard R. Buonanno					rrb@nch.norasia.COM
Chief Hack and Window Washer				mcsun!chsun!nch!rrb
Norasia Shipping Services SA   PO Box 560   1700 Fribourg Switzerland