Hello everybody,
we have an applications which changes the creation time (ctime) of some big
files it uses, even though they are not really being recreated or changed at
all. The modification time and filesize don't change, just the ctime!
Because of this changed ctime, TSM backs up these files ev
On 8 jan 2009, at 11:34, Stephan Boldt wrote:
Hello everybody,
we have an applications which changes the creation time (ctime) of
some big
files it uses, even though they are not really being recreated or
changed at
all. The modification time and filesize don't change, just the ctime!
Because o
On Jan 8, 2009, at 12:27 AM, KIRAN-SYSTEMS wrote:
Please let me know how to delete volume history of a particular
Volume.
The product does not provide a way to do this.
Richard Sims
hi,
i always thought this is normal since TSM does not know the
type/compression ratio
of data that will reside on these tapes
//
goran
On Thu, Jan 8, 2009 at 1:18 AM, James R Owen wrote:
> TSM Support,
>
> We have a new BackupL3R STGpool w/ 10 new LTO3 volumes explicitly defined.
>
> Despite ha
Drop the "not" and it will work fine. You might want to order by node_name.
Bob
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Larry Clark
Sent: Wednesday, January 07, 2009 5:57 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Request for som
Kiran,
This worked for me for a backupset. I don't know if it will work for your
particular case. The volume was a FILE type volume that no longer existed.
DELETE VOLHISTORY type=backupset volume=D:\88894302.OST force=yes
todate=today
Bob
-Original Message-
From: ADSM: Dist Stor Manag
Hi all *SMers,
Happy new year everyone,
We have TSM Client and Server 5.5.1 on Windows 2003 x64.
On the Client side are we running Exchange Server 2007 and TSM for Mail 5.5.
We do also run IBM CommonStore to Archive all our emails that are older then 1
year on TSM environment.
Everything works gre
>> On Thu, 8 Jan 2009 15:52:57 +0100, Christian Svensson
>> said:
> Everything works fine for us but I don't really like it's open so
> many sessions every day.
Why do you care?
Except for wrapping the session number when you get to a million,
there's really no impact on your server. Here's
Hi Allen,
As I said. It's not a problem. It's more annoying and if it is possible to cut
down number of sessions it should be good.
Another thing it is also hard to look though the Activity log when you see
CommonStore open and close all the time.
Best Regards
Christian Svensson
Cell: +46-70-32
I have a simplistic korn shell script that does this that I could share
with you if you are interested.
David Ehresman
>>> Bjørn Nachtwey 1/7/2009 8:53 AM >>>
Dear all,
looking at LAST_WRITE_DATE or LAST_READ_DATE of my tapes (some are in
2004), I'd like to move the data of tapes last accessed
I agree. Bad behavior. But you could fight fire with fire, if you enjoy
scripting. Perl, Ruby, etc. will allow you to change the ctime back to what
they were.
On Thu, Jan 8, 2009 at 4:09 AM, Remco Post wrote:
> On 8 jan 2009, at 11:34, Stephan Boldt wrote:
>
> Hello everybody,
>>
>> we have an
Hi James,
* *I believe Goran is correct. This is specifically for tapes.
On Thu, Jan 8, 2009 at 5:36 AM, goc wrote:
> hi,
> i always thought this is normal since TSM does not know the
> type/compression ratio
> of data that will reside on these tapes
>
> //
> goran
>
> On Thu, Jan 8, 2009 at 1:
Hi Christian, there is nothing in TSM that lets you adjust this. It is a
function of the CommonStore application and how it uses the API.
Best regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/T
As a workaround, you could create a management class/copy group that
specifies FREQUENCY 7, just for those files.
That would prevent them from being backed up more than once a week.
Reduce the pain a little.
On Thu, Jan 8, 2009 at 6:09 AM, Remco Post wrote:
> On 8 jan 2009, at 11:34, Stephan
Not entirely true. The product doesn't provide a DOCUMENTED way to do
this.
There are some undocumented parameters for the DELETE VOLHIST command.
Specifically, you can add "vol=VOLNAME force=yes" to the command to remove
the volume forcibly from the volhistory.
We have found this command necessa
>> On Thu, 8 Jan 2009 16:40:20 +0100, Christian Svensson
>> said:
> As I said. It's not a problem. It's more annoying and if it is
> possible to cut down number of sessions it should be good. Another
> thing it is also hard to look though the Activity log when you see
> CommonStore open and cl
Are you looking for automated tools? Generally the reporting tools that
are available and the DRM prepare utility is a good start.
However, most of them are manual, like Word and Excel.
See Ya'
Howard
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu]
Have you considered setting up a TSM instance to be used only by CommonStore?
[RC]
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Christian Svensson
Sent: Thursday, January 08, 2009 7:40 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] SV: Commo
Hi,
This is what we are going to do later.
We are anyway moving over from 1 TSM Server to 2 TSM Servers and use the old
TSM Server as Library Manager and then can we keep the old TSM Server only for
CommonStore.
Best Regards
Christian Svensson
Cell: +46-70-325 1577
E-mail: christian.svens...@cr
Thanks for the information. I am facing the same issue with the tapes with
shared library owing to the client server.
Regards,
Kiran.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Robben Leaf
Sent: Friday, January 09, 2009 1:02 AM
To: ADSM-L@
20 matches
Mail list logo
