Re: AIX snapshot filesystem backup

2009-07-20 Thread Erwann Simon

Hi Mehdi,

Snapshot support for JFS2 for AIX is a 5.5 client feature...

--
Best regards / Cordialement / مع تحياتي
Erwann SIMON


Mehdi Salehi a écrit :

Hi,

TSM Server: AIX 6.1+TSM 5.2
Client1: AIX 5.2+B/A Client 5.4
Client2: AIX 6.1+B/A Client 6.1
Both clients have /testfs

dsmc backup image /testfs performs a snapshot backup in Client2 but static
in Client1. How can I force Client1 to do snapshot backup?

Regards,
Mehdi


Move data

2009-07-20 Thread Lars-Erik Öhman
TSM version: 5.5.2.1
OS: Windows 2003
Library: 3584
4 drives: 3952


I have moved the library to a new location this weekend, and I started up the 
library and server and everything worked. Now when I try to do a move data on 
a offsite volume it goes like this:

ANR2017I Administrator LAROHM issued command: MOVE DATA 000139
ANR2232W This command will move all of the data stored on volume 000139 to
other volumes within the same storage pool; the data will be inaccessible to
users until the operation completes.
ANR2017I Administrator LAROHM issued command: MOVE DATA 000139
ANR0984I Process 811 for MOVE DATA started in the BACKGROUND at 13:28:16.
ANR1140I Move data process started for volume 000139 (process ID 811).
ANR1141I Move data process ended for volume 000139.
ANR0985I Process 811 for MOVE DATA running in the BACKGROUND completed with
completion state SUCCESS at 13:28:16.

And nothing is done. Does anyone have a clue why it doesn´t empty the offsite 
volume, even if it say so!!

/Larsa




This communication is from a Carnegie company within the Carnegie Group.

The information contained in it, including any attachment or enclosure, is 
intended only for the person or entity to which it is addressed and may contain 
confidential and/or privileged material. Any unauthorised use, review, 
retransmissions, dissemination, copying or other use of, or taking of any 
action in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete or shred the material immediately. Thank you.

Opinions, conclusions and other information expressed in this message are not 
given or endorsed by my firm or employer unless otherwise indicated by an 
authorised representative independent of this message.


Re: Move data

2009-07-20 Thread Lars-Erik Öhman
Here is the query on the volume.

q vol 000139 f=d

   Volume Name: 000139
 Storage Pool Name: COPYPOOL1
 Device Class Name: 3592CLASS
Estimated Capacity: 369.5 G
   Scaled Capacity Applied: 100
  Pct Util: 6.5
 Volume Status: Filling
Access: Offsite
Pct. Reclaimable Space: 93.5
   Scratch Volume?: Yes
   In Error State?: No
  Number of Writable Sides: 1
   Number of Times Mounted: 2
 Write Pass Number: 1
 Approx. Date Last Written: 07/12/2009 19:15:11
Approx. Date Last Read: 07/12/2009 17:49:50
   Date Became Pending:
Number of Write Errors: 0
 Number of Read Errors: 0
   Volume Location: VAULT
Volume is MVS Lanfree Capable : No
Last Update by (administrator): LAROHM
 Last Update Date/Time: 07/12/2009 20:12:02
  Begin Reclaim Period:
End Reclaim Period:
  Drive Encryption Key Manager: None


/Larsa

-Original Message-
From: Richard Sims [mailto:r...@bu.edu]
Sent: den 20 juli 2009 15:22
To: Lars-Erik Öhman
Subject: Re: Move data

When posting a question like this, you need to include evidence of the
problem, in this case Query Volume 000139 Format=Detailed, before and
after.
Keep in mind that if a Move Data or the like had been done before on
an Offsite volume, the volume should shift to Pending state.

   Richard Sims


On Jul 20, 2009, at 7:40 AM, Lars-Erik Öhman wrote:

 TSM version: 5.5.2.1
 OS: Windows 2003
 Library: 3584
 4 drives: 3952


 I have moved the library to a new location this weekend, and I
 started up the library and server and everything worked. Now when I
 try to do a move data on a offsite volume it goes like this:

 ANR2017I Administrator LAROHM issued command: MOVE DATA 000139
 ANR2232W This command will move all of the data stored on volume
 000139 to
 other volumes within the same storage pool; the data will be
 inaccessible to
 users until the operation completes.
 ANR2017I Administrator LAROHM issued command: MOVE DATA 000139
 ANR0984I Process 811 for MOVE DATA started in the BACKGROUND at
 13:28:16.
 ANR1140I Move data process started for volume 000139 (process ID 811).
 ANR1141I Move data process ended for volume 000139.
 ANR0985I Process 811 for MOVE DATA running in the BACKGROUND
 completed with
 completion state SUCCESS at 13:28:16.

 And nothing is done. Does anyone have a clue why it doesn´t empty
 the offsite volume, even if it say so!!

 /Larsa


 

 This communication is from a Carnegie company within the Carnegie
 Group.

 The information contained in it, including any attachment or
 enclosure, is intended only for the person or entity to which it is
 addressed and may contain confidential and/or privileged material.
 Any unauthorised use, review, retransmissions, dissemination,
 copying or other use of, or taking of any action in reliance upon,
 this information by persons or entities other than the intended
 recipient is prohibited. If you received this in error, please
 contact the sender and delete or shred the material immediately.
 Thank you.

 Opinions, conclusions and other information expressed in this
 message are not given or endorsed by my firm or employer unless
 otherwise indicated by an authorised representative independent of
 this message.



This communication is from a Carnegie company within the Carnegie Group.

The information contained in it, including any attachment or enclosure, is 
intended only for the person or entity to which it is addressed and may contain 
confidential and/or privileged material. Any unauthorised use, review, 
retransmissions, dissemination, copying or other use of, or taking of any 
action in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete or shred the material immediately. Thank you.

Opinions, conclusions and other information expressed in this message are not 
given or endorsed by my firm or employer unless otherwise indicated by an 
authorised representative independent of this message.


Del volh

2009-07-20 Thread Moyer, Joni M
Hi Everyone,

I would like to clean up the volume history, but I do not want to cause issues 
with tapes that are managed by DRM.  In looking at the command  what it can 
accomplish I would probably like to get rid of all old volume information for 
new, reused  deleted volumes from years ago.

del volhist todate=01/01/2007 type=stgnew,stgreuse,stgdelete

Would running this del volhist command have any negative impact on volumes 
managed by DRM that are still in storage groups and have a long retention 
period?

How often do most of you run this command and what do you typically purge from 
the volume history?

Thanks in advance!

Joni Moyer
Storage Administrator III
(717)302-9966
joni.mo...@highmark.com



This e-mail and any attachments to it are confidential and are intended solely 
for use of the individual or entity to whom they are addressed. If you have 
received this e-mail in error, please notify the sender immediately and then 
delete it. If you are not the intended recipient, you must not keep, use, 
disclose, copy or distribute this e-mail without the author's prior permission. 
The views expressed in this e-mail message do not necessarily represent the 
views of Highmark Inc., its subsidiaries, or affiliates.


TDP full-diff backups of SQLServer

2009-07-20 Thread Schaub, Steve
W2K3 SQL Server 2000, 2003, 2008
TDP 5.5.1.0
We are currently doing daily full backups of all SQLServer databases, thinking 
of going to weekly full, daily diffs.
One question I haven't been able to figure out is whether native full/diff 
backups done by the DBA's will mess up the ones from the TDP?

Thanks,

Steve Schaub
Systems Engineer, Windows
BlueCross BlueShield of Tennessee


-
Please see the following link for the BlueCross BlueShield of Tennessee E-mail 
disclaimer:  http://www.bcbst.com/email_disclaimer.shtm


Re: Del volh

2009-07-20 Thread Shawn Drew
I run the following every day with no issues:

del volh todate=-7 t=stgn
del volh todate=-7 t=stgr
del volh todate=-7 t=stgd

I didn't think you could use multiple types on one line like that.

Regards,
Shawn




Internet
joni.mo...@highmark.com

Sent by: ADSM-L@VM.MARIST.EDU
07/20/2009 10:27 AM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
[ADSM-L] Del volh






Hi Everyone,

I would like to clean up the volume history, but I do not want to cause
issues with tapes that are managed by DRM.  In looking at the command 
what it can accomplish I would probably like to get rid of all old volume
information for new, reused  deleted volumes from years ago.

del volhist todate=01/01/2007 type=stgnew,stgreuse,stgdelete

Would running this del volhist command have any negative impact on volumes
managed by DRM that are still in storage groups and have a long retention
period?

How often do most of you run this command and what do you typically purge
from the volume history?

Thanks in advance!

Joni Moyer
Storage Administrator III
(717)302-9966
joni.mo...@highmark.com



This e-mail and any attachments to it are confidential and are intended
solely for use of the individual or entity to whom they are addressed. If
you have received this e-mail in error, please notify the sender
immediately and then delete it. If you are not the intended recipient, you
must not keep, use, disclose, copy or distribute this e-mail without the
author's prior permission. The views expressed in this e-mail message do
not necessarily represent the views of Highmark Inc., its subsidiaries, or
affiliates.



This message and any attachments (the message) is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.


Re: Del volh

2009-07-20 Thread Moyer, Joni M
Hi Shawn,

You are probably right about the syntax.  I didn't see anything indicating you 
could place commas between the types.  Do you use DRM in your environment?

Thanks again!

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Shawn 
Drew
Sent: Monday, July 20, 2009 11:22 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Del volh

I run the following every day with no issues:

del volh todate=-7 t=stgn
del volh todate=-7 t=stgr
del volh todate=-7 t=stgd

I didn't think you could use multiple types on one line like that.

Regards,
Shawn




Internet
joni.mo...@highmark.com

Sent by: ADSM-L@VM.MARIST.EDU
07/20/2009 10:27 AM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
[ADSM-L] Del volh






Hi Everyone,

I would like to clean up the volume history, but I do not want to cause
issues with tapes that are managed by DRM.  In looking at the command 
what it can accomplish I would probably like to get rid of all old volume
information for new, reused  deleted volumes from years ago.

del volhist todate=01/01/2007 type=stgnew,stgreuse,stgdelete

Would running this del volhist command have any negative impact on volumes
managed by DRM that are still in storage groups and have a long retention
period?

How often do most of you run this command and what do you typically purge
from the volume history?

Thanks in advance!

Joni Moyer
Storage Administrator III
(717)302-9966
joni.mo...@highmark.com



This e-mail and any attachments to it are confidential and are intended
solely for use of the individual or entity to whom they are addressed. If
you have received this e-mail in error, please notify the sender
immediately and then delete it. If you are not the intended recipient, you
must not keep, use, disclose, copy or distribute this e-mail without the
author's prior permission. The views expressed in this e-mail message do
not necessarily represent the views of Highmark Inc., its subsidiaries, or
affiliates.



This message and any attachments (the message) is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.


This e-mail and any attachments to it are confidential and are intended solely 
for use of the individual or entity to whom they are addressed.  If you have 
received this e-mail in error, please notify the sender immediately and then 
delete it.  If you are not the intended recipient, you must not keep, use, 
disclose, copy or distribute this e-mail without the author's prior permission. 
 The views expressed in this e-mail message do not necessarily represent the 
views of Highmark Inc., its subsidiaries, or affiliates.


Re: TDP full-diff backups of SQLServer

2009-07-20 Thread Del Hoobler
Hi Steve,

Yes.. they could potentially step on each other.
DIFFERENTIAL backups are based on the previous FULL.
If you have multiple entities (TSM and native tools) taking
FULL and DIFFERENTIAL backups, they won't know about each other and
your restores could get messy because you may need to use a
combination of both to get what you want.

BTW.. if you are using DP/SQL with SQL Server 2008,
please upgrade to DP/SQL 5.5.2.

Thanks,

Del



ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 07/20/2009
11:07:14 AM:

 [image removed]

 TDP full-diff backups of SQLServer

 Schaub, Steve

 to:

 ADSM-L

 07/20/2009 11:08 AM

 Sent by:

 ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU

 Please respond to ADSM: Dist Stor Manager

 W2K3 SQL Server 2000, 2003, 2008
 TDP 5.5.1.0
 We are currently doing daily full backups of all SQLServer
 databases, thinking of going to weekly full, daily diffs.
 One question I haven't been able to figure out is whether native
 full/diff backups done by the DBA's will mess up the ones from the TDP?

 Thanks,

 Steve Schaub
 Systems Engineer, Windows
 BlueCross BlueShield of Tennessee


 -
 Please see the following link for the BlueCross BlueShield of
 Tennessee E-mail disclaimer:  http://www.bcbst.com/email_disclaimer.shtm


Re: TDP full-diff backups of SQLServer

2009-07-20 Thread Laughlin, Lisa
Only if you allow them to truncate the log.

My preference is to allow TDP to truncate the log, and then use the /notruncate 
(or something like that) switch in their Maint Plans   I guess you could 
try to sync the timing of the jobs if there is a quiet time when there will 
be no data changes.

thanks!
lisa consider the environment before printing

 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf
 Of Schaub, Steve
 Sent: Monday, July 20, 2009 10:07 AM
 To: ADSM-L@VM.MARIST.EDU
 Subject: [ADSM-L] TDP full-diff backups of SQLServer
 
 W2K3 SQL Server 2000, 2003, 2008
 TDP 5.5.1.0
 We are currently doing daily full backups of all SQLServer databases,
 thinking of going to weekly full, daily diffs.
 One question I haven't been able to figure out is whether native
 full/diff backups done by the DBA's will mess up the ones from the TDP?
 
 Thanks,
 
 Steve Schaub
 Systems Engineer, Windows
 BlueCross BlueShield of Tennessee
 
 
 -
 Please see the following link for the BlueCross BlueShield of Tennessee
 E-mail disclaimer:  http://www.bcbst.com/email_disclaimer.shtm


Re: Del volh

2009-07-20 Thread Shawn Drew
Yes, we use DRM, however we have since moved to using a remote VTL for the
DB Backups.
Ever since then, we've also added del volh todate=-7 t=dbb since we
don't manage those volumes with DRM.

If you are worried about losing track of tapes that become scratch or
Vault Retreive while they are offsite, that won't be a problem.  TSM
doesn't actually remove them from the Copy storage pool until they are
returned and  you run the move drm  tostat=onsiteret

Regards,
Shawn

Shawn Drew




Internet
joni.mo...@highmark.com

Sent by: ADSM-L@VM.MARIST.EDU
07/20/2009 11:24 AM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] Del volh






Hi Shawn,

You are probably right about the syntax.  I didn't see anything indicating
you could place commas between the types.  Do you use DRM in your
environment?

Thanks again!

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Shawn Drew
Sent: Monday, July 20, 2009 11:22 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Del volh

I run the following every day with no issues:

del volh todate=-7 t=stgn
del volh todate=-7 t=stgr
del volh todate=-7 t=stgd

I didn't think you could use multiple types on one line like that.

Regards,
Shawn




Internet
joni.mo...@highmark.com

Sent by: ADSM-L@VM.MARIST.EDU
07/20/2009 10:27 AM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
[ADSM-L] Del volh






Hi Everyone,

I would like to clean up the volume history, but I do not want to cause
issues with tapes that are managed by DRM.  In looking at the command 
what it can accomplish I would probably like to get rid of all old volume
information for new, reused  deleted volumes from years ago.

del volhist todate=01/01/2007 type=stgnew,stgreuse,stgdelete

Would running this del volhist command have any negative impact on volumes
managed by DRM that are still in storage groups and have a long retention
period?

How often do most of you run this command and what do you typically purge
from the volume history?

Thanks in advance!

Joni Moyer
Storage Administrator III
(717)302-9966
joni.mo...@highmark.com



This e-mail and any attachments to it are confidential and are intended
solely for use of the individual or entity to whom they are addressed. If
you have received this e-mail in error, please notify the sender
immediately and then delete it. If you are not the intended recipient, you
must not keep, use, disclose, copy or distribute this e-mail without the
author's prior permission. The views expressed in this e-mail message do
not necessarily represent the views of Highmark Inc., its subsidiaries, or
affiliates.



This message and any attachments (the message) is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or
partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that
certain
functions and services for BNP Paribas may be performed by BNP Paribas
RCC, Inc.


This e-mail and any attachments to it are confidential and are intended
solely for use of the individual or entity to whom they are addressed.  If
you have received this e-mail in error, please notify the sender
immediately and then delete it.  If you are not the intended recipient,
you must not keep, use, disclose, copy or distribute this e-mail without
the author's prior permission.  The views expressed in this e-mail message
do not necessarily represent the views of Highmark Inc., its subsidiaries,
or affiliates.


Re: Move data

2009-07-20 Thread Richard Sims

Thanks for the additional info on that vaulted volume.
With an Access state of Offsite, the Move Data should operate on local
primary pool volumes containing the same data.  Whereas that didn't
happen, it calls into question the state of the online volumes or
whether the TSM database contains entries for any files on that
offsite volume.  I'd start by performing a Query CONtent on that
volume, and then add DAmaged=Yes, to see if something strange going on
there: it's not impossible that the volume % utilization suggests data
on the tape but, due to problems, the database has no info for any
files on the tape.  For completeness, perform queries on the storage
pools themselves, to assure no odd state.  If a repeat of the Move
Data produces the same non-results, attempt on similar volumes to see
if there is a more widespread issue, and see if any further Activity
Log messages are produced to lend clues.  Hopefully, the library is
not now returning bizarre indications to the TSM server for volumes in
certain locations in the library.  You might want to review the TSM
Activity Log at restart time, when it would have tested the inventory
of the library.

   Richard Sims


Re: Del volh

2009-07-20 Thread Moyer, Joni M
Thanks Shawn!

I cleaned up the volume history.  I think I was just a little hesitant because 
of the warning it gives you in the explanation of delete volhist when you use 
DRM, but what you said makes sense!  Thanks again!

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Shawn 
Drew
Sent: Monday, July 20, 2009 11:57 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Del volh

Yes, we use DRM, however we have since moved to using a remote VTL for the
DB Backups.
Ever since then, we've also added del volh todate=-7 t=dbb since we
don't manage those volumes with DRM.

If you are worried about losing track of tapes that become scratch or
Vault Retreive while they are offsite, that won't be a problem.  TSM
doesn't actually remove them from the Copy storage pool until they are
returned and  you run the move drm  tostat=onsiteret

Regards,
Shawn

Shawn Drew




Internet
joni.mo...@highmark.com

Sent by: ADSM-L@VM.MARIST.EDU
07/20/2009 11:24 AM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] Del volh






Hi Shawn,

You are probably right about the syntax.  I didn't see anything indicating
you could place commas between the types.  Do you use DRM in your
environment?

Thanks again!

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Shawn Drew
Sent: Monday, July 20, 2009 11:22 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Del volh

I run the following every day with no issues:

del volh todate=-7 t=stgn
del volh todate=-7 t=stgr
del volh todate=-7 t=stgd

I didn't think you could use multiple types on one line like that.

Regards,
Shawn




Internet
joni.mo...@highmark.com

Sent by: ADSM-L@VM.MARIST.EDU
07/20/2009 10:27 AM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
[ADSM-L] Del volh






Hi Everyone,

I would like to clean up the volume history, but I do not want to cause
issues with tapes that are managed by DRM.  In looking at the command 
what it can accomplish I would probably like to get rid of all old volume
information for new, reused  deleted volumes from years ago.

del volhist todate=01/01/2007 type=stgnew,stgreuse,stgdelete

Would running this del volhist command have any negative impact on volumes
managed by DRM that are still in storage groups and have a long retention
period?

How often do most of you run this command and what do you typically purge
from the volume history?

Thanks in advance!

Joni Moyer
Storage Administrator III
(717)302-9966
joni.mo...@highmark.com



This e-mail and any attachments to it are confidential and are intended
solely for use of the individual or entity to whom they are addressed. If
you have received this e-mail in error, please notify the sender
immediately and then delete it. If you are not the intended recipient, you
must not keep, use, disclose, copy or distribute this e-mail without the
author's prior permission. The views expressed in this e-mail message do
not necessarily represent the views of Highmark Inc., its subsidiaries, or
affiliates.



This message and any attachments (the message) is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or
partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that
certain
functions and services for BNP Paribas may be performed by BNP Paribas
RCC, Inc.


This e-mail and any attachments to it are confidential and are intended
solely for use of the individual or entity to whom they are addressed.  If
you have received this e-mail in error, please notify the sender
immediately and then delete it.  If you are not the intended recipient,
you must not keep, use, disclose, copy or distribute this e-mail without
the author's prior permission.  The views expressed in this e-mail message
do not necessarily represent the views of Highmark Inc., its subsidiaries,
or affiliates.


This e-mail and any attachments to it are confidential and are intended solely 
for use of the individual or entity to whom they are addressed.  If you have 
received this e-mail in error, please notify the sender immediately and then 
delete it.  If you are not the intended recipient, you must not keep, use, 
disclose, copy or distribute this e-mail without the author's prior permission. 
 The views expressed in this e-mail message do not necessarily represent the 
views of Highmark Inc., its subsidiaries, or affiliates.


Re: TSM gui

2009-07-20 Thread Carol Trible
The TSM Administration center is our supplied interface. The 6.1 version
has significant improvements over earlier versions, and will support 5.5
and 5.4 servers.  It is available for download with no charge,  see
http://www.ibm.com/developerworks/wikis/pages/viewpage.action?pageId=10177
 for the location of the download and instructions.  It seems that long
term customers tend to stick to the command line, but new customers who
start with the Administration Center like it, so I would reccomend giving
it a try.

Carol Trible
 IBM Tivoli Storage Manager Development