Troubleshooting
Problem
This technote outlines the possible causes why attempts to cat, type, copy or more an element version within an IBM® Rational® ClearCase® VOB results in the error []Incorrect function[].
Symptom
Attempts to cat, type, or more an element version results in the following error:
Incorrect function
The following errors may also be reported in the ClearCase logs:
- In the MVFS log:
fetch cleartext view=<view> vob=<vob> dbid=<dbid> - I/O error
see view log on host <host> for more info
- In the View Log:
Error: Unable to construct cleartext for object "<dbid>" in VOB "<VOB storage directory path>": error detected by ClearCase subsystem
Error: Type manager "<type manager>" failed construct_version operation.
Cause
In general, this problem is due to the view_server process not having read access on the source pools of the VOB storage directory. Below is a breakdown of the different causes.
The following list of possible causes should be evaluated and their solutions matched below to resolve the specific issue.
Cause 1
Misprotection of the element or the share permissions are incorrect for the VOB storage.
Cause 2
The ClearCase Atria Location Broker (ALBD) account on Microsoft® Windows® has been locked out after ClearCase is started on this system, which is generally due to the password change of the ALBD service account.
Cause 3
The ClearCase server process account (clearcase_albd by default) is mapped to the wrong UNIX® or Linux® account (Samba® or TAS® configurations only).
Similar behavior will result from improper interop account setup for Windows users accessing UNIX (or Linux) VOBs.
Cause 4
The Windows System variables for TEMP and TMP are not defined.
Cause 5
This issue could also be caused by a corrupt source container. This has been seen to occur following a power outage.
Cause 6
This has been seen to occur when two views were pointing to the same global path where an attempt to copy an element from one of the views reports the error.
An "rgy_check -views" command will show the two different views with different tags but pointing to the *same* global_path. One of these views may be the one from which the error is reported.
Diagnosing The Problem
Review the ClearCase Command Reference Guide on the topic of mkeltype (cleartool man mkeltype) for more information regarding the element types defined by ClearCase.
Review the ClearCase Command Reference Guide on the topic of type manager (cleartool man type managers) for more information.
Resolving The Problem
The following solutions correlate to the causes above.
Solution 1
- Reprotect the element with the cleartool protect -chown -chgrp -chmod command; refer to technote 1211784 that discusses protection commands and utilities used with ClearCase.
- Check the share permissions at the operating system level and make sure the user (on UNIX and Linux) or the albd account/group (on Windows) has read and write privileges; consult your system administrator or operating system manuals for assistance on adjusting directory permissions.
Solution 2
Your network administrator will have the appropriate access to the domain controller to reset the ALBD account.
Since the albd service starts automatically (on each host that it is installed on) it may be necessary to track down which computer has the service set up with the incorrect password to prevent that account from becoming locked out again.
For information on changing the ALBD password, refer to technote 1146207.
Solution 3
Confirm that the interop configuration is correct, refer to technote 1142762 for guidance.
Solution 4
Set the TEMP and TMP variables as System variables and confirm the path to which they resolve is valid and writable:
Note: These variables must be system variables, not just user variables, because some of the Rational ClearCase processes, such as the Credentials Manager and the Lock Manager, run as LocalSystem account and use these variables:
Solution 5
If source container corruption has been confirmed (contact IBM Client Support if help is needed), refer to the following technotes for details about replacing the source container:
Technote 1221900 Replacing a source container in a replicated VOB from a container in a sibling replica
Technote 1221899 Replacing a source container from backup in a replicated VOB
Technote 1226698 Replacing a source container from backup in a non-replicated VOB
Solution 6
You can fix this inconsistency by running the command ct mktag -view -tag <right_tag> -repl -host <h> -gpath <right_global_path>, so that each view has its own .vws folder.
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21126427