Endeavor Sync Error

assigned a BASE date that will be EQUAL to the CURRENT SOURCE Date of the module you took ( do a display element and then an M to see the two screen display, hit enter to see the SECOND page, (PANEL2 OF 2)). the BASE DATE information looks like this: ----------------------------------- BASE ------------------------------------ USERID: TXXAKX9 DATE/TIME: 01JUL11 06:53 This date is the CURRENT SOURCE DATE of the element in the next highest stage, essentially. Display it and look at (PANEL 1 OF 2). That relationship makes sense.The next highest up is your "starting point" or what your code is "based" on. From that point forward, Endevor will ALWAYS know that you code was 'based' on that code. Here arethree scenarios that WOULD cause out of sync or SYNCHRONIZATION ERRORS. All require that you 'do' something. A synchronization error ALWAYS requires that you do something.. 1) the code 'above' yours wasn't quite right and needed a few more changes.... it wasn't perfect. That NEVER happens, right?Someone with the AUTHORITY to make changes at that level in the lifecycle makes changes directly to it. This causes the CURRENT SOURCE DATE of that program to change. Your program was "based" on changes prior to that, WITHOUT these 'corrections' so your BASE DATE no longer is equal to the CURRENT SOURCE dateof the program above it. If you try to promote that program, Endevor will tell you that the CURRENT SOURCE in the stage above is NOT what you based you program on.... Endevor is saying, there have been changes to that upper version that you might not be aware of and may not have included in your version. If you tell Endevor to ignore that SYNC error and proceed and you have not examined and then included any subsequent changes from the upper version into your version (using PDM, for example to insure you have all the current code) , when you move your program your version will appear to be 'deleting' those "corrections" that occurred after you initially took you 'copy' of the program. You will reintroduce the reason for the correction if you do not alter you code to include that change. Once you have assured yourself that ALL corrections have been include you CAN safely ignore the SYNC error at that point. . 2) Same setup. There is a program ahead of you, you take

don't have JavaScript enabled. This tool uses JavaScript and much of it will not work correctly without it enabled. Please turn JavaScript back on and reload this page.All Places > CA Endevor > DiscussionsLog in to create and rate content, and to follow, bookmark, and share content with other members.AnsweredAssumed AnsweredInstructions for developers when there is a synchronization failureQuestion asked by Mathew on Nov 9, 2014Latest reply on Nov 16, 2014 by buzz1961au Like • Show 0 Likes0 Comment • 4We have parallel migration paths to production. If a package cast fails due to an out of synchronization problem http://mainframe-tips-and-tricks.blogspot.com/2011/12/endevor-synchronization-errors.html then the developers will add an OPTION SYNC to the failing move action and cast the package again. Some developers add the OPTION SYNC to all of their move actions to bypass the failure and some developers also specify WITH HISTORY for all of their move actions. An out of synchronization condition implies there is a risk of a unwanted https://communities.ca.com/thread/241697167 code regression. We want to require our developers to check for code regression whenever there is a out of synchronization condition before adding an OPTION SYNC to a move action. Does anyone have suggestions regarding how to enforce such a policy and the contents of such instructions?buzz1961au Nov 13, 2014 11:44 PMCorrect AnswerIf you really want to stop people using WITH SYNC then put an SCL override in Exit 2. E.g. we use this to force SIGNIN/NOSINGIN and HISTORY/NOHISTORY at different stages.However this still won't stop users doing the wrong thing, not doing the required analysis and just doing 'whatever' to get rid on the SYNC error. Better education and holding users responsible for implementing incorrect versions to production (as well as better testing/reviews) will help as well as proper change control (essential with parallel environments) and review boards etc.See the reply in contextNo one else had this questionMark as assumed answeredOutcomesVisibility: CA Endevor339 ViewsLast modified on Nov 9, 2014 6:25 PMCategories: CA EndevorThis content has been marked as final. Show 4 comments4 RepliesNameEmail AddressWebsite AddressName(Requir

don't have JavaScript enabled. This tool uses JavaScript and much of it will not work correctly without it enabled. Please turn JavaScript back on and reload this page.All Places > CA Endevor > IdeasLog in to create and rate content, and to https://communities.ca.com/ideas/235714270 follow, bookmark, and share content with other members.Prevent MOVE of out-of-sync Elements to a specific stageIdea created by maria.hackmann-peters on Aug 11, 2014Comment • 8Wish-ListedScore4Vote up Vote down 4 votes up0 votes downNo one has voted against this ideaWe want to prevent out-of-sync Elements from being MOVEd into our stage RELEASE. Currently ENDEVOR does not enable us to do this.RELEASE is endeavor sync a stage higher in the map and developers should resolve their out-of-sync problems before they move to RELEASE ( or at least use the SYNC Options with the MOVE to RELEASE).In other stages, out-of-sync situations are still "allowed", thus we can NOT do a general change for message SMGR116C (SYNCHRONIZATION CONFLICT DETECTED....).To be able to realize this requirement, we would either endeavor sync error need toget a cast ERROR for elements, that are out-of-sync and do not use the SYNC Option with the MOVE to RELEASEmeaning: we would need to be able to increase message SMGR116C to a Error message ONLY for one SPECIFIC environment, NOT for every environmentorget the information about the out-of-sync situation in the element into Exit7 information : that would enable us to do this checks on our owntoday we only get the information, if or if not the SYNC option is set, but no information if the Element is out-of-sync or notVisibility: CA Endevor537 ViewsLast modified on Mar 31, 2015 6:40 PMTags:sync synchronize move smgr116 smgr116c conflict castContent tagged with sync synchronize move smgr116 smgr116c conflict castmhpContent tagged with mhpCategories: CA EndevorThis content has been marked as final. Show 8 comments8 CommentsNameEmail AddressWebsite AddressName(Required)Email Address(Required, will not be published)Website Addressjosef.thaler Aug 29, 2014 2:28 PMIt would definitely not be "aestethic" and not knowing your particular circumstances nor having played around with this specific situation==> just a quick idea: consider to have (1) MSGSEVERITY_SMGR116=E or =C and (2) having field REQSYNC checke