UNSUBSCRIBE

[Büttner , Christian]

UNSUBSCIRBE



Christian Büttner
Abteilung Informatik – Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon:  09561 96-44113
Telefax:  09561 96-44104
E-Mail:   christian.buett...@huk-coburg.de
Internet: www.huk.de
===
HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands 
a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav 
Herøy, Dr. Jörg Rheinländer (stv.), Sarah Rössler, Daniel Thomas (stv.).
===
Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte 
Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich 
erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist 
nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in 
error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this 
information is strictly forbidden.
===

-Ursprüngliche Nachricht-
Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von 
rou...@univ.haifa.ac.il
Gesendet: Mittwoch, 31. Januar 2018 11:29
An: ADSM-L@VM.MARIST.EDU
Betreff: [ADSM-L] Question about moving data to another stg pool directory 
container

Hi to all

Previously Storage container , I used the process of move nodedata to move 
nodenames from storage to another storage.

With container storage pool  is not allowed , anybody can point to another 
command to move nodename to another storage pool ( both storage pools are 
Directory container)

Best Regard in Advance

Robert

AW: [ADSM-L] 3494 catagory vs tsm libvol

[Büttner , Christian]

 
Hi Richard,

we have (had) the same problems. Trying to solve this we had calls with IBM TSM 
and 3494-Hardware
Support. The Hardware Support says in the logs thei can see that the TSM as the 
main application is
changing the category. but why? nobody can say that. we talked to an IBM 
internal - he said there 
is a code problem that will cause an loop and then cause this error.

do not audit your library from tsm. tsm will ask the Libmanager and will take 
his category!

with mtlib -l /dev/lmcpX -qI | grep mytapes you can see if ther are private 
012c or scratch 012d.

than manually change the category with

mtlib -l /dev/lmcp0 -C -V yourtape -s 012C -t 012D

or you use a file for a change:

mtlib -l /dev/lmcp0 -C -L /home//scratchtapes -s 012C -t 012D 

AFTER that audit your library from tsm with audit library your3494lib. when 
actlog everything is
successfully without failure then be happy, go drink a coffee and wait for the 
next time the 
failure occours and hope that there is no audit lib - command before you 
realize this problem,
because then you have to reference your volhist-file - and thats not funny!

best greeting 

chris   


-Ursprüngliche Nachricht-
Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im Auftrag von Richard 
Sims
Gesendet: Samstag, 8. Oktober 2005 12:45
An: ADSM-L@VM.MARIST.EDU
Betreff: Re: [ADSM-L] 3494 catagory vs tsm libvol

On Oct 7, 2005, at 3:59 PM, David E Ehresman wrote:

> I have a mismatch between my 3494 tape categories and tsl libvol
> status, i.e. the 3494 tape category is Private while the tsm libvol
> status is scratch.
>
> Will an audit library reconcile this?  If so, which way?  By
> forcing the 3494 categories on the libvol or forcing the libvol
> status on the 3494 categories?
>
> If audit library is not the fix, what is?  Manually updating the
> categories?
>
> David
>

See topic "AUDit LIBRary" in http://people.bu.edu/rbs/ADSM.QuickFacts
or in http://www.tsmwiki.com/tsmwiki
which addresses those issues.

I'd recommend researching your Activity Log to determine how this
happened, as it should not happen, and you want to prevent recurrences.

Richard Sims