Endevor

 View Only
Expand all | Collapse all

Endevor Backout Process

  • 1.  Endevor Backout Process

    Posted Apr 05, 2017 03:38 PM

    Hello fellow Endevorites!

    We are interested in totally revamping our Endevor Backout process and are curious if any of you out there have researched, customized, complained about the delivered process. 

    What we would like to see is the ability to submit a single BACKOUT process that will restore the remote production files AND the local PROD baselines to their previous versions prior to a Package Execute.  We are fine if the process adds elements back into the PROD stage and having the current verion (0) the same as the -2 version,  with the -1 being the version that was backed out, for audit purposes.

    The way backout works as delivered continues to be confusing to our development staff and often times our support staff, especially by those who rarely backout.  They often do not remember that their source will no longer match their development load if an Execute backout is done or if it is not, that the local PROD load does not even match the remote Production load.  This does not even take into account simple PDS elements, such as Copybooks and JCL that are not restored on development with either backout and are therefore out of sync with Production

    Thank you in advance for your input!

    Janet Spears

    Wells Fargo

    janet.spears2@wellsfargo.com.



  • 2.  Re: Endevor Backout Process

    Posted Apr 05, 2017 05:28 PM

    Hi Janet,


    When we backout our remote shipment we also backout our package so that the local executables and the same as the remote executables.


    I agree that there are some short comings with shipment related backouts when it comes to individual member backout.


    But I would say that there are a few Ideation entries that cover these short comings, so your votes may improve things.


    Stuart



  • 3.  Re: Endevor Backout Process

    Posted Apr 06, 2017 10:28 AM

    Thanks Stuart,

     

    Yes,  I see that this subject has been a part of Ideation for years now. 

    I am hoping to hear if anyone has created their own solution to this issue, as it does not appear that the Backout functionality in Endevor will be "repaired" by CA any time in the near future.  We are looking to correct sooner, rather than later.

     

    Janet



  • 4.  Re: Endevor Backout Process

    Posted Aug 04, 2017 10:43 AM

    Hi Janet,

     

    I'm automating some emails into our backout process which inform the users that their elements are now out of synch and they need to get it fixed.

     

    This feels like only a partial solution to the issue, because logically following this through I could just automate what I think the right thing to do is (ie re-apply the previous version to the final ENDEVOR environment). Hmm, is that ok with audit?

     

    We've also been asked to implement element backout, this has been an ENDEVOR feature since V15.

    So here's the thing, it works ok but it's really clunky - the panels can take an age to appear if you have large packages, it's really easy to miss the element and get the wrong one and even when you've done that work all it does is back out the element in the final ENDEVOR environment, you still (if on a remote machine) have to ship the old element. Endevor packaging and especially the backout piece with shipment appears overly complex and with customisations of having multiple targets and large /multiple packages, things aren't any simpler (eg like standard shipment the added scripting of database rebinds / phase in a CICS programs, recopy listings).

     

    So I'd need to automate this into a pipeline like my existing backout process which allows our operations team to backout based on CCID and then (if shipped to multiple targets) choose the ones they want to remove the package from.

     

    If I'm doing that then maybe I should think about just driving my own panel of elements, driven from a new menu eg:
     

    OPTIONS:

    1. BACKOUT PACKAGE (BY CCID) - ALL ELEMENTS / ALL TARGETS
    2. BACKOUT SPECIFIC ELEMENT(S) (ALL TARGETS)
    3. BACKOUT SPECIFIC ELEMENT(S) (SPECIFIC TARGET)

     

     

    In short I'd like CA to spend some time thinking about this whole thing maybe arrange some end-user sessions with admins to try and come up with a better solution.

    As Stuart mentioned, it's been asked before. The idea has 16 votes up but 2 down (it's odd way that the tool CA uses works and has been configured) as to me if you don't want a feature don't vote on it, we could do with some clarity from CA what downvoting means to then. As it's been stationary for 4 years it could mean that it will never be investigated.

     

    DevOps in theory leads to a fix forward mentality but it's never as simple as just one thing, there are also dependencies on the speed changes are implemented and the size and criticality to supporting areas which the associated risk.

    Do you want your system on the floor whilst your support guys fiddle around trying to fix something (especially if it’s "just" going back to the previous version) or just press one button and back it out.

     

    Backout is a great and required feature but it does need some TLC as it appears to have been neglected.

     

    Steve Blackett (HSBC)



  • 5.  Re: Endevor Backout Process

    Posted Aug 08, 2017 08:51 AM
    As I see this, a backout carries with it an implicit assumption that there is a problem for the developers to correct.  If the developers decide that the best course of action is to generate from the prior version level of the source code and migrate to production then they can do that, assuming that there is a prior version level.  If the developers instead decide that they need to modify the current version of the source code they can do that.  Either way, once the program element corrections reach production the version level increments.


    My understanding of what you are proposing is that the backout action increment the program element version level with the prior version level source code, automatically regressing the source code so that the source code continues to match the backed out generated outputs.  I disagree.  That is trying to do too much because it overlooks the complexities of the generate time input components, some of which are likely to be used by other program elements that were not in the backed out package, and because it assumes that the best way forward is to start again from the prior version source code. It is better to leave the source code alone and let the version level change history represent only the change history of the developer actions on the source code, ignoring the backout action, as it currently does.  The SCM tool should not mess with the source code, that is exclusively a developer responsibility, the proper role for the SCM tool is to track what the developer did.



  • 6.  Re: Endevor Backout Process

    Posted Aug 08, 2017 11:33 AM

    Mathew,

     

    Thanks for taking the time to explain this. I think you can probably tell I was conflicted to go in the way of a "full backout". I agree as well, the difficulty I am finding is to ensure ENDEVOR stays in synch as such as the "element backed out message" is quite subtle.

     

    I still think CA should be thinking about backouts (especially when it comes to individual elements) and perhaps document their findings on some sort of best practices guide as what you said makes a lot of sense and it would help newer people like myself understand how and why things work and should work.  



  • 7.  Re: Endevor Backout Process

    Broadcom Employee
    Posted Aug 11, 2017 08:43 AM

    This issue is that the backout does not do what is expected. Maybe we should notify and document the behavior better.

     

    What I'm thinking of is if we notify the user when they do a backout. I'm thinking in ISPF when they do a backout a windowed message saying that this does not backout source only objects are backed out. I'm also thinking as long as a element is backed out a flag appear when the Element is displayed. For example a red asterisk when the element list/master is shown. 

     

    Richard



  • 8.  Re: Endevor Backout Process

    Posted Aug 12, 2017 09:35 AM

    I think we agree.  Notifications when there is an email address in the SMTP table, exit notifications, 508 compliant identification of program elements and packages in ISPF, and a report would all be useful and appropriate.  Currently, this is lacking the extra visibility that is needed. I am going to add exit notification for this to my to do list.



  • 9.  RE: Re: Endevor Backout Process

    Posted Nov 05, 2020 01:45 PM
    Good afternoon Richard,

    My name is Márcio Jordão and I work at Caixa Econômica Federal in Brazil. We have a contract with Broadcom for the ENDEVOR tool and a few days ago we held a meeting to address the issue (Backout process at ENDEVOR). Many developers face difficulties because of the lack of synchronization between the load module and the source code due to backouts in the ENDEVOR tool packages. We know that the described behavior is foreseen in ENDEVOR and is not considered an error by the manufacturer, but as a way to guarantee the versioning of the elements in the production environment, mainly for audit purposes. However, during a meeting, there was a consensus that the backout information is not explained in the best way and it was agreed to request this change in the ENDEVOR initial panel to demonstrate more clearly that that element was backouted. Broadcom analyst Mauro Saito, who attended the meeting, suggested that we create a forum here in the community to record the request and try to convince the product manager that this is an important improvement for ENDEVOR. As a result of the above, I ended up reading your message of 05/04/2017, which goes against what we would like to propose. Therefore, we request to inform you if there has been any progress in your improvement proposal for inclusion in a new version of ENDEVOR. If not, we request that the proposal be evaluated by Broadcom, since, according to the messages published here, this is not a one-off problem, but a general one.

    Marcio Jordão
    marcio.j.sousa@caixa.gov.br


  • 10.  RE: Re: Endevor Backout Process

    Broadcom Employee
    Posted Nov 06, 2020 12:48 PM
    Hi,

    You are correct this tread explains how backout works. It sounds like you would like to suggest that it change.  The correct place to do that is in the Communities / Ideas . https://community.broadcom.com/ideation/allideas
    I can see that a few people have some ideas opened. Have a look at them and if you don't see any idea that matches what you are thinkin you can add a new one.

    Richard


  • 11.  RE: Endevor Backout Process

    Posted Dec 03, 2020 01:50 PM
    Edited by Mathew Goldstein Dec 03, 2020 03:00 PM
    Any automated back out of ​source code would require creating a new level from the prior level source code (as happens when the prior version is generated). It would not be proper to drop the current level from the change history and not display the back-out as the timestamped change to the source code that it is. A level increment normally initially occurs in an entry stage. If that instead initially happens in a non-entry stage, and the automated source code back out proposal appears to be partly about avoiding returning the source code to the entry stage (does anyone propose that the automated source code back out occur in the entry stage rather than the same stage where the backed out element resides?), then that would introduce synchronization complications. Everyone does not want automatic back out of source code every time an element is backed out, so if that is implemented it should be implemented as an opt-in option.