Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!usc!ucla-cs!uci-ics!milne
From: milne@ics.uci.edu (Alastair Milne)
Newsgroups: comp.protocols.nfs
Subject: Re: PC NFS
Keywords: Integration of PCs and SUNs
Message-ID: <16545@paris.ics.uci.edu>
Date: 4 Jun 89 09:04:14 GMT
References: <17676@vrdxhq.verdix.com> <577@eagle_snax.UUCP>
Sender: news@paris.ics.uci.edu
Reply-To: Alastair Milne <milne@ics.uci.edu>
Distribution: na
Organization: Educational Technology Center, Dept. of ICS, UC Irvine
Lines: 60

geoff@hinode.UUCP (Geoff Arnold) writes
>..., milne@ICS.UCI.EDU writes:
>
>}   I have only 2 complaints about PC-NFS so far:
>}   - can't get broadcasts to the PC's from either server or other PC's.
>}     would be very useful for downtime alerts.
>
>What protocol would you suggest we talk? We don't really want to fill up
>memory with TCP-based TSR's. 

    I don't know nearly enough about NFS to be able to talk about its
    protocols, but I do know that PC-NFS incorporates a serial number checker
    which causes each PC to check its own PC-NFS S/N against that of every
    other PC on the net; and if any 2 or more PC's are found to have the same
    number, the screens of both or all of them are erased and a message from
    Sun displayed on them.  If this happens 3 times, all copies with the same
    S/N are disabled.  The immediate reaction is that if Sun can do this
    much to guard against piracy (a reasonable measure, I think, though it can
    cause some incidental problems in installation), a similar service for 
    broadcasts should not be impossible, presumably derived from the 
    anti-piracy system.

    I more than agree with you about TSR's (TCP-based or any other kind): with
    an "operating system" such as DOS, which provides *no* runtime management
    of code, allowing stray bits of it to remain in memory -- unsupervised,
    unswappable, immovable -- seems to me likely to invite totally unexpected
    runtime problems, especially as few of them are likely to be as robust as
    one could wish.  As I recall, even the best known resident servicers 
    (such as PC Sidekick) can cause odd and devious problems when new 
    applications or TSR's are added.  Not quite as risky as throwing unknown
    chemicals together to see what happens, but not wholly dissimilar, either.
    I would certainly sooner tackle a problem in almost any other way.

>One suggestion (if you're good at DOS
>applications) would be to designate a particular file on an NFS drive
>as a bulletin board, and write a little TSR that periodically
>stat'd the file and if it had changed displayed the contents in
>a pop-up window. 

    I'm semi-moderate with DOS applications, though I've never tried a
    resident servicer (note paragraph above).  I have seen a little discussion
    of installing a servicer for the clock interrupt, though never a full
    implementation.  I'm not at all sure, though, that an interrupt handler is
    allowed to make BIOS calls, much less run a child program.  (BTW, the only
    "stat" I know of was a CP/M program.  Can't immediately think of a DOS
    equivalent.)  Would anybody care to explore this?

>If someone writes one and puts it on the net, we'd all be able to use it.
    
    Frankly, I'd sooner have a solution integrated into PC-NFS.  But this
    might at least be better than nothing.

>... SOS, a DOS NFS server written by See-Mong Tan at LBL.
>You can FTP it from lbl-csam.arpa in /pub/sos.tar.Z.

    A great tip, thanks!  I have ftp'd it already.  I tried running it, just
    for fun, on one of the Tandy's, but it just reported 4 things it couldn't
    do, and gave up.  I suspect it needs PC-NFS disabled first.  I need a
    closer look at the man sections.  (If it's for DOS, why is it so UNIX
    oriented?)