The operating system does not know anything about the MVC's. MVC's are mounted on drives direct attached to the VTS, bypassing MVS IO entirely. The only places in "MVS land" that know anything about the MVC's are the TMC (where they are usually marked in delete status) and the HSC CDS's. Virtual tapes (VTV's) are tracked exactly like any physical media and are known to MVS/TMS.
Data is never written directly to the MVC. It is only written to the VTV. If the virtual tape volume has already been migrated to the MVC and purged from the VTS cache, the only recourse is to recall the data from the MVC back to the VTS cache and then perform the append (this is possibly, but not necessarily faster than the physical equivalent). Another poster indicated the SETSYS PARTIALTAPE operand of DFHSM. We use this to minimize append processing. HSM media can be duplicated by HSM, or as in your case, by the VTS. There are pros and cons to either approach. STK has a white paper on DFHSM and VTS that I am sure you can obtain from the CRC. All of that being said, the VTS is not necessarily the best performer with append type data. YMMV. <snip> First of all, real tape's update mode is primarily append. But using disk, once the virtual volume is written to a multi-volume cartridge, assuming it's not the last volume on the multi-volume cartridge, no physical straight-forward append seems possible. I don't think it chains virtual volume "extents" in different locations on the mulit-volume cartridge or across them to simulate a virtual append ??? I assume for a non-scratch ring-in virtual mount of a pre-existing volser it loads the original virtual volume data from the multi volume cartridge to its disk cache and then after the job finishes appending data it just marks the original data area free in its CDS directory and rewrites the original data with appended data in a new location on a multi-volume cartridge. So virtual tape probably handles applications which append data to old tapes rather poorly, fragmenting the data on the cartridges until background reclaim processing reorganizes them. Doesn't HSM L2 do a lot of append processing, adding to the end of tapes? This site doesn't currently replicate HSM L2 tape volumes nor sysout archive migrate or backup tape volumes to the disaster recovery site. I am considering changing that. Today I will quantify the increase in data traffic. But quantifying the increase in fragmentation and need for reclaim/reorg is more difficult. Should I even worry about it? With virtual tape meeting the same objective of using more of the entire physical tape, can HSM be run in a mode which does not append to its old tapes? That would use many more tpae volumes, but heck they're "virtual." How can I quantify the greatly increased number of volsers that would require in my CA-1 tape library? Is this even possible? </snip> ---------------------------------------------------------------------- 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
