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 <rbs AT BU DOT EDU> |
|
| Sent by: "ADSM: Dist Stor | |
| Manager" | To|
| <ADSM-L AT VM.MARIST DOT EDU> | ADSM-L AT
VM.MARIST DOT ED|
| | U |
| 08/04/2006 22:38 | cc|
| | |
| Please respond to | Subject|
| "ADSM: Dist Stor | Re: [ADSM-L] Some |
| Manager" | strange tape |
| <ADSM-L AT VM.MARIST DOT 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.
######################################################################
|
