Synchronization errors

Synchronizing after an error

After a synchronization is failed or blocked, correct the problem and run the synchronization again. The new synchronization starts from the last synchronized root (file or folder) that was successfully synchronized in the failed or blocked attempt.

Known issues and workarounds

• The ClearCase-Synchronized Streams view can sometimes report a synchronization success or a blocked synchronization before the Build Results have been updated. To work around this problem, right-click the stream and click Latest Synchronization Details. Refresh the build Summary page to update the synchronization status.
• Most synchronization failures or blocks occur because process controls in one repository reject a change made in the other repository. The message in the log from the ClearCase® trigger (if ClearCase rejected the change) or Engineering Workflow Management process (if IBM Engineering Workflow Management rejected the change) tells you what went wrong. Fix the problem, and run the synchronize operation again.
• ClearCase Synchronizer uses its own basename to identify the baseline that it creates. If the baseline template name is changed, synchronization will fail. For example, if the following command is issued to change the basename:

  cleartool chproj –blname_template

  then the following error is returned:

  cleartool: Error: The current baseline naming scheme for project "MyProject" does not accept a basename.

• Synchronization blocks can also be caused by network errors (failure to contact one repository or another), permissions errors (the synchronization process Engineering Workflow Management account does not have sufficient rights in the Engineering Workflow Management repository, or the synchronization process itself is running with credentials that do not allow access to the specified ClearCase stream), or both. The details of the error messages are different for different cases. Fix the problem, and then run the synchronize operation again.
• If a post-op checkout trigger fails, but the checkout was otherwise successful, the cleartool operations end successfully but issue errors to stderr. This means that a failed post-op trigger causes the synchronization to be blocked, even if the command that triggered the post-op trigger succeeded.
• When you change the Jazz Provider Properties of a ClearCase Synchronized stream, you might see a Save workspace failed message in the Team Advisor view. You can ignore the message.
• If you are having problems with the ClearCase dynamic view, you can try to fix them by creating a new ClearCase dynamic view for that ClearCase Synchronized stream. See Changing the ClearCase dynamic view.
• If you notice the following error in the sync log, then set MVFS to preserve case by navigating to Control Panel > ClearCase > MVFS and setting Case Insensitive MVFS and Case Preserving:

   javax.wvcm.WvcmException: Failure while trying to execute cleartool command: 
   cleartool checkout -nc M:/some_pathname 
   cleartool: Error: Pathname not found: "M:/some_pathname". 

• If you are using DB2 and synchronizing large trees (> 10,000 files), ensure that your LOGFILSIZ is at least 16384 or you might encounter error SQLCODE: -964, SQLSTATE: 57011 The transaction log for the database is full in Db2.
  You can verify this value by issuing the following commands where the user is db2inst1 and database name is jazz:

  • For UNIX/Linux platforms:

    su -db2inst1
    db2start
    db2 get database config for jazz | grep LOGFILSIZ

    IF you need to increase the value, enter the following command:

    db2 update database config for jazz using LOGFILSIZ 16384

  • For Windows platforms:

    db2cmd
    set Db2INSTANCE=db2inst1
    db2 get database config for jazz><outputfile>

    Find the value for LOGFILSIZ in the output file. If you need to increase this value, enter the following command:

    db2 update database config for jazz using LOGFILSIZ 16384

  In addition to increasing the LOGFILSIZ parameter, you can also increase the value for the primary and secondary logs. These values are specified by the following parameters:

  • LOGPRIMARY
  • LOGSECONDARY

  Note: Increasing the LOGPRIMARY value also increases the disk requirements for the logs because the primary log files are preallocated during the very first connection to the database. Each log file has a size equal to LOGFILSIZ. See the DB2 documentation for more information about these values.
• If the ClearCase Synchronizer reports a failure in the chbl -incremental command, which creates a baseline in the synchronized UCM stream, after having checked in changes to that UCM stream, then the following steps should be taken:
  1. Use cleartool to delete or rename the baseline and its associated label types. If this does not complete cleanly, contact IBM Support to resolve any issues.
  2. Once you have all traces of the baseline cleanly removed, run the previously failed chbl -incremental ... command from the command line. If this does not complete cleanly, contact IBM Support to resolve any issues.
  3. Once the chbl command runs cleanly, request the previously failed synchronization again. Incoming merge conflicts are likely to appear because the synchronizer treats the changes that it already made in ClearCase during the original synchronization attempt (which did not complete because of the baseline creation failure) as new incoming changes.
  4. To resolve any merge conflicts, complete one of the following actions:
     • If it is possible that changes have been delivered to the synchronization stream since the failed synchronization, use the standard synchronized stream merge to resolve conflicts. Most of the changes will be auto-resolvable as trivial; for ones that are not, resolve with "mine". Then deliver the results of the merge to the Engineering Workflow Management stream, and request another sync.
     • If you are certain that no changes have been delivered to the synchronized stream since the failed synchronization, you can use a simpler, but potentially slower resolution, to resolve conflicts:
       1. Use the select files to synchronize operation to remove the existing sync root
       2. Click OK (which will result in a fast sync)
       3. Add that sync root back (which will be a slow sync, because it checks all the files under that sync root).
• If you notice this error in the synchronization log, fix the issue in either ClearCase or Engineering Workflow Management, and then synchronize again:

  javax.wvcm.WvcmException: Cannot write to pathname because input version content has been deleted from provider_name

  The ClearCase Synchronizer cannot access files where the content is deleted. You can fix it by checking in new file content.