On Fri, 6 Dec 1996 18:43:32 EST, Martha McConaghy wrote:
> Since then, however, the success of
>the list has gone way past any of my expectations. IMHO, this is 95%
>due to the participation of the ADSM developers, support programmers
>and others at IBM. They have set a new standard in being responsive to
>customers' needs, comments and problems.
I think that it is not only their participation, but how the
participate. I have never exchanged emails or talked to anyone at
ADSM who wasn't anything but helpfull and sincerely interested in
helping the client. I totally agree with you that they are probably
one of the best divisions at IBM. They always go the extra mile to
help you. And it has always angered me that their product is not
better marketted outside big iron circles. I understand that it is
more profitable to stay with the high marging markets, but I think
that this should be defined by the customer's needs and not the
platform they run on. For instance, in six months I have been using
ADSM I have only seen one ad for it (and I read several PC related
trade mags such as Inforworld, information week, pcweek, etc..).
Maybe they advertise on magazines that are used by large
organizations (where have they advertised historically?). Does this
mean that companies using OS/2, NT or some other Unix have no need
for ADSM? My guess is that if an organization has many clients that
need to be backed up (even if they are only DOS clients) ADSM is a
good program for such organization.
> What do you mean by "usability"?
Background info before I answer:
Currently using Version 1 server for ADSM (waiting for PO to go
through to get Version 2). Backing up Netware clients and using the
OS/2 admin GUI. The clients are up to V2 R1 L5. My users are
technical users and they have a mixed set of requirements which they
could probably not have with anything else but a program like ADSM
(ie keep 1 year worth of these xyz files, and 3 copies of abc files,
etc..).
> Have you attempted to submit formal requirements via a
>user group, or through a letter to ADSM development?
Other than ADSM-R I had not heard of any "easy" way to submit
requirements. When I asked the response was that the best way was to
submit then through our IBM rep. WE DON'T HAVE AN IBM REP. Surely I
have talked to MANY people at IBM when I was installing ADSM. After
all it took me over one month to find out how I could get support for
ADSM for OS/2 (on version 1 one had to go through the VMS/MVS(?)
people and it took me more than a month to find out). By the time I
got the info, and the contract to sign I already was hearing that
support on ADSM version 2 would be much simpler so I decided to wait.
> The ADSM-R list was
>an experiment which, unfortunately, did not succeed as ADSM-L did.
Anyone would venture to give explanations why? I will start. When you
submit requirements and you don't know what happened withit, it
gives you a feeling that your message is been ignored. My impression
of ADSM-L is that it is highly a reactive type of list
(questions/answers, problems/solutions) while ADSM-R was about been
pro-active; Clients talking about how to make ADSM better in the
future. In this case it is harder been pro-active when you have a non
disclosure policy of future requirements. I partly understand why
they keep it private, but if there is a feature everyone is waiting
for and they have the impression they will be able to have it in
upcoming releases wouldn't it be a good marketting to let us know
about those things?
>there are a number of ways to bring your requirements to IBM's attention.
>Both SHARE and GUIDE have formal requirements processes. Each requirement
>submitted to IBM must receive a response and normally do by the next major
>meeting. There are other, less formal ways of doing it as well.
I don't know what SHARE and GUIDE are. Even if I knew what they are I
am not sure I would want to go just to submit ADSM requirements that
I believe should be done on the WEB or by email. Even keeping the
current policy of privacy of the requirements list. Why not have
"formal" way to submit requirements on their web pages and display
that list to the public? By displaying the list at least we know what
they have "received".
>However, I think its unreasonable to expect that IBM can implement every
>requirement, especially within a few months.
Since they can't have EVERY requirement the more reason for them to
need a good list from their users. For instance if half the uers
requested something and it was easy to implement shouldn't they
implement it? The problem is that there may be requirements that a
high percentage of users need, but IBM doesn't even know about.
>Therefore, I think you need to be more specific about your problems. Where
>do you think ADSM has poor usability, and, please specify the platforms
>involved? What concerns do you have that aren't being addressed by
>ADSM development?
Some of the points I will write have been expresses by others in the
ADSM-L list. I must also admit that I pigy-bagged usability and
administration when I talked about usability and forgot to mention
it. I must also disclaim that perhaps some of what I may ask may be
in the server V2 (which I am waiting for) or may even be in the
clients I have, but I have not been able to find them.
** Clients **
-Ability to restore seamlesly from either a backup or an archive. Not
all my users know whether I backup or archive a directory, but the
all my users know whether I backup or archive a directory, but the
know what xyz directory is in ADSM. At restore time if the person who
needs to do the restore doesn't know to check both he/she may think
we don't have the file(s). When doing a restore ADSM doesn't care
about which policy domain manages the file. Why should it care if is
backed up or archived? The parameter could have a default to show
both and have parameters to specify only one or the other.
-Ability to see a list of files independently of whether they are
archived or backed up. Right now I don't even think I have a "query
archived or backed up. Right now I don't even think I have a "query
archive" in netware (client V2 R1 L5). This request could be
generalized to "ability to see list of files in a filespace
independently of whether they are backed up or archived".
-When using compression the log file only reports the number size of
what was transmitted to ADSM, but not the actual size. This is
what was transmitted to ADSM, but not the actual size. This is
important when doing restores. Sure one can compute it from amount
sent and compression %, but it would be much easier if the original
amount was displayed.
-List files in a storage pool and/or a way to determine where a file
physically is (disk, tape, etc..)
physically is (disk, tape, etc..)
-Centralization ADSM logs for the clients. Not only this would make
it easier to check for problems and look at the logs, but this would
it easier to check for problems and look at the logs, but this would
also allow third party companies to write reporting tools for ADSM.
Wouldn't it be nice to have a graph of the througput of your backups
per day/time, etc... These are not difficult tasks, the problem is
accessing all the logs because they could be on any of the many
platforms that ADSM clients run on.
-Centralization of ADSM option files. By having them centralized the
ADSM admin can determine whether him/her or the end users can change
ADSM admin can determine whether him/her or the end users can change
the option files. This would also allow ADSM to have something like
matching option files to the policy domain a client belongs too.
Example: All DOS clients belong to the DosPolicy and their option
file will exclude the DOS directory which could be kept somewhere,
but only ONE copy instead of one copy for each client. Even if you
have different DOS versions you only need one copy set per DOS
version
** Admin Gui **
-The basics: The OS/2 GUI has no way to save the window position or
the font size. How difficult can this be?
the font size. How difficult can this be?
-Ability to see/delete the files in ALL clients. Notice I am not
referring to restore. I understand the complexities of restoring to
referring to restore. I understand the complexities of restoring to
different client types. What I am referring to is that my admin GUI
is OS/2 and I backup mostly netware clients. As far as I know only a
netware client can have acces to another netware client filespace.
This would solve the current problem of deleting files that once
were part of an INCLUDE and now are not. The current method is
cumbersome to say the list.
-List of scheduled events in OS/2 Admin GUI has no option to default
to previous day. If I check every day for scheduled events I have to
to previous day. If I check every day for scheduled events I have to
go into the include filter and change the date. The server events
already has something simmilar feature (one hour back I think).
-Filter to see only failed events in Admin GUI list of scheduled
events. If I got a few days without checking scheduled events I am
events. If I got a few days without checking scheduled events I am
particularly interested in failed events more than anything else.
-When an even fails the OS/2 Admin GUI doesn't have the reason. I
only have about 10 clients so it is not terrible to go the client and
only have about 10 clients so it is not terrible to go the client and
check. How about large organizations (the ones I would suspect ADSM
was originally targeted) who have hundreds of clients. Should the
admin go computer by computer to check the reason the backup failed?
-Printing to file from the OS/2 Admin GUI can not be easily printed
because the headers make the lines too long. For example the print
because the headers make the lines too long. For example the print
storage pools doesn't fit into a page not even on landscape, not
because there is too much info, but because the titles are so long. I
understand that they don't have a direct method to print since ADSM
is cross platform, but if they changed the headers to be shorter at
print time or even better display the headers in several lines and
assume alignment based on a monospaced font.
Those were just usability/administration. Obviously some are easy to
implement (save window position on OS/2 admin GUI) others are harder,
but yet could be very usefull to making ADSM be more
manageable/easier to use.
|
