> Hey Andrew, how about we all put our request in
> this forum and you consolidate them to your
> management? I think my voice has a bit more of
> chance to be heard via this path then making a
> request to my IBM Partner account rep.
Actually the opposite is true. The fact is, while TSM development may have
some input into what goes into the product, ultimately it is IBM/Tivoli
marketing that has the biggest influence over what will go into future
releases. And since the marketing group sees the requirements that come in
through official channels, they are more likely to see your requirement if
you go the official route.
Assuming that your IBM Partner account rep can open a requirement for you,
that is the way you should request new features, changes, and
enhancements. When you open a requirement through the official channels
(ADSM-L is NOT an official channel), then you can be sure that the
requirement is evaluated by marketing (and development), and you will
receve a response. An alternative to this is to open the requirement via
SHARE, where new requirements are discussed with IBM, and responses to
requirements from the previous SHARE are given... at least I think that is
how it works, I have not been to SHARE for several years.
With that said, do not take this to mean that your suggestions on ADSM-L
fall on deaf ears. If an idea on this forum comes up that we thing is a
good, we will bring the idea forward internally. But that is not a
replacement for the formal method of opening a requirement, where it will
get more attention.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: [EMAIL PROTECTED]
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
mrkirra2001 <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
03/01/2002 19:17
Please respond to mrkirra2001
To: [EMAIL PROTECTED]
cc:
Subject: Re: Exclude SYSTEM_OBJECT redux
Hey Andrew, how about we all put our request in this forum and you
consolidate them to your management?
I think my voice has a bit more of chance to be heard via this path then
making a request to my IBM Partner account rep.
So I vote we have the option to NOT backup SYSTEMOBJECTS (the *.exe's,
*.dll's, etc...) on the W2K platform.
Thanks
/gjs
----- Original Message -----
From: "Andrew Raibeck" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 28, 2002 2:36 AM
Subject: Re: Exclude SYSTEM_OBJECT redux
> Matt,
>
> This is a recognized requirement, though no delivery timeframe is
> available yet.
>
> Taking this up with you rmarketing rep is a good idea. The more people
> request it, the more likely it is to receive a higher priority.
>
> Regards,
>
> Andy
>
> Andy Raibeck
> IBM Software Group
> Tivoli Storage Manager Client Development
> Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
> Internet e-mail: [EMAIL PROTECTED]
>
> The only dumb question is the one that goes unasked.
> The command line is your friend.
> "Good enough" is the enemy of excellence.
>
>
>
>
> "Matthew A. Bacchi" <[EMAIL PROTECTED]>
> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
> 02/26/2002 15:18
> Please respond to "ADSM: Dist Stor Manager"
>
>
> To: [EMAIL PROTECTED]
> cc:
> Subject: Exclude SYSTEM_OBJECT redux
>
>
>
> Folks,
> We are apparently in the minority due to the fact that we don't want to
> backup
> the SYSTEM_OBJECT on Windows 2000 on our clients. I have contacted
Tivoli
> support and know that my only option currently is to use the DOMAIN
> statement
> in the dsm.opt file to control this. Therefore I come to the community
> and
> ask what (if any) requests have you made of the developers for design
> changes concerning this topic.
>
> I know some developers frequent this list, and if any of them care to
> comment on this, I would love to have your input. I plan on talking
> with Tivoli Marketing soon, asking for a design change to incorporate
> a feature that will allow me to exclude the SYSTEM_OBJECT; so maybe
> something like an option called EXCLUDE.SYSTEMOBJECT. It is my
> opinion that this should be an option that could be set from a server
> client
> option set, so that each client dsm.opt file doesn't need to be
> modified. This is a problem in my environment, as I have over 10,000
> clients total, and it's difficult to make changes that require user
> action.
>
> When I spoke with Tivoli support about my problem, he mentioned that
> when designing the capability to backup the system files, they were
> required to take an 'all or nothing' approach. While this seems to be
> true, they make it quite difficult for the user to choose the
> 'nothing' route, much different from the philosophy TSM normally
> espouses.
>
> OK, thanks for listening. I look forward to your comments.
>
> -Matt
>
