Hello, We had some problems after upgrading to TSM 4.2.1.7 and subsequently TSM 4.2.1.9, and although the problems were 3not precisely the same as yours, I might offer some insight.
Our problem turned out to be that TSM 4.2.x.y could not append to tapes which had originally been written by ADSM 3.1.2.90 running on Solaris 7 on a Sun UE450. We also have 3590-E1A drives in our library. These tapes, which were marked with a status of "FILLING", had to be updated to "ACCESS" of "READONLY" so that the server would refuse to attempt to append to them. There were 73 volumes that fit this description. After marking them "READONLY", we had to perform a "MOVE DATA" operation on each of them; we could have moved them to any available sequential access storage pool's scratch volumes but chose to keep them within the same storage pool. You should choose the time to do this wisely, should you decide to try it, as you cannot perform restore/retrieve operations while these processes are running. There is also an option to RECONSTRUCT, which, according to the Administrator's Guide, "Specifies whether to reconstruct file aggregates during data movement. Reconstruction removes empty space that has accumulated during deletion of logical files from an aggregate." I would suggest you choose this option, as it will ensure a more efficient "new tape" usage. A recommended command would be: MOVE DATA READONLYVOLUME STGPOOLNAME RECONSTRUCT= YES WAIT=YES I chose "WAIT=YES" because this forces the process to the foreground, presumably allowing it to run faster. If you have other needs, you can always run it in the background with "WAIT=NO". Note that, as each volume's data is moved to a "new" tape, the original volume is returned to the scratch tape pool and the READONLY attribute becomes irrelevant, as the scratch volume should be marked READWRITE if it is returned to the storage pool. This might not be the answer to your problem, but you could try it, probably without any ill effect. I hope this helps, Dennis Glover
