Endevor is source control. It's strength is in ensuring there are no changes to source between environments... (typically development, test, user acceptance, production, and 'emergency' environment for catering for on-the-fly changes to deal with a production problem... like production JCL needing bigger a SPACE allocation for a file)... majorly, any source that's needs compiling is done via Endevor processes, so that there is confidence that source code truly reflects object/runtime code. Changes/variations are tracked (and I imagine that's what's driving this). Such is the theory...
In terms of systems programming, there no sensible need for such source/object/executable control. We've got SMP/E, which immediately covers much of Endevor's remit. If you want to control purely source that never needs compiling, such as PARMLIB or VTAMLST members or whatever, then again, I don't think something like Endevor is appropriate. The idea of having a hierarchy of environments that Endevor drifts unchanged source through doesn't really apply. Although system symbols allow common parmlib decks in many cases, it's more often the case that each system has it's own specific needs and parms... and there's no real 'test environment' to make sure any system parameter change actually works for any particular system... and no real hierarchy of environments in the same sense of having a tier of application environments where everything is notionally the same. You 'could' write Endevor generators that automatically change the source depending on the destination environment, but you'd better have a damned good naming convention for just about everything... and I doubt it would work properly anyway. Frankly, I think it would be easier to w! rite a usermod every time I wanted to update some parameter library member. Bone easy, using the same software and management techniques IBM themselves use to maintain the rest of z/OS. Throw a copy of the SMP/E log at management every day. Reporting requirement satisfied. I'd argue against it. Just like I'd argue that an application system development life-cycle is inappropriate for a system programmer's working practices. Square peg for a round hole. Get your management to ask CA one thing: has anybody anywhere on this or any other planet used Endevor to maintain z/OS system libraries? If you absolutely must, then try it using SCLM as an exercise. You'll have the same concepts and dramas to deal with and at much less cost. Better still, get your management to try it. They might develop a better understanding of what they are asking for. It's too big a hammer for the job really. Ant. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Lim Ming Liang Sent: Thursday, 15 March 2012 12:40 PM To: [email protected] Subject: Re: Endevor(Change Management Software) On 15-Mar-12 1:29 AM, gsg wrote: > Is anyone out there using CA-Endevor? Do you manage your system changes > using Endevor? If so, how are you doing this and was it hard to setup? > > We are looking into this, but there are so many system libraries that could > be changed, it needs a lot of thought to get it right. > > Thanks > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN > You can include any system parmlibs, proclibs and/or vtamlst libraries to be updated only by Endevor, effectively let the Endevor process to control and monitor the changes in those libraries. But that will really affect the system programmer productivity. Long time ago, any system changes made, my boss will required me to submit a change request, to document the actions and recovery plan, before or after the change. That was good enough at that time to pass the audit. -- Regards Lim ML ---------------------------------------------------------------------- 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
