Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bbn!rochester!cornell!batcomputer!itsgw!steinmetz!uunet!sdrc!crgabb From: crgabb@sdrc.UUCP (Rob Gabbard) Newsgroups: comp.sys.apollo Subject: Re: Apollo's NFS !! Summary: Lets get this straight Message-ID: <309@sdrc.UUCP> Date: 20 Jun 88 19:08:04 GMT References: <3c80c931.4653@apollo.uucp> <292@sdrc.UUCP> <3c9567ba.d858@apollo.uucp> Organization: Structural Dynamics Research Corp., Cincinnati Lines: 31 In article <3c9567ba.d858@apollo.uucp>, heinzl_c@apollo.UUCP (Carl Heinzl - Apollo Computer, Chelmsford, MA) writes: > would) and runs it from there. Don't forget exactly what we're discussing > here either. Do you actually want to try and run a binary on an Apollo that > lives on a SUN, sorry - it just won't work. Try running a VAX binary on your > SUN and see what results you get there. > > > > > I feel DOMAIN is a much better remote file system implementation than NFS > >but it's not very heterogeneous. Apollo needs to address this NFS problem. > > Now then, in light of the discussion above, exactly what *NFS* problem are you > talking about? I simply want to store Apollo executables on an NFS-mounted disk and have an Apollo execute them from that disk just as if they were on a local disk or on a disk accessed via DOMAIN. For example, if disk space is low on the Apollo ring, I have nowhere to turn. If disk space is low on the Suns or HPs or any other NFS-running UNIX box I can turn to another NFS-server machine, including VAX/VMS and use some space there. Sure, I can store non-executables there, but why restrict the users in such a way ? It should be transparent to them. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rob Gabbard | UUNET: uunet!sdrc!crgabb Workstation Systems Programmer | PHONE: (513)576-2600 Structural Dynamics Research Corporation | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=