I can't speak for this particular option, but in general there is great peril in running shared systems with different views of what to protect/allow and how to do it. In some cases, a new system cannot even join a GRSplex if key options don't match. You could take the trusting optimist view that if joining is not prohibited, then everything must be hunky dory.
Or not. Greg Saccomanno <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List <[email protected]> 01/23/2007 11:03 AM Please respond to IBM Mainframe Discussion List <[email protected]> To [email protected] cc Subject z/OS 1.7 SYNCHRES=YES & z/OS 14 SYNCHRES=NO I have checked the manuals and the archives on this and I am still unsure about mixing the yes and no values for SYNCHRES in a GRSPlex (Basic sysplex if that matters any). I need to bring my TEST LPAR into our plex for testing. I would rather wait until either our outage weekend next month to change the value of this on the systems that are already in the sysplex or until each cuts over to 1.7 but I need to bring the TEST system up in the plex and test before I can migrate 1.7 to the next system. I see that I can change the value via the SETGRS command and I guess I could always code the 1.7 system as SYNCRES=NO for this phase but from the way I interpret the FM it doesn't seem like it should be a concern. However, nothing I found gave a definitive answer. Does anyone know of any problems with having two z/OS 1.4 systems with SYNCHRES=NO and a z/OS 1.7 systems with SYNCHRES=YES active in a basic sysplex? Has anyone run this way when migrating to 1.7 from 1.4? ---------------------------------------------------------------------- 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
