Steve O'Connell wrote: [snip]
I still don't understand the suggestion to turn off Type19 as an acceptable solution to be honest - it doesn't help if folks actually want to collect them does it? Fortunately we don't.
The impression I got from Level 2 was that most installations don't collect Type 19 records (I think I know why) and that nobody at IBM really wants to waste any time looking into this issue. Basically, if you collect Type 19 records, you're subject to SYSVTOC delays -- even an IPL time. If you don't collect them, you're not. (It's sorta' like that joke where the patient complains to the doctor, ""It hurts when I do this" so the doctor tells him "Don't do that!")
In a related issue, early SYSVTOC release during volume dump processing seems to be popular among some contributors to this list. I *assume* that's a minority position since the default behavior is to hold SYSVTOC for the duration of the dump. Personally, I don't like the idea of early VTOC ENQ release. You could very easily end up with a VTOC that doesn't properly reflect what's on the volume! Data sets and/or additional extents can be added or removed between the time the VTOC is dumped and the remainder of the volume is dumped. If you have to restore the volume in an emergency situation, those changes will be lost. What good is that??!
OTOH, the DFSMShsm book seems to suggest that you could be subject to deadlocks if you *don't* change the default! (See http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2i450/2.5.34.) It's difficult for me to imagine the scenario where the DFSMShsm address space performing the dump needs to allocate a data set on the very DASD being dumped while switching to a new output tape. It must be possible or it wouldn't be so prominently documented, but I've been dumping this way for at least 15 years and never experienced any such deadlock.
I guess it is something that worked in the old days of single unconnected MVS images and never got updated.
Mumble .. grumble .. mutter ... I'm starting to sound like Shane ... grumble ... mutter ... ;-)
-- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ ---------------------------------------------------------------------- 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
