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
>[EMAIL PROTECTED]
>
>
>
>-----Original Message-----
>From: Dominique Costantini [mailto:[EMAIL PROTECTED]]
>Sent: Friday, November 17, 2000 7:22 AM
>To: [EMAIL PROTECTED]
>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:[EMAIL PROTECTED]
---
W. Curtis Preston, Principal Consultant at Collective Technologies
Email: [EMAIL PROTECTED] (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
