So I tested a simple project (only a step that does an echo) using management console v 7.1.2.0-0-0341
with a 7.1.2.0-0-0016 agent and I got this message:

EXEC	Unable to set working directory to '/view/my_view/home/my_user' (2).

The step path is set to absolute and the server path is /home/my_user. If I change my server path to / I get this:

EXEC	Unable to set working directory to '/view/my_view' (2).

Any idea what could be happening?

To use a CC view for a step you must have two things:
1) CC View context
2) CC VOB context

The root of the view is read only on purpose by ClearCase. As such when using the CLEARCASE_VIEW variable it is usually also used in conjunction with the _CEARCASE_VOBS variable to automatically mount VOBs and start and set the view. That still leaves you with one final piece - the VOB context. This is typically accomplished by using an absolute step with the VOB tag as the step directory. Doing this will give you view context - from the CLEARCASE_VIEW variable - and VOB context from the step path. Assuming the user you are using for this step has access to CC then you should be able to run builds that way.


Hope this helps.

Or to be a little more detailed:
To start there are a few concepts that need to be understood:
The below applies to dynamic views only:
CC View: The CC view is similar in concept to a workspace in eclipse to a point. It uses something called a config spec to draw the list of versions for a particular repository - called a VOB - and present them to the user. The view itself is mounted in UNIX, or placed on a share on Windows. This area is called the view root. On Windows this is typically M:, and on Unix it is typically /view.

View context: Based on the previous data setting the view context not only requires the view root, but also the view tag which is also seen as a directory on the file system. Now lets say we have a view named temp_view. On a Windows system to say we have "view context" would mean our current directory is M:\temp_view. On UNIX we would say we have view context if the pwd is /view/temp_view. Normally one would manually CD to this location, however we will see later how BF can do this piece automatically for builds.

Starting\Stopping a view: In order to set view context for a view it must be started. If the view is not started it will not appear in the dir\ls listing of the view root, and the OS will prevent cd into that directory - as it does not exist until the view is started. This prompts us to also appreciate that the view must be started in order to set view context. This too BF can do for us automatically.

Snapshot View:
A snapshot view is a different animal entirely. We have an additional item here required vs. dynamic views - loading the data in. A dynamic view's power lies in the fact that once the view is made the data in the VOB, or source control, is immediately available. A snapshot view works much the same way as say an SVN checkout - you have to load the data objects up locally into the snapshot view root. This is a vastly different view root concept over a dynamic view. For one it is usually on the C: drive on Windows, or in the user's home directory on UNIX. There is no concept of "starting\stopping" the view - once made it exists much like a workspace for Eclipse. Instead of "starting\stopping" a snapshot view, you update it. BF does not manage, or handle this type of view automatically - end users have to code their steps around this need much like those using SVN or CVS.

VOBs:
VOBs, or versioned object base, are the repositories where versioned artifacts live. Not unlike the SVN repositories we use, however the difference here is you cannot ever access a VOB directly - you use views to peek inside them. The same premise as start\stop views applies to VOBs - for them to be accessible they must be started. This introduces a new concept - the view\VOB context. The view\VOB context is defined as the current working directory being the view root + view tag + VOB tag. For example using the temp_view example from above and a VOB named temp_VOB we would have a view\VOB context of:
M:\temp_view\temp_VOB on Windows
/view/temp_view/temp_VOB on UNIX

There again are variables used to "start" a VOB so it is accessible through BF automatically. There does not exist a variable which sets the full view\VOB context, only the view context. The reason for this is simply - one view can concurrently have access to 1...n VOBs. If we were to set the VOB context it would be too constricting. In general the step directory is used to set the VOB context, and the BF variables are used to set the view context. In this way the step starts in the full view\VOB context if that makes any sense.

From our help:
ccviewroot root-path
This setting specifies the default view root for this host. See ClearCase documentation on init for more information. The internal defaults are as follows:

* Windows: ccviewroot M:
* UNIX or Linux: ccviewroot /view

cc_suppress_server_root
If set, then the view path is the path set by ccviewroot. If not set, then the path set in the server definition is appended to the path set by ccviewroot. This setting does not need a value. If it is present in bfagent.conf, then it is set.

CLEARCASE_VIEW


Starts the specified ClearCase view. The view specified in this variable must exist, and the step using this variable must be set to "absolute". On systems running Microsoft Windows, this variable must be used with the cc_suppress_server_root configuration option for the agent in bfagent.conf.

_CLEARCASE_VIEWS


Specifies a list of ClearCase views to start before command execution. Set the value to a comma-separated list of views; for example, "View1,View2,View3".

_CLEARCASE_VOBS


Specifies a list of ClearCase VOBs to mount before command execution. Set the value to a comma-separated list of VOBs; for example, "\Vob1,\Vob2,\Vob3".


The basic CC integration relies upon both Agent side entries, and BF ENV variables for proper implementation. The agent side entries are largely for if the view root is different than the default, or a Windows machine.