We have the same issue (more than 2 hours). I've asked IBM about this in the past and didn't get much of an answer besides WAD. I've considered taking the application specific mounts out of BPXPRMxx and mount them after the system is up. Maybe make it part of the application startup in System Automation. Haven't yet pursued it, but with our DR test next month it's back on the radar. The only good thing is that based on the timing of our DR tests this always gives us a good lunch break.
Bart -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Dave Butts Sent: Thursday, October 08, 2015 11:40 To: [email protected] Subject: IOEZ00807I when OMVS initializes at Disaster Recovery site Searched the archives and saw others had this issue, but never saw a good answer. We recently implemented ZFS file sharing for the first time here. We run GDPS/XRC to replicate our dasd from HQ to DR site and then often "flash" the farm to a set we can IPL our recovery system from. Because the of replication, our ZFS files are obviously never closed properly before being used when we IPL the recovery LPAR. The nature of our 24/7 environment and GDPS/XRC means that the flash of the dasd farm will ALWAYS be "fuzzy". The contents of block 0 in each ZFS file will always contain data So we experience the dreaded IOEZ00807I message and a 65 second delay per mount. We have so many ZFS files in use that this takes almost 2 hours to complete a successful IPL of the recovery system. What do other shops do about this? I would hate to have to IPL a minimal system just to mount/unmount the files properly before IPLing the recovery PROD system. Is there a parm anywhere to tell ZFS to ignore integrity checking at IPL? Thanks, Dave ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
