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