Ari,
I've opened a PMR on this (#73550). IBM support told me, too, that they had
no similar problems in their database. They also mentioned the possibility
that this might be a procedural error, and not a product bug. They said
they'd get back to me when they've found something, but after 3 weeks, I
haven't heard from them.
Peter
-----Original Message-----
From: Ari Plaut [SMTP:ari AT TKG DOT COM] <mailto:[SMTP:ari AT TKG
DOT COM]>
Sent: Tuesday, January 26, 1999 3:25 PM
Subject: Re: Reclamation Process Hangs
We've encountered the same problem on an AIX ADSM SERVER 3.1.1.3. I
opened
PMRs with no resolution (or even suggestions) other than recycling
ADSM.
The frustrating part was that I asked if this is a known defect,
and level
1 support said that there were no other similar problems listed in
their
database.
-----Original Message-----
From: Virginia Hysock [SMTP:vhysock AT CSC DOT COM]
<mailto:[SMTP:vhysock AT CSC DOT COM]>
Sent: Friday, January 22, 1999 1:22 PM
To: ADSM-L AT VM.MARIST DOT EDU <mailto:ADSM-L AT VM.MARIST DOT EDU>
Subject: Reclamation Process Hangs
Peter,
Yes, I had the same problem. I opened a ticket with IBM
(#70122) back
in September 1998 on this. The only solution to eliminating the
hung
reclamation process is to recycle ADSM. We got no satisfaction from
IBM on
this. We finally resorted to updating the access of the storage
pool to
offsite 15 minutes before starting reclamation on the pool to
eliminate the
problem. It has done that - but I agree with you, we should not
have to
resort to this. I have left my ticket open awaiting some response
from
IBM.
Ginny
P.S. I'm OS390 too; was at 3.1.1.3 in September, now at 3.1.2.1.
Hello, ADSMers!
Here's the scenario:
Offsite tape reclamation happens to be still running when the
scheduled
command executes to change the access status of any OFFSITE tapes
that are
Onsite
(i.e., upd v * acc=of wherestg=copy_off1 whereacc=readw,reado
wherest=fil,ful).
The new OFFSITE tape that is currently being written to then
dismounts, on
account of its newly changed status, and the courier takes it away
to its
offsite location.
The Offsite Reclamation process is hung at this point, the input
tape stays
mounted, and this state of affairs will remain until the Server is
stopped/restarted.
Why doesn't the Reclamation process simply ask for another scratch
tape
when
the current output tape dismounts?
Would this be a procedure problem-or a bug?
We never had this problem under V2.
We are now running under MVS-OS/390 V3, Release 2.0.
Any comments or suggestions would be most appreciated.
Thanks, in advance.
Peter Glass
Norwest Services, Inc./Wells Fargo Company
|