Unzone the library and drives on the test machine, so the OS doesn't see
them (then the TSM Server won't, either).  Add the "disable sessions" line
to the DSMSERV.OPT file.  Now you're isolated.  Fire up TSM, and do a DB
Backup to a file (you're doing to want to do this more than once, right?),
then you can test your expiration.   To repeat, restore the DBBackup you
did to disk.  Each expiration will expire the same data

Note:  Your results won't match the real world.  There's no other load on
this server, while a real TSM production server will have other things
going on, even when it's fairly idle.  So don't be surprised if things take
10% longer when you have this server as the real one.

Nick Cassimatis


----- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 08/15/2008 10:58 AM
-----

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 08/15/2008
10:39:24 AM:

> [image removed]
>
> Re: Expiration on a Test server.
>
> Zoltan Forray/AC/VCU
>
> to:
>
> ADSM-L
>
> 08/15/2008 10:40 AM
>
> Sent by:
>
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> Please respond to "ADSM: Dist Stor Manager".
>
> This is one of the reasons I haven't brought it up after the reload, yet.
>
> The test server isn't going to use/do anything but test things like
EXPIRE
> INVENTORY.  We will be eraseing/reloading it numerous times.
>
> So, how do I avoid these possible complication?  Disconnect the ethernet
> cable and work from the console?  Remove/change the test servers
> definition from the production server?
>
>
>