Where do your virtual volumes go ??? (straight to tape or first to a buffer
diskpool ???)
If they go straight to tape there is the possibility that your second
virtual volume to be reclaimed ends up being on the physical volume to which
your first reclamation process opened its output volume.  (thus the output
voume gets closed on the remote server because the tape is rewound to find
the second input/reclamation volume)

What is the mount retention of your device class for your virtual volumes
???

Generally virtual volumes are only used for a unit of work (or until their
estimated capacity is reached), since your reclamation processes are
actually TWO different processes I would expect TSM to close that output
virtual volume at the end of the first process and thus terminate its use.
I would not expect the second process to pick that back up and try to use
it... and this might be what is going on in that the virtual volume is
closed upon completion of the first reclamation and then the second process
tries to use it but it is closed...

Try this, if your mount retention for your device class for your virtual
volumes isn't zero, try setting it to zero.  This way upon completion of the
first reclamation every one / all routines involved will agree to close out
that virtual volume,  then when your second reclamation initiates it will
call for a new scratch.
NOW for the flip side of my twisted thinking... if your mount retention IS
currently zero, try setting it up to 1 or 2, IF currently zero it ~might~ be
triggering an early close of the volume even though the one environment
knows it has additional work to go to it.

BUT generally I'd expect the normal flow of things to be: upon completion of
the first reclamation task, the output virtual volume to be closed (since
that is a completed unit of work) and upon the initiation of the second
reclamation task, a new output virtual volume to be opened...


Dwight


-----Original Message-----
From: Sascha Braeuning
[mailto:Sascha.Braeuning AT SPARKASSEN-INFORMATIK DOT DE]
Sent: Tuesday, October 08, 2002 2:35 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: space reclamation when using server-to-server communication


Hello TSMers,

I've got a problem with my space reclamation for virtual volumes. We use
two TSM Servers Version 4.2.2.0 (OS Sun Solaris 2.7). They do
server-to-server communication. When space reclamation starts for the first
reclaimable virtual volume in a storage pool, everything looks fine. Then
the second reclaimable virtual volume starts their reclamation process and
I allways get an ANR9999D error.

Here is what TSM reports:

ANR8340I  SERVER volume TBS.BFS.032957914 mounted.
ANR8340I  SERVER volume TBS.BFS.033992020 mounted.
ANR1340I  Scratch volume TBS.BFS.033992020 is now defined in storage pool
REMOTE_UNIX.
ANR0986I  Process 360 for SPACE RECLAMATION running in the background
processed 34 items for a total of 1.997.933
          bytes with a completion state of SUCCESS at 14:05:16.
ANR1041I  Space reclamation ended for volume TBS.BFS.032957914.
ANR0984I  Process 361 for SPACE RECLAMATION started in the background at
14:05:16.
ANR1040I  Space reclamation started for volume TBS.BFS.033704013 storage
pool REMOTE_UNIX (process number 361).
ANR1044I  Removable volume TBS.BFS.033704013 is required for space
reclamation.
ANR8340I  SERVER volume TBS.BFS.033704013 mounted.
ANR1341I  Scratch volume TBS.BFS.032957914 has been deleted from storage
pool REMOTE_UNIX.
ANR8213E  Session 93 aborted due to send error; error 32.
ANR9999D  pvrserv.c(918): ThreadId <43> ServWrite: Error writing SERVER
volume TBS.BFS.033992020 rc=30.
          ....
ANR1411W  Access mode for volume TBS.BFS.033992020 now set to read-only due
to write error.


When I move data from TBS.BFS.033992020, no problems occured. Can anybody
explain, what happened at the server?


MfG/regards
Sascha Brduning


Sparkassen Informatik, Fellbach

OrgEinheit: 6322
Wilhelm-Pfitzer Str. 1
70736 Fellbach

Telefon:   (0711) 5722-2144
Telefax:   (0711) 5722-1634

Mailadr.:  sascha.braeuning AT sparkassen-informatik DOT de