On Thu, 18 Mar 1999, Prather, Wanda wrote:

> I don't think IBM has much interest in getting it to work well.  The
> documentation is lousy, and the design appears to me to be very much a
> patch/kludge, because as Reinhard noted, you have to maintain a zillion
> virtual mount points manually to support your users properly, and there is
> no good way to do it. IBM doesn't seem to have much grasp on how people
> really use DFS in real-world environments that support lots of users.

We discussed that at length with IBM when we introduced ADSM in 1995 (to
no avail as usual). We now strongly discourage the use of the GUI. In the
command line interface, the difference is not quite so big: people have to
type in the full path, so they are less tempted to have ADSM search for
hours (literally! can happen with one wrong click in the GUI)  through
portions of the file space where none of their files reside.

> So we run the BUTA interface, not by choice, but because that is what works.
> SO users have no access to ADSM for file-level backup and restore, we have
> do to it for them.  So they have no access to archiving, so they don't have
> the problem you describe.

We use BUTA as well, but are perfectly happy with it. We terminated
file-level backup quite some time ago because it was hardly used: with
AFS, you have the version of the day before always still mounted, so that
*per individual user* a restore is a very rare operation. The user will
then call us anyway, and it does not make much difference whether to
explain it to them or to do it ourselves. When we have spare time, we
might make a automatically processed Web interface for restoration
wishes.

With archive, things are different. There are not too many users using it,
but those who do it do it on a regular basis and must be able to do it
without aid from our side.

On the other hand, we are fairly happy with the non-AFS/DFS-aware clients
errr.. we *were* happy as long as they worked. Users do not normally
archive whole volumes/file-sets, and they may restore their access control
lists themselves when they at least get their data back (this is more a
DFS than an AFS problem as the latter has no file-level ACLs). If IBM
wants to spare the effort of supporting AFS and DFS, we - I am not
speaking for other customers - invite them do so: if an ADSM client is
able to read a file back from where it was written to, that would solve
most of the problem, and it would match what is promised in the manual.
Additional support of AFS/DFS specifics would be great, of course, but not
*vital*. But the current (non-vital: lethal) situation is that ADSM won't
give you back your AFS or DFS file *because* it is AFS or DFS, although
you did not ask that it be processed any different from any other file.

> So far, all our DFS systems are AIX-only.

Servers yes. But here we have a client problem, and clients are very
diverse, even comprising hosts where the ADSM client is not officially
supported (Linux with AFS, Cray with DFS, Fujitsu VPP with DFS (to come),
...).

Best regards,

Helmut Richter

==============================================================
Dr. Helmut Richter                       Leibniz-Rechenzentrum
Tel:   +49-89-289-28785                  Barer Str. 21
Fax:   +49-89-2809460                    D-80333 Muenchen
Email: Helmut.Richter AT lrz-muenchen DOT de    Germany
==============================================================