ADSM-L

ADSM SHARE requirements

1995-02-23 17:34:33
Subject: ADSM SHARE requirements
From: "R. Alexander" <[email protected]>
Date: Thu, 23 Feb 1995 17:34:33 EST
Appended are three draft requirements for ADSM/6000 that
I intend to submit at Share next week.  I would be interested
in any comments and suggestions you can supply.

Thanks, in advance,
Richard
      ---------------------------------------------------
Draft ADSM/6000 requirement 1
Statement of Problem:

IBM makes available ADSM/6000 documents on a CD/ROM
with a builtin DOS and OS/2 reader.

1) We would like to print these documents with
a high quality printer using postscript.

2) We want to avoid the requirment to use
some system other than AIX to process these documents.

3) We would like to print these documents without
the need of some additional product in AIX.

For those customers without access to DOS or OS/2,
the current CD-ROM solution is less than satisfactory.
The use of Compuserve is also less than satisfactory.

It seems reasonable that IBM would deliver all
parts of a product in the form useable in that
product's own environment.  This is a request
that postscript versions of all the ADSM/6000 manuals be
delivered in a form processable directly on AIX
without additional products.

IBM business case:

The product is more useful in a straight-forward
manner without the overhead associated with today's
method.  Customer satisfaction is improved.

      ---------------------------------------------------
Draft ADSM/6000 requirement 2
Statement of Problem:

We need the ability to customize the ADSM/6000 client
gui screen to display to the user ONLY those file
systems he is allowed to manipulate.

One way to supply this request is to allow
environment variable expansion in the ADSM/6000 client.
Expansion should be allowed everywhere that an option
can be set.  It seems that currently, all of the
customization (domain, virtualmountpoint and incl/excl
is applied AFTER the user selects files to be manipulated.

In large Unix shops, user directories are often a symbolic
link to some pseudo-random name, user's need to see
their own home directories in the gui display.
For example, a normal path to a home directory is /home/84/alexar.
It is bad human engineering to require each user to know this
esoteric name.  If one could code "$HOME" in the include list
and exclude all else, the problem is solved.  Instead of
include/exclude, if the virtualmountpoint could be "$HOME",
and domain could be "$HOME" the problem is solved.

IBM business case:

The attractiveness of the product would be improved
and use simplified with the above changes.


      ---------------------------------------------------
Draft ADSM/6000 requirement 3
Statement of Problem:

The current ADSM/6000 product does not support Andrew File
System and Distributed File System environments well.

While there is a kerberized version of the AIX version
of the client, most of the power of AFS/DFS is lost.
Users are required to use ADSM from only one node on
the system, though their home directories are available
on all.  Apparently AFS/DFS links to other cells
are not recognized; therefore other cells are backedup.

IBM business case:

1) AFS/DFS support would appeal to a larger customer base.
2) Robustness would be enhanced by eliminating a single
   point of failure in ADSM.
3) Usability with current AFS sites would be improved.

Richard Alexander                         phone: (518) 276-6785
Mgr, High Performance Computing           fax: (518) 276-2809
Rensselaer Polytechnic Institute          Internet: alexar AT rpi DOT edu
<Prev in Thread] Current Thread [Next in Thread>
  • ADSM SHARE requirements, R. Alexander <=