Sorry,
I just realized I send my previous append without a subject. Pardon me
sending this again, if you have already read it.

> Howdy People,
> I've been thinking about the time it take s to unload and load a TSM
> DB. Depending on the size of the TSM DB it may require TSM to be
> offline for more than a day.
> I welcome some thoughts about the following steps:-
> 1) loaddb the production TSM DB.
> 2) Bring TSM back up to continue operation.
> 3) loadformat and load the TSM DB onto a "big" test system.
> 4) Backup db on the production TSM DB.
> 5) Shutdown the production TSM DB.
> 6) Copy the "new optimized" db files across to the production TSM
> server.
> 7) DSMSERV RESTORE DB for step 4.
>
> Would the restore be possible in the first place.
> Would the restore db have a fragmentation effect on the optimized db?
> On a general note, I was under the impression that the unload did the
> optimization, but from some load times I've seen, it may be done on
> the load operation. Which is it?
>
> Alternately we could do an cut-down export and import of the nodes.
>
> Share and Enjoy
>
> Wayne Gorton
> TSM Certified Nerd
> Innovative Business Knowledge (IBK) P/L
> PH:    +61 2 9614 1604
> FAX: +61 3 9820 2840
> MOB: +61 417 427 441
> Email: wayneg AT ibk.com DOT au
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (HYPERLINK
> "http://www.grisoft.com"http://www.grisoft.com).
> Version: 6.0.386 / Virus Database: 218 - Release Date: 09-Sep-02
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.394 / Virus Database: 224 - Release Date: 03-Oct-02