Paul,

I will add the following:

I've tried to add a diskpool volume of 5GB to my TSM server (testserver
running on Linux, ISC/AC is on AIX) and the volume creation failed right
before it reached 5GB with no apperent reason. Off course the command-line
worked fine.

Richard.





Paul Fielding <paul AT FIELDING DOT CA>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
03-03-2005 10:49
Please respond to "ADSM: Dist Stor Manager"

        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Initial problems and bugs with ISC (long)


Ok IBM, here's my initial ISC findings for you.  There'll probably be more
down the road, I'm sure....

Bugs/Annoyances:

1. When setting the dbbackup trigger, the ISC doesn't let you set 0
incrementals between fulls.  If I want to have every dbbbackuptriggered
dbbackup run as a full, I need to set the trigger from the command line.

2. When adding node associations to a client schedule, the final list of
nodes displayed is only wide enough for nodenames roughly 8 characters
wide.  Any decently long nodename gets wrapped, making it a pain in the
butt to read.

3. The Actlog is a pain in the butt to read.  Either give us back a clean
window that can display standard actlog output (as per the old web
interface) or at least fix the actlog display so that it
  a) has the timestamp first, instead of way off to the left where one has
to scroll to see it,
  b) let us choose a begint
  c) show us *all* entries - currently it seems to me that not all
messages get displayed.

4. When looking at a client schedule: if there are nodes associated with
the schedule, the ISC displays only the nodes that are associated (good).
If there are *no* nodes associated with the schedule, it displays *all*
nodes that exist (bad).  It gives the impression that all of those nodes
are associated.

5. **BIG BUG**  Management Classes.  The new ISC philosophy seems to be
that we now hide the existence of Policy Sets and Copy Groups from the end
user.  Policy sets are completely hidden, and copy groups are simply shown
as values that can be set within a mgmt class.  Ok, I can live with that.
Except that it's inconsistent and in one case genuinely wrong.  In order
to hide policy sets from the end user, the ISC needs (and tries) to
validate and activate the STANDARD policyset after changes have been made
to the mgmt class/copy group.  If we ignore the fact that one probably
shouldn't be blindly letting the ISC validate and activate the policy set,
we cannot igore the fact that it doesn't always do it.

When you make changes to a mgmt class/copy group, the ISC automatically
validates/activates the policy set.

However, when you *add* or *remove* a mgmt class/copy group, the ISC does
*NOT* validate/activate the policy set.  The mgmtclass is added or removed
from STANDARD, but ACTIVE is untouched.  Worse yet, the ISC happily
declares that your changes were successful and then displays your changes.
 ie. it displays what the STANDARD policy set is doing, not what the
ACTIVE one is doing.  This gives you the false impression that your
changes are active.

Fortunately, there is one single place in the ISC where policy sets are
mentioned - the teeny drop down option under Policy Domains that says
"Activate Policy".  Of course,  this is the one case where rather than
being it's usually over wordy self it instead explains none of this to the
end user.   If you use this action, the policy set will indeed be
activated.

One of two things needs to happen: a) val/act when adding or removing a
mgmt class, or b) never val/act and instead make it more clear that this
needs to be done by the user after making changes.

If IBM fixes nothing else on my above list, this issue must, must, must be
addressed.

6. Comand line.   Please - give us back a usable command line from within
the ISC.  The great thing about the command line in the old web interface
was that it sat at the bottom of the browser, out of the way when you were
pointin' and clickin' around the GUI, but was right-there-now when you
wanted to enter a command, and the results showed up nice and big in a
grand window that was wide enough to show the output and you could scroll
down easily to see the results.  The command line interface in the ISC is
in a dumb, annoying to reach place - you need to make a million clicks to
find it, and then it's annoying to use when you get there.

The GUI has some advantages, but sometimes there's just no substitute for
being able to fire off a few ad-hoc commands.

7. The FINISH button.  Every other wizard in existence, after asking you
all your questions, gives you a FINISH button - at which point you may
either click on FINISH to make the action take place, or you can cancel
out, knowing you haven't changed anything.   The ISC wizards actually do
their action after you press an arbitrary NEXT button, and only displays
FINISH *after* the action has taken place.   You don't get that last ditch
chance to not make your change.  Not very intuitive.



I'm sure I'll have more, but these are all I can think of right now.  I
hope somebody passes these on to the right people...

later,

Paul