Re: space reclamation when using server-to-server communication
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:[EMAIL PROTECTED]] Sent: Tuesday, October 08, 2002 2:35 AM To: [EMAIL PROTECTED] 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 ANRD 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. ANRD 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.: [EMAIL PROTECTED]
Re: space reclamation when using server-to-server communication
Sascha Maybe this helps: APAR= IX78238 ANRD PVRSERV.C(833): SERVWRITE: ERROR WRITING SERVER VOLUME X. RC=30 WHEN COMMTIMEOUT VALUE < TIME REQUIRED TO MOUNT TAPE. APAR= IC22660 ANRD PVRSERV.C(833): SERVWRITE: ERROR WRITING SERVER VOLUME X. RC=30 WHEN COMMTIMEOUT VALUE < TIME REQUIRED TO MOUNT TAPE. LOCAL FIX: Increase the commtimeout value on the source server. Jeroen -Original Message- From: Sascha Braeuning [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 08, 2002 9:35 AM To: [EMAIL PROTECTED] 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 ANRD 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. ANRD 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 Bräuning Sparkassen Informatik, Fellbach OrgEinheit: 6322 Wilhelm-Pfitzer Str. 1 70736 Fellbach Telefon: (0711) 5722-2144 Telefax: (0711) 5722-1634 Mailadr.: [EMAIL PROTECTED]
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 ANRD 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. ANRD 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 Bräuning Sparkassen Informatik, Fellbach OrgEinheit: 6322 Wilhelm-Pfitzer Str. 1 70736 Fellbach Telefon: (0711) 5722-2144 Telefax: (0711) 5722-1634 Mailadr.: [EMAIL PROTECTED]