Good morning Richard On the first point I may have confused things. When I brought the new TSM server up I made sure the library was indeed in Auto mode, I just had it in manual when I did the initial db restore (which completed without any errors). However, I did not try to get the new TSM server to do an audit of the lib.
This may sound like a silly question, but I'm assuming that the TSM audit commands can have no effect on the actual library inventory. I just want to make sure I don't create any more problems for myself. On the second point, I did run a few mtlib queries on the old server (after all server activity had finished and TSM had been halted), and on the new server immediately after it was connected to the library. The commands I ran were as follows :- mtlib -l 3494a -vqK -s fffd (to count all cleaning tapes) mtlib -l 3494a -vqK -s 12E (to count all scratch) mtlib -l 3494a -vqK -s 12C (to count all private) mtlib -l 3494a -vqK -s 0000 (to count all volumes) mtlib -l 3494a -qS (to get info about lib) mtlib -l 3494a -qI (to get a list of all volumes) I then compared the output from the old server with that of the new one and confirmed that the output was identical on both. I would not have gone ahead had this not been the case. I am assuming the atldd driver is in good shape, but apart from running the above queries, how can I tell? I am running a later version of the driver form that on the original server. As far as the lib being able to talk to the server OK, it has it's own dedicated little network. I didn't change anything on the library here, I just made sure that the required interface with the exact same IP address was present on the new server. Again, as the mtlib commands work, I'm assuming this is OK. On the third point, there are architectural differences. The original server resides on a Solaris 2.7 server, and the new one is Solaris 2.9. But, last time I tried this, I got as far as being able to back up the db, audit volumes etc, and it only started having problems when trying to migrate to tapes that already had a state of 'filling' (which I was hoping to solve this time round). So it doesn't sound like an OS problem here. Thanks Farren |-----------------------------+-------------------------------------------| | Richard Sims <[EMAIL PROTECTED]> | | | Sent by: "ADSM: Dist Stor | | | Manager" | To| | <ADSM-L@VM.MARIST.EDU> | [EMAIL PROTECTED]| | | U | | 08/04/2006 22:38 | cc| | | | | Please respond to | Subject| | "ADSM: Dist Stor | Re: [ADSM-L] Some | | Manager" | strange tape | | <ADSM-L@VM.MARIST.EDU> | related issues? | | | | | | | | | | | | | | | | | | | |-----------------------------+-------------------------------------------| On Apr 8, 2006, at 1:20 PM, Farren Minns wrote: > Hi Richard > > I see the following which to me looks as I would expect and vol > 000188 was > indeed the volume I used this morning. I did not see any errors during > backup or restore. > > The only thing is that the database volumes on the new server had > mirrored > copies already in place. These were stale when I started the server > but > then syncd ok. Could this have caused a problem? Farren - Unused mirrors should not be an issue, in that the unmirrored copy of the database should be fully viable unto itself. The Vary On which performed synchronization just copies the primary image data. You mentioned in your first posting today that the library was in Pause mode for some reason when the new instance of the TSM server was started. The library needs to be viable when TSM goes to use it at any time; and at start-up time, TSM is trying to do a lot of communication with it, for volumes consistency checking. Putting the 3494 back into Auto mode does not result in an audit, but rather a library-specific Inventory check (depending upon library settings), where the accessor runs around scanning storage cell and drive contents. Manually performing a TSM Audit Library may correct TSM's knowledge of its volumes in the library. I would use mtlib commands to get a list of the library tapes with Category Codes reported, to assure that all volumes seem reasonable and appropriate for use with the Library category code numbers as end up in the new TSM server. Presumably, your atldd driver is in good shape on the new server (?) and the 3494's Library Manager has been updated to allow access by the new server system? (I expect so, but want to assure that basics are not overlooked.) The only other thing I could think of is that there may be some architectural inconsistency which makes a db restoral type of server transfer dubious or invalid, possibly one system being 32-bit and the other 64-bit, for example. I would pore over the Activity Log in the new server looking for other problem indications. Richard Sims ###################################################################### The information contained in this e-mail and any subsequent correspondence is private and confidential and intended solely for the named recipient(s). If you are not a named recipient, you must not copy, distribute, or disseminate the information, open any attachment, or take any action in reliance on it. If you have received the e-mail in error, please notify the sender and delete the e-mail. Any views or opinions expressed in this e-mail are those of the individual sender, unless otherwise stated. Although this e-mail has been scanned for viruses you should rely on your own virus check, as the sender accepts no liability for any damage arising out of any bug or virus infection. ######################################################################