On Thu, Oct 30, 2008 at 6:47 PM, Marcy Cortes <[EMAIL PROTECTED]> wrote:
> Unless you have rigid change control processes and approval that takes > longer than actually doing the change! Unlike what some people (and shops) may think, change control is the means and not the aim ;-) Your options are different when there's home cooked applications or modifications, leading to service levels that dictate time for application testing. I do see that modern z/VM installations will have less of that, which makes it more likely code works right out of the box. As a VM Systems Programmer you stick out your neck when you type PUT2PROD, close your eyes, and press Enter. When that breaks, it may take a while before you (and your management) are willing to try it again. As long as there are no complications, either approach works. But when there are complications, some installations just don't have resources to address multiple issues in the same maintenance window. The more different people are involved, the more likely you get conflicts in a full change weekend. > Argh - if I divided it into CP , CMS, and TCPIP, that's 3x7 systems or > 21 change items to get in and approved. It'd take 6 months of weekends > (given change freeze periods)! That's because z/VM does not come with a method to promote the code from your test system into production. Instead, you're told to re-apply maintenance on each of your systems. Most installations I worked with developed their own in-house z/VM software distribution to allow for robust activation and back-out of a change. With that we did a full new release (with all program products) in production in 2-3 weekends. But normally not both CP and CMS in one weekend. -Rob
