Hi again OK, here's something I have just found, and this is on the current working live server (that has worked this way for years).
When I look at the lib definition within TSM, I see the following :- Library Name 3494A Library Type 349X ACS Id - Private Category 300 Scratch Category 301 But, when I do a 'mtlib -l 3494a -qI' from the command line I see the following (just an example):- 000212 FFFA 01 10 00 (this is a copypool vol) 000222 012E 00 10 00 (this is scratch) 000223 012C 00 10 00 (this is private) Now, when I punch 300 in to my scientific calculator I get a Hex value of 12C, and that fits in with the info above. But, when I enter 301 I get 12D which does not fit in with the above 3494 assignments. So how on earth is this working at all? Also, the category FFFA seems to cover copypool volumes that have yet to be moved from the library and also cleaning tapes. Is this meant to work in this way? 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. ######################################################################
