If you saw my response about the less structured change implementation, your shop was exactly what I was talking about and what I have seen over the years.
One point I didn't bring up in my response. Considering dozens or even hundreds of applications in some of the large shops I've been at, if you did do all your changes to all applications at a given time (once a week, once a month, whatever...) that could be considered a lot more of a risk than different application portfolios each having their own change schedule. With all the application interdependencies and interfacing with distributed systems (which have their own change schedules BTW), debugging an application problem after a change window could be really difficult also). Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:[email protected] Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ On Wed, 15 Jan 2014 11:11:54 -0800, Frank Swarbrick <[email protected]> wrote: >We are a small enough shop that we don't, in fact, group our production >application updates in that manner.� We update in what one might call a more >"agile" manner.� As a programmer/developer completes updates for a project >they create a work order and the programs are implemented by work order.� For >batch programs this is done throughout the day.� For CICS programs we >generally implement only during the short period that we have CICS unavailable >when we cut over our business day. So while obviously no one program is updated more than once a day (or week, or month, or year), other than for bug fixes (and of course we test first!), we implement changes to different programs throughout the business day. I do realize that we are probably an exception (we often note how differently we do things than other shops), but it has worked well for us for over 30 years.� It allows us to respond much faster to enhancement requests from the business, as well as bug fixes. Frank Swarbrick Application Development Architect FirstBank -- Lakewood, CO� USA >________________________________ > From: Peter Relson <[email protected]> >To: [email protected] >Sent: Wednesday, January 15, 2014 5:43 AM >Subject: Re: LLA/VLF -- NAMED LNKLST? > > >Regarding frequent updates: > >I suppose I was wondering why you would be changing code in a production >library even as frequently as several times a day. I would have guessed >that your application would reach stability and not require updates aside >from functional enhancements (which most would not roll out several times >a day, I think) and bug fixes. > >And wouldn't most try out their code in a test environment and not choose >to inject potential instability several times a day, thus grouping their >updates to production? > >So I'm curious.... > >Updating data upon which the code operates is a different matter, but >that's perhaps not frequently within production code libraries. > >Peter Relson >z/OS Core Technology Design > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN > > > > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
