Re: TSM and VMWare

2004-03-12 Thread Coolen, IG (Ilja)
Yup,

I've done that, and it works fine,
although you have to specify the /vmfs/filesystemname/* directory
explicitly, because TSM doesn't recognize it as a filesystem during it's
scan of all-local filesystems.


Ilja G. Coolen


  _  

ABP / USZO  
CIS / BS / TB / Storage Management  
Telefoon : +31(0)45  579 7938   
Fax  : +31(0)45  579 3990   
Email: [EMAIL PROTECTED]
Centrale Mailbox : Centrale Mailbox - BS Storage (eumbx05)

  _  

- Everybody has a photographic memory, some just don't have film. - 



-Original Message-
From: Rogelio Bazán Reyes [mailto:[EMAIL PROTECTED] 
Sent: vrijdag 12 maart 2004 2:13
To: [EMAIL PROTECTED]
Subject: TSM and VMWare

Anyone has tried to backup or restore a vmware file system on a VMware
server?

regards

--
-
Rogelio Bazán Reyes
Grupo Financiero Santander Serfín
Soporte Técnico
Tlalpan 3016. Col Espartaco
C.P. 04870
D.F., México
Tel. +52 +55 51741100 ext.19321 
+52 +55 51741953
-


=DISCLAIMER=

De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de 
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te 
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit 
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij 
aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige 
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij 
overgebrachte virussen.

The information contained in this e-mail is confidential and may be privileged. It may 
be read, copied and used only by the intended recipient. If you have received it in 
error, please contact the sender immediately by return e-mail; please delete in this 
case the e-mail and do not disclose its contents to any person. We don't accept 
liability for any errors, omissions, delays of receipt or viruses in the contents of 
this message which arise as a result of e-mail transmission.


AW: TSM and VMWare

2004-03-12 Thread Salak Juraj
Ilja,
did you try a restore or only a backup?
Juraj

-Ursprüngliche Nachricht-
Von: Coolen, IG (Ilja) [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 12. März 2004 09:14
An: [EMAIL PROTECTED]
Betreff: Re: TSM and VMWare


Yup,

I've done that, and it works fine,
although you have to specify the /vmfs/filesystemname/* directory
explicitly, because TSM doesn't recognize it as a filesystem during it's
scan of all-local filesystems.


Ilja G. Coolen


  _  

ABP / USZO  
CIS / BS / TB / Storage Management  
Telefoon : +31(0)45  579 7938   
Fax  : +31(0)45  579 3990   
Email: [EMAIL PROTECTED]
Centrale Mailbox : Centrale Mailbox - BS Storage (eumbx05)

  _  

- Everybody has a photographic memory, some just don't have film. - 



-Original Message-
From: Rogelio Bazán Reyes [mailto:[EMAIL PROTECTED] 
Sent: vrijdag 12 maart 2004 2:13
To: [EMAIL PROTECTED]
Subject: TSM and VMWare

Anyone has tried to backup or restore a vmware file system on a VMware
server?

regards

--
-
Rogelio Bazán Reyes
Grupo Financiero Santander Serfín
Soporte Técnico
Tlalpan 3016. Col Espartaco
C.P. 04870
D.F., México
Tel. +52 +55 51741100 ext.19321 
+52 +55 51741953
-


=DISCLAIMER=


De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd
voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken
wij u contact op te nemen met de afzender per kerende e-mail. Verder
verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud
ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid
voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van
een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen.

The information contained in this e-mail is confidential and may be
privileged. It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as
a result of e-mail transmission.


Re: AW: TSM and VMWare

2004-03-12 Thread Phil Jones
Salak,

we've just done a DR test and the one thing that worked really well was the
restores of VM's.

Cheers

Phil Jones
Technical Specialist
United Biscuits
Tel (external) 0151 4735972
Tel (internal) 755 5972
e-mail: [EMAIL PROTECTED]


   
  Salak Juraj  
  [EMAIL PROTECTED]To:   [EMAIL PROTECTED]
  T   cc: 
  Sent by: ADSM:  Subject:  AW: TSM and VMWare
  Dist Stor
  Manager 
  [EMAIL PROTECTED]
  .EDU
   
   
  12/03/2004 09:07 
  Please respond to
  ADSM: Dist Stor 
  Manager 
   
   




Ilja,
did you try a restore or only a backup?
Juraj

-Ursprüngliche Nachricht-
Von: Coolen, IG (Ilja) [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 12. März 2004 09:14
An: [EMAIL PROTECTED]
Betreff: Re: TSM and VMWare


Yup,

I've done that, and it works fine,
although you have to specify the /vmfs/filesystemname/* directory
explicitly, because TSM doesn't recognize it as a filesystem during it's
scan of all-local filesystems.


Ilja G. Coolen


  _

ABP / USZO
CIS / BS / TB / Storage Management
Telefoon : +31(0)45  579 7938
Fax  : +31(0)45  579 3990
Email: [EMAIL PROTECTED]
Centrale Mailbox : Centrale Mailbox - BS Storage (eumbx05)

  _

- Everybody has a photographic memory, some just don't have film. -



-Original Message-
From: Rogelio Bazán Reyes [mailto:[EMAIL PROTECTED]
Sent: vrijdag 12 maart 2004 2:13
To: [EMAIL PROTECTED]
Subject: TSM and VMWare

Anyone has tried to backup or restore a vmware file system on a VMware
server?

regards

--
-
Rogelio Bazán Reyes
Grupo Financiero Santander Serfín
Soporte Técnico
Tlalpan 3016. Col Espartaco
C.P. 04870
D.F., México
Tel. +52 +55 51741100 ext.19321
+52 +55 51741953
-


=DISCLAIMER=



De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd
voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken
wij u contact op te nemen met de afzender per kerende e-mail. Verder
verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud
ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid
voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van
een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen.

The information contained in this e-mail is confidential and may be
privileged. It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose
its
contents to any person. We don't accept liability for any errors,
omissions,
delays of receipt or viruses in the contents of this message which arise as
 a result of e-mail transmission.


AW: Retiring LTO tapes

2004-03-12 Thread Salak Juraj
another very usefull commands in this context are  restore volume 
and/or restore stg
I love this two very much and highly appreciate related TSM concepts  :-)
Juraj

-Ursprüngliche Nachricht-
Von: Mitch Sako [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 11. März 2004 23:02
An: [EMAIL PROTECTED]
Betreff: Re: Retiring LTO tapes


I share the same policy.  If I see any sort of error on a tape that looks
like it's jeopardizing the repository, I immediately move the data off
using 'move data' or worst case I delete the volume using discard=yes.  The
absolute worst possible thing I can think of is going to restore someone's
file and finding out that it's unavailable for some reason.  That's my
biggest nightmare, and luckily in my 15+ years of using ESMS/WDSF/ADSM/TSM
that has not happened yet.

The cost of the tape or the time needed to get rid of it is minuscule
compared to the value of a file that a user wants back really badly and
can't have back because it's not backed up reliably.

At 3/11/2004 07:41 AM Thursday, you wrote:
I have not found a useful policy. If I start getting write errors on tapes
I make them a candidate for retirement, no matter how new or old they are.


AW: AW: TSM and VMWare

2004-03-12 Thread Salak Juraj
it´s good news, thanks Phil!

would you mind to share with us steps to restore the vmware OS itself?

Juraj

-Ursprüngliche Nachricht-
Von: Phil Jones [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 12. März 2004 09:59
An: [EMAIL PROTECTED]
Betreff: Re: AW: TSM and VMWare


Salak,

we've just done a DR test and the one thing that worked really well was the
restores of VM's.

Cheers

Phil Jones
Technical Specialist
United Biscuits
Tel (external) 0151 4735972
Tel (internal) 755 5972
e-mail: [EMAIL PROTECTED]


   
  Salak Juraj  
  [EMAIL PROTECTED]To:
[EMAIL PROTECTED]
  T   cc: 
  Sent by: ADSM:  Subject:  AW: TSM and VMWare
  Dist Stor
  Manager 
  [EMAIL PROTECTED]
  .EDU
   
   
  12/03/2004 09:07 
  Please respond to
  ADSM: Dist Stor 
  Manager 
   
   




Ilja,
did you try a restore or only a backup?
Juraj

-Ursprüngliche Nachricht-
Von: Coolen, IG (Ilja) [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 12. März 2004 09:14
An: [EMAIL PROTECTED]
Betreff: Re: TSM and VMWare


Yup,

I've done that, and it works fine,
although you have to specify the /vmfs/filesystemname/* directory
explicitly, because TSM doesn't recognize it as a filesystem during it's
scan of all-local filesystems.


Ilja G. Coolen


  _

ABP / USZO
CIS / BS / TB / Storage Management
Telefoon : +31(0)45  579 7938
Fax  : +31(0)45  579 3990
Email: [EMAIL PROTECTED]
Centrale Mailbox : Centrale Mailbox - BS Storage (eumbx05)

  _

- Everybody has a photographic memory, some just don't have film. -



-Original Message-
From: Rogelio Bazán Reyes [mailto:[EMAIL PROTECTED]
Sent: vrijdag 12 maart 2004 2:13
To: [EMAIL PROTECTED]
Subject: TSM and VMWare

Anyone has tried to backup or restore a vmware file system on a VMware
server?

regards

--
-
Rogelio Bazán Reyes
Grupo Financiero Santander Serfín
Soporte Técnico
Tlalpan 3016. Col Espartaco
C.P. 04870
D.F., México
Tel. +52 +55 51741100 ext.19321
+52 +55 51741953
-


=DISCLAIMER=



De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd
voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken
wij u contact op te nemen met de afzender per kerende e-mail. Verder
verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud
ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid
voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van
een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen.

The information contained in this e-mail is confidential and may be
privileged. It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose
its
contents to any person. We don't accept liability for any errors,
omissions,
delays of receipt or viruses in the contents of this message which arise as
 a result of e-mail transmission.


Re: AW: AW: TSM and VMWare

2004-03-12 Thread Phil Jones
No problem, except we are still writing it up, so bear with us.

Regards

Phil Jones

e-mail: [EMAIL PROTECTED]


   
  Salak Juraj  
  [EMAIL PROTECTED]To:   [EMAIL PROTECTED]
  T   cc: 
  Sent by: ADSM:  Subject:  AW: AW: TSM and VMWare
  Dist Stor
  Manager 
  [EMAIL PROTECTED]
  .EDU
   
   
  12/03/2004 09:13 
  Please respond to
  ADSM: Dist Stor 
  Manager 
   
   




it´s good news, thanks Phil!

would you mind to share with us steps to restore the vmware OS itself?

Juraj

-Ursprüngliche Nachricht-
Von: Phil Jones [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 12. März 2004 09:59
An: [EMAIL PROTECTED]
Betreff: Re: AW: TSM and VMWare


Salak,

we've just done a DR test and the one thing that worked really well was the
restores of VM's.

Cheers

Phil Jones
Technical Specialist
United Biscuits
Tel (external) 0151 4735972
Tel (internal) 755 5972
e-mail: [EMAIL PROTECTED]



  Salak Juraj
  [EMAIL PROTECTED]To:
[EMAIL PROTECTED]
  T   cc:
  Sent by: ADSM:  Subject:  AW: TSM and VMWare
  Dist Stor
  Manager
  [EMAIL PROTECTED]
  .EDU


  12/03/2004 09:07
  Please respond to
  ADSM: Dist Stor
  Manager






Ilja,
did you try a restore or only a backup?
Juraj

-Ursprüngliche Nachricht-
Von: Coolen, IG (Ilja) [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 12. März 2004 09:14
An: [EMAIL PROTECTED]
Betreff: Re: TSM and VMWare


Yup,

I've done that, and it works fine,
although you have to specify the /vmfs/filesystemname/* directory
explicitly, because TSM doesn't recognize it as a filesystem during it's
scan of all-local filesystems.


Ilja G. Coolen


  _

ABP / USZO
CIS / BS / TB / Storage Management
Telefoon : +31(0)45  579 7938
Fax  : +31(0)45  579 3990
Email: [EMAIL PROTECTED]
Centrale Mailbox : Centrale Mailbox - BS Storage (eumbx05)

  _

- Everybody has a photographic memory, some just don't have film. -



-Original Message-
From: Rogelio Bazán Reyes [mailto:[EMAIL PROTECTED]
Sent: vrijdag 12 maart 2004 2:13
To: [EMAIL PROTECTED]
Subject: TSM and VMWare

Anyone has tried to backup or restore a vmware file system on a VMware
server?

regards

--
-
Rogelio Bazán Reyes
Grupo Financiero Santander Serfín
Soporte Técnico
Tlalpan 3016. Col Espartaco
C.P. 04870
D.F., México
Tel. +52 +55 51741100 ext.19321
+52 +55 51741953
-


=DISCLAIMER=




De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd
voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken
wij u contact op te nemen met de afzender per kerende e-mail. Verder
verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud
ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid
voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van
een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen.

The information contained in this e-mail is confidential and may be
privileged. It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose
its
contents to any person. We don't accept liability for any errors,
omissions,
delays of receipt or viruses in the contents of this message which arise as
  a result of e-mail transmission.


Re: TSM and VMWare

2004-03-12 Thread Coolen, IG (Ilja)
Of course we did both.
It looks and feels just like a simple file backup and restore, but you have
to make sure to also 
Include the configuration file of the guest OS in the backup and restore
actions, because they rely on each other.

Let say we have an guest os running in
/vmfs/sharkdisk/Windows2003-server.dsk
The configuration of this OS is stored in a .vmx file in the /root/vmware
directory. You can dictate the locations of these files, so this could vary.
But you need these files when you want to run the guest OS.

Grtz.

Ilja

-Original Message-
From: Salak Juraj [mailto:[EMAIL PROTECTED] 
Sent: vrijdag 12 maart 2004 10:08
To: [EMAIL PROTECTED]
Subject: AW: TSM and VMWare

Ilja,
did you try a restore or only a backup?
Juraj

-Ursprüngliche Nachricht-
Von: Coolen, IG (Ilja) [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 12. März 2004 09:14
An: [EMAIL PROTECTED]
Betreff: Re: TSM and VMWare


Yup,

I've done that, and it works fine,
although you have to specify the /vmfs/filesystemname/* directory
explicitly, because TSM doesn't recognize it as a filesystem during it's
scan of all-local filesystems.


Ilja G. Coolen


  _  

ABP / USZO  
CIS / BS / TB / Storage Management  
Telefoon : +31(0)45  579 7938   
Fax  : +31(0)45  579 3990   
Email: [EMAIL PROTECTED]
Centrale Mailbox : Centrale Mailbox - BS Storage (eumbx05)

  _  

- Everybody has a photographic memory, some just don't have film. - 



-Original Message-
From: Rogelio Bazán Reyes [mailto:[EMAIL PROTECTED]
Sent: vrijdag 12 maart 2004 2:13
To: [EMAIL PROTECTED]
Subject: TSM and VMWare

Anyone has tried to backup or restore a vmware file system on a VMware
server?

regards

--
-
Rogelio Bazán Reyes
Grupo Financiero Santander Serfín
Soporte Técnico
Tlalpan 3016. Col Espartaco
C.P. 04870
D.F., México
Tel. +52 +55 51741100 ext.19321 
+52 +55 51741953
-


=DISCLAIMER=


De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd
voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken
wij u contact op te nemen met de afzender per kerende e-mail. Verder
verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud
ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid
voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van
een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen.

The information contained in this e-mail is confidential and may be
privileged. It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as
a result of e-mail transmission.


=DISCLAIMER=

De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de 
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te 
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit 
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij 
aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige 
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij 
overgebrachte virussen.

The information contained in this e-mail is confidential and may be privileged. It may 
be read, copied and used only by the intended recipient. If you have received it in 
error, please contact the sender immediately by return e-mail; please delete in this 
case the e-mail and do not disclose its contents to any person. We don't accept 
liability for any errors, omissions, delays of receipt or viruses in the contents of 
this message which arise as a result of e-mail transmission.


to the spanish members of the TSM community

2004-03-12 Thread Gianluca Mariani1
Maybe this is not the best place,
but I wanted, together with the other Tivoli GRT members, to express our 
deep sadness for the 11 march events in Madrid.
for what it's worth we feel close to you and your pain of today.
coraggio fratelli.


Cordiali saluti
Gianluca Mariani
Tivoli TSM Global Response Team, Roma
Via Sciangai 53, Roma
 phones : +39(0)659664598
   +393351270554 (mobile)
[EMAIL PROTECTED]

The Hitch Hiker's Guide to the Galaxy says  of the Sirius Cybernetics 
Corporation product that it is very easy to be blinded to the essential 
uselessness of  them by the sense of achievement you get from getting them 
to work at all. In other words  and this is the rock solid principle  on 
which the  whole  of the Corporation's Galaxy-wide success is founded 
-their fundamental design flaws are  completely  hidden  by  their 
superficial design flaws...


AW: TSM and VMWare

2004-03-12 Thread Salak Juraj
Hi,

there is a misunderstanding somewhere.
I thought Rogelio was asking about backup of the vmware OS itself,
not about virtual machines.

The task you talk about - of backing up / restoring virtual machines
is working like a breeze, it is really a pleasure and
a viable disaster recovery solution
for Windows servers.

Juraj




-Ursprüngliche Nachricht-
Von: Coolen, IG (Ilja) [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 12. März 2004 10:42
An: [EMAIL PROTECTED]
Betreff: Re: TSM and VMWare


Of course we did both.
It looks and feels just like a simple file backup and restore, but you have
to make sure to also 
Include the configuration file of the guest OS in the backup and restore
actions, because they rely on each other.

Let say we have an guest os running in
/vmfs/sharkdisk/Windows2003-server.dsk
The configuration of this OS is stored in a .vmx file in the /root/vmware
directory. You can dictate the locations of these files, so this could vary.
But you need these files when you want to run the guest OS.

Grtz.

Ilja

-Original Message-
From: Salak Juraj [mailto:[EMAIL PROTECTED] 
Sent: vrijdag 12 maart 2004 10:08
To: [EMAIL PROTECTED]
Subject: AW: TSM and VMWare

Ilja,
did you try a restore or only a backup?
Juraj

-Ursprüngliche Nachricht-
Von: Coolen, IG (Ilja) [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 12. März 2004 09:14
An: [EMAIL PROTECTED]
Betreff: Re: TSM and VMWare


Yup,

I've done that, and it works fine,
although you have to specify the /vmfs/filesystemname/* directory
explicitly, because TSM doesn't recognize it as a filesystem during it's
scan of all-local filesystems.


Ilja G. Coolen


  _  

ABP / USZO  
CIS / BS / TB / Storage Management  
Telefoon : +31(0)45  579 7938   
Fax  : +31(0)45  579 3990   
Email: [EMAIL PROTECTED]
Centrale Mailbox : Centrale Mailbox - BS Storage (eumbx05)

  _  

- Everybody has a photographic memory, some just don't have film. - 



-Original Message-
From: Rogelio Bazán Reyes [mailto:[EMAIL PROTECTED]
Sent: vrijdag 12 maart 2004 2:13
To: [EMAIL PROTECTED]
Subject: TSM and VMWare

Anyone has tried to backup or restore a vmware file system on a VMware
server?

regards

--
-
Rogelio Bazán Reyes
Grupo Financiero Santander Serfín
Soporte Técnico
Tlalpan 3016. Col Espartaco
C.P. 04870
D.F., México
Tel. +52 +55 51741100 ext.19321 
+52 +55 51741953
-


=DISCLAIMER=


De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd
voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken
wij u contact op te nemen met de afzender per kerende e-mail. Verder
verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud
ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid
voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van
een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen.

The information contained in this e-mail is confidential and may be
privileged. It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as
a result of e-mail transmission.


=DISCLAIMER=


De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd
voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken
wij u contact op te nemen met de afzender per kerende e-mail. Verder
verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud
ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid
voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van
een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen.

The information contained in this e-mail is confidential and may be
privileged. It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as
a result of e-mail transmission.


Looking for 3590 tape supplier

2004-03-12 Thread Tyree, David
We need to get some more 3590K tapes for our library and our
regular supplier is not able to help us right now. All we need is 30 new
tapes to tide us over while we migrate to LTO-2.

Any suggestions?





David Tyree
Enterprise Backup Administrator
South Georgia Medical Center
229.333.1155

Confidential Notice:  This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information.  Any unauthorized review, use,  disclosure or
distribution is prohibited.  If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.


Re: update all copy groups

2004-03-12 Thread Andrew Raibeck
You need to update each copy group one at a time. You can not use SQL to
modify the TSM server database.

One method that might facilitate this for you is to use the SELECT
statement to build the UPDATE COPYGROUP statements for you:

   dsmadmc -id=storman -pa=x -dataonly=yes  -commadelimited
  select 'UPD CO ' || domain_name, set_name, class_name || ' SER=ST'
  from bu_copygroups
  where set_name='STANDARD'  admin.mac

Edit the resulting admin.mac file and change the commas to blank spaces.
Then execute the macro like this:

   dsmadmc -id=storman -pa=x macro admin.mac

Then you will need to activate your policy set.

The above SELECT statement is just an example; you will need to modify it
to suit your own environment. Note that if you have very short domain,
policy set, and management class names, then using -commadelimited may not
be necessary. I included it to avoid output where the names are wrapped to
multiple columns. Another alternative is to use the AS keyword to create
new column names with longer widths:

   dsmadmc -id=storman -pa=x -dataonly=yes
  select 'UPD CO ' || domain_name as \DOMAIN \,
  set_name as \POLICYSET\,
  class_name || ' SER=ST' as \MGMTCLASS  \
  from bu_copygroups
  where not set_name='ACTIVE'  admin.mac

Notice (a) the blank spaces in the AS column names to force a longer
column width, and (b) the backslashes in front of the double quotation
marks that are embedded in the double quotes that surround the entire
SELECT statement. This variant does not require you to edit out commas in
the macro file.

This was done from a Windows OS command prompt.

Others may have other variations that work.

Have fun!

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED]
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.



Magalie Siaud [EMAIL PROTECTED]
Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED]
03/11/2004 19:36
Please respond to
ADSM: Dist Stor Manager


To
[EMAIL PROTECTED]
cc

Subject
update all copy groups






Hi,

I wish to update all my copy groups by setting serialization=static.
UPD CO * * * SER=ST doesn't work.

could I use a update BU_copygrousp set serialization='STATIC' kind of
statement?

Magalie.


Re: Looking for 3590 tape supplier

2004-03-12 Thread Coats, Jack
try CDW at cdw.com ---

-Original Message-
From: Tyree, David [mailto:[EMAIL PROTECTED]
Sent: Friday, March 12, 2004 7:15 AM
To: [EMAIL PROTECTED]
Subject: Looking for 3590 tape supplier


We need to get some more 3590K tapes for our library and our
regular supplier is not able to help us right now. All we need is 30 new
tapes to tide us over while we migrate to LTO-2.

Any suggestions?





David Tyree
Enterprise Backup Administrator
South Georgia Medical Center
229.333.1155

Confidential Notice:  This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information.  Any unauthorized review, use,  disclosure or
distribution is prohibited.  If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.


Re: Looking for 3590 tape supplier

2004-03-12 Thread Hart, Charles
Also try Imprint They've always been a big help to us 800-646-9099

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Coats, Jack
Sent: Friday, March 12, 2004 11:22 AM
To: [EMAIL PROTECTED]
Subject: Re: Looking for 3590 tape supplier


try CDW at cdw.com ---

-Original Message-
From: Tyree, David [mailto:[EMAIL PROTECTED]
Sent: Friday, March 12, 2004 7:15 AM
To: [EMAIL PROTECTED]
Subject: Looking for 3590 tape supplier


We need to get some more 3590K tapes for our library and our
regular supplier is not able to help us right now. All we need is 30 new
tapes to tide us over while we migrate to LTO-2.

Any suggestions?





David Tyree
Enterprise Backup Administrator
South Georgia Medical Center
229.333.1155

Confidential Notice:  This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information.  Any unauthorized review, use,  disclosure or
distribution is prohibited.  If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.


Re: Looking for 3590 tape supplier

2004-03-12 Thread Ward, Stuart
Once used degaussed tapes available at

Magnetic Products  Services, Inc.
Tara Turley
Phone : 800-447-1277 ext. 115

The last ones we got were actually brand new and half the price of new ones.

Stu

-Original Message-
From: Hart, Charles [mailto:[EMAIL PROTECTED]
Sent: Friday, March 12, 2004 12:21 PM
To: [EMAIL PROTECTED]
Subject: Re: Looking for 3590 tape supplier


Also try Imprint They've always been a big help to us 800-646-9099

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Coats, Jack
Sent: Friday, March 12, 2004 11:22 AM
To: [EMAIL PROTECTED]
Subject: Re: Looking for 3590 tape supplier


try CDW at cdw.com ---

-Original Message-
From: Tyree, David [mailto:[EMAIL PROTECTED]
Sent: Friday, March 12, 2004 7:15 AM
To: [EMAIL PROTECTED]
Subject: Looking for 3590 tape supplier


We need to get some more 3590K tapes for our library and our
regular supplier is not able to help us right now. All we need is 30 new
tapes to tide us over while we migrate to LTO-2.

Any suggestions?





David Tyree
Enterprise Backup Administrator
South Georgia Medical Center
229.333.1155

Confidential Notice:  This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information.  Any unauthorized review, use,  disclosure or
distribution is prohibited.  If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.


Re: Looking for 3590 tape supplier

2004-03-12 Thread Ward, Stuart
Clarification:  Although we use DLT's they may have what you need

-Original Message-
From: Ward, Stuart
Sent: Friday, March 12, 2004 1:54 PM
To: 'ADSM: Dist Stor Manager'
Subject: RE: Looking for 3590 tape supplier


Once used degaussed tapes available at

Magnetic Products  Services, Inc.
Tara Turley
Phone : 800-447-1277 ext. 115

The last ones we got were actually brand new and half the price of new ones.

Stu

-Original Message-
From: Hart, Charles [mailto:[EMAIL PROTECTED]
Sent: Friday, March 12, 2004 12:21 PM
To: [EMAIL PROTECTED]
Subject: Re: Looking for 3590 tape supplier


Also try Imprint They've always been a big help to us 800-646-9099

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Coats, Jack
Sent: Friday, March 12, 2004 11:22 AM
To: [EMAIL PROTECTED]
Subject: Re: Looking for 3590 tape supplier


try CDW at cdw.com ---

-Original Message-
From: Tyree, David [mailto:[EMAIL PROTECTED]
Sent: Friday, March 12, 2004 7:15 AM
To: [EMAIL PROTECTED]
Subject: Looking for 3590 tape supplier


We need to get some more 3590K tapes for our library and our
regular supplier is not able to help us right now. All we need is 30 new
tapes to tide us over while we migrate to LTO-2.

Any suggestions?





David Tyree
Enterprise Backup Administrator
South Georgia Medical Center
229.333.1155

Confidential Notice:  This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information.  Any unauthorized review, use,  disclosure or
distribution is prohibited.  If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.


Re: Looking for 3590 tape supplier

2004-03-12 Thread Richard Sims
Once used degaussed tapes available at

Well, they could not degauss 3590s as that would destroy the servo track
and thus their usability.  Perhaps they just write over them?

   Richard Sims


Re: Looking for 3590 tape supplier

2004-03-12 Thread Ward, Stuart
Yup my bad - we use DLT's.  The 3590's are 'recertified' at about $43 ea

-Original Message-
From: Richard Sims [mailto:[EMAIL PROTECTED]
Sent: Friday, March 12, 2004 2:04 PM
To: [EMAIL PROTECTED]
Subject: Re: Looking for 3590 tape supplier


Once used degaussed tapes available at

Well, they could not degauss 3590s as that would destroy the servo track
and thus their usability.  Perhaps they just write over them?

   Richard Sims


Strange inventory expiration problem

2004-03-12 Thread Scott McCambly
Here's a good one for a Friday afternoon

We've had a requirement to temporarily suspend expiration of objects on
selected client nodes.
We copied the active policy set for the domain containing these nodes
and set all backup and archive copy group parameters to NOLIMIT, and
activated this new policy set.  I have verified that I see these new
values from the client side (q mgmt -detail).
The strange part is that now when we run expiration processing in
verbose mode, as the processing hits the filespaces for these nodes, it
is still reporting statistics of  many hundreds of backup objects being
deleted.  How is this possible?!?  We of course only let expiration
processing run for a minute before canceling it again.  A few sample
query backup -inactive on one of the nodes that was listed in the log
messages of expiration processing seem to show all the versions there as
expected.
I then tried to turn on tracing to see what files were being deleted,
but the trace messages generated by IMEXP and IMDEL only show the object
ID, and I assume once deleted that you couldn't retrieve the file name
from the database anyway.
Can anyone please explain this behavior, or possibly point me to more
trace flags that might help show what files are being deleted?
Thanks

Scott.


Re: Strange inventory expiration problem

2004-03-12 Thread Richard Sims
Here's a good one for a Friday afternoon

We've had a requirement to temporarily suspend expiration of objects on
selected client nodes.

We copied the active policy set for the domain containing these nodes
and set all backup and archive copy group parameters to NOLIMIT, and
activated this new policy set.  I have verified that I see these new
values from the client side (q mgmt -detail).

The strange part is that now when we run expiration processing in
verbose mode, as the processing hits the filespaces for these nodes, it
is still reporting statistics of  many hundreds of backup objects being
deleted.  How is this possible?!?

I believe that the documentation of expiration mechanics in the Admin Guide
manual cover this...  When a Backup is performed under a prevailing policy
set, it will push in new Active versions of files, and effectively push out
the oldest Inactive version which exceeds the versions retained value: it
marks it for expiration.  Once a file is marked, I don't know that anything
can unmark it - even extending policy values.  Thus, the next Expire Inventory
will cause the marked files to evaporate.  And the manual describes how files
can otherwise be flagged for expiration, other than date-based.

Whereas your requirement is to suspend expiration, I would not run expiration.

  Richard Sims


Re: Strange inventory expiration problem

2004-03-12 Thread Dwight Cook





hard to say...
I'll speculate though...
now, after doing all the voodoo, did you push an incremental from each node
you desired to increase the retention of ???
there is the internal table Expiring.Objects and I ~think~ that as your
client runs its normal incremental and you see all of those expiring
blah... that is putting entries into the Expiring.Objects internal table
to assist in the expiration process
Backups prior to your environment modifications might have placed entries
into that table that are being processed during expiration.
Maybe if you rerun incrementals from all those nodes, it will properly
rebind all the files and cure that problem.

this is a LOT of guess work by me... don't have any logic manuals for TSM
available.

I would start by forcing the clients to connect to the tsm server and
perform fresh incremental processing to get the new management class
characteristics picked up and applied...

just a thought

Dwight E. Cook
Systems Management Integration Professional, Advanced
Integrated Storage Management
TSM Administration
(918) 925-8045



   
  Scott McCambly   
  [EMAIL PROTECTED]To:   [EMAIL PROTECTED]
  AM.NET  cc: 
  Sent by: ADSM:  Subject:  Strange inventory expiration 
problem
  Dist Stor
  Manager 
  [EMAIL PROTECTED]
  .EDU
   
   
  03/12/2004 01:27 
  PM   
  Please respond to
  ADSM: Dist Stor 
  Manager 
   
   




Here's a good one for a Friday afternoon

We've had a requirement to temporarily suspend expiration of objects on
selected client nodes.

We copied the active policy set for the domain containing these nodes
and set all backup and archive copy group parameters to NOLIMIT, and
activated this new policy set.  I have verified that I see these new
values from the client side (q mgmt -detail).

The strange part is that now when we run expiration processing in
verbose mode, as the processing hits the filespaces for these nodes, it
is still reporting statistics of  many hundreds of backup objects being
deleted.  How is this possible?!?  We of course only let expiration
processing run for a minute before canceling it again.  A few sample
query backup -inactive on one of the nodes that was listed in the log
messages of expiration processing seem to show all the versions there as
expected.

I then tried to turn on tracing to see what files were being deleted,
but the trace messages generated by IMEXP and IMDEL only show the object
ID, and I assume once deleted that you couldn't retrieve the file name
from the database anyway.

Can anyone please explain this behavior, or possibly point me to more
trace flags that might help show what files are being deleted?

Thanks

Scott.


inline: graycol.gifinline: ecblank.gifinline: pic19149.gif

Can't restore files in Client

2004-03-12 Thread Taha, Hana
Hello All,

I am trying to restore some files on my test server with tapes that I had on
my production server. I recently changed my dsm.sys file to make my test
server a TSM server and not a client. Now I am getting this error message.
Can anyone please tell me how I can get around this?

Servername localSrv
COMMM  TCP
TCPPort1500
TCPServeraddress   192.7.2.154
INCLExcl   /usr/tivoli/tsm/client/ba/bin/inexclude.opt
SCHEDMODE  PROMPTED
TCPW   64
TXNB   25600
TCPB   32
PASSWORDACCESS GENERATE
SCHEDLOGName   /usr/tivoli/tsm/client/ba/bin/dsmsched.log
SCHEDLOGRET7
ERRORLOGRET7
NODENAME   stooge

tsm restore /purchasing/* -sub=yes
Node Name: STOOGE
ANS1353E Session rejected: Unknown or incorrect ID entered

Restore function invoked.

ANS1353E Session rejected: Unknown or incorrect ID entered

Thanks -
Hana Taha
Systems Analyst III
Parker Drilling Information Technology
281*406*2486


Re: Can't restore files in Client

2004-03-12 Thread Alexei Kojenov
The message you are getting means that the node STOOGE is not registered
on the server. Are you sure you are connecting to the right server? You
can run dsmadmc (administrative client) and do 'query node' command to see
which nodes are registered.

Alexei Kojenov
TSM Client Development
(408) 256-7009
[EMAIL PROTECTED]





Taha, Hana [EMAIL PROTECTED]
Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED]
03/12/2004 02:43 PM
Please respond to
ADSM: Dist Stor Manager


To
[EMAIL PROTECTED]
cc

Subject
Can't restore files in Client






Hello All,

I am trying to restore some files on my test server with tapes that I had
on
my production server. I recently changed my dsm.sys file to make my test
server a TSM server and not a client. Now I am getting this error message.
Can anyone please tell me how I can get around this?

Servername localSrv
COMMM  TCP
TCPPort1500
TCPServeraddress   192.7.2.154
INCLExcl   /usr/tivoli/tsm/client/ba/bin/inexclude.opt
SCHEDMODE  PROMPTED
TCPW   64
TXNB   25600
TCPB   32
PASSWORDACCESS GENERATE
SCHEDLOGName   /usr/tivoli/tsm/client/ba/bin/dsmsched.log
SCHEDLOGRET7
ERRORLOGRET7
NODENAME   stooge

tsm restore /purchasing/* -sub=yes
Node Name: STOOGE
ANS1353E Session rejected: Unknown or incorrect ID entered

Restore function invoked.

ANS1353E Session rejected: Unknown or incorrect ID entered

Thanks -
Hana Taha
Systems Analyst III
Parker Drilling Information Technology
281*406*2486


Re: Select for finding if a file on tape already has a copy in a copypool

2004-03-12 Thread Steven Pemberton
On Thursday 11 March 2004 01:35, PAC Brion Arnaud wrote:
 Hi Juraj,

 Thanks for the tip, I could probably use it, case I would not succeed in
 building a proper SQL statement. But so far, I really need that precise
 info to build a sub-query in my main query ... Cheers.

I don't think the copied= parameter is exposed for the purposes of SQL
queries.

You need to remember the TSM database isn't really a relation database. The
software only presents us with a releational view of the data, which does
not always contain every attribute of the original.

But, you can probably make do with something like the query below, which
instead compares the occupancy table for primary and copy storage pool
contents:

select (select sum(num_files) from occupancy where stgpool_name like '%PRI%')
- (select sum(num_files) from occupancy where stgpool_name like '%COPY%') as
UNCOPIED_FILES, (select sum(physical_mb) from occupancy where stgpool_name
like '%PRI%') - sum(physical_mb) as UNCOPIED_MB from occupancy where
stgpool_name like '%COPY%'

The output should look something like the following:

UNCOPIED_FILES   UNCOPIED_MB
-- -
 2  0.12

Note, the query assumes certain naming conventions for primary and copy
storage pools, but you could make it more generic easily enough.

Regards,
Steven P.

--
Steven Pemberton
Senior Enterprise Management Consultant
IBK, Senetas Group

Mobile: +61/0 418 335 136 | Phone: +61/3 9820 5811 | Fax: +61/3 9820 9907
Level 1, 11 Queens Road, Melbourne, Victoria, 3004, Australia
http://www.senetas.com.au | http://www.ibk.com.au | http://www.datum.com.au


Re: Strange inventory expiration problem

2004-03-12 Thread Paul Fielding
Not only that, but if I recall correctly the only files that'll get rebound
are the ones that get touched by the client as either a still active file
(along with it's inactives) or a 'just' deleted file, one that was
previously active but as of this incremental has been deleted and becomes
inactive.

I seem to recall a discussion once that files that have been inactive for
awhile won't get touched during the rebinding process because there's no
active file getting scanned and no deleted file to be marked inactive (that
process is already done).  So I *think* files that were deleted more than 1
day ago won't get rebound to the new mgmt class.

I'm not certain of this, if someone can affirm or tell me otherwise that'd
be appreciated...

regards,

Paul

- Original Message -
From: Dwight Cook [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, March 12, 2004 3:08 PM
Subject: Re: Strange inventory expiration problem







hard to say...
I'll speculate though...
now, after doing all the voodoo, did you push an incremental from each node
you desired to increase the retention of ???
there is the internal table Expiring.Objects and I ~think~ that as your
client runs its normal incremental and you see all of those expiring
blah... that is putting entries into the Expiring.Objects internal table
to assist in the expiration process
Backups prior to your environment modifications might have placed entries
into that table that are being processed during expiration.
Maybe if you rerun incrementals from all those nodes, it will properly
rebind all the files and cure that problem.

this is a LOT of guess work by me... don't have any logic manuals for TSM
available.

I would start by forcing the clients to connect to the tsm server and
perform fresh incremental processing to get the new management class
characteristics picked up and applied...

just a thought

Dwight E. Cook
Systems Management Integration Professional, Advanced
Integrated Storage Management
TSM Administration
(918) 925-8045




  Scott McCambly
  [EMAIL PROTECTED]To:
[EMAIL PROTECTED]
  AM.NET  cc:
  Sent by: ADSM:  Subject:  Strange inventory
expiration problem
  Dist Stor
  Manager
  [EMAIL PROTECTED]
  .EDU


  03/12/2004 01:27
  PM
  Please respond to
  ADSM: Dist Stor
  Manager






Here's a good one for a Friday afternoon

We've had a requirement to temporarily suspend expiration of objects on
selected client nodes.

We copied the active policy set for the domain containing these nodes
and set all backup and archive copy group parameters to NOLIMIT, and
activated this new policy set.  I have verified that I see these new
values from the client side (q mgmt -detail).

The strange part is that now when we run expiration processing in
verbose mode, as the processing hits the filespaces for these nodes, it
is still reporting statistics of  many hundreds of backup objects being
deleted.  How is this possible?!?  We of course only let expiration
processing run for a minute before canceling it again.  A few sample
query backup -inactive on one of the nodes that was listed in the log
messages of expiration processing seem to show all the versions there as
expected.

I then tried to turn on tracing to see what files were being deleted,
but the trace messages generated by IMEXP and IMDEL only show the object
ID, and I assume once deleted that you couldn't retrieve the file name
from the database anyway.

Can anyone please explain this behavior, or possibly point me to more
trace flags that might help show what files are being deleted?

Thanks

Scott.