HDTenEightyP/NetNews huggingface dataset:
From: eichin@athena.mit.edu (Mark Eichin)
Newsgroups: comp.protocols.time.ntp
Subject: Re: Ntpdate Xntpdc Xntpd Troubles
Date: 22 Jan 1993 18:36:03 GMT
Organization: Massachusetts Institute of Technology
Distribution: inet
	<2B5B1D41.6033@news.service.uci.edu> <1993Jan19.180901.28425@sura.net>
NNTP-Posting-Host: tweedledumber.cygnus.com
In-reply-to: jmalcolm@sura.net's message of 19 Jan 93 18:09:01 GMT

>> I think this one has been around for a while. (Fixed in Solaris 2?)
	Not in 2.0, nor in 2.1:
ntp		123/tcp				# Network Time Protocol

Frankly, I haven't found *anything* that was "fixed" in Solaris 2.0 --
unless you mean what they mean when they say a cat is "fixed"...
				_Mark_ <eichin@athena.mit.edu>
				MIT Student Information Processing Board
				Cygnus Support <eichin@cygnus.com>
ps. 2.1 may be better. I'll find out soon.
pps. Has anyone ported xntp3 to Solaris? I'm trying quick pass through
adding header files, switching b* to mem*, and using sigprocmask, but
if you've done it already, I'd like to hear about it...
Newsgroups: comp.protocols.time.ntp
From: Jim-Miller@suite.com
Subject: Clock adjustment interval
Reply-To: Jim-Miller@suite.com
Organization: Suite Software, Dallas, Anaheim, La Mesa.
Date: Tue, 26 Jan 1993 22:59:05 GMT

I see in the following comment and #define in the source code for xntp3:

/* Note that these are appropriate for a crystal time base.  If your
 * system clock is line frequency controlled you should read the
 * specification for appropriate modifications.  Note that the...
 */
..
#define	CLOCK_ADJ	0	/* adjustment interval: 2**0 = 1 */
..


But on page 40 of RFC-1305 there is a table (Table 6) with the following:

__________________________________________________________________
|Parameter             Name              Crystal          Mains  |
|----------------------------------------------------------------| 
|Adjustment Interval   CLOCK.ADJ          4 sec            1 sec |


Which of these is incorrect, the comment, the code, or Table 6?  Is a 1 second  
adjustment interval ok for most modern workstations?

Thanks,

Jim-Miller@suite.com
From: ken@sdd.hp.com (Ken Stone)
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp on HP 710 running HP-UX 8.05 - problems
Date: 21 Jan 93 20:11:33 GMT
Distribution: inet
Organization: The Internet


For those of you on the list ... this was asked of me by David when the
latest stuff bombed oh HP-UX.

> xntpd failed to compile due to the fact that we seem to be missing 
> the following two files:
> 
> refclock_as2201.c: 25: Can't find include file stropts.h
> ./include/sys/clkdefs.h: 6: Can't find include file sys/ioccom.h
> 
> I can't find either file anywhere on our system. Is our system lacking,
> or is xntp expecting things that it should not expect? 
> 
> I am trying to build NTP Version 3....

The problem is with the new clock driver refclock_as2201.c ... the ifdef
that enables the Austron code is a bit low :-)  Its include files start
making assumptions beyond HP-UX's means (ie STREAMS).  Attached is a patch
to just scoot up the ifdef and make everyone happy.

  -- Ken

P.S. Dave Mills ... did you really mean "just plain ole diffs" or just 
     "no fancy GNU" stuff ?  This one is still a context since the plain
     ole really ugly diff wasn't very meaningful.


*** xntpd/refclock_as2201.c.orig	Thu Jan 21 11:52:15 1993
--- xntpd/refclock_as2201.c	Thu Jan 21 11:52:35 1993
***************
*** 21,32 ****
  #include "ntp_refclock.h"
  #include "ntp_unixtime.h"
  
  #include <stropts.h>
  #include <sys/clkdefs.h>
  #include "ntp_unixtime.h"
  #include <sys/ppsclock.h>
- 
- #if defined(REFCLOCK) && defined(AS2201)
  
  /*
   * This driver supports the Austron 2201 GPS Timing Receiver
--- 21,32 ----
  #include "ntp_refclock.h"
  #include "ntp_unixtime.h"
  
+ #if defined(REFCLOCK) && defined(AS2201)
+ 
  #include <stropts.h>
  #include <sys/clkdefs.h>
  #include "ntp_unixtime.h"
  #include <sys/ppsclock.h>
  
  /*
   * This driver supports the Austron 2201 GPS Timing Receiver
From: jones@HERMES.CHPC.UTEXAS.EDU
Newsgroups: comp.protocols.time.ntp
Subject: Solaris 2.1
Date: 27 Jan 93 02:14:53 GMT
Distribution: inet
Organization: The Internet



Solaris does not add a "_" to kernel variables.   It defines
the kernel variables "tickadj", "dosynctodr" and, "noprintf".
It does not define "tick".

The default tickadj value is 10000 us.   

I don't know what to use for tick.  Does anyone have any ideas.
What about sysconf(_SC_CLK_TC)?

settimeofday only set the second part of the time you must use adjtime
to set the micro second part of the time.

Sun had fixed gettimeofday to return the full micro second time.
Solaris 2.0 only return the time to 10 ms.

I am fairly close to having a working version of xntpd for Solaris 2.1.

Would anyone like to try it out before I send Mills the patches?

Bill Jones
Newsgroups: comp.protocols.pcnet,comp.os.msdos.programmer
From: rrwood@canrem.com (Roy Wood)
Subject: Lantastic SDK?
Organization: Canada Remote Systems
Distribution: na
Date: Sun, 24 Jan 1993 16:25:47 GMT

Hopefully this is the right group(s) for this question....

I'm interested in doing some programming that involves exchangin information
over a Lantastic network.  Conceptually, it's similar to the idea of the
network "chat" program supplied with the hardware, so I know that it is
possible to do so.

My question is, do the Lantastic people make some sort of software
developer's kit available?  Or is it all proprietary?

I've checked the local bookstores, and they don't seem to know of any books
on the subject (though there are a number for Novell networks).

Also, the meagre manual supplied with the LAN is intended for sheep-like users,
not anyone interested in hacking it.

Thanks for any help-- even a friendly RTFM if you can tell me which FM....

-Roy
From: epstein@trwacs.fp.trw.com (Jeremy Epstein)
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Date: 28 Jan 1993 15:51:07 -0800
Organization: TRW Systems Division, Fairfax VA
NNTP-Posting-Host: ftp.uu.net
Keywords: POSIX, 1003.2
X-Submissions: std-unix@uunet.uu.net

Submitted-by: epstein@trwacs.fp.trw.com (Jeremy Epstein)

mclemore@edsel.eng.gtefsd.com (Ken McLemore) writes:
>i'm looking for a POSIX convention for manual pages (Section 1,2,3,4,5,8)
>and 1003.1 alludes to 1003.2 as possibly supplying the manual page
>conventions.  does 1003.2 address this issue and what is the current status
>of 1003.2 (eg. draft, being published, etc) ?

1003.2 doesn't have "manual page" conventions per se, although
commands are described in a form somewhat similar to manual pages.

1003.2 is published, and available from IEEE for US$95 (request
a copy of IEEE Std 1003.2-1992).

-- 
Jeremy Epstein			Internet: epstein@trwacs.fp.trw.com
Trusted X Research Group	Voice: +1 703/803-4947
TRW Systems Division
Fairfax Virginia


Volume-Number: Volume 30, Number 48
From: norcott_bill@tandem.com (Bill Norcott)
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Date: 28 Jan 1993 15:52:56 -0800
Organization: Tandem Computers, Inc.
Reply-To: norcott_bill@tandem.com (Bill Norcott)
NNTP-Posting-Host: ftp.uu.net
Keywords: POSIX, 1003.2
X-Submissions: std-unix@uunet.uu.net

Submitted-by: norcott_bill@tandem.com (Bill Norcott)

In article <1k9b4bINN643@ftp.UU.NET>, mclemore@edsel.eng.gtefsd.com (Ken McLemore) writes:
> i'm looking for a POSIX convention for manual pages (Section 1,2,3,4,5,8)
> and 1003.1 alludes to 1003.2 as possibly supplying the manual page
> conventions.  does 1003.2 address this issue and what is the current status
> of 1003.2 (eg. draft, being published, etc) ?

The man utility says: "The man utility shall write information about
each of the name operands.  If name is the name of a standard
utility, man shall at a minimum write a message describing the
syntax used by the standard utility, its options, and operands.  If
more information is available, the man utility shall provide it in
an implementation-defined manner".

The format of the text is implementation defined, i.e. there are no
"manual page conventions" other than for minimum content.  It is 
also interesting that man does not have to provide descriptions of
system calls or anything else that is not a POSIX.2 utility.

I believe that POSIX.2 Draft 12 has already been balloted and approved
and that it is officially an IEEE standard.
-- 
Bill Norcott			GUARDIAN POSIX project
Tandem Computers, Inc.		
10600 N. Tantau Avenue		PHONE:  (408) 285-3253
Cupertino, CA   95014		EMAIL: norcott_bill@tandem.com

Volume-Number: Volume 30, Number 49
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: IMPORTANT: POSIX threatens our use of l
Date: 23 Jan 1993 18:35:27 -0800
Organization: U.S. Army Ballistic Research Lab, APG MD.
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)

In article <1js17fINNenp@ftp.UU.NET> davecb@nexus.yorku.ca (David Collier-Brown) writes:
>  I'd like to follow the implied RFC model a bit closer and define a
>protocol.  You know, like ``first you open the file, then read or write
>for a while, then close''.

Well, gee, once you look at it that way, the spooler interface ought to
be something like:
	cp print_me /dev/spool
where the /dev/spool filesystem takes care of assigning unique queue names,
etc. and for example
	ls /dev/spool/status | grep "^$MY_UID"
would show how your jobs are doing.
Of course that's a bit simplistic, but why should we even THINK about
introducing a new, different protocol for some set of open/read/write/close
actions when we already have a general one?  (Or should have.)


Volume-Number: Volume 30, Number 39
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: 1003.7.1/Palladium/Existing Practice
Date: 21 Jan 1993 10:30:25 -0800
Organization: U.S. Army Ballistic Research Lab, APG MD.
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)

In article <1jhvrnINNrdm@ftp.UU.NET> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>  Also, there was already precedent set within POSIX by the POSIX.2
>inclusion of lp(1) as a command line interface for printing.  This has
>been studiously ignored by the vendors promoting Palladium --

It's been a while since I've seen POSIX.2 drafts, but unless something
has radically changed from existing "lp" practice, one should note that
there need be little connection between an interface such as "lp" and
the guts of a spooling system.  As previously noted, MDQS includes
Bourne shell scripts implementing useful subsets of "lp" and "lpr"
even though the "lp"/"lpr" user requests all get translated into MDQS-
specific operations within these implementations.  Presumably something
similar could be done to provide "lp" functionality for any reasonable
UNIX/POSIX spooling system.


Volume-Number: Volume 30, Number 34
From: bartley@spss.com (Dennis Bartley)
Newsgroups: comp.std.unix
Subject: Select
Date: 23 Jan 1993 10:01:38 -0800
Organization: SPSS Inc.
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: bartley@spss.com (Dennis Bartley)

Can anyone tell me if select() is part of POSIX?

Volume-Number: Volume 30, Number 37
From: jason@jazz.cnd.hp.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Date: 28 Jan 1993 11:17:01 -0800
Organization: HP-Network and Systems Management Division
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: jason@jazz.cnd.hp.com (Jason Zions)

In article <1hqil1INN8tg@ftp.UU.NET> casey@anchovy.wpd.sgi.com (Casey Schaufler) writes:
> I thought the audit commands were being done as an addendum to 1003.2.
> Has this idea been dropped?

>All of 1003.6 should be considered an addendum.

Almost. 1003.6 is actually an *amendment*, and to IEEE Std 1003.1-1990. The
putative audit commands would be developed in a separate standard which
would be an amendment to IEEE Std 1003.2-1992.

Jason Zions
Chair, 1003.8 Transparent File Access

This is not an official statement of The Hewlett-Packard Company. No war-
ranty is expressed or implied. The information included herein is not to be
construed as a committment on HP's part. Save a tree - disband an ISO working
group today.

Jason Zions			The Hewlett-Packard Company
Colorado Networks Division	3404 E. Harmony Road
Mail Stop 102			Ft. Collins, CO  80525  USA
jason@cnd.hp.com		(303) 229-3800



Volume-Number: Volume 30, Number 43
Xref: sparky comp.std.unix:531 comp.realtime:1629
From: davecb@nexus.yorku.ca (David Collier-Brown)
Newsgroups: comp.std.unix
Subject: Re: IMPORTANT: POSIX threatens our use of l
Date: 23 Jan 1993 10:02:23 -0800
Organization: York University
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: davecb@nexus.yorku.ca (David Collier-Brown)

geoff@tyger.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
>Maybe we should just define a printing API. Nail down a really
>straightforward interface (just half a dozen calls or so), then divvy
>up the work to create a SunOS shared lib for Solaris 2.x, plus one for
>SunOS 4.1.x, a DLL for MS Windows, a static lib for BSD386/386bsd (and
>linux?), one for Ultrix etc. Thoughts?

  I'd like to follow the implied RFC model a bit closer and define a
protocol.  You know, like ``first you open the file, then read or write
for a while, then close''.
  A little more formally, `` open [read*|write]* [seek [write*|read]] close''.

  An API is necessary and about two thirds of sufficient.  A protocol is
odd-loking, but sufficient.  To make it more palatable, you could easily
include a call interface in a common language.
  The advantage of doing the extra work is in making any ordering, temporal
effects and prerequiesites explicit.  This leads to easy implementation of
programs using the interface.

--dave (who is notably lazy, and so goes to great lengths
	to avoid future work) c-b
-- 
David Collier-Brown,  | davecb@CCS.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  | York postmaster and
CANADA. 416-223-8968  | occasional sendfail(8) consultant.


Volume-Number: Volume 30, Number 38
From: jason@cnd.hp.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Posix compliance (application)
Date: 28 Jan 1993 11:19:53 -0800
Organization: Hewlett Packard, Network & System Management Division
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: jason@cnd.hp.com (Jason Zions)

>Where may I obtain information about certifying that my *application* is
>POSIX compliant?  I know about the NIST, X/Open and AT&T conformance suites, 
>but as I read about those, I surmise that they are geared to *operating system*
>compliance as opposed to application compliance.  Can someone assist me?

Ah, yes, the "POSIX Conforming Application" question.

This is a much tougher thing to test, although I seem to recall Mindcraft
talking about having a product that did this; the talk was back in April
1990 (the POSIX Snowbird meeting, anyway).

An application is said to strictly conform to 1003.1 if it uses only things
defined by that standard and the ones it relies on (e.g. ISO C). So, a test
suite would have to make sure that every time your application invokes
open() that you are using it in a way for which the standard defines
functionality. Recall that there are many times the standard is deliberately
silent on the way a conforming implementation behaves when an application
takes some action; if your application ever takes that action, it no longer
strictly conforms. For some interfaces (perhaps not open()), this checking
may be equivalent to the Stopping Problem; I suspect full verification of
application conformance is NP-Complete.

1003.2 will be even worse.

Jason


Volume-Number: Volume 30, Number 44
From: tomw@ccadfa.cc.adfa.oz.au (Tom Worthington)
Newsgroups: comp.std.unix
Subject: Government Open Systems Document for Comment
Date: 25 Jan 1993 07:23:40 -0800
Organization: Australian Defence Force Academy, Canberra, Australia
NNTP-Posting-Host: ftp.uu.net
Keywords: POSIX, AAP, NIST, COSE, GOSIP, XPG, OSI, Open Systems
X-Submissions: std-unix@uunet.uu.net

Submitted-by: tomw@ccadfa.cc.adfa.oz.au (Tom Worthington)

COMMONWEALTH OPEN SYSTEMS ENVIRONMENT PROFILE (COSE)

Following the Commonwealth Government's commitment, made in the March 1991
Industry Statement, to move to open systems the Information Exchange
Steering Committee (IESC) has been working on the development of an Open
Systems Environment Profile for use by agencies in establishing a more
open environment in government computing.

The IESC's Open Systems Subcommittee (OSSC) has prepared a draft COSE, a
copy of which is attached for your information [see note below]. The COSE
profile utilises the Application Portability Profile (AAP) developed by
the National Institute of Standards and Technology (NIST) of the US
Department of Commerce. The draft has been compiled in consultation with a
number of Commonwealth agencies represented on the OSSC and industry
through the Australian Information Industries Association (AIIA).

The draft specification is issued for comment and we would welcome your
assistance in reviewing this document and providing any comments, by close
of business February 12 1993, direct to the COSE Project Manager Ms Ann
Whitehead, ITSG, Department of Finance, Newlands Street, Parkes, ACT 2600
and who can be contacted on ph 06 263 3552 or fax 06 263 2276 [see e-mail
address below].

The IESC is also formulating more specific guidance on the implementation
of the Open Systems Environment Profile for all Commonwealth Departments
and Agencies. It is planned that, following the receipt of comments, and
amendments to the draft, the official launch of COSE will take place on 29
March 1993 at an IESC sponsored seminar in Canberra.

Allan Maclean
Chairman 
IESC Open Systems Subcommittee
18 December 1992

DEPARTMENT OF FINANCE, Newlands Street, Parkes, A.C.T. 2600, Australia
Telephone: Canberra (06) 263 2222, Telex: 62639, Fax: (06) 273 3021       

X.400:  g=Ann;s=Whitehead;o=Finance;p=ausgovfinance;a=Telememo;c=au
Internet E-mail:  Ann.Whitehead@finance.ausgovfinance.telememo.au

------------------------------------------------------------------------

Posted with permission from the IESC, as a community service by:
Tom Worthington, Director of the Community Affairs Board, Australian
Computer Society Incorporated (e-mail: tomw@adfa.oz.au).

NOTE: A text-only copy of the Draft COSE is available electronically, from
the archive at archie.au in file /ACS/COSE-Draft via ftp and netfetch.
Please direct queries and comments on the draft to the IESC at the
Department of Finance.

Standards trivia: Kim Fenley, the Defence Department's OSI expert,
suggests that the acronym for the profile (COSE) should be pronounced
"kozzi", as in the Australian slang for a swimming costume (cossie).



Volume-Number: Volume 30, Number 40
From: jason@cnd.hp.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Select
Date: 28 Jan 1993 11:26:44 -0800
Organization: Hewlett Packard, Network & System Management Division
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: jason@cnd.hp.com (Jason Zions)

>Can anyone tell me if select() is part of POSIX?

Not yet, but it should eventually be.

The System Interface Coordinating Committee is composed of the chairs of the
POSIX working groups whose standards are destined for ISO 9945-1; that is,
1003.1, 1003.4, 1003.6, 1003.8, 1003.10, and 1003.12. It also includes the
chairs of any existing language binding groups working on bindings for
9945-1 components; that is, 1003.5 and 1003.9/1003.19.

The 1003.12 working group (Sockets, XTI/TLI) asked SICC to help resolve the
issue of where select()-like functionality belongs (in terms of working
group with expertise to develop it), threatening to add it themselves if no
other group took it on. After some debate, the 1003.1 working group was
identified as the responsible party.

Some future revision of the 1003.1 standard, whether by amendment or
revision, will include something like select(). I do not know the current
status of the work; the newly-confirmed chair of 1003.1, Paul Wanish, should
be asked that question. (If I remember, I'll ask him myself at the next SICC
meeting in April.)

Oh, yeah; besides chairing 1003.8, I also chair the SICC, serve on the PMC,
and am vice-chair (acting chair) of the DSSC (Distributed Services Steering
Committee). I don't sleep much during POSIX meetings.

Jason


Volume-Number: Volume 30, Number 46
From: duke@osf.org
Newsgroups: comp.std.unix
Subject: There is a printing API in 1003.7.1 (Was Re: IMPORTANT: POSIX threatens our use of l)
Date: 22 Jan 1993 10:58:04 -0800
Organization: Kithrup Enterprises, Ltd.
Reply-To: duke@osf.org
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: duke@osf.org

geoff@tyger.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
>Actually, the biggest pain in the ass is not the printing commands, or
>even the administration model. It's the absence of a standard printing
>API. ....
>It's been a while since I looked at the palladium doc (I've just
>pulled DEC-palladium-overview.ps over from gatekeeper.dec.com - it's in
>/.3/net/info/ietf/print-wg - and I'll read it over), but I don't recall
>there being any kind of API which would be suitable for cross-platform
>uses. 

Palladium defines two APIs you could use to write print clients.  One 
is real high level--each command has a function version.  The other
is much lower level.  It lets you build up print requests and submit
them to a spooler.  Chapter 4 of the POSIX draft is this second api.

>Maybe we should just define a printing API. Nail down a really
>straightforward interface (just half a dozen calls or so), 

The Palladium one is more complicated than that, since there's so
much more stuff to do in Palladium than in, for example, lpr/lpd.

Bob Robillard, Technical Editor 1003.7.1, duke@osf.org


Volume-Number: Volume 30, Number 36
From: geoff@tyger.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.std.unix
Subject: Re: IMPORTANT: POSIX threatens our use of l
Date: 21 Jan 1993 10:31:20 -0800
Organization: SunSelect
Reply-To: geoff@tyger.East.Sun.COM
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: geoff@tyger.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)

Actually, the biggest pain in the ass is not the printing commands, or
even the administration model. It's the absence of a standard printing
API. If you don't believe me, take a look at the sources for pcnfsd.
To determine what printers are available, queue jobs, cancel jobs,
list queues, etc. I have to spawn commands (making sure that I
get the location right - is "lpc" in /usr/bin, /usr/etc, or /usr/ucb
on this system?) and parse the output, hoping that the vendor hasn't
tweaked the output format or localized things in some way. (Companies that
are really good about preserving the syntax of commands seem to think
nothing of changing error messages, etc.)

It's been a while since I looked at the palladium doc (I've just
pulled DEC-palladium-overview.ps over from gatekeeper.dec.com - it's in
/.3/net/info/ietf/print-wg - and I'll read it over), but I don't recall
there being any kind of API which would be suitable for cross-platform
uses. Plus as Marcus said, it's still pretty vaporous..

Maybe we should just define a printing API. Nail down a really
straightforward interface (just half a dozen calls or so), then divvy
up the work to create a SunOS shared lib for Solaris 2.x, plus one for
SunOS 4.1.x, a DLL for MS Windows, a static lib for BSD386/386bsd (and
linux?), one for Ultrix etc. Thoughts?

---
Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)

Volume-Number: Volume 30, Number 35