Endevor Sync
Article ID: 197724
Updated On:
Products
Issue/Introduction
Endevor needs to warn users against the two methods that you quoted to "fix "the sync issue:
- the use of the SYNC method
- the retrieve delete add back method.
- possible messages are SMGR116/SMGR117
Both methods, if used without any other form of intelligence will cause a change to be backed out.
Environment
All Supported Releases
Resolution
Below are SYNC scenarios explained and how it needs to be handled with caution.
A SYNC condition occurs when an element's delta versions do not have a common timestamp with the last (current) time stamp with the same element up the map. There are a few simple scenarios which can create a sync condition (consider the map STG1 - STG2 - STG3 - STG4):
Scenario #1
A new element gets added to STG1, then an element with the same name type sys/subs get added to STG3 and moved to STG4. In this case the element in STG1 has no common delta level with the element in STG4 so when moving the element in STG1, or when validating the element a SYNC condition gets detected (SMGR116).
Scenario #2
an element is retrieved by two users from STG4 and added back with changes into STG1 in different subsystems, both mapping to the element in STG4.
Both elements are in sync because during the add back (or the QE EDIT operation) the last delta level at STG4 got fetched back. Notice that the elements have 2 delta levels, the oldest being the one from STG4 (the fetched level) the newest being the change level. If a VALIDATE is run on either of the elements it will result in RC0, both are synchronized with the next element up the map.
Now one of the two updated elements gets promoted to STG2, then STG3 then STG4.
If a VALIDATE is run on the remaining element in STG1, you will get a SYNC error SMGR116 because the element in STG1 does not have a matching delta level with the most current level in STG4
Scenario #3:
An element exists in STG4, it gets retrieved, changed and added back, moved up to STG3.
Then the element in STG3 gets retrieved and changed and added back to STG1.
All the elements are aligned. STG4 has the latest level, STG3 has a common delta level with the one in STG4 and a new level, while the element in STG1 has a common level with the element in STG3 and its own new level.
VALIDATE actions against each of the elements would not find any SYNC errors.
Now the element in STG3 is found to be in error (change not needed after all- Scenario 3a, or change needs to be improved Scenario 3b)
=3a=
the element in STG3 gets deleted as the change is not needed.
Now the element in STG1 is no longer connected to the last delta level in STG4 so VALIDATE will correctly report SMGR116
=3b=
the element in STG3 gets updated once more, creating another delta level.
VALIDATE of the element in STG3 will tell you it is synchronized, but a VALIDATE of the element in STG1 will fail, as there is no connection between any level in STG1 and the latest (current) delta level in STG3. (This is very similar to scenario-2).
These are the most common scenarios for sync errors. To add to the mix, the TRANSFER action in or do the same with Quick-Edit, it does not really matter. The current level (last level) at the next higher location in the map must match with a source level.
So what does the SYNC option do and why does it need to be used with extreme care:
The SYNC option tells Endevor that the user knows what he/she is doing (...) and that the current source version is the correct one
In scenarios #1, #2 and #3b option SYNC will replace what's in STG4 and delete all the changes that were made previously. The simplest illustration can be made using scenario#2. Using SYNC here would simply back-out the parallel change that got to STG4 earlier.
Only in scenario #3a would the SYNC option be harmless, where the user would not corrupt any existing changes but acknowledge the fact that his element is good but not synchronized, although in this case using SYNC would cause the retention of a delta level (the one that existed in STG3) that may have no use and might in the future confuse your users.
Now let's talk about RETRIEVE, DELETE, and ADD BACK.
Here too, only in scenario #3a this would be the correct solution. For this scenario it would accomplish exactly what was needed. When the add back gets done, the last level of the element in STG4 gets fetched back and the elements are now in sync, leaving no trace of the deleted element in STG3.
For the other scenarios on the other hand, RETRIEVE, DELETE and ADD BACK would have the same effect as using SYNC with one minor difference.
When adding back, Endevor fetches the last level of the element in STG4 and from then on the elements are synchronized, but as with the SYNC option, the element that was added back does not contain the changes that were made previously in STG4 and thus it will undo them.
The only correct solution is to retrieve the element from STG4, merge the changes of STG1with the ones from STG4 and then RETRIEVE, DELETE, ADD BACK, or simply add back and use the SYNC option to tell Endevor that you know what you're doing.
The merging process is greatly simplified when using the Endevor PDM function but with or without PDM, the programmer and in the end the approvers need to validate that in case of SYNC problems nobody accidentally removed any changes that were previously made.
Endevor Users need to remember that SYNC is a “sledgehammer” approach - using SYNC the programmer will basically say that his source is the best and does not care what changes were made before. SYNC will push this version of the element through to STG4 and nothing will stop it.
In most shops, the use of SYNC is very much restricted and under for good reasons under constant scrutiny.
The SYNC trace is a tool for administrators to understand why some more complex sync errors are indeed sync errors. The SYNC trace can be added to you just simply by adding these 2 DD statements:
If you think that a reported sync error is not an error, run the trace and if you still think Endevor is not detecting the sync error correctly then we invite you to contact the Endevor Technical Support Team.
Feedback
