• 2 replies
  • Latest Post - ‏2013-05-24T20:14:59Z by brcowan
Specialist CM
Specialist CM
8 Posts

Pinned topic VOB elements getting Corrupted often.

‏2013-05-21T14:11:25Z | clearcase elements


Our VOB is of size size 52GB, 10years old, mounted on Solaris OS and using by 400 Users. From the past One Year, we observed that VOB elements are keep on corrupting with "/000" or "text_file_delta" error. We are unable to do diff with predecessor version, not able to make Builds because of corrupted files. Even we are unable to count Source Lines of Code also. I forgot to mention that, we are using ClearCase ver.6.0.

Last 8 months back, we raised a PMR, IBM resolved some file elements using "checkvob" and by remotely accessing they used some IBM scripts to solve the issue. Finally, by the end of March. We and IBM Technical Support Engineers resolved all corrupted file elements issue. Recently, we observed that 2 (two) of the files got corrupted again and VOB is not in Sync with two of our replicas. Problem started again.

Please let me know, why VOB file elements corrupts often? Is it because of, if any user uses some third party tools for his Coding/Development in VOB? We CMs follow strict polocies, some of the file elements are not even loading into VOB (Snapshot views), saying "size got exceeded". This became a big mess for us. Now, Developers are making Builds by hijacking the files. We know that, this is not a Good Practise. Please someone of you can help us in this regard. PFA, VOB Errors. Thanks in advance!

Best Regards/Specialist.



  • stamaja
    8 Posts

    Re: VOB elements getting Corrupted often.


    Could it be that the "corruption" is really someone changing an Ascii file to UTF-8?  That could be the case if the "/000" is in the first byte of the file.

  • brcowan
    763 Posts

    Re: VOB elements getting Corrupted often.


    Looking at the error messages, I will say first that this issue is really oustide the scope of a forum post, I would recommend opening a PMR since this will take more than a few minutes to diagnose...

    Are you experiencing problems with element types OTHER THAN text_file elements? If so, what types?

    text_file elements have a single source container for the entire element, as a result, ANY operation that writes a container writes THE container for the element. Those operations are:

    • mkelem
    • mkbranch
    • checkin
    • rmbranch
    • rmver

    If you are getting repetitive corruption of these elements, I would recommend starting with taking an lshist of the problem elements. this will work because it does not need to parse the container to get the history information. It is usually the most recent of the above operations that corrupted the container. Since source containers are written to the VOB by the client performing the above operations, that would be where you would focus your investigations.

    To repair the existing containers, can be tricky, so that is a discussion best left to the PMR.