Funny you should bring this up about the interaction of tlms (and probably
ca1)  and adsm with the arctvext. . I just spent several e-mail and phone
conversations last week with both CA and IBM trying to get them to jointly
determine an approach to this issue.
  As far as I can tell it matters not what release of either ADSM or TLMS you
have (we have tlms 5.5 and adsm MVS 3.1.1.3). The issue is that when ADSM is
doing a process that may result in a deletion (move data, tape reclamation)
tapes that are full are opened for input, tapes that are still filling are
opened for output. By itself this would be o.k, but the request to close the
tape and the call to arctvext are issued asynchronously, so there's no
guarantee which will finish first. If the the close is done first, everything's
fine. If the the exit finishes first, the tape is released, marked scratch by
TLMS, and then the close comes and TLMS says "oops, someone needs this tape,
I'd better mark make it a scratch no." (If you look at the create date/time for
that tape in TLMS you'll see it's a few 100's of a second after the delete time
that ADSM shows for the tape).
  We first ran into this problem a year ago with tlms 5.4, but it applied at
the time to tapes opened for input as well. I went away for a month long
vacation and came back to my teammates telling me adsm was swallowing tapes - I
ended up comparing what adsm thought it had with what TLMS thought adsm had and
ended up releasing over 1,000 tapes manually from TLMS.  CA provided a fix (I
think created in nov 97) that took care of the situation when a close for input
arrives after the arctvext completes, but in doing additional compares this
summer I discovered that the issue is still there, just less visible. I figure
we orphan about 150 tapes a year this way.  In our discussions last week, IBM
tells me they have never heard of anyone else having this problem -  if anyone
else has the time to make the comparison I would like to pass the outcome to
both CA and IBM.
  - Marian Dalton


Virginia Hysock wrote:

>      Has anyone running version 3.1.2.20 of the OS/390 server had a problem
> with the scratch exit ARCTVEXT?  I am getting ready to upgrade to the 20
> level and find in testing that when deleting a volume through a MOVE DATA
> command the SCRATCH indicator in TLMS 5.4 is not updated to YES (even
> though the SCRDT field is updated with the appropriate date).  I placed a
> call to CA, and they indicated this is a problem specific to ADSM's use of
> the exit, in that a MOVE DATA calls a CLOSE FOR OUTPUT rather than INPUT,
> causing TLMS to disallow scratching.  I can't believe I'm the only one with
> this problem??
>
>                          Ginny