On Wednesday, 11/04/2009 at 02:44 EST, Lee Stewart <lstewart.dsgr...@attglobal.net> wrote: > Problem #1 -- Dump time. Customer took an abend on a 190GB VM LPAR. > VM started dumping. (We assume it was to be a "small" dump -- just CP > areas and the frame table.) Dumping at the rate of "25% every 6 > minutes"... (And we're dumping...) The customer IPLed at 12 minutes > into the dump because they needed to get their production systems back > up. > > Have any of the other large LPAR shops dealt with this? (Other than SET > DUMP OFF ;-) Telling a customer to leave his system down for half an > hour for a dump isn't popular...
Then don't. If time-to-recovery is less than time-to-obtain-diagnostics, then you can't really depend on a single LPAR. I would bring up my other z/VM LPAR (cold, warm, or hot) and let it start everyone while the other system dumps. I would probably add some automation in AUTOLOG1 using XLINK-formatted shared dasd that would atttempt to determine if the "other" LPAR was up and, if so, don't start any guests. In the event of an abend, then you have to manually intervene and use XLINK RESET on the to remove links held by the failed system. > Problem #2 -- Dump size. CP seems to allocate about 17GB for dump > space out of the spool. Then to try and process the dump I'd need > something like a mod-27 as a single large CMS minidisk... (Or a giant > SAN LUN.) Then what? If I'm going to send the dump to IBM, I doubt > FTPing a 20GB file is a choice... Back to good old tape? > > #2a -- does IBM accept huge SPXTAPE DUMPs? We accept whatever you can get to us. z/VM 6.1 has a new DUMPLD2 utility that can break a dump into pieces as it loads to one or more minidisks. Then you can ftp each piece to us individually. Alan Altmark z/VM Development IBM Endicott
