HDTenEightyP/NetNews huggingface dataset:
Mail-System-Version: <VAX-MM(309)+TOPSLIB(155)@TGV.COM>
Postal-Address: TGV Inc.; 603 Mission St.; Santa Cruz, CA 95060
Phone: (408) 427-4366 or (800) TGV-3440
Newsgroups: vmsnet.networks.tcp-ip.wintcp
Date:         Mon, 13 Apr 1992 00:57:05 -0700
From:         "David L. Kashtan" <KASHTAN@TGV.COM>
Subject:      Re: TGV MultiNet vs. WIN/TCP NFS Client
X-To:         smith@mcclb0.med.nyu.edu
X-cc:         wintcp-l%ubvm.bitnet@cunyvm.cuny.edu, info-vax@sri.com,
              info-multinet@TGV.COM

> The metafile scheme is fine and clearly works well, but there is a MAJOR
> problem if the little files start chewing up space and headers.  I feel very
> strongly that if a package creates files (like .FDL... things) then it should
> also clean them out if they become orphaned.  We use PacerShare as an
> AppleShare file server on the VAX.  It uses these things too.  Recently we
> ran out of file headers on the disk.  After writing a DCL script to clean out
> the orphans we deleted about 5,500 orpahn files.  This is rediculous.

WOW!  Sounds like you hit a bug or a mis-design in the AppleShare file server.
I would wonder what the circumstances were that caused those AppleShare
files to stick around.  It turns out that the TGV NFS Client has the ability
to discover orphaned meta-files whenever the directory cache is refreshed.
We had many internal discussions on whether or not to "fix-up" the directory
by deleting those files and decided not to for the following reasons:
	1) Getting orphaned meta-files is apparently EXTREMELY rare.

	2) Silently going ahead and deleting a file someone might have
	   wanted was not a good thing.
If problems with orphaned meta-files show up then we would consider adding
something to the NFS client to scan for these files and, under close
supervision of a system manager, remove them.  Again -- this has not been
a problem and I don't expect it to become one.

(this, by the way, is quite a different argument than the argument we have
 been seeing from TWG that meta-files are BAD -- this is just that software
 that uses meta-files had better be VERY careful to keep proper track of them
 and get rid of ones that are of no more use).

> Please.  If you create files with your file NFS client s/w, please delete
> them again if they are nolonger needed.  The files should be usable from both
> the VAX and the UNIX sides and operations on either platform or another should
> leave the file system lean, mean and efficient.  No excuses.
>

Absolutely -- and this is the way that we do it.

David
Newsgroups: vmsnet.networks.tcp-ip.wintcp
From: reece@eco.twg.com (Reece R. Pollack)
Subject: Re: Daylight savings time
Reply-To: reece@eco.twg.com (Reece R. Pollack)
Organization: The Wollongong Group (East Coast Operations)
Date: Mon, 6 Apr 92 18:32:41 GMT


In article <29DC9CF0.13051@orion.oac.uci.edu>, iglesias@draco.acs.uci.edu (Mike Iglesias) writes:
|>I'm running WIN/TCP v5.2 on my VAXcluster.  I'm running ntp on the
|>VAXen, using our campus ntp time servers to keep the time accurate.
|>When daylight savings time rolls around this weekend, what will happen
|>at 2am Sunday?  Will the time slowly correct itself, change quickly,
|>or ???

NTP uses GMT internally, so unless you change the timezone within
WIN/TCP, your system will continue on Standard Time. If you change
only the WIN/TCP timezone, NTP will complain that the time is more
than 1000 seconds in error (1hr = 3600sec), and won't change the
system time.

The proper procedure is to change the system time and the WIN/TCP
timezone at the same time. Something like this in a batch job should
work:

	$ SET PROCESS/PRIVILEGE=(LOG_IO,OPER,SYSNAM,CMKRNL)
	$ SET TIME="+01:00:00"
	$ SETZONE PDT
	$ DEFINE/SYSTEM PONY$TIMEZONE "''F$TRNLNM("WIN$TIME_ZONE")'"

Submit the job /AFTER="05-APR-1992 02:00:00". Don't forget to change the
timezone in TWG$TCP:[NETDIST.MISC]STARTINET.COM, or you'll lose the
change when the system reboots.

--
Reece R. Pollack
Senior Software Engineer
The Wollongong Group, Inc.
Newsgroups: vmsnet.networks.tcp-ip.wintcp
From: reece@eco.twg.com (Reece R. Pollack)
Subject: Re: Upward compatibility of images linked with WINTCP
Reply-To: reece@eco.twg.com (Reece R. Pollack)
Organization: The Wollongong Group (East Coast Operations)
Date: Mon, 6 Apr 92 18:37:00 GMT


In article <1992Apr2.153122@VMS.SAS.COM>, sasjzs@VMS.SAS.COM (Joe Slater) writes:
|>We have V5.2 of WINTCP. We link our tcp programs against
|>TWG$TCP:[NETDIST.LIB]TWGLIB.OLB. If we upgrade to V5.3
|>or higher versions, will I need to re-link my images?

Probably not, since the QIO interface used by the socket library hasn't
changed in a while. Of course, you wouldn't pick up any bugfixes that
might be included in the new release.

|>Any experience going from 5.1 to 5.2 will be appreciated.
|>(IMHO a shareable image would be just the ticket here...)

Humble or not, the idea has merit, and a documented shareable image
is being strongly considered.

--
Reece R. Pollack
Senior Software Engineer
The Wollongong Group, Inc.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Envelope-to: wintcp-l@ubvm.cc.buffalo.EDU
X-VMS-To: IN%"wintcp-l@ubvm.cc.buffalo.edu"
X-VMS-Cc: CANSYS
Newsgroups: vmsnet.networks.tcp-ip.wintcp
Date:         Tue, 7 Apr 1992 11:44:00 EDT
From:         "Alan Weitzsacker @ Computer Center (2453)"
              <CANSYS%canisius.bitnet@CUNYVM.CUNY.EDU>
Subject:      sorry
X-To:         wintcp-l@ubvm.cc.buffalo.EDU

Sorry about the subscribe request sent to the list; I followed that message
with one directed to wintcp-request, so I hope that one works.

I have a (hopefully) quick question. I have the Charon LPR/LPD software
running here, however jobs are not entirely getting through via the WIN$LPD
server queue. The job initiates OK, where the LPD sends a "Receive print job
command accepted", but then nothing else happens. There are no errors in the
LPD.LOG nor LPRSMB.LOG files. Has anyone else run into a similar problem in
the past that may have a clue or 2 to lend?

Please send responses direct to me, since I'm not sure if my subscription
request will have been accepted (or processed) any time soon.

Thanks!

                --alan
From: bailey@hmivax.humgen.upenn.edu (Charles Bailey)
Newsgroups: vmsnet.networks.tcp-ip.wintcp
Subject: Re: Upward compatibility of images linked with WINTCP
Date: 8 Apr 92 20:07:55 GMT
Article-I.D.: hmivax.1992Apr8.150755.1
Organization: HHMI/Human Genetics, Univ of Pa.

In article <1992Apr6.183700.3938@eco.twg.com>, reece@eco.twg.com (Reece R. Pollack) writes:
> |>Any experience going from 5.1 to 5.2 will be appreciated.
> |>(IMHO a shareable image would be just the ticket here...)
> 
> Humble or not, the idea has merit, and a documented shareable image
> is being strongly considered.

At the moment, I've found that the undocumented TWG_RTL works well in most
situations.  It must be linked in *after* VAXCRTL, however, as it appears to
contain its own symbols for (at least) some of the C strto*() functions. 
Ideally, both TWGLIB and TWG_RTL will remain part of the distribution, as it's
useful to keep most applications as small as possible, but occasionally one
wants to maximize portability.

					Charles Bailey

!-------------------------------------------------------------------------------
!          Dept. of Human Genetics / Howard Hughes Medical Institute
! University of Pennsylvania School of Medicine  Rm. 430 Clinical Research Bldg.
!     422 Curie Blvd.  Philadelphia, PA 19104 USA      Tel. (215) 898-1699
!          Internet: bailey@hmivax.humgen.upenn.edu  (IN 128.91.200.37)
!-------------------------------------------------------------------------------
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Via: sun3.nsfnet-relay.ac.uk; Wed, 8 Apr 1992 17:08:11 +0100
Newsgroups: vmsnet.networks.tcp-ip.wintcp
Date:         Wed, 8 Apr 1992 17:12:00 BST
From:         G_SOUNDY@ICRF.AC.UK
Subject:      subs. request address?
X-To:         WINTCP-L <WINTCP-L@UBVM.CC.BUFFALO.EDU>

How do I subscribe to this list ? Or does wintcp-l@ubvm.cc.buffalo.edu
serve both purposes ...

Thanks,
================================================================================
Graham Soundy                       |      Internet: g_soundy@icrf.ac.uk
System Support Manager              |      Janet:    g_soundy@uk.ac.icrf
Imperial Cancer Research Fund       |      Phone:    (uk) 071-269-3622
London WC2A 3PX, UK                 |      Fax: 071-269-3124
================================================================================
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Envelope-to: wintcp-l@ubvm.BITNET
X-VMS-To: IN%"KASHTAN@TGV.COM"
X-VMS-Cc: IN%"info-vax@sri.com",IN%"info-multinet@tgv.com",IN%"wintcp-l@ubvm"
Newsgroups: vmsnet.networks.tcp-ip.wintcp
Date:         Sat, 11 Apr 1992 12:52:00 EDT
From:         Stephen Tihor <TIHOR@NYUACF.BITNET>
Subject:      Re: TGV MultiNet vs. WIN/TCP NFS Client
X-To:         KASHTAN@TGV.COM
X-cc:         info-vax@sri.com, info-multinet@tgv.com, wintcp-l@ubvm.BITNET

I am also mildly curious as to why TGv choose the reserved area rather than an
Application ACE for the SETUID/SETGID information.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Envelope-to: wintcp-l@ubvm.BITNET
X-VMS-To: IN%"KASHTAN@TGV.COM"
X-VMS-Cc: IN%"info-vax@sri.com",IN%"info-multinet@tgv.com",IN%"wintcp-l@ubvm"
Newsgroups: vmsnet.networks.tcp-ip.wintcp
Date:         Sat, 11 Apr 1992 12:50:00 EDT
From:         Stephen Tihor <TIHOR@NYUACF.BITNET>
Subject:      Re: TGV MultiNet vs. WIN/TCP NFS Client
X-To:         KASHTAN@TGV.COM
X-cc:         info-vax@sri.com, info-multinet@tgv.com, wintcp-l@ubvm.BITNET

Let me just mention one other approach.  Pathworks for VMS (mac) uses  meta
files but stores roughly one per directory with the shared information (and a
separate subdirectory with other resource data in it.)   Nontheless if  the
problem is using up FILE HEADERS then the best fix would bea  meta data file
with all the file information in it for whatever granularity  you want. Of
course that makes the "moving the file and losing the attributes" problem WORSE
but if thats the key issue then do it.
Newsgroups: vmsnet.networks.tcp-ip.wintcp
Subject: HELP!  Converting SMTP.CONF aliases to Pony Express
From: fisher%boot.decnet@edwards-tems.af.mil
Date: 10 Apr 92 15:20:02 -0700
Organization: T&E Mission Simulator - Edwards AFB, CA

We are attempting to convert to WIN TCP/IP V5.2 and are experiencing problems
with Pony Express.

We were using SMTP.CONF to perform aliasing of addresses.  An example line
would be to the effect of:

*.NOVELL	MB		<**@internet.node.name.mil>

What this would do is take in address of the form:

user.novell@edwards-vax.af.mil

and convert them to

user@internet.node.name.mil

The SMTP MAILER would then forward these messages to the appropriate place.

I need this same functionality under the Pony Express mailer.  We have
many  mailing lists throughout the country that are using these addresses and
it would be quite difficult to update them.

We have mail backing up and we need this resolved as soon as possible.


Thank you
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: vmsnet.networks.tcp-ip.wintcp
Date:         Sat, 11 Apr 1992 12:22:20 PDT
Reply-To:     Kenneth Adelman <Adelman@TGV.COM>
From:         Kenneth Adelman <adelman@TGV.COM>
Subject:      Re: TGV MultiNet vs. WIN/TCP NFS Client
X-To:         TIHOR@ACFcluster.NYU.EDU
X-cc:         info-vax@sri.com, info-multinet@TGV.COM,
              "wintcp-l @ ubvm.bitnet @ cunyvm.cuny.edu"
              <wintcp-l%ubvm.bitnet%cunyvm.cuny.edu@TGV.COM>

>> I am also mildly curious as to why TGV choose the reserved area rather than
 an
>> Application ACE for the SETUID/SETGID information.

    Actually, we don't store these bits in the reserved area of the file
header (defined in the ODS-2 specificiation, section 3.2.5), but rather
in the reserved-to-customer byte of the user-characteristics longword
(defined in the ODS-2 specification, section 3.5.2.14), FCH$L_FILECHAR.

    Application ACEs are definitely not the only nor the best way to store
such "extra" information with a file. Besides being relatively expensive
to read (compared to UCHAR) they aren't preserved by BACKUP/INTERCHANGE.

								Ken
From: gao@dcs.ed.ac.uk (Bo Gao)
Newsgroups: vmsnet.networks.tcp-ip.wintcp
Subject: How to access UNIX printers from VAX/VMS
Date: 9 Apr 92 11:31:49 GMT
Reply-To: bo.gao@ncl.ac.uk (Bo Gao)
Organization: Dept. of EEE, Newcastle University.

We wonder if anybody on the net can help us on the following problem.

We are running VAX/VMS 5.2, and older version of WIN TCP/IP which
do not have lpr/lpd utilities to access remote UNIX printer hosts.
We do not intend to update VAX/VMS and WIN TCP/IP, but we do need
to set up printer queues on our VAX which can forward printing jobs
to UNIX printer hosts. Does anybody know if there are any public
domain programs (queue processor and relevant daemons for instance) 
available, or who has implemented such an utility and is willing
to let us have it?

Thanks in advance.

Gao, Bo, Dept. of E&E Engineering,   | USENET: gao@dcs.ed.ac.uk
University of Newcastle upon Tyne,   | JANET:  gao@uk.ac.ed.dcs
Merz Court,                          | Tel:    +44 91 222 7322
Newcastle NE1 7RU, U.K.              | <<<<<<<<<<<<<<<<<<<<<<<<<
--
Gao, Bo, Dept. of Computer Science,  | USENET: gao@dcs.ed.ac.uk
University of Edinburgh, JCMB,	     | JANET:  gao@uk.ac.ed.dcs
The King's Buildings, Mayfield Road, | Tel:    +44 91 222 7322 (O)
Edinburgh, EH9 3JZ, Scotland U.K.    | <<<<<<<<<<<<<<<<<<<<<<<<<<<<
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Mail-System-Version: <VAX-MM(309)+TOPSLIB(155)@TGV.COM>
Postal-Address: TGV Inc.; 603 Mission St.; Santa Cruz, CA 95060
Phone: (408) 427-4366 or (800) TGV-3440
Newsgroups: vmsnet.networks.tcp-ip.wintcp
Date:         Sat, 11 Apr 1992 10:43:13 -0700
From:         "David L. Kashtan" <KASHTAN@TGV.COM>
Subject:      Re: TGV MultiNet vs. WIN/TCP NFS Client
X-To:         TIHOR@ACFcluster.NYU.EDU
X-cc:         info-vax@sri.com, info-multinet@TGV.COM,
              wintcp-l%ubvm.BITNET@TGV.COM

>
> I am also mildly curious as to why TGV choose the reserved area rather than an
> Application ACE for the SETUID/SETGID information.
>

That was a historical artifact and may, indeed, change in an upward compatible
fashion in the future.
David
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: drop to vt52, Solved
From: "John Clement-Rice U. (713)527-8101x2037" <clement@physics.rice.edu>
Date: Thu, 09 Apr 1992 09:53:30 CDT
Reply-To: "John Clement-Rice U. (713)527-8101x2037"
Organization: The Internet
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

The problem is that FTP's PC/TCP sends null terminated strings for the terminal
type.  CMUTEK can handle names such as DEC-VT200 or VT200, but the current
release can not handle null terminated strings.  It will not recognize
VT200<null>.  Most of the other implementations of Telnet do not send null
terminated strings, so they work.  This will be fixed in a future release.

	John Clement
	Rice University
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: X server/clients via TCP/IP
From: jimmy@sparc.ncpa.olemiss.edu (Jimmy Ball)
Date: Mon, 06 Apr 92 10:40:38
Reply-To: jimmy@sparc.ncpa.olemiss.edu (Jimmy Ball)
Organization: The Internet
Errors-To: SYNFUL@CMUTEK.CC.CMU.EDU
X-Listname: CMU-TEK TCP/IP Mailing list <CMU-TEK-TCP@CMUTEK.CC.CMU.EDU>

Hi,

  I am interested in finding out how to run X clients under the Unix
operating system and communicating with a Decwindows server via TCP/IP.
Our vaxcluster is currently running VMS V5.4 and CMU-TEK V6.4 is
installed.  We have the ability to ftp,telnet,etc. with CMU-TEK.  Also,
I can establish an X client/server connection between 2 vaxcluster
members via DECNET and an X client/server connection between two unix
workstation via TCP/IP.
  I have tried to establish an X client/server connection between a
vaxstation and a unix workstation with no success.  I have tried making
the unix workstation the X server and the vaxstation the client.  This
did not work either.  I both cases an error message returns simply
saying 'Can't open display' or something like that.
  I believe either my vaxstation account security is not setup correctly
or the CMU-TEK is running with incorrect options.  I would appreciate it
if you would address these questions if they could be the source of the
problem.  Please feel free to suggestion other solutions to the problem.
The SYOP who installed CMU-TEK has moved on and I am left with limited
documentation.
  Thanks for your help.

Jimmy Ball
Research Associate/Senior Computer Analyst
National Center for Physical Acoustics/University of Mississippi
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: NFS File Server
From: "CHRIS STRICKLAND" <stricklandc@h8700a.boeing.com>
Date: 8 Apr 92 10:09:00 CST
Reply-To: "CHRIS STRICKLAND" <STRICKLANDC@h8700a.boeing.com>
Organization: The Internet
Errors-To: SYNFUL@CMUTEK.CC.CMU.EDU
X-Listname: CMU-TEK TCP/IP Mailing list <CMU-TEK-TCP@CMUTEK.CC.CMU.EDU>

I keep getting an insufficient disk space error when trying to write to
the NFS disk.  Does anyone have any ideas on how I can fix the problems.

When I do a dir I show over 70 megs free.
From: gulli@vedur.is (Gunnlaugur Kristjansson)
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Problem getting v6.6-5
Date: 9 Apr 92 21:34:54 GMT
Organization: Icelandic Meteorological Office

Hi!

I am trying to FTP version 6.6-5 from CMUTEK.CC.CMU.EDU and
it always aborts the transfer. I get around 70 blocks worth
and then the abort. Is there something wrong at CMUTEK.CC.CMU.EDU?
I can FTP from elsewhere without difficulties.

Best regards,
gulli
-- 
---------------------------------------------------------------------------
Gunnlaugur Kristjansson                  Email......: gulli@vedur.is
Systems Analyst                          PSImail....: 274011724200::gulli
Data Processing Division                 DECUS mail.: EDCHUB::KRISTJANSSON
Icelandic Meteorological Office          COMPUSERVE.: 72461,2160
Bustadavegi 9                            Telephone..: +354 1 600600
IS150 Reykjavik                          Telefax....: +354 1 28121
Iceland.
---------------------------------------------------------------------------
From: visnucc@ubvmsb.cc.buffalo.edu (Niagara U. Courtesy Account)
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Name Resolving
Date: 9 Apr 92 08:02:00 GMT
Article-I.D.: acsu.1992Apr9.070251.4135
Organization: University at Buffalo
News-Software: VAX/VMS VNEWS 1.41

Hello,

  We are running CMU-Tek v6.6-3(?) here in a closed system.  Our system 
comprises of 1 MicroVAX running VMS 5.4-1, and a room full of PC on the
same Ethernet.  I installed CMU-Tek, and tested it and am able to FTP and
Telnet successfully, but CMU-Tek does not seem to recognize the domain
name we have given it, VAX.CC.NIAGARA.EDU.  We get messages saying stuff
like "Returning to         ", which obviously should have some name, but
don't.  Also we are unable to FTP/Telnet to the VAX from the VAX unless
we use it's IP address.  The domain names don't work.  The installation is
fairly straight forward (followed the script/command procedure).  In the
manual it seems to point toward a Domain Server for resolving the address,
with NamRes being the go between.  Since we are running only CMU-Tek (PCs
have Domain Names -> IP address hard coded in startup file) how do we
get CMU-Tek to resolve Domain Names?  It looks like there was a Domain
Server on the dist. tape, but no instructions on how to install, or if
it could be used for what we need.  Please, anyone who can help, or offer
a suggestion, send E-Mail to this account.  I apologise for the lack of
TCP/IP knowledge, but we are only learning now, and hope to be comfortable
with it before we get our Internet line in the summer/fall.  Thanks!

-Rich

--------------------------------------------------------------------------
Richard P. Kernin                  Internet: visnucc@ubvmsc.cc.buffalo.edu
Niagara University                   BITNET: visnucc@ubvmsc.BITNET
--------------------------------------------------------------------------
From: munroe@dmc.com (Dick Munroe)
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re: DNS problem
Date: 5 Apr 92 22:56:31 EDT
Organization: Doyle Munroe Consultants, Inc., Hudson, MA

In article <9204011735.AA26600@depot.cis.ksu.edu>, Saadaoui Kamel <saadaoui@spiky.rsinet.tn> writes:
>  The telnet application gives the following error message when we try
>  to connect to a LOCAL machine :" No domain servers could be contacted"
>  We include here the file "internet.config".
>  Please let us know if you have any ideas !
>  We appreciate your help.
>     Best regards

It won't be just the telnet application.  I eventually managed to get my
domain server working, although I'm STILL not quite sure why and haven't
received any analysis from the readers of this news group.  The following is a
copy of an earlier note I'ld posted to this list:

X-NEWS: dmc.com vmsnet.networks.tcp-ip.cmu-tek: 447
From: munroe@dmc.com (Dick Munroe)
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re: Trouble with the Domain Server (I think)
Date: 23 Mar 92 12:14:56 EST
Organization: Doyle Munroe Consultants, Inc., Hudson, MA

In article <1992Mar17.184528.4215@dmc.com>, munroe@dmc.com (Dick Munroe) writes:

Well, I managed to get the problem to go away, but what I did is a little
counter-intuitive.

1. I added an initial record to the DOMAIN$SERVER_STARTUP file:

--------------------------------------------------------------------------------
; Startup file for domain server
primary dmc.com 		domsdir:dmc-com.zone_master
primary 1.1.192.in-addr.arpa    domsdir:1-1-192.zone_master
initial				domsdir:initial.dat
--------------------------------------------------------------------------------

The initial file contained:

--------------------------------------------------------------------------------
; RR's to initialize server
thehulk.dmc.com. in a 192.1.1.1
--------------------------------------------------------------------------------

2. I manually shutdown the name resolver and the domain server and deleted the
cache file (*.mcom).

3. I rebooted the machine to get the communication system reset to a known
clean spot.  Interestingly enough, no combination of shutting down the name
server, the name resolver, the ipacp or running domain/update seemed to get
things into a known good state.  It seemed to require a reboot.

Now it seems to correctly resolve name requests although I'm still not able to
get DOMAIN/LOOKUP to return anything sane (it always reports a server error).

I'm going to declare victory, but I would like to point out that there are a
couple of things that don't make sense.

First, why should I have to tell the domain server how to contact the node upon
which the domain server is started (that's what I believe the contents of the
initialization file did).

Second, if you MUST tell the domain server how to contact itself, why isn't
that documented.

Third, all of this is black magic and I just got it working by accident.  There
is no such thing as cause and effect.

Anybody out there want to take a stab at an explanation?  I would sure like to
hear one.
-- 
Dick Munroe				Internet: munroe@dmc.com
Doyle Munroe Consultants, Inc.		UUCP: ...uunet!thehulk!munroe
267 Cox St.				Office: (508) 568-1618
Hudson, Ma.				FAX: (508) 562-1133

GET CONNECTED!!! Send mail to info@dmc.com to find out about DMConnection.
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: DNS - again
From: gordon@chmeds.ac.nz
Date: 9 Apr 92 14:53:24 +1300

I'm another who is having trouble with the DNS.

chmeds.ac.nz is a very simple domain - just two machines, BLISS
(192.101.16.1) and TWIZON (192.101.16.2) and a PCROUTE slip line
(192.101.16.3) to the world.

Does anyone have a simple set of zone-master, START.DAT, INITIAL.DAT
etc. files which work that they would be prepared to send me, or the group
for enlightenment?  Are any changes, other than the WKS entry, needed
in INTERNET.CONFIG?

Thanks
-- 
Gordon Findlay,  Computer Scientist, Christchurch School of Medicine
                 Nuclear-free New Zealand
Generic:  Gordon@CHMEDS.AC.NZ            
JANET:    Gordon%NZ.AC.CHMEDS@UK.AC.NSFNET-RELAY 
Paper:    PO Box 4345, Christchurch,  NEW ZEALAND