ADSM-L

Re: [ADSM-L] Tape Drive compatibility

2014-03-12 16:49:19
Subject: Re: [ADSM-L] Tape Drive compatibility
From: George Huebschman <george.huebschman AT PNC DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 12 Mar 2014 16:46:32 -0400
Cheers back to you Neil!

 - They are all JA volumes.  I have to wait for them to fail to ID them.
 -  There are copypools so a second virtual library is a good option.
 -  I was able to determine that all of the scratch made private were
formatted for E06 drives.  I took the E06 drives/paths offline and the
tapes were all umountable.  The volser label could not be read.
     I was able to make them usable by labeling them back in using only
E05 drives.
Since then I found 1,432 "ANR8447E .No drives are currently available in
library" in the actlog.  Normally that would make my mouth dry, but I know
that I DO have paths to drives available.  I expect that the errors are
symptoms of TSM trying to mount E06 media with no E06 drives, so it is a
reassuring symptom.  I can look up the media involved and either do a
restore volume or move data.   I would need to use an E06 drive for the
move data and possibly (pretty likely) for the restore volume operations.

- My favored solution would be to upgrade the drives to all the same type,
but I am not writing the check and neither is our customer.

I like the idea of utilizing the two E06 drives for another reason beyond
just using full capacity.
     We are correcting an issue with replication of SVC volumes over
Global Mirror.  It is billed as asynchronous, but ...it isn't.
When daily changes were a quarter of what they are now it caused
detectable but trivial slowness in Prod applications.  Now it is a serious
problem.
The cure requires restructuring replication...and reshipping ALL of the
production data.  It's going to take ten days more or less.
That is ten days without a recovery point....well, without one that meets
the SLA
Management demands on the one hand that service interruptions and delays
to the customer end, but they are unwilling to accept such a serious gap
in DR capability  So, the problem gets worse.
(To me) Export media seems to be a way to mitigate that recovery gap.
Daily exports are not elegant, they are a poor plug in the gap, but the
alternative is no plug in the gap.  Export media don't need to be in the
destination TSM DB, which makes it unnecessary to restore a Prod db
_backup to the DR TSM server.  The idea is not popular though.

The catch is that Prod is using E06.  However, it has unused E05 drives.
Partitioning the libraries looks ever better.

Thanks Neil and Norman
George Huebschman (George H.)



The contents of this email are the property of PNC. If it was not addressed to 
you, you have no legal right to read it. If you think you received it in error, 
please notify the sender. Do not forward or copy without permission of the 
sender. This message may contain an advertisement of a product or service and 
thus may constitute a commercial electronic mail message under US Law. The 
postal address for PNC is 249 Fifth Avenue, Pittsburgh, PA 15222. If you do not 
wish to receive any additional advertising or promotional messages from PNC at 
this e-mail address, click here to unsubscribe. 
https://pnc.p.delivery.net/m/u/pnc/uni/p.asp
By unsubscribing to this message, you will be unsubscribed from all advertising 
or promotional messages from PNC. Removing your e-mail address from this 
mailing list will not affect your subscription to alerts, e-newsletters or 
account servicing e-mails.

<Prev in Thread] Current Thread [Next in Thread>