Xref: utzoo comp.dcom.lans:6227 comp.sys.att:10609
Path: utzoo!attcan!uunet!lll-winken!sun-barr!olivea!orc!inews!iwarp.intel.com!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.dcom.lans,comp.sys.att
Subject: Re: Questions about StarGROUP Software
Message-ID: <1990Oct17.175023.3105@chinet.chi.il.us>
Date: 17 Oct 90 17:50:23 GMT
References: <1990Oct16.173745.18064@mccc.uucp>
Organization: Chinet - Public Access UNIX
Lines: 45

In article <1990Oct16.173745.18064@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes:
>I'm in the process of installing StarGroup software (Version 3.2) on a
>386 running SV/386 R3.2.2 and a bunch of Zenith PCs running DOS, and
>have run into a couple of small things. 
>
>1.  The "DOS Client Server Admin's Guide" mentions that it "...is
>possible to configure a computer as a concurrent client/server..." but
>neither it nor the "386 Server S/w Installation and Admin Guide" tell
>how to do this. 

It's been a while since I did this, but I thought the dos installation
program asked you wanted to be a client or server or both.  Anyway
you lose a lot of memory so you probably don't want to do this unless
you have something unusual in mind.  There should be a book labeled
"DOS client Server Administration" in the set somewhere.

>2.  The error messages section of the DOS guide mentions a "Simul-Task
>Client S/W Installation & Config Guide."  Does this suggest that a
>client must be running DOS -- even if it's under Simultask -- to be a
>client for a StarGROUP server?

Yes, there is no native-unix way to get client access to the things
offered by the StarGroup servers.  For straight unix-unix links you
can just use RFS mounts, though.  The Simul-Task Client add-on is
needed to let a DOS program on the unix machine connect to resources
from other server machines.

>3.  I have a DOS application installed in a shared directory tree and
>I'd like to prevent users from writing to any of those directories. 
>However, it appears that the program itself writes temp files to its
>"home" directory because making the directory read-only produces error
>messages.  What should I examine to determine if I can make the
>application write its temp files somewhere else?

I've worked around this kind of problem by giving each user a home
directory on the unix server, then making a subdirectory for each
such program and making a link there to a copy of every file that
the program needs.  From the DOS side it looks like each user has
his own copy in is own workspace but it doesn't take any extra
room on the server.  The real solution is to get network-aware
programs - lots of them aready are and will provide some way for
you to specify the locations of various parts and the workspace.

Les Mikesell
  les@chinet.chi.il.us