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