Jeff,
From what I have been able to absorb from my ADSM experiences is that
the sessions will go into MediaW when there is not enough space on the
storage pool (that the management class is associated with) to hold the
dataset currently being backed up.   The dataset will then be backed up
to the next storage pool in the hierarchy - usually tape.   If you have
a limited number of tape drives, you will get numerous sessions going
into MediaW if your disk storage pool is full.

Once the dataset for each session that was forced to go to the next pool
in the hierarchy is backed up, then the succeeding datasets for that
session should go to the disk storage pool providing that there is
sufficient space.   However, if you've got a lot of sessions in MediaW
and few tape drives available, this may take awhile.    A suggestion may
be that once your disk storage pool is down to 85% or so, to cancel the
migration task so that the session(s) needing the tape drive can get it.


Hope this helps...
John Rushton
Lockheed Martin

> ----------
> From:         Jeff Connor[SMTP:connorj AT NIMO DOT COM]
> Reply To:     ADSM: Dist Stor Manager
> Sent:         Wednesday, March 18, 1998 10:04
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Client Session Stuck in MEDIAW Status During Migration
>
> I have a problem that comes up from time to time that I was wondering
> if
> anyone else has experienced the same thing during disk to tape storage
> pool
> migrations.  My ADSM environment is as follows:
>
> ADSM MVS Server V2.1.10 running on OS/390 V1R2.
> TCPIP for MVS V3.2
> Client is HP-UX V10 running V2.1.6 of the ADSM Client
> 80GB disk storage pool migrated to Magstar 3590's in an STK Silo daily
> by
> setting hi and lo thresholds to zero.
> Disk pool migration thresholds are set at hi=95 lo=75 during the
> night.
>
> The scenario is our disk pool fills up during the nightly backups and
> migration begins.  Last night we got as high as 99.2% utilized while
> migrations were running.  The problem, aside from having a disk pool
> that
> is currently undersized, is that some client backup sessions show a
> status
> of mediaw indefinitely.  I can understand that occurring initially
> when the
> disk pool is 99+% full.  I mean hey there's no place for the data to
> go
> right?   The problem is that even when the pool utilization drops to
> say
> under 60% the sessions that showed mediaw still are stuck/not running
> still
> showing a status of mediaw even though there appears to be plenty of
> space
> available in the disk pool.  Does anyone know why these sessions are
> hanging in a mediaw state and don't just start running as space
> becomes
> available as data migrates from disk to tape?  I thought of setting
> the
> high migration value to a lower number like 80 for example thinking
> that if
> migration started before we reached such a high utilization factor  it
> might avoid the apparent "gridlock".  Even if that fixes the problem
> it
> still doesn't explain why the sessions hang in mediaw state
> indefinitely
> and have to be eventually canceled even though space does become
> available
> as data is migrated.  Any ideas?
>
> Jeff Connor
> Niagara Mohawk Power
> Syracuse, NY
>