Re: PPRC and page datasets
Darth, I think I see now that the hardware you are using does not support FlashCopy Consistency and delta resynch. When you're ready to update to hardware that support more recent versions of FlashCopy, Timefinder or Shadowimage you may want to look at the Shadowimage's At-Time Split capability. Till then, it sounds like you have come up with a delta-resynch method that works out fine for you. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Darth Keller Sent: Wednesday, May 28, 2008 8:08 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] PPRC and page datasets Ron - We're not really doing a remote copy. Logically, we mirror 1 half of the box to the other half of the same box. We are asynchronous for most of the day and only swap to synchronous mode a few minutes before we're ready to do our backups, break the pairs once they are synchronous, and then start the backups on the offline mirrors. Once the backup is complete, we re-establish pairs asynchronously and wait for the next cycle. In the past, we would take full volume backups for DR. These backups would run over a period of several hours while batch was up and running leaving us with loads of inconsistencies. Then we restore these backups at DR, do what clean-up we could, and then applications would start their recoveries. With our current method, we achieve very nearly synchronous backup. I won't quibble about 'near zero', but I can say that to date when we restore at DR, we've not seen any file problems. We still have instances where applications was running and our flashcopy was taken in the middle of their batch cycle, but it's much cleaner than anything we've had before and doesn't involve the extra costs of a remote site. ddk -- 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
Re: PPRC and page datasets
Ron - We're not really doing a remote copy. Logically, we mirror 1 half of the box to the other half of the same box. We are asynchronous for most of the day and only swap to synchronous mode a few minutes before we're ready to do our backups, break the pairs once they are synchronous, and then start the backups on the offline mirrors. Once the backup is complete, we re-establish pairs asynchronously and wait for the next cycle. In the past, we would take full volume backups for DR. These backups would run over a period of several hours while batch was up and running leaving us with loads of inconsistencies. Then we restore these backups at DR, do what clean-up we could, and then applications would start their recoveries. With our current method, we achieve very nearly synchronous backup. I won't quibble about 'near zero', but I can say that to date when we restore at DR, we've not seen any file problems. We still have instances where applications was running and our flashcopy was taken in the middle of their batch cycle, but it's much cleaner than anything we've had before and doesn't involve the extra costs of a remote site. ddk Then why use asynchronous remote copy software and skip just about all of the performance hit? The ONLY reason for using Synchronous remote copy is when you need zero data loss on the remote side, which is not your requirement. Note that zero data loss with synchronous remote copy does not occur by default. Most synchronous remote copy sites only provide near zero data loss, which always makes me wonder what the point of synchronous is in the first place. Ron ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ** -- 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
Re: PPRC and page datasets
The point of this whole set-up is to be able to get as close as we can with the hardware we have available to a point in time backup for DR. The 2ndary mirrored devices are then backed up offline to tapes and the tapes shipped to off-site storage. The .08ms .03ms were basically for documentation - the expensive part for us would be to establish then 2nd site for remote mirroring. dd keller Thanks for the details on your normal daily backup cycle. I just have one question. The difference between .08 ms. and .03 ms. is .05 ms., or 50 microseconds. Do you really need to reduce write elapsed time by that small an amount at the cost of having your secondary mirror devices in the same room as your primary devices? You must be seriously write-intensive with very low I/O service times for 50 microseconds to be a large increment in service time. Bill Fairchild Rocket Software ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ** -- 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
Re: PPRC and page datasets
Darth, Then why use asynchronous remote copy software and skip just about all of the performance hit? The ONLY reason for using Synchronous remote copy is when you need zero data loss on the remote side, which is not your requirement. Note that zero data loss with synchronous remote copy does not occur by default. Most synchronous remote copy sites only provide near zero data loss, which always makes me wonder what the point of synchronous is in the first place. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Darth Keller Sent: Tuesday, May 27, 2008 8:02 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] PPRC and page datasets The point of this whole set-up is to be able to get as close as we can with the hardware we have available to a point in time backup for DR. -- 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
Re: PPRC and page datasets
In a message dated 5/8/2008 2:17:54 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: We established a PPRC Metro Mirror - Loop Back environment, which means that we PPRC from the front end of the box to the back half of the box. We were told that in a metro mirror with 30 kilometer separation in full Synchronous mode, the delay could be up to .08 ms on writes. Since our loop back metro mirror is approximately 3ft, our delay is less than .03 ms. on writes. Thanks for the details on your normal daily backup cycle. I just have one question. The difference between .08 ms. and .03 ms. is .05 ms., or 50 microseconds. Do you really need to reduce write elapsed time by that small an amount at the cost of having your secondary mirror devices in the same room as your primary devices? You must be seriously write-intensive with very low I/O service times for 50 microseconds to be a large increment in service time. Bill Fairchild Rocket Software **Get trade secrets for amazing burgers. Watch Cooking with Tyler Florence on AOL Food. (http://food.aol.com/tyler-florence?video=4?NCID=aolfod000302) -- 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
Re: PPRC and page datasets
So the general consensus seems to be that mirroring page packs is a bad idea resulting in a performance hit. Does anyone have any #'s on how much of a hit this is? ddk ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ** -- 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
Re: PPRC and page datasets
What would you do with a mirrored page pack if your system crashed? I don't think you could use it for anything. I know there are others out there who have a more definitive answer, but I can't see much use for it. Eric Darth Keller [EMAIL PROTECTED] wrote: So the general consensus seems to be that mirroring page packs is a bad idea resulting in a performance hit. Does anyone have any #'s on how much of a hit this is? ddk -- Eric Bielefeld Systems Programmer Aviva USA Des Moines, Iowa 515-645-5153 -- 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
Re: PPRC and page datasets
Darth Keller [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] .com... So the general consensus seems to be that mirroring page packs is a bad idea resulting in a performance hit. Does anyone have any #'s on how much of a hit this is? ddk Remember that the penalty is on writes, i.e. pageouts. For massive pageouts you should already have robust paging configuration to handle the burst, if mirrored it might have to be a little more robust. Normal performance is more depedent on page-in response times and they are not influenced by mirroring. One reason to mirror pagevolumes is to keep the configuration simple: mirror everything, so you are sure you will never forget a volume. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- 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
Re: PPRC and page datasets
So the general consensus seems to be that mirroring page packs is a bad idea resulting in a performance hit. Does anyone have any #'s on how much of a hit this is? If it's synchronous double the I/O response. If it's also to another site --GDPS-- add in the speed of light differential. Also, at a second site, none of the data will be used. It will be the virtual/real storage map of the second site. - Too busy driving to stop for gas! -- 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
Re: PPRC and page datasets
On Thu, 8 May 2008 08:44:27 -0500, Darth Keller [EMAIL PROTECTED] wrote: So the general consensus seems to be that mirroring page packs is a bad idea resulting in a performance hit. Does anyone have any #'s on how much of a hit this is? ddk That would of course depend on how busy those volumes are. With EMC SRDF we use adaptive copy for the page packs. What that means is the volumes were copied once to the remote side and then they are never touched again. We have to do the same thing (one time) when new page volumes are added. Our last DR drill proved that sometimes the DASD team forgets to do that. :-) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: PPRC and page datasets
On Thu, 8 May 2008 09:59:37 -0500, Darth Keller [EMAIL PROTECTED] wrote: Hi Eric - Our SOP is that we mirror everything locally for DR. Once a day, we break the link and back all the offline volumes up to tape. Doing every volume just makes the restore process at DR much simpler - once the restore process is done, we ipl - no additonal steps like page packs to set up, spool volumes to initialize, whatever. We're backing up over 4,000 addresses - a lot of which are mod-27's. So even if we had 100 page packs (mod-3's), it's not a real significant portion of the backup or restore and isn't seen to be a big enough impact to change the procedure. If the performance hit is small, there's no justification to changing the process. But if it's significant... One word: Bandwidth. The one time copy we do with SRDF makes sending all that useless data across the network unnecessary. We also don't mirror spool for all but a couple of very small environments (one sysplex has about 70 3390-3 volumes we don't mirror). We accept that anything in the spool at the time of a disaster is lost. This wouldn't be much as we have output control software. If network bandwidth wasn't a consideration, we would mirror everything as it does make the process simpler. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: PPRC and page datasets
Hi Eric - Our SOP is that we mirror everything locally for DR. Once a day, we break the link and back all the offline volumes up to tape. Doing every volume just makes the restore process at DR much simpler - once the restore process is done, we ipl - no additonal steps like page packs to set up, spool volumes to initialize, whatever. We're backing up over 4,000 addresses - a lot of which are mod-27's. So even if we had 100 page packs (mod-3's), it's not a real significant portion of the backup or restore and isn't seen to be a big enough impact to change the procedure. If the performance hit is small, there's no justification to changing the process. But if it's significant... What would you do with a mirrored page pack if your system crashed? I don't think you could use it for anything. I know there are others out there who have a more definitive answer, but I can't see much use for it. Eric Darth Keller [EMAIL PROTECTED] wrote: So the general consensus seems to be that mirroring page packs is a bad idea resulting in a performance hit. Does anyone have any #'s on how much of a hit this is? ddk ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ** -- 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
Re: PPRC and page datasets
On Thu, 8 May 2008 10:23:37 -0500, Mark Zelden [EMAIL PROTECTED] wrote: We also don't mirror spool for all but a couple of very small environments (one sysplex has about 70 3390-3 volumes we don't mirror). We accept that anything in the spool at the time of a disaster is lost. This wouldn't be much as we have output control software. That came out wrong. Obviously if that environment needs 70 spool volumes there could be a lot of data lost. What I meant to say is that it wouldn't be much loss of anything importance since all the important stuff is managed by the output control software. Anything in the spool waiting to print that was production could be re-spooled. Test / programmer output... who cares. If network bandwidth wasn't a consideration, we would mirror everything as it does make the process simpler. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: PPRC and page datasets
In a message dated 5/8/2008 10:05:07 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: We're backing up over 4,000 addresses - a lot of which are mod-27's. Can you describe this backup process a little? E.g., I assume you use some kind of FlashCopy. If so, then you need 4,000 more addresses for their secondary volumes, right? How much total elapsed time does it take to do all those backups? How many output tapes are produced? What DASD vendor? If you start all 4,000 FlashCopies at once, how long does that take? Total down time for the backup site before you start mirroring again? How long to get back in sync? This sounds like the kernel of a good session for SHARE or CMG. Bill Fairchild Rocket Software **Wondering what's for Dinner Tonight? Get new twists on family favorites at AOL Food. (http://food.aol.com/dinner-tonight?NCID=aolfod000301) -- 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
Re: PPRC and page datasets
In my earlier post, I described categories of data: mirror continuously, synchronize only, don't mirror at all. I didn't mention spool. When we started this 10 years ago, we were using conventional ESCON channel extenders from a well-known vendor in that biz. Bandwidth was a consideration, but other limitations of channel extension were more important. We opted not to mirror spool (but synchronize periodically) on the grounds that production output was mostly sucked up by an output manager product on DASD that *was* mirrored. The nagging problem we had trouble solving was this: in the event of a sudden break, how would we figure out exactly where we got interrupted in order to resume unfinished processes? With no spool or SMF (previous post), how could we determine what was in progress at what stage? As time went on, advancing technology allowed us to move to FICON over DWDM. Everything got way faster. We flirted with the idea of mirroring the *alternate* checkpoint and the spool volumes. Primary checkpoint still seemed daunting. Then one day our XRC guru turned on mirroring for the entire JES2 array. The effect was barely noticeable. Problem solved. Now we warm start JES in DR and pick up wherever we left off in production. My recommendation: try mirroring the entire spool and monitor performance. If it looks OK, leave it on. You'll avoid a lot of recovery problems. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Mark Zelden [EMAIL PROTECTED] CHNA.COM To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Re: PPRC and page datasets 05/08/2008 08:28 AM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU On Thu, 8 May 2008 10:23:37 -0500, Mark Zelden [EMAIL PROTECTED] wrote: We also don't mirror spool for all but a couple of very small environments (one sysplex has about 70 3390-3 volumes we don't mirror). We accept that anything in the spool at the time of a disaster is lost. This wouldn't be much as we have output control software. That came out wrong. Obviously if that environment needs 70 spool volumes there could be a lot of data lost. What I meant to say is that it wouldn't be much loss of anything importance since all the important stuff is managed by the output control software. Anything in the spool waiting to print that was production could be re-spooled. Test / programmer output... who cares. If network bandwidth wasn't a consideration, we would mirror everything as it does make the process simpler. -- Mark Zelden -- 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
Re: PPRC and page datasets
Ted, There may be a statistical impact on DASD response time, but I don't believe that mirroring page datasets actually impacts performance to any significant degree. Page in of any variety is not affected by Synchronous remote copy. It's a read and reads are local. Most page ins are synchronous to task execution and thus this performance stays the same. Page outs are not synchronous to task execution. As I read it most page out activity is related to low touch pages and tasks are unaware that the page has even moved to AUX until it needs to page it in again. Whether the page out takes 0.5ms or 1.5ms with Synchronous Remote Copy does not really affect performance, just performance statistics. The only impact would be Memory challenged environments that require expeditious page out performance to make room for spikes in memory usage, where the source of the spike is mission critical. The reason I don't mirror page datasets is that any reduction in link traffic is a good reduction. It goes hand in hand with the best IO is the one you don't do. With page out rates as low as we see today and the big pipes used for Synchronous remote copy I have to consider if this rule is still valid. XRC, HUR and TrueCopy Asynch have other challenges with paging because of timestamps. I recommend Skip's technique for these products. Ron If it's synchronous double the I/O response. If it's also to another site --GDPS-- add in the speed of light differential. Also, at a second site, none of the data will be used. It will be the virtual/real storage map of the second site. - Too busy driving to stop for gas! -- 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 -- 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
Re: PPRC and page datasets
Can you describe this backup process a little? E.g., I assume you use some kind of FlashCopy. If so, then you need 4,000 more addresses for their secondary volumes, right? How much total elapsed time does it take to do all those backups? How many output tapes are produced? What DASD vendor? If you start all 4,000 FlashCopies at once, how long does that take? Total down time for the backup site before you start mirroring again? How long to get back in sync? This sounds like the kernel of a good session for SHARE or CMG. Bill Fairchild Rocket Software Bill - because you asked - We have a DS8100-931 from IBM defined with a total of 6576 online devices (mixed mod-3?s, 9?s, 27?s). Approximately 4400 volumes are currently in use. To support this configuration, our DS8100 has 28 LSS's/Arrays and 44 LCU's online and a matching 44 offline. We describe the online devices as being the front half and the offline devices as being the back half. All of our online devices are in a one to one relationship with the corresponding offline device, i.e. address 5000 is always paired with offline address 9000. We backup approximately 4400 volumes on a daily basis to 3592 tapes which fits onto 20 3592 300GB cartridges. Our backup cycle runs in approximately 4 hrs. We could actually use less than 20 cartridges but choose to use 20 drives for backups as we have 20 drives at the DR site available for restores. We established a PPRC Metro Mirror - Loop Back environment, which means that we PPRC from the front end of the box to the back half of the box. We were told that in a metro mirror with 30 kilometer separation in full Synchronous mode, the delay could be up to .08 ms on writes. Since our loop back metro mirror is approximately 3ft, our delay is less than .03 ms. on writes. We run in synchronous mode from 16:00 to 03:58, at 03:58 we still do our DB2 and IMS log suspend as soon as this happens we issue a freeze against all of the LSS's this process takes roughly .3seconds. A freeze breaks the relationship between your PPRC primary and secondary volumes. We then do a failover which is a series of ICKDSF commands to prepare the PPRC secondary volumes to be backed up. We backup the offline volumes (our PPRC secondary devices) using Innovations FDR products. The backups themselves take 4 hrs. Once the backups complete, we re-establish the PPRC pairs, do a failback, and sync up in XD mode (extended distance). We currently wait until 16:00 to issue the commands to go fully synchronous. Which has more to do with a application tuning problem than any performance issues with PPRC. Resuming in XD mode takes about 45 minutes - times vary depending upon how many writes were executed during the backup window. A query job run prior to going to XD mode will show exactly how tracks are out of sync. We have three jobs that run single thread to convert us to from XD mode to syncronous mode. Each job runs about five minutes. As a note, the 1st time we established the PPRC pairs, we ran it on the weekend and it took 13+hours. ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ** -- 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
PPRC and page datasets
Hello Are there any rectrictions or recommendations about PPRC (metro mirror) and volumes with page datasets? Good ide, bad ide, some performance impact, recomented? Venlig hilsen Frank Allan Rasmussen IT, IT - drift og udvikling [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Direkte tlf. 76631650 Mobil: 29201650
Re: PPRC and page datasets
Ooooh...my email translation page can't read Martian! Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 05/07/2008 06:55:47 AM: -- Information from the mail header --- Sender: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Poster: Frank Allan Rasmussen Frank.Allan. [EMAIL PROTECTED] Subject: PPRC and page datasets --- SGVsbG8NCg0KIA0KDQpBcmUgdGhlcmUgYW55IHJlY3RyaWN0aW9ucyBvciByZWNvbW1lbmRhdGlv bnMgYWJvdXQgUFBSQyAobWV0cm8gbWlycm9yKSBhbmQgdm9sdW1lcyB3aXRoIHBhZ2UgZGF0YXNl dHM/DQoNCiANCg0KR29vZCBpZGUsIGJhZCBpZGUsIHNvbWUgcGVyZm9ybWFuY2UgaW1wYWN0LCBy ZWNvbWVudGVkPw0KDQogDQoNClZlbmxpZyBoaWxzZW4NCg0KRnJhbmsgQWxsYW4gUmFzbXVzc2Vu IA0KDQpJVCwgSVQgLSBkcmlmdCBvZyB1ZHZpa2xpbmcNCg0KRnJhbmsuQWxsYW4uUmFzbXVzc2Vu QHJlZ2lvbnN5ZGRhbm1hcmsuZGsgPG1haWx0bzpGcmFuay5BbGxhbi5SYXNtdXNzZW5AcmVnaW9u c3lkZGFubWFyay5kaz4gDQpEaXJla3RlIHRsZi4gNzY2MzE2NTAgICBNb2JpbDogMjkyMDE2NTAN Cg0K Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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
Re: PPRC and page datasets
On Wed, 7 May 2008 12:55:47 +0200, Frank Allan Rasmussen wrote: Are there any rectrictions or recommendations about PPRC (metro mirror) and volumes with page datasets? Good ide, bad ide, some performance impact, recomented? It should be a prerequisite for a GDPS HyperSwap. For the HyperSwap you should mirror everything, except couple data sets. -- aromil -- 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
Re: PPRC and page datasets
Frank Allan Rasmussen wrote: Hello Are there any rectrictions or recommendations about PPRC (metro mirror) and volumes with page datasets? Good ide, bad ide, some performance impact, recomented? If you don't have GDPS, then *avoid* replicating them. You'll get better performance. To be more accurate: It is even possible to have GDPS and no need to replicate page's. It depends on GDPS flavor. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2008 r. kapitał zakładowy BRE Banku SA wynosi 118.642.672 złote i został w całości wpłacony. -- 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
Re: PPRC and page datasets
However, GDPS/PPRC or GDPS/HyperSwap can mirror the LOGRxx. Terry Traylor charlesSCHWAB TIS Mainframe Storage Management Remedy Queue: tis-hs-mstg (602) 977-5154 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Zaromil Tisler Sent: Wednesday, May 07, 2008 4:13 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PPRC and page datasets On Wed, 7 May 2008 12:55:47 +0200, Frank Allan Rasmussen wrote: Are there any rectrictions or recommendations about PPRC (metro mirror) and volumes with page datasets? Good ide, bad ide, some performance impact, recomented? It should be a prerequisite for a GDPS HyperSwap. For the HyperSwap you should mirror everything, except couple data sets. -- Žaromil -- 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 -- 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
Re: PPRC and page datasets
General case is a performance hit that does not add value. Volumes with page datasets shouldn't have anything else. My $0.02 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Frank Allan Rasmussen Sent: Wednesday, May 07, 2008 5:56 AM To: IBM-MAIN@BAMA.UA.EDU Subject: PPRC and page datasets Hello Are there any rectrictions or recommendations about PPRC (metro mirror) and volumes with page datasets? Good ide, bad ide, some performance impact, recomented? Venlig hilsen Frank Allan Rasmussen IT, IT - drift og udvikling [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Direkte tlf. 76631650 Mobil: 29201650 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
Re: PPRC and page datasets
Hal, I don't think that is true anymore. The reason for dedicating page datasets to a single volume was to stop the seldom ending channel programs from ending. I'm sure I read on this list that the suspend/resume subchannel commands are not used by ASM anymore, so there is no reason to dedicate. And if this is not the case, have you been paging heavily enough that seldom ending channel programs will make a huge difference to a Demand page-in? There is also PAV exploitation for page datasets to consider. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt Sent: Wednesday, May 07, 2008 8:02 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] PPRC and page datasets General case is a performance hit that does not add value. Volumes with page datasets shouldn't have anything else. My $0.02 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Frank Allan Rasmussen Sent: Wednesday, May 07, 2008 5:56 AM To: IBM-MAIN@BAMA.UA.EDU Subject: PPRC and page datasets Hello Are there any rectrictions or recommendations about PPRC (metro mirror) and volumes with page datasets? Good ide, bad ide, some performance impact, recomented? Venlig hilsen Frank Allan Rasmussen IT, IT - drift og udvikling [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Direkte tlf. 76631650 Mobil: 29201650 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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 -- 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
Re: PPRC and page datasets
My context was backup/recovery. Page datasets tend to be large and so numerous as to fully occupy whole volumes in the first place. DASD is too cheap to fret about a couple of cylinders here and there. With two exceptions, backing up page volume makes no sense to me. One exception is that it is much simpler to restore a page volume than to allocate the page datasets by hand. The other exception is having data on these volumes. Once had an LPAR load a wait PSW once when a volume backup job on another LPAR sat on a page volume a bit too long. Most would call that a performance hit. Don't recall, but that may have been before PAV. So, the simple way out is ban data (dedicate the volume) and exclude page volumes from routine backups and mirroring. We don’t fool with page or JES volumes. Being a simple minded sort, simple solutions have some appeal to me. ;-) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ron Hawkins Sent: Wednesday, May 07, 2008 11:41 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PPRC and page datasets Hal, I don't think that is true anymore. The reason for dedicating page datasets to a single volume was to stop the seldom ending channel programs from ending. I'm sure I read on this list that the suspend/resume subchannel commands are not used by ASM anymore, so there is no reason to dedicate. And if this is not the case, have you been paging heavily enough that seldom ending channel programs will make a huge difference to a Demand page-in? There is also PAV exploitation for page datasets to consider. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt Sent: Wednesday, May 07, 2008 8:02 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] PPRC and page datasets General case is a performance hit that does not add value. Volumes with page datasets shouldn't have anything else. My $0.02 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
Re: PPRC and page datasets
We've been mirroring 'all' DASD for 10 years. From the outset we chose XRC over PPRC because the distance between data centers ruled out synchronous mirroring. (Everything was slower in those days.) Our DR recovery would require IPLs at the remote center. If your use of mirroring somehow allows you to avoid system restarts, then you can ignore many of the following points. We have a 'cool' site: mirrored DASD but no running system to use it seamlessly. We have to IPL all necessary systems. Hence some data is needed, other data is not. Our reasoning. 1. Don't mirror 'throwaway' data. For example, SORTWK and other temp data is totally unnecessary after reIPL. Isolate all such data via SMS and refrain from mirroring it. Total waste. 2. Don't mirror data that is otherwise backed up on a constant basis. For example, our SMF MANx data sets are placed on a specific set of volumes. SMF data is offloaded to tape and the data sets cleared frequently. In the event of a disaster, lost SMF data is the least of our worries. Yet SMF data is a drain on mirroring resources because it is hugely write intensive. 3. For any volume that is not mirrored, provide a 'placeholder' volume for DR. Placeholders are of two types: (a) SORTWK and temp volumes require nothing more than a VTOC with a volser that SMS at the DR site can utilize. (b) Some data like SMF requires an actual 'image' of the volume containing all data sets for normal IPL at the DR site. That is, the SMF objects must exist on the volume with the proper allocations, but the actual data contents are irrelevant. For this type, we schedule a job once a week to synchronize SMF volumes and then cease mirroring immediately. Overhead is brief and minimal. So to the original question: where do page data sets fit? For us, unequivocally, they are type 3(b) that need only specific allocations on specific volumes. Like SMF, we synchronize them once a week but do not mirror the actual data, which are totally refreshed on IPL at the DR site. To summarize the three types: - Mirror continuously - Synchronize regularly only to assure proper allocations - Don't mirror at all . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Frank Allan Rasmussen Frank.Allan.Rasm To [EMAIL PROTECTED] IBM-MAIN@BAMA.UA.EDU NMARK.DK cc Sent by: IBM Mainframe Subject Discussion List PPRC and page datasets [EMAIL PROTECTED] .EDU 05/07/2008 03:55 AM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU Hello Are there any rectrictions or recommendations about PPRC (metro mirror) and volumes with page datasets? Good ide, bad ide, some performance impact, recomented? Venlig hilsen -- 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
