I have been running the MVS v2 server for about 2 months now.  I am still
tweaking the operating proceedures.  An interesting thing happened today.

The background is that I don't use scratch tapes. I run the full database backup
feature to sets of specific volumes, and reuse the sets every 5 weeks.
Incremental db backups are run to sms disk, and migrated with hsm.  In order
to reuse the tape sets, they must be deleted from the volume history.  In
the course of doing this delete, incremental backups will also be deleted,
based on a specified date.

The volume history delete was kicked off by an administrator schedule, another
v2 feature.  Almost immediately all ADSM processing stopped.  The cpu 
utilization
according to SDSF was 0%.  Queries from my admin client  didn't respond.
People called to say they couldn't connect.  The problem is that the way a 
delete
of the migrated incremental backup files is done, they are recalled first!
And mvs makes tasks wait during an hsm recall, so ADSM waited (it is a single
TCB).
(Actually I already new this, having tested the import of a filespace exported
to disk.  On a test server, the server waited.  But it just didn't register
with me.)

The recall is done because the server is written in 'C', and the C runtime
makes no attempt to be smart about deleting migrated datasets.
(I called this into IBM service.)

To get the server going again, I quickly deleted the rest of the files that
were to be deleted by the 'delete volh' process -- total outage was just 8
minutes.

So, when you go to V2, mvs, and use the sequential disk file feature,
don't let ADSM do any recalls!  I will fix up HSM and SMS so that the
incremental backups get deleted before the 'delete volh' command runs.

Bill Colwell
C. S. Draper Lab
Email: BColwell AT draper DOT com
Voice: 617-258-1550