From: geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.protocols.nfs
Subject: Re: Who HAS PCNFSD compiled for System V
Date: 6 Oct 1992 14:20:31 GMT
Organization: SunSelect
NNTP-Posting-Host: tyger.east.sun.com

Quoth jallen@oat2.standard.com (John Allen) (in <BvnzDv.GH9@oat2.standard.com>):
#
#We need several versions of PCNFSD version 2 for several machines.
#Does anyone have PCNFSD version 2 compiled for any of the following.
#
#             AT&T 3b2 3.2.3 Unix System V
#             AT&T 386 3.2.3 Unix System V
#             Sequent PTX 1.31 (System V version of Dynix)
#
#
#We would need source modifications and makefiles so we can taylor
#to our environment.  
#------------------------
#Sun - if you are listening please take note to the following.
#
#Please invest in PCNFSD development, or turn it over to
#the PC based NFS product vendors to create a standard.
#If you do not have the resources, then pay someone to do it.

PCNFSD was developed by the Sun group responsible for PC-NFS, now
SunSelect. In other words, we are a "PC based NFS product vendor".
PCNFSD is the standard, and is documented in the X/Open PC Interworking
Group's (PC)NFS Specification. We do invest in PCNFSD.

#Keep a repository of changes, modifications, and versions
#like they do for Kermit.  Make this available to all.
#Source must compile, Period.  Otherwise the end user sees
#your product as non-functional.

We do maintain a repository of source code. If you have read the
documentation that accompanies the pcnfsd kit, you will see that we
have always encouraged contributions of ports, bug fixes, enhancements,
etc. The source code is available from three official FTP archives
world-wide as well as from dozens of unofficial sites - check "archie"
for details.

The biggest peoblem we face is that there is no standard API for
printing. IMHO, this is a major issue which POSIX should address. In
the absence of a standard API, PCNFSD must implement printing services
by executing platform specific printing programs and attempting to
parse the text output. This is extremely difficult to do in a portable
fashion: a vendor who would never dream of tweaking an API will think
nothing of introducing a "cosmetic" change to the output of a command.

Furthermore, many vendors provide a suite of proprietary printing
programs together with a set of shell scripts which attempt to emulate
some standard - usually SVR3. These scripts are often very poorly
written and inadequately tested.

The bottom line is that PCNFSD is *much* harder to port between
Unix versions than, say, kermit. For this reason, we prefer
major system vendors to do their own ports. For example, people
at IBM have just completed a port to AIX which uses the "native"
printing services of that platform, and other vendors also
have developments under way. A few, unfortunately, seem indifferent
to the problem. In these cases, we must all rely on the efforts
of our peers.

#It is very hard for end users to get software modifications
#from many vendors.  If we are to use PCNFSD then you must make
#it available as part of the LAN solution.  Otherwise drop out
#and let someone else do it.

It is available. The source code has always (since 1986) been freely
redistributable.

If you use a box from company XYZ as an NFS server, your first step in
obtaining a copy of PCNFSD should be to contact the customer support
organization. If they don't hear your requests, they have no incentive
to do anything about it. It should be obvious that a vendor-supported
version of PCNFSD is going to be preferable to a hacked-up kit pulled
off the net, however competent the hacker.

If the vendor is unresponsive, check the version on the archives.  If
it doesn't build on your platform, check with comp.protocols.nfs.  In
some cases we (SunSelect) will be able to provide help directly; we
have a number of binary versions which have been contributed by various
people (but which we cannot put up on the archives); we can also put
you in touch with support or engineering staff at various vendors.
(Sometimes customer support simply doesn't know.....)

#Make less assumptions about your end users. Not all are going to
#be using Sun's or even BSD type machines for that fact.  YP is not
#always in good shape and many of us do not use it anyway.

I normally test a new version on five systems before I push it out:
a Sun 386i (to cover older Sun), Solaris 1.0.x (current Suns), Solaris
2.x (future Suns), BSD/386 (generic BSD) and UHC SVR4 (generic SVR4).
For Ultrix and AIX I rely on DEC and IBM, who are very cooperative.
Various folks at AT&T have PCNFSD upon on 3B's. And so on.

#Many of
#your customers see the PC-NFS solution tied to needing a Sun server.
#This should not be the case.  PC-NFS should be an open systems product.

It is. We have many customers using PC-NFS without a single Sun in their
network.

#If Sun does not think this way then it easily becomes the challenge
#for the other PC based NFS products to take on.  We need server
#based authentification, printing, and other services, PCNFSD 
#is part of the puzzle.

We'd be delighted if other PC-based NFS vendors contributed code,
enhancements, etc. In fact at Connectathon in 1991 we all got together
to ratify the spec for PCNFSD V2 and agreed to support it....

--
Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)
-----------
News software that enforces a four-line .signature limit is responsible for
the fact that these postings just go on and on and on and seem to end in mid-
Newsgroups: comp.protocols.nfs