I'm a fan of the big bang method myself. It's always worked well for us. I like knowing that what I'm running is what IBM actually ran for an extended period of time.
Just my 2 cents. Marcy "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack Sent: Thursday, October 30, 2008 10:09 AM To: [email protected] Subject: Re: [IBMVM] TCPIP for z/VM 5.4 Thanks. That is the way I have (almost) always worked. I hate a "big bang" change. The Prog. Directory, 5.2.4.2.1 is misleading, at best. Jim Alan Altmark wrote: > On Thursday, 10/30/2008 at 10:13 EDT, Edward M Martin > <[EMAIL PROTECTED]> wrote: > > >> But I thought that TCP/IP and CMS were tied to each other level >> > wise. > >> They work on different levels but there could be inconsistencies. >> > > You are correct. A particular release may include a TCP/IP change > that depends on a new CMS function that depends on a new CP function. > Sometimes yes, sometimes no. If a service that TCP/IP or one of its > servers needs isn't present in CP and/or CMS, that app will typically > stop. We try to do it gracefully and it is our general rule to check > for the availability of a new service when the server starts - not > waiting until it is actually needed. This way the error appears right away. > > If you don't do a big bang: > 1. Upgrade CP > 2. Upgrade CMS > 3. Upgrade TCP/IP with all of its attendent servers > > What is underneath needs to be newer than what rides on top. We do > our best to make this work if it's reasonable to do so, but there are limits. > E.g. When the SSL support for z/VM 5.4 ships later this year, it will > not work with an old stack and the new stack will not work with the > old SSL server. The expense of making it work was prohibitive. > > Within reason we'll support a mixed configuration while you are migrating. > > Alan Altmark > z/VM Development > IBM Endicott > > -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell [EMAIL PROTECTED]
