I absolutely agree with the findings. Especially the automatic activation of Policy is really dangerous.
Rajesh Oak ----- Original Message ----- From: "Ben Bullock" <[EMAIL PROTECTED]> To: [email protected] Subject: Re: Initial problems and bugs with ISC (long) Date: Thu, 3 Mar 2005 08:24:58 -0700 > > Nice write up. > #5 in your list was the one that drove me nuts. It just does not > work as expected and I had to go to the command line to create a new > domain and policy. > > Ben > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of > Paul Fielding > Sent: Thursday, March 03, 2005 2:49 AM > To: [email protected] > 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 -- _______________________________________________ Find what you are looking for with the Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10
