ADSM-L

Re: TSM and VTS

2000-11-17 15:28:04
Subject: Re: TSM and VTS
From: "W. Curtis Preston" <curtis AT COLLTECH DOT COM>
Date: Fri, 17 Nov 2000 12:21:52 -0800
Where can I find a basic explanation of VTS as it relates to TSM in a 3494?

At 12:45 PM 11/17/00 -0600, you wrote:
Dominique:
My experience with TSM and a VTS (3494 configed as 3490e models) has been
mixed. VTS is great for multiple mount points.  Performance penalties do
apply.  IMO limited for more than occasional use.  Costs with *SM data
involve VTS thrashing and cache flush.  Our take is VTS is TMM in-a-box;
great for many small files that are to much trouble to convert to DASD.
Large ADSM files (any large file - HSM, DB2 etc) fills the VTS  with data
not likely to be re-read.  VTS cache gets full & flushed - forcing other
data out to 3590 backstore.  Read active then 'costs' a recall delay (yes,
can be 8 or more minutes before logical drive goes ready).
The VTS has another quirk - the logical vs physical implementation.  VTS
emulates physical tape in that each expired file holds space.  A logical
volume must be re-written to reclaim scratched space.

One of our blunders involved logical tape count.  One must balance number of
defined volume serials in VTS to number re-written ever day.  ADSM output is
full-to-the-brim volumes.  When recycled or expired the data remains in the
backstore (on the real 3590 carts).  After the tape is scratched by tape
management (volser available in scratch pool) the physical length of 3590
tape representing the logical volume remains in use until MVS writes new
data to that logical volume.  The VTS can then reclaim the now-freed space.
-- bottom line is don't define more logical volumes than you need right now.
Add (define) volumes to stay above your threshold.

When our VTS logical inventory exceeded daily capacity (MANY inactive
volumes) the physical capacity of the 3590 backstore was exhausted keeping
up with inactive(ie deleted) ADSM BFS and DBB files.
We have since added 4 3590 native drives to the VTS frame, sharing the
robot.  The VTS is used as a spill (migration) for the DASD buffers during
nightly backup.  As soon as practical (only 4 drives to share, HSM needs 2
for mainframe backup and duplex, & one more for migration level 2 recalls)
the local 3590 copy is written VTS-to-local 3590, then local-to-copy pool on
3590.  I'd prefer a larger DASD buffer for the overnight LAN backups and
avoid VTS; however everything is a tradeoff.  Maybe Santa Claus will bring
some channel-attached DASD.

Just-for-grins - since sources tell me VTS is ADSM on a R/6000, isn't the
idea of using ASDM on ADSM a gas?

<soap box> In my opinion - Tape is good for write-never-read; VTS good for
write and might read; use DASD if one expects to use data as input.  ever.
</soap box>

----- Alan Wise
MVS sysprog & general purpose grunt
Alan.Wise AT bcbsla DOT com



-----Original Message-----
From: Dominique Costantini [mailto:dominique.costantini AT UNICIBLE DOT CH]
Sent: Friday, November 17, 2000 7:22 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: TSM and VTS


HI
I'm learning a configuration with TSM on OS390 and VTS.
 I'm looking for informations about TSM on OS390 ( CPU, .. ) and TSM with
or not VTS
Thanks in advance for any reply!
Kindest regards,
_________________________
Dominique Costantini
Unicible

tel: +41 (0)21/644 6151
fax: +41 (0)21/644 6300
mailto:dominique.costantini AT unicible DOT ch

---
W. Curtis Preston, Principal Consultant at Collective Technologies
W. Curtis Preston, Principal Consultant at Collective Technologies
Email: curtis AT colltech DOT com                (Best way to contact me)
Work : 408 452 5555                       (Leave a message.)
Pager: 800 946 4646, pin#1436065        (If urgent.)

Tap into the Collective Intellect (TM): http://www.colltech.com
Backup & Restore resources:        http://www.backupcentral.com
<Prev in Thread] Current Thread [Next in Thread>