HI Unless something has changed the IBM recommended JES ckpt config was one on CF the other on disk and then to have the alternates visa versa so that at start-up on the remote site, the cf structure would be empty but the dasd ckt would have the data in a time consistent state ( xrc).
Regards Gerard Ceruti -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Miller Sent: 15 June 2007 11:13 PM To: [email protected] Subject: Re: DR and JES check point question Hi Andy, We use synchronous PPRC on a HDS9980V and synchronous SRDF on a EMC DMX200 unit. We previously ( June 1998 to October 2004 ) had used XRC to a site about 900 'cable miles' away. One of the 'operational issues' we had to deal with was the fact that XRC being asynchronous might cause our D/R solution to be seconds to possibly a minute or more 'behind' the 'write activity' of the production site. We didn't XRC the JES2 Checkpoint/Spool volumes at that time ( our PPRC/SRDF solution does now ) so that wasn't an issue. The thing I liked about XRC was the 'time consistency' of the data, even across multiple storage subsystems ( we had 4 HDS 7700E's, 1 HDS9960 & 1 HDS9980V ). So, XRC will make sure that the data is written to the XRC Secondary DASD volumes in the same exact order they were written to the XRC Primary DASD volumes. The question becomes: How does JES2 react during startup when it attempts to access the primary CF resident Checkpoint dataset and that attempt fails? Have you tried that failure scenario at your primary site on a 'sandbox' z/OS system? For example, while JES2 is running at the primary site, SYSTEM RESET CLEAR the z/OS image AND SYSTEM RESET CLEAR the CF LPAR that contains the primary checkpoint ( simulates a site failure at the primary site ). Then IPL z/OS and restart JES2, see what messages/WTORs JES2 issues. HTH Glenn Miller ---------------------------------------------------------------------- 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 __________________________________________________________________________________________________________________________________ Standard Bank Disclaimer and Confidentiality Note This e-mail, its attachments and any rights attaching hereto are, unless the context clearly indicates otherwise, the property of Standard Bank Group Limited and/or its subsidiaries ("the Group"). It is confidential, private and intended for the addressee only. Should you not be the addressee and receive this e-mail by mistake, kindly notify the sender, and delete this e-mail, immediately and do not disclose or use same in any manner whatsoever. Views and opinions expressed in this e-mail are those of the sender unless clearly stated as those of the Group. The Group accepts no liability whatsoever for any loss or damages whatsoever and howsoever incurred, or suffered, resulting, or arising, from the use of this email or its attachments. The Group does not warrant the integrity of this e-mail nor that it is free of errors, viruses, interception or interference. Licensed divisions of the Standard Bank Group are authorised financial services providers in terms of the Financial Advisory and Intermediary Services Act, No 37 of 2002 (FAIS). For information about the Standard Bank Group Limited visit our website http://www.standardbank.co.za ___________________________________________________________________________________________________________________________________ ---------------------------------------------------------------------- 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
