HDTenEightyP/NetNews huggingface dataset:
From: Bruce.Weinel@p1.f456.n632.z3.fidonet.org (Bruce Weinel)
Newsgroups: comp.protocols.nfs
Subject: SUN PC-NFS Printing problem.
Date: Mon, 21 Dec 1992 07:08:12

johnm@bowen.cc.utas.edu.au was heard in "The Pit" saying to  All

  ju> From: johnm@bowen.cc.utas.edu.au (John Miezitis)
  ju> Organization: University of Tasmania, Australia.
  ju> 
  ju> One of my PC-NFS users here is having a problem printing
  ju> directly to a redirected printer port...
  ... 
  ju> If he net prints the file everything works.
  ju> 
  ju> I tried the following:-
  ju> 
  ju> copy xxx.ps u: file appears intact
  ju> 
  ju> copy xxx.ps lpt2: Lost data, file size approx 3100 bytes.
  ju> 
  ju> Printing directly to lpt2: from within application Lost
  ju> data, file size now only approx 1100 bytes

The most likely cause is DOS sensitivity to 1Ah (^Z) in sequential text files.
The DOS 'copy' command to a block device (u:) bases end-of-file on the size
stored in the directory, not file content. However, 'copy' to a sequential
device
(lpt2:) senses end-of-file when it encounters 1Ah (^Z). I would expect that
the 3543rd byte is such an end-of-file marker. I would also expect that the
behavior of varying file sizes is due to physical and logical block sizes
relative
to sensing the end-of-file. On the sequential copy 3100 is roughly 3543 - 512
(physical block size). From the application 1100 is roughly 3543 - (2048 -
512)
or a cluster minus the first sector.

This problem can usually be avoided by using ASCII Encapsulated PostScript
(EPS)
format for images; rather than binary EPS. It can also be circumvented by
software
that knows the data stream may contain binary and therefore reads the file as
a blocked device with one byte records; as I assume net print does.

I-{>

 * Origin: Howls from "The Pit" BBS (03) 321-3295 (3:632/456.1@fidonet)
Newsgroups: comp.protocols.nfs,comp.sys.novell
From: dwight@hyphen.com (Dwight Ernest)
Subject: Re: INFO NEEDED: Mutual file server for NFS *AND* Novell networks?
Organization: Hyphen, Inc., Wilmington, MA 01887 USA / +1 508 988-0880
Date: Fri, 1 Jan 1993 17:44:26 GMT

mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:

>In article <C0538L.DB@qualis.com> mikeh@qualis.com (Michael T. Horne) writes:
>>Basically I'm looking for a file server that can serve both Novell clients
>>and NFS clients that are on separate nets, possibly linked via a SLIP
>>telephone link.

>What you want is Novell Netware 3.11 with Netware NFS.  It will
>probably run you somewhere between $6,000 and $15,000, depending on
>how many users your Netware license is for.  Plus, of course, the cost
>of the PC hardware.  It will do everything you need, except for
>SLIP -- I don't think Novell has any SLIP support.  You will probably
>have to get a router with SLIP or PPP capabilities, attach it to your
>net, and have your remote stations dial into the router in order to
>talk to the server.

Or a Sun server with Netware Sunlink, which is the way I'd probably go
for a good price/performance ratio.  Then SLIP or PPP would be available
either commercially or in the public domain for the Sun platform, as
thousands of Sun users can attest.  And, of course, NFS would be in there
from the beginning.

More and more frequently, a Sun server is becoming a very reasonable 
alternative to PC servers.
-- 
--Dwight A. Ernest   R&D Manager (USA)     I speak only for myself.
  Hyphen, Inc./181 Ballardvale St./Wilmington, MA 01887/+1 508 988 0880 x125
  dwight@hyphen.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS packet size
Date: 31 Dec 92 04:17:11 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Dec30.231852.22129@phx.mcd.mot.com>, mat@phx.mcd.mot.com (Mat Cucuzella) writes:
> In article <C01s5x.5Bn@news.iastate.edu> john@iastate.edu (John Hascall) writes:
> >schittel@geo.Uni-Koeln.DE (Christoph Schittel) writes:
> >}What is the maximum value for the "rsize" and "wsize" options
> >}to make an NFS datagram fit completely into one ethernet packet
> >}(max. 1500 byte)?
> >
> >   1024
> 
> An Ethernet frame size is 1514. Subtracting Ethernet header (6+6+2), IP
> header (20) and UDP header (20), that leaves 1460. I'm not sure if RPC
> headers have to be included in this, but I believe 1460 or slightly
> less will still keep everything in one Enet packet.


After the UDP header and before the data, an NFS READ REPLY message
tends to have about 108 bytes of RPC and NFS header.

Powers of 2 tend to be nice choices for rsize and wsize because powers
of 2 tend to be nice multiples or divisors of the "natural" buffer
sizes disk cache in the client as well as the server.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.protocols.nfs
From: john@iastate.edu (John Hascall)
Subject: Re: NFS packet size
Organization: Iowa State University, Ames, IA
Date: Fri, 1 Jan 1993 15:03:37 GMT

boyd@prl.dec.com (Boyd Roberts) writes:
}john@iastate.edu (John Hascall) writes:

}> A dropped TCP fragment can result in a large amount of resending too.

}True, but that all happens at the TCP/IP level which is far more
}responsive than NFS's 1, 2, 4, 8 ... _second_ exponential backoff
}when a datagram gets lost.

Ummm, sure if you set timeo=10 (timeo is in tenths of a second)
[admittedly, I would guess most TCP implementations are more
responsive than .1 sec].

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systmes Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc
From: semenoff@fraser.sfu.ca (Robert Semenoff)
Subject: soss as RPC server?
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Tue, 22 Dec 1992 20:11:01 GMT

The soss I have download from ftp.uu.net seems to be only for
use as an NFS server. 
Has anyone tried to extend it to be able to register additional
programs and procedures ?  Any comments about how difficult this
would be ? Or any pointers to alternative public domain software
which would fill the bill ?

Thanks in advance for any input or advice.

-Robert
--
  



Newsgroups: comp.protocols.nfs
From: boyd@prl.dec.com (Boyd Roberts)
Subject: Re: NFS packet size
Organization: Digital Equipment Corporation - Paris Research Laboratory
Date: Fri, 1 Jan 1993 11:50:15 GMT

In article <C05ICp.CF0@news.iastate.edu>, john@iastate.edu (John Hascall) writes:
> 
> And how would I turn that on under Ultrix?  ;-)

You can't :-(

> A dropped TCP fragment can result in a large amount of resending too.

True, but that all happens at the TCP/IP level which is far more
responsive than NFS's 1, 2, 4, 8 ... _second_ exponential backoff
when a datagram gets lost.

We had a flakey drop cable here a while back.  When it was bad it would
take in the order of a minute to write an 8K block.  You could see the
fragments being dropped and the NFS retries.  I _never_ want to see
that again -- it was _awful_.


Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''
Newsgroups: comp.protocols.nfs
From: john@iastate.edu (John Hascall)
Subject: Re: NFS packet size
Organization: Iowa State University, Ames, IA
Date: Fri, 1 Jan 1993 01:19:36 GMT

boyd@prl.dec.com (Boyd Roberts) writes:
}UDP fragments that are needed to make up NFS I/O operations are a bad idea.
}Drop a fragment and resend the whole RPC.  Bite the bullet -- use TCP/IP.

And how would I turn that on under Ultrix?  ;-)

A dropped TCP fragment can result in a large amount of resending too.

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systmes Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
Newsgroups: comp.protocols.nfs
From: erik@til.com (Erik Horstkotte)
Subject: Re: SUN PC-NFS Printing problem.
Reply-To: erik@til.com
Organization: Togai InfraLogic, Inc.
Date: Thu, 24 Dec 1992 16:25:27 GMT

In article AA05059@csource.oz.au, Bruce.Weinel@p1.f456.n632.z3.fidonet.org (Bruce Weinel) writes:
>johnm@bowen.cc.utas.edu.au was heard in "The Pit" saying to  All
>
>  ju> From: johnm@bowen.cc.utas.edu.au (John Miezitis)
>  ju> Organization: University of Tasmania, Australia.
>  ju> 
>  ju> One of my PC-NFS users here is having a problem printing
>  ju> directly to a redirected printer port...
>  ... 
>  ju> If he net prints the file everything works.
>  ju> 
>  ju> I tried the following:-
>  ju> 
>  ju> copy xxx.ps u: file appears intact
>  ju> 
>  ju> copy xxx.ps lpt2: Lost data, file size approx 3100 bytes.
>  ju> 
>  ju> Printing directly to lpt2: from within application Lost
>  ju> data, file size now only approx 1100 bytes
>
>The most likely cause is DOS sensitivity to 1Ah (^Z) in sequential text files.
>The DOS 'copy' command to a block device (u:) bases end-of-file on the size
>stored in the directory, not file content.

If this really is the problem, shouldn't doing 

    copy xxx.ps lpt2: /b

fix the problem?
---
Erik Horstkotte, Togai InfraLogic, Inc.
The World's Source for Fuzzy Logic Solutions (The company, not me!)
erik@til.com, gordius!til!erik - (714) 975-8522
info@til.com for info, fuzzy-server@til.com for fuzzy mail-server
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS over TCP rather than UDP
Date: 29 Dec 92 21:20:12 GMT
Organization: Auspex Systems, Santa Clara

>I believe Solaris 2.0 has TCP NFS, but I'm not sure if it is shipping.

Does "it" here refer to Solaris 2.0, or to TCP NFS?

I suspect Solaris 2.0 isn't shipping - a SPARCstation 10 that arrived
here appears to have Solaris 2.x pre-installed, and I don't think 2.0
ran on Sun-4m machines like the SS10, so it presumably has 2.1 on it;
given that, they're unlikely to be shipping 2.0 any more.

:-)
From: tclark@med.unc.edu (Thomas B. Clark III)
Newsgroups: comp.protocols.nfs
Subject: PCNFSD
Date: 27 Dec 92 16:40:08 GMT
Article-I.D.: samba.1992Dec27.164008.5750
Organization: UNC-CH School of Medicine
Originator: tclark@hudson

I am trying to use PCNFS to mount a printer on a UNIX
host using PCNFSD.
PCNFSD consistently returns the error
No such printer on server,
no matter which of the synonyms in /etc/printcap
I specify.  Can anybody think of what might
be causing this?

Any help would be appreciated.
Newsgroups: comp.protocols.nfs
From: boyd@prl.dec.com (Boyd Roberts)
Subject: Re: NFS packet size
Organization: Digital Equipment Corporation - Paris Research Laboratory
Date: Thu, 31 Dec 1992 20:12:52 GMT

UDP fragments that are needed to make up NFS I/O operations are a bad idea.
Drop a fragment and resend the whole RPC.  Bite the bullet -- use TCP/IP.

Connection based stream protocols are your friends.


Boyd Roberts			boyd@prl.dec.com

``Not only is UNIX dead, it's starting to smell really bad.''  -- Rob Pike
Newsgroups: comp.protocols.nfs
From: john@iastate.edu (John Hascall)
Subject: Re: NFS packet size
Organization: Iowa State University, Ames, IA
Date: Wed, 30 Dec 1992 01:01:07 GMT

schittel@geo.Uni-Koeln.DE (Christoph Schittel) writes:
}What is the maximum value for the "rsize" and "wsize" options
}to make an NFS datagram fit completely into one ethernet packet
}(max. 1500 byte)?

   1024

  {wr}size must be a multiple of 512

} Are there any implementations of NFS and TCP/IP
}(or certain hardware) where IP-fragmentation slows things
}(NFS over UDP) down?

   No doubt.

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
Newsgroups: comp.protocols.nfs
From: jswanson@csfb1.fir.fbc.com (James Swanson)
Subject: Distributed NFS
Keywords: Fault-tolerance High-availability Distributed-NFS
Reply-To: uunet!csfb1!jswanson
Organization: First Boston Corporation
Date: Tue, 29 Dec 1992 15:07:45 GMT

I am looking for a solution to provide a backup NFS server that is located
away from the primary server.  This precludes the use of disk sharing across
CPU's or disk-mirroring.

I have implimented a solution that involves periodical copying of updated
file systems from the primary to the backup system.  The problem is trying
to achieve up-to-the-moment concurrency between the primary and backup.

I am considering modifying a version of NFSD or BIOD that would either forward
all file updates to the replicate server or send the update to more than one
server from the client.

There seems to be very little on this subject available.  Anyone have any
ideas?

-- 
Jim Swanson
(212)322-1085
5WTC - 9th floor
From: cr@antares.fct.unl.pt (Complementos de Robotica)
Newsgroups: comp.protocols.nfs
Subject: Looking for... NFS Toolkit for Borland C++ 3.x
Date: 22 Dec 92 20:34:26 GMT
Organization: Universidade Nova de Lisboa, PORTUGAL
X-Newsreader: TIN [version 1.1 PL8]

I'm looking for PC-NFS Toolkit for Borland C++. If someone knows about where 
I can find it, please let me know how.
Thanks in advance!


--
Alunos de Comp. de Robotica       | BITNET/Internet: cr@fctunl.rccn.pt
Universidade Nova de Lisboa	  | 
FCT - Dpto. de Informatica        | Fax:   (+351) (1) 295-5641/4461
2825 Monte Caparica, PORTUGAL     | Phone: (+351) (1) 295-4464
Newsgroups: comp.protocols.nfs
From: ksundar@hubcap.clemson.edu (Komal Sundaram)
Subject: Help with NFS procedures
Keywords: NFS procedure calls
Organization: Clemson University
Date: Mon, 28 Dec 1992 16:56:38 GMT

Is there a document that describes the various nfs procedures like
"getattr","lookup" etc.  In particular, I need the calling syntax
and the return syntax.

Any help will be appreciated. 

Thanks

Komal sundaram

ksundar@hubcap.clemson.edu
From: geertj@ica.philips.nl (Geert Jan de Groot)
Newsgroups: comp.protocols.nfs
Subject: Re: NDIS protman 2.1 compliant network solutions
Date: 21 Dec 92 00:42:46 GMT
Organization: Philips Consumer Electronics, Eindhoven, The Netherlands

Bruce.Weinel@p1.f456.n632.z3.fidonet.org (Bruce Weinel) writes:

>Try NetManage NEWT, Chameleon or Chameleon/NFS. Contact is:

>NetManage, Inc.                     Phone: (408) 257-6404

>These are the best TCP/IP stack, TCP/IP application suite or NFS application
>suite (respectively) that I have seen for Windows. Includes SMTP, SNMP, FTP
>server, RPC/XDR, BIND, et cetera support and is easy to install. Also will
>coexist
>with either LAN Manager (NDIS) or NetWare (ODI) protocol stacks.

Beware that, despite the advertizing, Netmanage does NOT have an
NFS redirector for windows NT yet. The advertizement we received mentioned
this possibility, but it was only after we received the stuff that this
appeared to be unavailable. I was able to return my copy, fortunately.

Geert Jan
Newsgroups: comp.protocols.nfs
From: gord@edm.uucp (Gordon Derk)
Subject: Public domain pcnfs???                                         
Date: Tue, 22 Dec 1992 15:53:44 GMT
Organization: Gator Software Corporation

Are there any public domain PCNFS products out there?  We have a very simple
drive sharing need and are trying to do something on the cheap side.

Thanks in advance
Gordon Derk
Sentai Software Corporation
Edmonton, Alberta, Canada
From: brent@terra.Eng.Sun.COM (Brent Callaghan)
Newsgroups: comp.protocols.nfs
Subject: Re: Distributed NFS
Date: 29 Dec 1992 19:16:42 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: brent@terra.Eng.Sun.COM
NNTP-Posting-Host: terra

In article 7tK@csfb1.fir.fbc.com, jswanson@csfb1.fir.fbc.com (James Swanson) writes:
>I am looking for a solution to provide a backup NFS server that is located
>away from the primary server.  This precludes the use of disk sharing across
>CPU's or disk-mirroring.
>
>I have implimented a solution that involves periodical copying of updated
>file systems from the primary to the backup system.  The problem is trying
>to achieve up-to-the-moment concurrency between the primary and backup.
>
>I am considering modifying a version of NFSD or BIOD that would either forward
>all file updates to the replicate server or send the update to more than one
>server from the client.

There's already a product available that does this called  the Isis Reliable Network File System
from Isis Distributed Systems Inc.  Their mail address is ids@isis.com.


---

Made in New Zealand -->  Brent Callaghan  @ SunSoft
			 Email: brent@Eng.Sun.COM
			 phone: (415) 336 1051

Newsgroups: comp.protocols.nfs
From: mat@phx.mcd.mot.com (Mat Cucuzella)
Subject: Re: NFS packet size
Organization: Motorola Computer Group, Tempe, Az.
Date: Wed, 30 Dec 1992 23:18:52 GMT

In article <C01s5x.5Bn@news.iastate.edu> john@iastate.edu (John Hascall) writes:
>schittel@geo.Uni-Koeln.DE (Christoph Schittel) writes:
>}What is the maximum value for the "rsize" and "wsize" options
>}to make an NFS datagram fit completely into one ethernet packet
>}(max. 1500 byte)?
>
>   1024

An Ethernet frame size is 1514. Subtracting Ethernet header (6+6+2), IP
header (20) and UDP header (20), that leaves 1460. I'm not sure if RPC
headers have to be included in this, but I believe 1460 or slightly
less will still keep everything in one Enet packet.

Mat oneT Cucuzella
mat@phx.mcd.mot.com
Xref: sparky comp.protocols.nfs:3012 comp.sys.sun.hardware:6510
From: brada@bardlover.Eng.Sun.COM (Brad Albom)
Newsgroups: comp.protocols.nfs,comp.sys.sun.hardware
Subject: Re: Does a Prestoserve S-bus card improve local disk access too?
Followup-To: poster
Date: 25 Dec 1992 02:50:16 GMT
Organization: Sun Microsystems Inc., Mountain View, CA
NNTP-Posting-Host: bardlover

>I'm wondering if the support also speeds local operations on the exported
>disks which are implicitly synchronous (at least with the UFS file system).

Briefly, the answer is yes.  Presto will accelerate local FS writes in
exactly the same way as it does NFS writes.  In fact, its default mode
of startup is to accelerate all file systems it finds in /etc/fstab.

Technically, Presto doesn't even know the difference between NFS & UFS
as it does its stuff by intercepting I/O just before it would get to
the disk driver level.

-brad albom
Software Engineering Solutions, Inc (Not related to Sun Micro)
Office: (415) 969-0141    - Probably get a secretary
FAX   : (415) 969-0177    - Probably get a high pitched tone
email : brada@eng.sun.com - Best Bet (In On Random Weekdays)
Newsgroups: comp.protocols.nfs
From: backman@vaxeline.ftp.com  (Larry Backman)
Subject: Re: NFS over TCP rather than UDP
Nntp-Software: PC/TCP NNTP
Organization: FTP Software, Inc., Wakefield, MA
Date: Mon, 21 Dec 1992 15:50:23


 >> Which vendors offer their NFS able to use TCP?
 >> 

FTP Software's PCTCP for both DOS and OS/2.  Others that we have tested
against that I know are shipping include TGV's Multinet & Interstream's
eNFS.  I believe Solaris 2.0 has TCP NFS, but I'm not sure if it is
shipping.


Larry Backman
FT P Software

Newsgroups: comp.protocols.nfs,comp.mail.uucp,comp.mail.misc,comp.bbs.waffle,comp.windows.ms
From: steck@ccs.northeastern.edu (Paul Steckler)
Subject: WinBiff 1.4 available
Organization: College of CS, Northeastern U
Date: Sun, 3 Jan 1993 14:56:30 GMT

WinBiff 1.4, a 'biff' program for Windows 3.x in conjunction with
UUPC/ex, Waffle, FUUCP, or PC-NFS, is ready for distribution.

It should be available sometime this week on SIMTEL20
(PD1:<MSDOS.WINDOWS3>) (as WNBFF14.ZIP) and ftp.cica.indiana.edu 
(in pub/pc/win3/misc/wnbff14.zip).

WinBiff now will show Waffle mail headers, and you can click on
WinBiff to launch your mail reader.  You no longer have to choose
manually between sendmail and MMDF mail formats; WinBiff figures it
out. 

-- Paul

 -----------------------------------------------------------------------
| Paul Steckler                       |  Desperately seeking clever     |
| steck@ccs.northeastern.edu          |    new .signature slogan        |
 -----------------------------------------------------------------------

-- 
 -----------------------------------------------------------------------
| Paul Steckler                       |  Desperately seeking clever     |
| steck@dworkin.ccs.northeastern.edu  |    new .signature slogan        |
 -----------------------------------------------------------------------
From: toreh@bootes.sds.no (Tore Haraldsen)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS cookies
Date: 29 Dec 92 12:36:58 GMT
Organization: Statens Datasentral A/S, SDS, Norway

In article <1992Dec14.222036.25546@twg.com> hyung@twg.com writes:
>
>Unfortunately, the cookie is not THAT opaque.  A lot of clients do
>care about what is inside the cookie, including Sun's.  A couple of months
>ago I posted a similar problem to this group describing a problem where
>a 'ls' from a Sun client kept on listing the same set of files again
>and again.  It turned out that although my cookies were increasing from 0
>onward, the 32-bit word (cookie) was not in network byte order.  The
>VAX NFS server, having a different integer representation than that of
>Sun's, sent the cookie in its native representation thinking that the
>cookie is opaque, which turned out to be not true.  Consequently, the
>client was seeing cookies with some huge values and in a strange order.
>Changing the byte order of the cookie on the server pleased the client
>and resolved the problem.
>
I saw something strange while accessing a CD-ROM over NFS from my PC:

in a directory with a huge amount of files, I could only see abt. the
first 40-50% of the files. The server was an Ultrix box. Could this be
some of the same syndrome??

-- tore
-- 
------------------------------------------------------------------------
Tore Haraldsen, Statens Datasentral A/S - SDS, Norway
email: toreh@bootes.sds.no
From: rstevens@noao.edu (W. Richard Stevens)
Subject: more info requested on dosynctodr
Keywords: xntp3, dosynctodr
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Date: Sun, 3 Jan 1993 15:19:13 GMT

Just wondering if anyone can give any additional information on
just what the "dosynctodr" kernel flag does in SunOS, and why
it should be set to 0.

Also, the tickadj(8) man page says that it must be set off for
SunOS 4.0--is that still true for 4.1.3?

Lastly, is there any way to set tickadj and dosynctodr when
building the kernel (I couldn't find them defined in any of
the .c files that you can change) or do you need to run tickadj
each time a new kernel is built?

	Rich Stevens  (rstevens@noao.edu)
Newsgroups: comp.protocols.time.ntp
From: dglattin@trirex.com (Dennis Glatting)
Subject: loops
Organization: Trirex Systems Inc.
Date: Mon, 28 Dec 1992 20:04:53 GMT


In RFC1119 there is a small discussion regarding loops where it is stated  
that loops are bad.  I assume that it is speaking in reference to a group  
of NTP servers all peered to one another.

My questions are:  What are loops?  Why are they bad?  If I had a group of  
four (4) servers all peered to each other is that bad?  (In this case each  
of the four are servers to a primary source.)

--
Dennis P. Glatting / Sr. Technical Manager / Trirex Systems Inc.
315 Post Road West / Westport, Connecticut 06880 / (203)221-4600
dennis_glatting@trirex.com (NeXTmail Ok)
Member League for Programming Freedom
Newsgroups: comp.protocols.time.ntp
From: owen@astro.washington.edu (Russell Owen)
Subject: ntp or xntp for VAX/VMS?
Followup-To: comp.protocols.time.ntp
Organization: University of Washington
Distribution: na
Date: Mon, 21 Dec 1992 17:47:00 GMT

Can anyone recommend an implementation of npt (or xntp or anything) for
VAX/VMS? I will soon have a GPS radio clock (from Datum) and wish to set up
a stratum 1 server with the ntp software reading the clock. At present, I
use Multinet's ntp server software, but I have to read the radio clock
myself (that's OK, but ntp can do it better).

If you know of such software, two additional bits of information would also
be appreciated, should you know the answers:
- can one modify the clock-reading code (I need to make minor mods)
- how difficult is it to set up the software?

Thank you for any pointers. I'll post a summary of responses.

Russell Owen
owen@astro.washington.edu