*** WARNING: Long Post ***
Sigh. Well, it looks like I need to wade into the fray. As the developer
who actually designed how this function works, maybe I can shed some light
on this issue, at least to what the thought processes were:
Thoughts
--------
1) Realize that in ADSM, no matter what version, the DOMAIN option has
1) Realize that in ADSM, no matter what version, the DOMAIN option has
always been only a *suggestion* of what should be backed up. Using the
command line, you can backup anything in or out of the so-called domain.
Same way with the GUI. The V2 GUI did indeed highlight the drives listed
in the domain, but all it took was a "Select All" and everything was
highlighted. The user has *always* had full control of what could be
backed up on the machine.
2) One of the big problems with the V2 GUI was its terrible performance
when displaying filesystems and trees. Customers have been very unhappy
with its performance for several years. So one of the key design points
was to make the trees dynamic - don't spend time, potentially minutes,
reading information that the user hasn't requested. Therefore, the
filesystems, directories, and files are only read in from disk when the
user asks for that information.
In order to correctly highlight the filesystems in the DOMAIN option, all
filesystems would have to be queried up front. The DOMAIN option can
specify local filesystems and network filesystems. However, the reading of
filesystems can take a long time. All too often I have waited around while
trying to display a list of network drives on NT or Unix, and waiting for
the network timeouts to occurr. And we have had many customers over the
years complain about this delay as well. They were not interested in
looking at the network drives, why were we querying them, and wasting their
time? Some customers have hundreds of local and network filesystems.
So we decided to seperate out the Local and Network drives into different
sections. This would provide the user with the ability to better control
what they saw, queried, and backed up, while providing better overall
performance and better user experience.
3) We did make two mistakes in this design (hey, we're not perfect). We
did know that we would need to provide some way to be able to quickly
backup the defined DOMAIN - we ran out of time and it fell through the
cracks. We also missed the fact that removable media, particularly
CD-ROMs, appeared in the Local Filespaces category. I agree that's a
problem.
Solutions We're Implementing
----------------------------
There are a couple things we're doing to make this better to use
There are a couple things we're doing to make this better to use
1) in PTF 3, we've added the "Backup Domain" menu option. We intended to
have something like this in the original version, but it didn't make it.
It provides the function that you really want - to backup the filesystem in
the domain. You may see this appear as a button in the Main Window (maybe
"One-click Backup" or something) - but that is still in debate (any
feedback on this is welcome and appreciated).
We were not happy with other proposed solutions: we didn't wan't to
preselect them in the tree window, because it would bypass the performance
benefits we had gained. We could have provided a button that the user
could press to read all the filespaces and select them based on the DOMAIN,
but that didn't seem right either - too many actions to go through to do
it. We felt that being able to select one menu item and have your machine
backed up according to your DOMAIN definition provided an easy and usable
way for the user to perform this function.
2) We will be auto-expanding the Machine node (top level node in the tree)
so that the user will immediately see the Local and Network nodes. This
will make it much more apparent what the user will be backing up then they
select one of those nodes. If they select the machine node, they will see
that Local and Network are also selected. Most users know that backing up
network drives is not good.
3) We will be creating a new node, called Removable (or something), that
CD-ROMs, ZIPs, etc, will be shown under. These types of filesystem
shouldn't appear in the Local section.
Responses
---------
There were a variety of posts on this - instead of responding to each one
There were a variety of posts on this - instead of responding to each one
individually, I've copied relevant parts here and responded to them:
*** Allen Barth wrote: ***
> You didn't miss a thing. This is being marketed as a FEATURE! The
> gui ignores the domain parm in dsm.opt, but I've been told that the
> command line and scheduler do not (I'm not willing to try).
>
> If the gui's stay this way, then they're useless "cow droppings"
>
> I'm hoping someday the ADSM developers will recognize and admit this
> to be the major FLAW that it is, as opposed to adding menu bar items
> to do what the client is supposed to be doing in the first place!
I don't know where it's being mentioned as a feature, but its function that
we weren't able to get into the initial release. However, if it had made
the initial release, it would have been implemented the same way. We have
tried very hard in Version 3 to incorporate a variety of changes and
enhancements that customers have been asking for over 5 years (obviously
there are more for us to do ;-). In doing so, we have necessarily had to
change how we did some things - several paradigm shifts were introduced.
These changes were not done to cause confusion, but to move the product
forward both in usability and functionality.
*** Bob Matthews wrote: ***
>Unfortunately, what I hear is not encouraging. Neither the latest fix nor the
>proposed future development come anywhere near solving the problem.
>There's no
>way we can upgrade our 1,000 clients to version 3 while this situation
>exists.
>In my humble opinion, once a domain has been defined for a client, the client
>should never look at anything outside that domain irrespective of whether the
>backup is by GUI, non-GUI, scheduled or non-scheduled.
This is not how V2 works either. The DOMAIN option has always been only a
suggestion of what should be backed up. The user has always been free to
backup anything on their system. This is not a V3 issue.
>If I understand the
>documentation correctly, I can "enforce" a domain in a client option set
>but the
>GUI will then ignore it. What's the use of "enforcing" something that can be
>ignored? This seems like a contradiction!
By using the "Backup Domain" menu in the GUI, it will backup whatever the
DOMAIN has been set to, either by the options file or the server. This
takes only one click from the menu. If they use the tree, then they can
backup anything they want, just like V2.
>Is this another example of IBM not listening to the requirements of its
>customers?
>Forgive me if I'm wrong.
We try very hard to listen to customer requirements. However, we usually
get many conflicting requirements from customers, some want it one way and
others want it another way, and we have to balance all of them. A big part
of V3, at least from my standpoint, was to try to handle many of the
customer requirements and problems we've gotten over the years. There are
still many more to deal with, but we do hear what you all are asking for.
*** Cris Robinson wrote: ***
>You are so very right. This issue is one my major beefs with vendors.
>There is not enough input from the customers.
>Version 3 was being developed before we could ask for input. We are
>faced with the same issue although we are developing
>ways to overcome this issue. One thing that we are doing is creating a
>command line shortcut, WIN95, which does an incremental backup
>of the client device sans GUI. It don't eliminate the ability to backup
>through the GUI but if people are given the simple backup icon they tend
>to take the shortest road to completing a backup. This process is used
>by our portable users who are not plugged into the network during the
>"normal" backup
>window at night.
We do get feedback from customers - we run internal usability sessions with
customers, and we did give early code to some customers. I am hoping that
we will be able to have more extensive beta programs in the future.
So let me ask you this: If we created another graphical button on the main
window, called something like "Easy Backup" or "Quick Backup" or something,
would this obviate the need for creating a command line shortcut?
>Also - There needs to be the facility to grant or deny functions on the
>client GUI from the server. We would like to limit the client
>interaction
>with the server in certain cases like locking the preferences, denying
>access to the preferences and access to the opt file. users just LOVE to
>mess with that one!
It is already possible to limit access to the options file. Almost every
option can be "forced" by the V3 server, which means no matter what the
user sets it to, the server value will take precedence. Even the GUI
options editor won't let the user change settings that the server has
"forced".
*** Allen Barth wrote: ***
> What you describe below is NOT a solution...it's a work around.
>
> Your discussion here, Andy's earlier, and all other discussion about
> this fail to point out why the v3 client gui still does not establish
> whatever is specified in DOMAIN as the default. You know...highlight
> those drives! Pre-expanding the tree is a good idea, but not enough.
I hope I have answered this above. There are performance and usability
reasons for not doing this.
> If the command line and scheduler interfaces do recognise and honor
> the DOMAIN as stated, the gui should too... WITHOUT the need for
> developers to add new action items, and more important WITHOUT the
> need for me to run around to all my users and retrain them!
It is true that the initial V3 clients did ignore the DOMAIN option.
However with PTF 3, we added the Backup Domain function. We didn't just
add another action item, we implemented the function we were planning on
implementing anyway. I understand the difficulty in the some of the
retraining that will have to happen, but the ADSM interface hasn't been
changed in over 5 years. There were many things we couldn't do with the
old interface, and it was time to make a change. There is no way to get
around having to do some retraining. Hopefully future changes won't be as
dramatic.
> Um, when did Jerry become the sole voice of the ADSM user community?
> He certainly did recognize a problem, report it, and something was
> done. But, as I've stated before, the methods ADSM development is
> proposing are UNACCEPTABLE to me because of the very real aspects of
> system failure and data integrety.
Jerry happened to be the most vocal about this problem at the time, and was
willing to work offline with us. I'm not sure he is fully satisfied with
our implementation either, but we have to make tradeoffs to maintain
certain design goals.
I hope this, if nothing else, at least explains some of our thinking behind
this issue.
Cheers,
Brett Walker
ADSM Development
o------------------------------------------------------o
Brett Walker ADSM Development, IBM
walkerbl AT vnet.ibm DOT com tie 276-0265
o------------------------------------------------------o
"That's just my opinion; I could be wrong."
--- Dennis Miller
|
