ADSM-L

Planning for tape requirements for MVS

2015-10-04 18:01:07
Subject: Planning for tape requirements for MVS
From: INTERNET.OWNERAD at SNADGATE
To: Jerry Lawson at ASUPO
Date: 2/19/98 9:17AM
First of all, last year I had some issues with MVS tape allocation, and ran a
short survey here.  One of the questions I asked was "do you dedicate tape
drives to ADSM on an MVS system.   The answer was a resounding "NO" - only one
person (out of 25) did, and he was only doing it on one of his several ADSM
systems.

ADSM will use dynamic allocation to get a tape drive, and as such, when he needs
one, will go to the head of the queue.  This is why most people let MVS get the
drives and manage them for him.  I know at my shop, ADSM will use drives in
bunches - a migration for example - we run 4 parallel tasks - so we would need 4
drives.  I wouldn't want to dedicate 4 drives all of the time to ADSM.

There is a priority among ADSM tasks - I don't remember what it is, but it is
somewhat logical, as I recall - for example, a DB backup will preempt a tape
reclaim, etc.

Within ADSM, on the device level, you can control the number of tape drives ADSM
will take - for example, If you don't want his use of drives to exceed 4 at one
time, you can set this limit, and then processes will wait until the devices
become available.  Sort of lets you be politically correct.

As far as when does he release a tape drive, there are a couple of answers here
too.  First there is a mount retention period that you can set - this allows
ADSM to hold a drive for a period of time after the task is finished with a
tape.  The idea is that a lot of time the same tape will be needed again.  This
is most true in restores, where a customer might do a few files at a time. If,
for example, you set mount retention at 5 minutes, and a user restores a few
files, when the restore is finished, the tape will be held on the drive for 5
minutes before it is released.  If the user wants some more files before the 5
minutes, and they are on the same tape, the process will start again
immediately.  This is obviously of more value on a manual tape system, than it
is on a robot driven system.

The other answer to your question has to do with end of reel processing.  ADSM
does not follow a typical MVS paradigm here.  The intent of the design is to
speed the process, and so at end of reel, rather than wait for a rewind/unload
of the drive before a new mount on the same device, ADSM will ask for a new
mount on a different device (assuming you aren't at the mount limit,) and will
then issue the unload/rewind.   This works fine until MVS runs out of drives,
and then the fun can start - ADSM will ask for a mount, he is under his mount
limit, so he expects that they will be available, but they are not.  MVS will
put him at the top of the queue, but in the mean time, the old drive sits and
waits - no unload is issued.  Depending on your system, this may or may not
occur very often, just be aware.

Hope this helps

Jerry Lawson
jlawson AT thehartford DOT com

______________________________ Forward Header __________________________________
Subject: Planning for tape requirements for MVS
Author:  INTERNET.OWNERAD at SNADGATE
Date:    2/19/98 9:17 AM


I am trying to determine how many tape drive we will need for ADSM on MVS.

How does ADSM manage tape drives on MVS?

Is there a priority amongst ADSM subtask?  Does a request for recover carry
a higher priority over backup?

When does ADSM release a tape drive? (at end of tape or end of task)


Regards,
<Prev in Thread] Current Thread [Next in Thread>