Hi
I got similar upgrade quite recently. In my case I went to second scenario
from your list (finally it took less than 1 hour to reorg index of
BACKUP_OBJECTS of 200GB 4 year old DB previously running 6.2 ).
To prevent server from crashing you can follow document
http://adsm.se/?p=280 Focus on
We have a number of TSM server instances running under zSeries Linux. These
were created with 6.2.2.0 server codes, subsequently upgraded to 6.2.5.0, and
upgraded to 6.3.5.0 in early April. One of the server instances is now
displaying the message:
PM ANR3497W Reorganization is required on
Adding a new server to our tsm installation.
Will be installing on redhat 6.5, and using strictly for tsm for ve.
Would really like to get to version 7, but having heard of the restore problems
with 7.1.1, wondering what the sense of the list is on most stable version.
Any information welcome.
These three server options were added at 6.3.5 and 7.1.1 (per APAR IC95301).
In the case of DISABLEREORGTable, if no table names are listed, no table
reorgs are disabled. So in Zoltan's example, all table reorgs are enabled.
Note that reason code 2 in the ANR3497W message indicates that the
I can relate. See the same thing every day. When upgrading to 6.3.5.100,
IBM/Tivoli by default disable almost all database reorgs by adding these to
the dsmserv.opt:
DISABLEREORGTable
DISABLEREORGIndex
BF_AGGREGATED_BITFILES,BF_BITFILE_EXTENTS,BACKUP_OBJECTS,ARCHIVE_OBJECTS
Running into some issues troubleshooting VE backups and hopefully I just don't
know where to look.
I came in this morning and was surprised to find that one of my datamovers was
still running a schedule.
There were 2 sessions in TSM, but of course they were using the datacenter name
so I had no
This is close. I check time stamps to identify failures. The time stamp could
also indicate a backup in progress.
select substr(filespace_name,9,18) as VM, filespace_id as FSID, cast(backup_end
as char(19) ) as Backup Completed from filespaces where
node_name='VC1_CH2_DM' order by 3
Jim
The 7.1.1.100 release had a bug where it would favor copy pool
volumes over local volumes for restores. This may not be an issue
unless you have copy pool volumes(virtual volumes) on a remote TSM
server like I do. To fix this issue IBM supplied me with 7.1.1.104
and I've been running it for
I've had 6.3.5.100 up since December 2014 with absolutely no issues. Only
running 7.1.0 (need to update) on one, offsite server that does very little
so it isn't a good benchmark. I hear the 7.1.1.100 patch adds a lot of
stability to feature I don't use (replication, dedup) but I am not ready to
