We are experimenting with the SUN client, but are finding that it
makes some assumptions that aren't realistic for our environment.
The following comments are from the administrator of the UNIX
systems for a department in our engineering school:

                                          In order to make it
   practical for users to restore their own files, or for them
   to use the archiving facility, I think I would need the ability
   to set up logical pathnames.  For example, if you had an eenet
   account, your home directory would probably be stored on the
   fileserver odin in /export/home.faculty/melinda.  But that
   pathname would not exist on any of the hosts that you log on
   to.  Instead, you would access your home directory as /u/melinda.
   This would actually be a symbolic link to /home/faculty/melinda.
   Any attempt to access that pathname would provoke the automounter to
   mount odin:/export/home.faculty on /amd_tmp/odin/export/home.faculty,
   after which the automounter would claim that /home/faculty/melinda is
   a symbolic link pointing to /amd_tmp/odin/export/home.faculty/melinda.
   Several minutes after you log off, the automounter would unmount
   the remote filesystem and forget the purported symbolic link.

   To compound the problem, odin:/export/home.faculty might fill up,
   at which time I might move your home directory to some entirely
   different filesystem, perhaps on a different host.  Now, as I
   understand ADSM, it will only backup your home directory as
   /export/home.faculty/melinda on host odin.  I would not expect
   you (and more so most of my users) to understand how to find
   your own files.  Moreover, the pathname under which your directory
   was backed up would not even exist on any of the machines that
   you can log on to.  What is needed is a way for me to tell ADSM
   that all of the subdirectories of /export/home.faculty on host
   odin should be backed up under the pathname /u/<directory_name>,
   and independent of any particular host (or, better, limited to
   those hosts listed in some NIS netgroup).

   I do have one specific complaint: the install script discovers
   its current working directory by using the "pwd" command, then
   edits a file and optionally makes symbolic links using that
   knowledge.  As explained above for users' home directories, the
   result is not a legitimate pathname.  So, it is necessary to
   either edit the install script, wiring in the installation directory,
   or go back and manually fix its misunderstandings after running it.
   This is something that IBM should fix, probably by having the
   script ask the user for confirmation of the pathname it will use
   (and allowing the opportunity to specify a different pathname).

Melinda Varian
Princeton University