In <0F672B7FF23CD211A41500A0C9CFE0FA27F195 AT ffxexcluster1.co.fairfax.va DOT 
us>,
on 11/20/98
   at 11:19 AM, "Nichols, Linnea" <linnea.nichols AT CO.FAIRFAX.VA DOT US> said:

>I'm pulling my hair out over this one and hope someone can help. I am
>getting tape mounts at night while clients are backing up and can't figure
>out why. I'm running the MVS server at 3.1.2. I'm doing a "query process"
>every hour, and it shows that there are no processes running. At the time
>the tape mounts occur, migration thresholds are set to 95 80, and there are
>no migration messages appearing. Space reclamation on both my onsite tape
>and copy tape pools are much earlier, and are to be completed 4 to 5 hours
>earlier than these tape mounts occur. All of my "maximum size file" limits
>on my storage pools show as "no limit".

>From doing a "q content" and "q vol" on the tapes, it looks like the
>backups from some of my clients are going directly to my tape pool, and NOT
>to my DASD pool, but for the life of me, I can't figure out why!!

>Am I doing something wrong or something stupid? Or should I log this as a
>problem with IBM support?

>Linnea Nichols

>Fairfax Co. Govt, Fairfax, VA    Linnea.Nichols AT co.fairfax.va DOT us
>Phone:703/324-2708                FAX: 703/324-3931

Try doing a 'q ses f=d' periodically in addition to 'q proc'.  This will
show what nodes are using tapes if any.

Are you using caching on the diskpool?  This complicates the search for free
space to hold new backups.  I suspect that the freespace in your diskpool is
very fragmented and when the server is looking for room to hold a file that
the client says is big, it can't find enough space in a limited number of
pieces.  There may be an undocumented limit to how many pieces of freespace
can be put together for use by one aggregate.  Or it may be a bug.

You could try running the pool at 85 70 instead of 95 80 to see if the
problem goes away.  Another trick would be to empty one of the volumes in
the diskpool by doing a move data on it.  then you will have  big chunk of
unfragmented free space.
--
-----------------------------------------------------------
-----------------------------------------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
-----------------------------------------------------------
=========================================================================