McKown, John wrote:
-----Original Message-----
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Liberatore
Sent: Sunday, September 04, 2005 9:34 AM
To: [email protected]
Subject: CA-Vtape
Would anyone have any experiences that they would like to share (
dos/donts....)? Thanks in advance!
We have it running. But only for a few things. We are ditching it ASAP.
The reason is CPU consumption. We use it as an extremely fast tape
drive. We daily dump about 140 3390-3 volumes which are about 60% full
to CA-VTAPE. We run 8 jobs (volumes) at a time. On our z890, capacity
250, this eats up a bit over 15% of our CPU in the SVTSAS address
spaces. We find this unacceptable. It also confuses our operators
something fierce when a problem occurs (like, how to you reload a tape
on a virtual drive? That z/OS message can occur, but is meaningless and
confusing). But this confusion may well be a local phenomenon.
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology
The area in which VTape excels is in reducing physical tape mount time
and number of physical volumes - provided virtual tape used in place of
real tape for the thousands of typical cases where applications only use
a fraction of a 3490 tape volume. VTape also allows for the efficient
migration to 3590's in such environments without having to completely
redesign all application usage of tape datasets.
For handling very large tape datasets spanning multiple
hardware-compressed cartridges, or for applications like DFHSM, which
does its own tape packing and tape "direct" access, VTape virtual
volumes are probably not the best choice. Data passed to VTape virtual
tape must be handled twice, pass through the logical I/O subsystem 4
times, and through the physical I/O channels 3 times, even if the
virtual volume is never re-read: (1)write to virtual tape drive,
(2)write to physical DASD, (3)read from physical DASD, (4)write to
physical tape. This requires some "horses" if used for massive
datasets, especially if you add software compression to hold down the
use of DASD cache and virtual volumes. We still put our largest tape
datasets on either native 3490E or native 3590E, and in particular put
our daily DASD volume dumps to JCL-stacked 3590 tapes. Writing large
datasets directly to our 3590 drives on FICON also takes less elapsed
time than writing to virtual 3490 backed on ESCON DASD.
We went to VTape because we had no physical space to expand our onsite
or offsite 3490 cartridge storage, a VTS hardware solution was at least
an order of magnitude more expensive, and there was no practical or
quick way to change the way application areas were using tape data sets.
Today, after considerable growth, we have around 45,000 virtual 3490
volumes that are backed by around 400 physical 3590 cartridges, with
about an equal number of offsite 3590 duplex copies. The remaining
physical 3490 library is well under 10K active volumes and shrinking.
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
