ADSM-L

Tape mount problems and MVS PTF 12

1997-04-16 15:59:31
Subject: Tape mount problems and MVS PTF 12
From: Jerry Lawson <jlawson AT THEHARTFORD DOT COM>
Date: Wed, 16 Apr 1997 15:59:31 -0400
Date:     April 16, 1997      Time:    1:37 PM
From:     Jerry Lawson
          The Hartford Insurance Group
          (860) 547-2960           jlawson AT thehartford DOT com
We have had an interesting few evenings with our server.  While I think it is
mostly how we have (or perhaps haven't) handled our storage pools, I should
note that the problems started when we applied the Level 12 server PTF (and
APAR).  Here is what has happened:

Our primary storage pool for servers is a 12GB pool of 8 3380K volumes on an
Iceberg (RAMAC) device.  We have the Min and Max for the pool set at 10% and
95% respectively, so we should be able to handle approximately 11GB of data a
night before a migration is forced.  When checking, I have found that the
pool is usually at about 9% each day before the nightly backups occur.  The
problem seems to be that we write more than 11GB to the pool in the course of
the night, which of course will cause us to start a migration in the middle
of the night.  I know this is not the ideal situation, but we have had this
problem before without a real issue - perhaps some degradation, but nothing
extreme.

Since we applied the maintenance, it would appear that ADSM has trouble
getting tape drives from MVS - or at least handling the mount requests in a
timely manner.  What we see is the 95% thresholds being reached, the
migration processes starting, and then shortly thereafter, backup sessions
asking for tape mounts too.  This would indicate to me that the pool is now
100% full, or that the client wants to write a file to the pool that exceeds
the amount of free space remaining (is the free space reserved by a client
during it's processing?)  This has caused several of these jobs to run very
long - backups that are normally done in 20 minutes have been taking 5 hours,
thus impacting server availability in some situations.   This morning it was
at it's worst - we had 20 queued sessions - most of them waiting for tapes.
What was the worst part of this was that in the meantime, the migrations were
completed - and the pool was at 10% .

The immediate answer is to send IBM some money and mount a couple of more
volumes of DASD!  (we are adding 2 more volumes - 3GB - for tonight's
processing.  But I am also wondering why the problem hasn't raised it's ugly
head prior to the past week - as I said - we have been running this pool
tight for a long time.  Also, one would expect that we should be able to
write to tape faster than we can read from the network.  However, it looks
like the 3 concurrent migration processes aren't keeping up.

Also, why wouldn't ADSM send the clients back to the DASD pool once the
occupancy has decreased safely.  We have the mount limit set at 5, and we run
3 migration processes against the pool.  With 15+ sessions waiting on a tape
drive this morning - the wait was long - especially  when the pool was empty!

Has anyone else seem problems with drive allocations after applying the MVS
level 12 maintenance?


                                         Jerry

Insanity is doing the same thing over and over..and expecting the results to
be different - Anon.
<Prev in Thread] Current Thread [Next in Thread>