Here is the full exception:
CRVAP0087E (conflict): CCRC command 'Update' failed:
Unable to get contents of directory "E:\ccweb_views\akash.sharma\akash.sharma_AR_TAS_Release1_int_2\rainwater\src\TAS\codegenerator\pom.xml":
ClearCase object not found
Problems were encountered while retrieving view synchronization information and data.
It goes on with:
ClearCase CM Server: Error:
Unable to access "\rainwater\src\TAS\codegenerator\pom.xml": Permission denied.
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.realException(StpExceptionImpl.java:493)
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.<init>(StpExceptionImpl.java:572)
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.<init>(StpExceptionImpl.java:538)
at com.ibm.rational.stp.client.internal.cc.Util.ccrcCmdStatusToWvcmException(Util.java:155)
at com.ibm.rational.stp.client.internal.cc.Util.runCommandAndCheckResults(Util.java:107)
at com.ibm.rational.stp.client.internal.cc.WebViewRefresh.run(WebViewRefresh.java:151)
at com.ibm.rational.stp.client.internal.cc.CcFileImpl.doRefresh(CcFileImpl.java:240)
at Refresh_View.main(Refresh_View.java:65)
How would you troubleshoot that?
If there is some kind of permission issue, you need to check:
what user is actually executing the Java call?
What is its PRIMARY_CLEARCASE_GROUP (environment variable)?
(As you found out in your question "Java CM api for ClearCase throw exception", CLEARCASE_PRIMARY_GROUP cannot be used with the CCRC CLI or, I suspect, with the Java CM API)
You need to make sure that user has a main ClearCase group within the groups (primary or secondary) of the Vob 'rainwater'
If you are 100% sure the user is already in the correct group, fixprot might help.
Related
I am getting an error while checking out the file.
Error is: lock on VOB database "\EPAS prevents all write operations.
I tried to unlock the VOB but no luck.
Cleartool: Error: Object is not locked.
Cleartool: Error: Unable to unlock versioned object base "\EPAS_NF".
I even try to run the Protect VOB. still, the VOB is not working.
Please let me know how to unlock the VOB.
It can depend on your:
ClearCase version (an old one would have dbcheck for instance)
(a ClearCase 8 had issue on Vobs idle for too long)
ClearCase usage (a multiSite one can exhibit VOB communication issue)
(a multiSite migrated Vob can have lock issue)
Looking at the Windows Event viewer can help pinpoint the issue (a network communication of some sorts)
I have a vague recollection of seeing something like this come across as a tech support case. Ah, there it is... There were a number of other errors in your VOB server logs as I recall, including the \EPAS_NF or \EPAS VOB not being registered.
I am guessing that \EPAS_NF is an admin VOB to \EPAS, or vice versa. If you are checking out on a VOB where a given global brtype has never been instantiated, and the Admin VOB is locked, you will get an error stating that the admin VOB is locked.
This being said, I would make sure that the VOBs in question are currently fully and correctly registered and tagged, and that both databases are at least basically intact using dbcheck.
If you are getting an error message stating that the VOB is not consistently locked, it stands to reason that there is at least SOME database corruption, that should appear in a dbcheck or in a reformatvob.
The support case does not mention a timeline for the issue. And that may be key to knowing how you got into this mess... And in the case of corrupt databases, having some idea as to the cause would assist in knowing how practical database recovery will be.
I am getting below error while updating the view.
Problems were encountered while retrieving view synchronization and data.
Clearcase CM server error: Unable to access "vob name" : unknown error in vob
Clearcase CM server error: Error 2 config spec load rule problems encountered
How to troubleshoot that error message?
You need to access the logs (both locally or on the server) to know more.
It used to be cleartool getlog (ClearCase 7.x, even for CC 8.x)
cleartool: Error: Checkout is currently disabled for element "element_name".
Its config spec rule information is currently unavailable due to either an aborted update or an update in progress
That is similar to an older CC (7.0.x) described in this technote:
Possible cause for symptom 1:
If an update, rebase or deliver operation is not currently in progress for the view in question, the error can often be attributed to the view being out of sync with the stream.
Try:
cd /path/to/snapshot/view
cleartool setcs -stream
Possible cause for symptom 2:
Hijacked nocheckout means that the version hijacked in the view is no longer the version the config spec selects from the VOB.
Rename the hijacked file and update the view.
Check out the version from which the file was hijacked.
Copy the hijacked file over the checked-out version.
Merge from the current version to the checked-out version.
The version can now be checked in.
Possible cause for symptom 3:
Per the error message explanation noted above, the problem may be caused by an issue with the view's config spec or an aborted or incomplete view update.
Try:
cd /path/to/snapshot/view
cleartool setcs -current
(original answer)
It can be a right issue, as illustrated by this thread.
Check group permissions on user and on those two VOBs.
Do you rely on the CLEARCASE_PRIMARY_GROUP environment variable?
If so, check the value of the user performing the update.
Compare the rights of the vob with the ones for your current snapshot view that you are trying to update:
cd /path/to/snapshot/view
cleartool lsview -l -full -pro -cview
If the CLEARCASE_PRIMARY_GROUP is not set properly, it is easier to:
set it to the right group (ie the primary group of the vob, or one of the secondary groups)
delete and recreate your view.
(if you do not want to delete/recreate your view, you can fix_prot it)
I am getting strange error (see below) when I am trying to add/checkout/checkin a file/folder. I never used to get this error before. The only change is that this is the new UCM Project. Has anyone seen this error?
How would you troubleshoot that error message.
Here is the text version (for facilitating future text search)
CRMAP7018: Unable to create M:\user1_dev_cm_training_view\training\new_folder
CRMAP7026: unknown error.
reason: write-failed
resource: null
I have seen a similar error message when the CLEARCASE_PRIMARY_GROUP environment variable isn't properly set.
It should reference the primary group of the vob you are trying to access.
(in CTE - ClearTeam Explorer, Window -> Preferences -> IBM Rational ClearTeam Explorer -> Groups)
In your case, this is ClearTeam 8.0.0.6, the new name for CCRC, which supports dynamic views, and in an heterogeneous environment (Windows client, Unix server)
The first thing to check are the logs:
client logs for CTE
server logs for ClearCase server
System Event Viewer logs on the client side.
If nothing obvious seems to show up:
check if there is a process keeping an handle on M:\user1_dev_cm_training_view\training
(one way is simply to reboot and check if the issue persists)
check if the issue persists with another new dynamic view (and then with another account on another machine)
Check if a latest patch might resolve the issue (like a 8.0.0.7)
I don't see any mention of CRMAP7018 or CRMAP7026 on ibm.com.
I am receiving the below error when I am trying to edit the value of Proj_Mgr in UCM.
Please advise
no permission to perform operation "Make attribute" UCM
You must see an error like:
No permission to perform Make Attribute.
Must be one of: member of object group, object owner, VOB owner, member of admin group
So check your CLEARCASE_PRIMARY_GROUP environment variable, and compare it to the groups of the vob, or the associated pvob (in UCM).
You can see those by describing the vob:
cleartool descr -l vob:\myVob
As a possible cause, check out the IBM technote
"Problems that occur if the ClearCase Administrator group owns the VOB or VOB objects":
When a VOB or objects contained within a VOB (elements and metadata) are owned by the ClearCase Administrators group, this will most certainly result in permissions errors whenever an operation is performed against that object by a non-Admin user.
Since the administrators group by default has access to all ClearCase objects, it is not necessary to explicitly add that group and should be avoided.
You can see a concrete scenario where that error pops up in:
"Error setting the recommended baselines for this stream" (for a Stream though. In your case, you shouldn't have to reprotect the Vob, but rather make sure you have the right identity/group).
I used this command to solve this issue (a protection issue as described above):
ct protect -chgrp ccuser project
When I try to 'rebase' my stream in clear case, I get the 2 options : 'Resume rebase' and 'Undo rebase'.
But both of them give me errors. It seems a previous rebase failed and left the stream in a corrupted state.
How to solve this?
I tried stopping and starting ClearCase but no luck.
EDIT: the error is :
IDispatch error #14083
Execution of a hook failed during the action Complete. It was the ACTION_COMMIT hook attached to the UCMUtilityActivity "CR00155721".
The reason for the failure was:
Trouble communicating with VOB database: "\Alerts_Proj".
Check database log on VOB host "123yyyyy.com".
Could not perform requested operation: a UCM/ClearQuest data
inconsistency may exist:
ClearQuest "UCMUtilityActivity" record "CR00155721" is linked to a UCM object
that can not be found.
Unable to complete the rebase activity in ClearQuest.
Unable to undo set of integration activity.
Unable to complete integration.
FYI I've also seen this happen when the "CQIntSvr11.exe" fails. It seems to occur when you need to use the application on the same machine with different users (e.g. admin and developer account).
If you kill the process using task manager and then retry the operation the IDispatch 14083 should stop and then you can use your stream again.
One solution might be deactivating the trigger, but this could be put by the ClearCase-ClearQuest link and not be possible without severing completely that link.
So you can start by checking out this IBM technote with your ClearCase administrator:
This error occurs because the UCM project VOB and associated activities have been removed, ClearQuest is still looking for this information and needs this information to remove the defect.
This issue is the result the ClearCase items being removed before the ClearQuest defects and project.
Solution
To resolve this issue perform the following to fix the Activity so it can be deleted:
Browse to the ClearCase utils directory:
c:\program files\rational\clearcase\etc\utils
Run the following command from a command prompt:
Note: This command cannot be performed in the GUI
squid_patch <DBNAME> -activity ucm_vob_object ""
Note: It will display an advisory message, but it will change the field in ClearQuest.
Delete the ClearQuest record.
Remove the UCM project with the following command:
squid_patch <DBNAME> -project ucm_vob_object ""