HDTenEightyP/NetNews huggingface dataset:
From: geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.protocols.nfs
Subject: Re: PC-NFS 4.0 and MS Windows--telnet windows only painting halfway
Keywords: PC-NFS windows telnet
Date: 16 Apr 92 23:21:36 GMT
Reply-To: geoff@east.sun.com (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Organization: Sun Microsystems PC-NFS Engineering
NNTP-Posting-Host: hinode.east.sun.com

Quoth leoh@hardy.hdw.csd.harris.com (Leo Hinds) (in <7919@travis.csd.harris.com>):
#In article <hz01930.703255404@cygnus> hz01930@hx.deere.com (Jay D. Anderson) writes:
#>This problem occurs on both 3.0 and 3.1 versions of Windows.  About 50% of the
#>time, telnet windows will not repaint completely after a return is typed in.
#
#This problem IS mentioned in the readme file ... I only assume that it implies 
#a fix is imminent.

Yes, it is. We didn't nail it before FCS because it was so
intermittent - it seems to be video driver and speed related.

I hope to push out a fix early next week.

Geoff
------------------------------------------------------------------------------
--         Geoff Arnold, PC-NFS architect (geoff.arnold@East.Sun.COM)       --
--                 SunSelect, a Sun Microsystems Business                   --
------------------------------------------------------------------------------
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.protocols.nfs
Subject: Re: YPBIND Question
Date: 16 Apr 92 00:15:18 GMT
Organization: Auspex Systems, Santa Clara

>Why did SUN use 0's per default?

Because, when they were first doing machines, that was the default that
*Berkeley* had *BSD* use, as I remember.  It's not as if somebody at Sun
thought "gee, all-0's broadcast addresses would be a Good Idea".

Later, when all 1's became the more popular choice, they incorporated
the 4.3BSD-vintage stuff to support settable broadcast addresses, but
continued to default it to zero out of fear that mixing Suns running the
all-0's old release and Suns running the all-1's new release on the same
network would cause Bad Things to happen. 

Perhaps it wouldn't have, but that's life.

>Did they ever read the Host requirements RFC?

I'm sure they did, but probably not before drafts of it were even
written.  The date on the copy of RFC1122, "Requirements for Internet
Hosts -- Communication Layers" I have here has a date of October 1989;
SunOS 4.0 came out before then.

If it were the case that essentially all Suns out in the field at the
time 4.0 came out were capable of being told to use all-1's broadcast
addresses, the release of 4.0 (which came out somewhere in 1987 or 1988,
as I remember) might have been the time to change, although there would
probably have to have been a Large Warning Label on the release notes
saying "change the broadcast addresses on your 3.x machines or die, and
by the way, if you're running a release that can't support the new
broadcast address, upgrade or die".  I'm not sure whether support for
settable broadcast addresses made its first appearance in 3.2 or in a
later release.

In some ways, RFC1122 is nice, in that it gives Sun a chance to say
"look, we're changing the broadcast address to all 1's, we have to, we
don't have any choice; if that causes problems on your network, tough
darts, fix it or die".  At times being able to wield a standard to club
the more recalcitrant portions of the customer base into submission, in
order to please other portions, can be very handy, indeed....

(It's been ages since I've done a "suninstall" - or an "NSinstall", for
that matter :-) - so I don't know whether they let you set the broadcast
address nor what they default it to if they do.)
From: brunette@sju.edu (Glenn M. Brunette)
Newsgroups: comp.protocols.nfs
Subject: PC-NFS 4.0 Telnet and Line Drawing
Keywords: ingres pc nfs telnet line drawing
Date: 14 Apr 92 02:36:12 GMT
Organization: Academic Computing, Saint Joseph's University




With the upgrade to PC-NFS 4.0, came a couple suprises with regard to 
telnet.  We have several database applications (Ingres) which use 
line drawing functions for their forms (ie. boxes, lines, etc.).  Before
the upgrade to 4.0, they came up ok.  Since the upgrade, however, it appears
as though telnet no longer looks to ansi.sys, because the line drawings come
up as their character equivalents.  Is there any switch or something which
will correct these problems?? 

We tried running NSCA telnet (CUTCP/CUTE 2.2D) with PC-NFS 4.0, and the
applications came up ok.

Any help would be grealt appreciated,

Thanks in advance,
Glenn


-- 
Glenn M. Brunette, Jr.                             Internet  : brunette@sju.edu
Assistant Systems Manager/Network Analyst              UUCP  : sjuphil!brunette
Academic Computing                                 Telephone : (215) 660-1524  
Saint Joseph's University                                Fax : (215) 660 1536
Philadelphia,  PA,  USA
From: leoh@hardy.hdw.csd.harris.com (Leo Hinds)
Newsgroups: comp.protocols.nfs
Subject: Re: Using DOS BACKUP with PC-NFS mounted drives
Date: 8 Apr 92 14:24:03 GMT
Organization: Harris Computer Systems, Ft. Lauderdale, FL

In article <7462@uqcspe.cs.uq.oz.au> dirk@cs.uq.oz.au writes:
>I am having problems using the standard DOS program, "BACKUP", to
>backup local drives on to a drive mounted under PC-NFS.  

>Any assistance would be greatly appreciated.  I am using DOS 3.3 and
>PC-NFS v3.5c on a 386-25.

The ERRATA (readme.txt) file on the 4.0 disks says (quote WITHOUT permission):

	MS-DOS 5.0 BACKUP COMMAND WORKS INCORRECTLY ON NETWORK DRIVES

	The MS-DOS 5.0 BACKUP command does not work correctly when you attempt
	to back up files to a network drive.

When I called (800)USA-4SUN for details on this index like note in the readme 
file, the person did not know the details, but said they would get back to 
me with more info, as well as answers to other problems/concerns.  

That was 3/26/92 - there was some phone tag & some questions answered, but 3 
items remain unanswered (including the BACKUP question) and my attempts on 
contacting the person at Sun (last done on April 2nd) are still be unanswered.


leoh@hdw.csd.harris.com         	Leo Hinds       	(305)973-5229
Gfx ... gfx ... :-) whfg orpnhfr V "ebg"grq zl fvtangher svyr lbh guvax V nz n
creireg ?!!!!!!? ... znlor arkg gvzr
From: geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.protocols.nfs
Subject: Re: PCNFS 4.0 telnet dies....
Date: 8 Apr 92 21:22:22 GMT
Reply-To: geoff@east.sun.com (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Organization: Sun Microsystems PC-NFS Engineering
NNTP-Posting-Host: hinode.east.sun.com

Quoth hak@kodak.kodak.com (Al Killenbeck) (in <1992Apr8.124932.2524@kodak.kodak.com>):
#Ok, I upgraded to PC-NFS 4.0, and telnet doesn't work ... I THINK I see the
#"connecting to... escape character" messages, but it's so quick (even on a
#6Mhz AT) that I can't be sure WHAT'S there. ... all I end up with is a 
#blank screen and a blinking cursor.

Time to do a little digging...

From a DOS prompt, type the following:

	telnet 				[no arguments]
	use tracefile c:\tmp\trace.txt	[or whatever]
	set netdata
	set prettydump
	set options
	open <host>			[<host> is the destination]

If you wind up with "a blank screen and a blinking cursor", type
ctrl+] (the telnet escape character) and "quit". Then check the contents
of c:\tmp\trace.txt.

Under Windows, double click the "Telnet" icon and click the "OK"
button without typing in any arguments. You may want to maximize
the window. Then proceed as above.

Most of the telnet command stuff is the same as in 4.3BSD (which
is where a lot of the code came from).

Geoff

------------------------------------------------------------------------------
--         Geoff Arnold, PC-NFS architect (geoff.arnold@East.Sun.COM)       --
--                SunConnect, A Sun Microsystems Business                   --
------------------------------------------------------------------------------
From: slang@waikato.ac.nz
Newsgroups: comp.protocols.nfs
Subject: RPC request ID caching.
Date: 8 Apr 92 12:03:01 +1200
Organization: University of Waikato, Hamilton, New Zealand

I am looking for some example code, or just general ideas, on caching RPC
request ID's. The data structure I need to access is (from RFC 1057)

struct rpc_msg {
    unsigned int xid ;
    union switch (msg_type mtype) {
    case CALL:
	call_body cbody ;
    case REPLY:
	reply_body rbody ;
    } body ;
} ;

in particular, the line "unsigned int xid;"

How does one actually extract this information from an RPC request. I want to
cache RPC requests, so if they are re-transmitted, they don't get executed more 
than once.

Any pointers/help would be greatly appreciated.

Cheers -

-- 
	   If it's safe -		Steve Lang
	  Test it in Paris		Systems Programmer Analyst
	  Dump it in Tokyo		University of Waikato
	And keep our Pacific		Hamilton
	    Nuclear Free		NEW ZEALAND
					<slang@waikato.ac.nz>
					Ph	+64-7-856 2889 Ext 8341
					Fax	+64-7-838 4066

I am not responsible for my employers opinion (thank heavens,) and neither are
they for mine.
From: rcr@Logix.DE (Rainer Ruppert)
Newsgroups: comp.protocols.nfs
Subject: simulate annother ip-number
Date: 13 Apr 92 10:39:58 GMT
Organization: Logix GmbH, Wiesbaden, Germany

Hi Netters,
is there a solution to the following problem ?

In a Client-Server network a client is working with data located at 
the server, identified by the ip-number. Then another nfs-client
simulates the same ip-number while the original system is cut off.

Some time ago I heard something about a public key encryption at
mount-time-does it help ?

Thank you for your help

rainer
-- 
Rainer Ruppert, Logix GmbH				        rcr@Logix.DE
Moritzstr. 50, D-6200 Wiesbaden            ...!uunet!mcsun!unido!logixwi!rcr
Newsgroups: comp.protocols.nfs
Subject: Re: How to connect a MAC to SGI fileserver.
From: kdb@intercon.com (Kurt D Baumann)
Date: 14 Apr 92 14:55:06 GMT
Reply-To: kdb@intercon.com (Kurt D Baumann)
Organization: InterCon Systems Corporation

In article <moty.703072096@techunix.technion.ac.il>, 
moty@techunix.technion.ac.il (Moty Gerner) writes:
> Hi net-people !
> 
> We have here three MAC IIsi connected to an appletalk net. We also intend to
> buy some IRIX indigo SGI stations using one of them as a fileserver.

We have one Indigo in house.  You probably should purchase whatever ethernet 
hardware you need for your si's (several companies make cards, shop for 
price, they are starting to look much the same, though we have some 
favorites).  Then buy one of the two following packages:

NFS/Share, InterCon Systems
MacPathWay NFS Client, Wollongong Group

> Now, we want to use NFS and mount the fileserver disks on the MACs.
> My question is - how do we do this ? What hardware/software do we need ?
> The word is such connection is very slow, is this true ?
> 

This is not true when running over an ethernet using NFS.

> Thanks
> 
> Moty Gerner.

Have fun.



Kurt Baumann                  Creators of fine TCP/IP Products
InterCon Systems            For the Macintosh
From: halvard@trd.sdata.no (Halvard Halvorsen)
Newsgroups: comp.protocols.nfs
Subject: Re: number of nfsd to run
Date: 15 Apr 92 15:42:40 GMT
Organization: Skrivervik Data A/S

In article <1992Apr13.184849.11921@news.larc.nasa.gov>, eckman@eos1.larc.nasa.gov (Richard Eckman) writes:
|> 
|>   I suspect that this has been asked before, but I've just started reading
|> this newsgroup...
|>   I recently added three more Wren 8 disks to our DECsystem 5000/200 file 
|> server which is now exporting a total of nine filesystems via nfs to six 
|> 'client' DECstation 5000/200 machines.  The increase in exported filesystems 
|> doesn't appear to be placing an obvious burden on the server, but response 
|> time seems to be a bit slower when doing disk operations.  
|>   I've never been able to determine when it is appropriate to run more 
|> than four nfs daemons on the nfs server machine.  The ultrix nfs manual
|> seems to imply that four is suitable for most situations.
|>   Is there a good rule for determining how many nfs daemons should be
|> running on the server (perhaps, one per exported filesystem)?
|>   Thanks, in advance, for any assistance.
|> 
|> Richard Eckman
|> NASA Langley Research Center
|> Hampton, VA
|> eckman@dobson.larc.nasa.gov

for all of you that has the same question : get a copy of
Sun's Software Technical Bulletin from July 1991; article "nfsd Q&A".
the article is quite general so even if you have another unix than SunOS
it is good reading. doubling from 4 to 8 on a DECsystem 5000/200 should
as far as i read the article be 'no problem' ...


-- 

    0  	   halvard halvorsen - systems consultant - Skrivervik Data A/S
  \/|/\    email  	: halvard@trd.sdata.no
    |      telephone    : + 47 7 59 23 74
   / \/\   fax          : + 47 7 59 23 30
 \/ ___________________________________________________________________



      
Newsgroups: comp.protocols.nfs
From: nick@ee.ryerson.ca (Nick Colonello)
Subject: Re: number of nfsd to run
Organization: Ryerson Polytechnical Institute, Toronto
Date: Tue, 14 Apr 1992 12:39:03 GMT

In article <1992Apr13.184849.11921@news.larc.nasa.gov> eckman@eos1.larc.nasa.gov (Richard Eckman) writes:
>  I suspect that this has been asked before, but I've just started reading
>this newsgroup...

>  I've never been able to determine when it is appropriate to run more 
>than four nfs daemons on the nfs server machine.  The ultrix nfs manual
>seems to imply that four is suitable for most situations.
>  Is there a good rule for determining how many nfs daemons should be
>running on the server (perhaps, one per exported filesystem)?

While running more nfsds may improve performance there is a problem with
running too many.
Since nfsds run in a round-robin fashion (and rapidly) if there are more of
them then there are contexts in the MMU there can be a significant amount
of overhead involved (I know this to be true on Suns and assume it may be true
on DEC systems).
What happens is MMU page tables are constantly being reloaded.
How many contexts are there? On Suns SS1,SLC,IPC,SS1+,ELC,IPX there are 8.
On the SS2 there are 16 (one reason why the SS2 makes a better disk server than
the other desktops). On the 4/470 and other "servers" I believe there are 64.

This is another example of how raw compute power does not necessarily make a
good server.
-- 
#define NAME  "Nick Colonello"
#define WHERE "Ryerson Polytechnical Institute    Phone: 1 416 979-5000 x6102"
#define MAIL  "nick@ee.ryerson.ca or ryelect!nick"
#include <feeble-attempt-at-humour.h>
From: curt@aixwiz.austin.ibm.com (Curt Finch)
Newsgroups: comp.protocols.nfs
Subject: Re: spray
Date: 11 Apr 92 16:39:04 GMT
Reply-To: curt@aixwiz.austin.ibm.com (Curt Finch)
Organization: IBM AWD, Austin, TX

sherwood@space.ualberta.ca  (Sherwood Botsford) said:
> Move over to an ibm Risc 6000
> 
> spray hostname
> 2300 packets per second
> 
> spray -l 1000
> bytes per second 3,500,000 ????!!!

There was a bug in spray on the 6k which I fixed recently, which caused
the timing in between packets to be incorrect.  There is an emergency
fix available from defect support.  It's probably shipped in 2009,
(which isn't out yet,) but I'm not sure.

CUSTOMER:   IBM CORP (USA)
PMR:        7x396,004,000
APAR:       ix21990
DEFECT:     33987
EFIX:       a21990  (Available from Defect Support at 1-800-237-5511.)

curt@aixwiz.austin.ibm.com (Curt L. Finch) | AIX NFS/NIS Field Quality 
My views are unrelated to those of IBM     |       Austin, TX
 "A little rebellion is a good thing now and then" - Thomas Jefferson
From: slang@waikato.ac.nz
Newsgroups: comp.protocols.nfs
Subject: NFS-NDIS/DIS_PKT Compatabiltiy problems
Date: 15 Apr 92 12:28:39 +1200
Organization: University of Waikato, Hamilton, New Zealand

Is there a combination of NDIS, NFS-NDIS and DIS_PKT drivers that work?

I have tried the latest versions of all of the above that I can find;

  Sun Microsystems PC-NFS(R) NDIS Interface Driver
  Version 3.5b    (There doesn't seem to be a corresponding one for PC-NFS 3.5c)

  MAC/DIS to Packet Driver converter loaded. Version 1.10

  Netbind V1.1d

  Protman.sys V1.1f

  Isolan NDIS Driver (1.11) (Makes no difference, my machine still hangs even
  when using the WD NDIS driver.)

NOTE:: Everything works fine if I take out the DIS_PKT Packet Driver Shim. In
this case, PC-NFS seems to work well over the NDIS Driver, but I want a
Packet Driver Shim that will co-exist with SUN PC-NFS.

From a previous message somewhere, it seems that the latest version of DIS_PKT
may actually be 1.13, but it doesn't appear to be on any of the archie listed
archive servers that I can find.

Is anyone outthere successfully running the Packet Driver Shim, and PC-NFS over
NDIS Drivers???

Cheers -

-- 
	   If it's safe -		Steve Lang
	  Test it in Paris		Systems Programmer Analyst
	  Dump it in Tokyo		University of Waikato
	And keep our Pacific		Hamilton
	    Nuclear Free		NEW ZEALAND
					<slang@waikato.ac.nz>
					Ph	+64-7-856 2889 Ext 8341
					Fax	+64-7-838 4066

I am not responsible for my employers opinion (thank heavens,) and neither are
they for mine.
Newsgroups: comp.protocols.nfs
From: megauthi@watcgl.waterloo.edu (Marc E. Gauthier)
Subject: Re: How to connect a MAC to SGI fileserver.
Keywords: IRIX MAC SGI
Organization: University of Waterloo
Date: Tue, 14 Apr 1992 18:13:02 GMT

In article <moty.703072096@techunix.technion.ac.il> moty@techunix.technion.ac.il (Moty Gerner) writes:
>Hi net-people !
>
>We have here three MAC IIsi connected to an appletalk net. We also intend to
>buy some IRIX indigo SGI stations using one of them as a fileserver.
>Now, we want to use NFS and mount the fileserver disks on the MACs.
>My question is - how do we do this ? What hardware/software do we need ?
>The word is such connection is very slow, is this true ?
>
>Thanks
>
>Moty Gerner.

There are a couple of ways to do it.  Probably the best way (throughput-wise)
is to buy Ethernet cards for your Macs, and get some software that turns your
Mac into an NFS client (e.g., NFS/Share Work by Intercon, comment@intercon.com;
I'm not yet familiar with packages available, so I don't if/how many other
companies are offering such software).  Another solution is the "GatorBox"
(sp?), which is a box that connects to both your AppleTalk network and to
Ethernet, and actually makes a translation between AppleShare and NFS to do an
equivalent job; the advantage is that you don't need new software or hardware
on your Macs, but I would think, at the cost of much throughput.  I don't know
about speeds, but ftp'ing from a Mac, I average around 150k/sec (200k/sec
peak), so I would guess that NFS over a direct Ethernet would be of comparable
speed, but this is only a guess.  I think GatorBox is by Cayman, but I don't
have any info about it with me at the moment.

-Marc
-- 
Marc E. Gauthier   +1 613 991 6976 or 993 1384 (work)  +1 819 777 5841 (res)
[Computer Graphics Lab, Univ of Waterloo:  megauthier@watcgl.waterloo.edu]
Autonomous Systems Lab, IIT, National Research Council:  mgauthier@iit.nrc.ca
From: geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.protocols.nfs
Subject: Re: PCNFS port 2049 to 3049 hack possible ?
Date: 13 Apr 92 01:16:45 GMT
Reply-To: geoff@east.sun.com (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Organization: Sun Microsystems PC-NFS Engineering
NNTP-Posting-Host: hinode.east.sun.com

Quoth fr@sunbim.be (in <9204091014.AA01472@voyager.sunbim.uucp>):
#Hello netcitizens,
#
#
#Anyone out there knows a hack to tell PCNFS to use port 3049 rather
#than 2049 for NFS operations ?

RTM, my friend. The "/qNNNN" option on the PCNFS.SYS line does what
you want. In the PC-NFS 4.0 docset, this stuff is in the Reference
Manual on pp.155-157. I don't have a copy of the 3.5 books to hand.

#The NFS-server is a Siemens used for optical archiving. Somehow it's using
#another port....

Well, the only option here is to use a non-standard port for *all*
NFS operations. So if you want to communicate with another NFS server
in addition to the Siemens, you're SOL.....

Geoff

------------------------------------------------------------------------------
--         Geoff Arnold, PC-NFS architect (geoff.arnold@East.Sun.COM)       --
--                 SunSelect, a Sun Microsystems Business                   --
------------------------------------------------------------------------------
From: liam@dcs.qmw.ac.uk (William Roberts)
Newsgroups: comp.protocols.nfs
Subject: Re: Performance: RPC vs. sockets
Keywords: rpc, sockets
Date: 14 Apr 92 09:16:43 GMT
Organization: Computer Science Dept, QMW, University of London

In <2755@media03.UUCP> rla@media03.UUCP (Raymond van der Laan) writes:
>Has anyone ever lokked at differences in performance between
>RPC-calls and communications via the socket interface?

>I sure am interested in the results, if they are not too
>specific for a certain network.

Go to the bottom of the class: what communications services to
you think are used to implement RPC?

In principle, sockets should be faster than RPC in the same way
that assembler should be faster than C - you can sometimes cut corners,
make use of special properties of your program etc. In practice
the whole business is likely to be dominated by the
communication time (unless your RPC mechanism is broken).

--

% William Roberts                 Internet:  liam@dcs.qmw.ac.uk
% Computer Science Department     
% Queen Mary & Westfield College  UUCP:      liam@qmw-dcs.UUCP
% Mile End Road                   Telephone: +44 71 975 5234
% LONDON, E1 4NS, UK              Fax:       +44 81-980 6533
Newsgroups: comp.protocols.nfs,comp.os.msdos.desqview
From: mark@drd.com (resident.alien)
Subject: Re: Desqview/X and PC-NFS
Keywords: Desqview NFS
Organization: DRD Corporation
Date: Fri, 10 Apr 1992 16:47:53 GMT

In article <1992Apr9.181117.5390@athena.mit.edu> chris@blarney.MIT.EDU (T Christopher Murphy) writes:
>Here's what I understand about DV/X networking options.  This comes
>from docs, a pre-release note, and conversation with Quarterdeck tech
>staff, and all the info agrees.  There is support for Novell, NetBIOS,
>and TCP/IP.  Any network option requires a Network Manager and a
>network kernal which you supply.  The Network Managers for Novell (not
>to be confused with Novell's LAN Workplace) and NetBIOS are included
>with DV/X, the TCP/IP Network Manager is optional (grrrrr...).  The
>kernals supported for TCP/IP are Novell's and FTP's.  Packet drivers
>alone are not enough.  I suspect that for any future supported kernals
>the Network Manager will still be needed.


so FTP's and Sun's claimed adherence to NDIS doesn't buy anything here?
-- 
mark.lawrence@drd.com                                     (918)743-3013
DRD Corp., 5506 South Lewis Ave., Tulsa, OK 74105         (918)745-9037 fax
Newsgroups: comp.protocols.nfs,comp.unix.aux
From: mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
Subject: Query about IBM fault tolerant filesystems -
Keywords: Desqview NFS
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
Date: Thu, 9 Apr 1992 20:02:44 GMT


	I've been hearing interesting things about a distributed
fault tolerant filesystem IBM's claiming is coming soon. Can anyone
shed any light on what it is and does? From the (few) noises I've
heard it sounds like VAX Clusters...

mjr.
-- 
When they say "GNU's not UNIX" they mean they have abandoned the UNIX
tenets of "simplicity, elegance, and ease of use."	- rcd