understand about text modes (msdostext_mode)

Text Modes and Changes to the VOB
All new VOBs created in 2002.05.00 and later will be MSDOS enabled by default.

Note: For versions before 2002.05.00, running msdostext_mode on a VOB makes a change to the VOB database, which lets the VOB database store both the UNIX and MSDOS file lengths (sizes) for any given version of an element.

Running msdostext_mode does not create additional source containers, but will result in additional cleartext generation for the alternate text mode.

Text Modes and Individual Elements
To check if a particular element version has been converted for msdostext_mode, use the "cleartool dump " command. Under heading "stored fstat", there is an entry for "mode". If mode is set to "00", then the version has NOT been converted with the msdostext_mode utility. If mode has a value other than "00", the version has been converted.

Example (not converted):
stored fstat:
ino: 0; type: 1; mode: 00; uid: 4294967294; gid: 4294967294
^^

Example (converted):
stored fstat:
ino: 0; type: 1; mode: 021; uid: 4294967294; gid: 4294967294
^^^

Text Mode and Views
To determine the mode of a view, use the "cleartool lsview -properties -full ".

Transparent text mode is displayed as unix, strip_cr text mode is displayed as strip_cr, and insert_cr text mode is displayed as msdos.

Examples:
%>cleartool lsview -prop -full strip_cr
strip_cr \\kis2\ccstg_e\views\KIS2\jdoe\strip_cr.vws
^^^
Text mode: strip_cr
^^^

%>cleartool lsview -prop -full insert_cr
insert_cr \\kis2\ccstg_e\views\KIS2\jdoe\insert_cr.vws
^^^
Text mode: msdos
^^^

%>cleartool lsview -prop -full transparent
non-share-do \\kis2\ccstg_e\views\KIS2\jdoe\transparent.vws
^^^
Text mode: unix
^^^

Alternatively, you can view the contents of the ".view" file in the view storage directory. For transparent mode views, there will be nothing indicated about text modes. For insert_cr mode views, there will be a line that reads "-textmode msdos". For strip_cr mode views, there will be a line that reads "-textmode strip_cr".

Text Mode and Cleartext
Cleartext created for an insert_cr mode (msdostext_mode) view will have an ".msdos" extension at the end of the cleartext file name.

In a dynamic view you can use the "mvfsstorage " or use the "cleartool dump " to view the cleartext container.

Tips on Troubleshooting
If you have problems with file truncation or file contents when using text mode views there are some basic troubleshooting techniques you can use.

Note the following example of using UNIX and DOS mode views to access an element.

1. Make sure the text mode for the view is the intended one (using the steps above).

2. Verify that the VOB has been msdostext_mode enabled and that the file version in question has been converted.

3. Make sure the view text mode matches the type of editor being used.

4. Check the type of machine the file is being accessed from (Windows or UNIX).

For example, if the answers to the above were:

1. -textmode msdos
2. Yes and yes
3. Notepad
4. Windows

Then the file should look correct. In other words, the correct mode of the view being used.

If the answers are:

1. -textmode msdos
2. Yes and yes
3. Emacs
4. UNIX

Then the file will NOT look correct since Emacs is a UNIX-based editor. So, in this case, the correct version of the cleartext is not being presented to the editor due to the mode of the view being used.

If the answers are:

1. Nothing relating to tmode
2. No and no.
3. Emacs
4. UNIX

Then the file should look correct. In other words, the correct version of the cleartext is being presented to the editor based on the mode of the view being used.

copy file versions from ClearCase using cleartool find on UNIX or Linux

You can copy certain versions out of your view to the local filesystem using command line operations.

If the element version that you want to copy is selected by the view's config spec, then the copy can be completed using the operating system (OS) copy command.

Here is the syntax using the OS copy command:

cp

However, if the version of interest is not selected by the config spec, then you will need to construct a cleartool find syntax as the find command is not limited by the view's config spec.

Using cleartool find will allow you to copy files that are not selected by the view you are using.

Note: The source version must be selected by its version extended pathname.

The copy operation will need to rename the version extended pathname to the original element name, because the OS copy command considers the last part of the version extended pathname to be the element's true name.

Example:

%>cp file.txt@@/main/3 /export/home/user/file.txt

Note the rename from file.txt@@/main/3 to file.txt

%>cd /export/home/user

%>ls
file.txt

For the copy to work correctly on the versions that are not selected by your view, you need to copy the files using the environment variable (EV), CLEARCASE_XPN.

To counteract the OS copy behavior of preserving the version extended pathname, you can use CLEARCASE_PN to strip the leaf name of the element version, which will capture the correct target.

The following find command example will locate the file and specific version in the VOB and copy it to your location of choice:

Example:

cleartool find . -exec 'cp -p $CLEARCASE_XPN /tmp/$CLEARCASE_PN'

CAUTION: You will see unexpected results if running this find command from a snapshot view because of a known behavior difference with how snapshot view render path delivered by the CLEARCASE_XPN variable versus how dynamic views render the paths.

A snapshot view will provide a path which is will contain the snapshot view path followed by the VOB tag path followed by the actual filename and path below the VOB tag root.

A dynamic view will provide will simply show the VOB path followed by the actual filename and path below the VOB tag root.

Example:

Snapshot View Output from CLEARCASE_XPN

/export/home/snapshots/view_1/vobs/vob1/dir1/file

is returned from a snapshot view instead of...

Dynamic View Output from CLEARCASE_XPN

/vobs/vob1/dir1/file

copy all view private files and Derived objects between views

In order to move all view private files from one view to another, the following types of files must be moved or copied:

o Derived Objects (Dynamic views only)

o View-private copies of checked-out elements

o "Other" view private files

Derived Objects

The best method to move Derived Objects from one dynamic view to another is to promote the DO's from the old view to the VOB and then wink the DO into the new view.

The process is as follows:

1. Start and or set to the old view
Note: Ensure all VOBs referenced by this view are mounted; otherwise, you will receive VOB not Mounted... errors during steps 2 and 3 below.

2. Run the following command to create a list of all DO's in this view for later use. This list is relative to the root of the view, taking the rest of this procedure possible with a minimum of editing required.

3. Windows:
cleartool lsprivate -do > c:\dolist.txt

UNIX/Linux:
cleartool lsprivate -do > ~/dolist.txt

4. Run cleartool lsprivate -do | view_scrubber -p

This promotes ALL DOs to the VOB.

Another method to use involves winking the files into the new view.

Note: This is strictly optional since any wink-ins needed will be accomplished during the next clearmake or omake build.

1. Start and or set to the old view

2. Run the following command to wink in all DOs created in the initial view:

Windows:
for /F "delims==" %x in (C:\dolist.txt) do cleartool winkin "%x"

UNIX/Linux:
cat ~dolist.txt | xargs -i cleartool winkin {}

VIEW-PRIVATE FILES

There are 2 remaining types of view private files. View-private copies of checked-out files and "other" view private files.

The best means to save the checked-out files is to check those files back in. This is by far the best way to save work in progress.

If, on the other hand, you are working in a shared branch or UCM stream, and checking could impact your colleague's work, run the following commands to undo all checkouts, keeping the checked-out files as view private files with .keep extensions.

1. CD into the old view.

2. CD into each VOB and run this command:

Windows:
for /F %x in ('cleartool lsco -all -cview') do cleartool unco -keep "%x"

UNIX/Linux:
cleartool lsco -all -cview | xargs -i cleartool unco -keep {}

Saving other view private files can be done any number of ways. You can either copy them manually, or use a third-party archive utility to move the files.

On Windows, the process for saving other view private files without using third party tools is:

1. Ensure that a drive is mapped to both the old and new views.

2. CD or set into the old view.

3. Run the following command to list all remaining view private objects:

for /D %x in (*.*) do cleartool ls -view_only -recurse %x >C:\rest.txt

One option to avoid ".contrib" files created by merge operations (including UCM delivers and merges) is to filter the output in as illustrated below:

cleartool ls -view_only -recurse| find /V ".contrib > C:\Otherlist.txt"

This will filter out all files that contain the string ".contrib" in their names, potentially narrowing the list of files to review considerably.

4. Edit the file list to include only files you wish to copy, save it as "Filteredlist.txt".

5. Run this command to copy the desired files from the old view to the new one (If X: is the old view and Y: is the new one):

for /F "delims==" %a in (C:\FilteredList.txt) do copy "X:%a" "Y:%a"

On Windows, this operation can be dramatically simplified through the use of third-party archive tools.

For example, the same procedure using the Info-Zip third party toolkit can be done as follows:

1. CD into the old view.

2. Run the following command:

for /D %x in (*.*) do cleartool ls -view_only -recurse %x | zip -m -@ c:\tempzip.zip

3. CD into the new view

4. Run the following command:

unzip c:\tempzip.zip

On UNIX, however, archiving all the view-private files in a view can be condensed to a single command line.

That command line is:

tar cvf ~/myfiles.tar `cd /vobs;ls -1|xargs -i cleartool ls -view_only -recurse {}`

To reverse this process in UNIX , set into the new view and run the below command line:

cd /vobs;tar xvf ~/myfiles.tar

onfigure a time-out session for idle views

CONFIGURE VIEW SERVER PROCESS TIMEOUT PERIOD

A new feature was introduced in the following patches that allocates a time-out period for view server processes whereby they terminate themselves automatically.

Snapshot Views Only

The new feature was introduced with SNAPSHOT VIEWS ONLY in the following releases:

2003.06.00
clearcase_p2003.06.00-14	Full ClearCase UNIX
Service Release 4	Full ClearCase & CCLT Windows
clearcase_lt_p2003.06.00-10	CCLT UNIX

2002.05.00
clearcase_p2002.05.00-40	Full ClearCase UNIX
clearcase_p2002.05.00.NT-34	Full ClearCase Windows
clearcase_p2002.05.00-19	CCLT UNIX
clearcase_lt_p2002.05.00.NT-13	CCLT Windows

Dynamic Views:
The new feature was expanded to include dynamic views in ClearCase version 7.0.


INSTRUCTIONS:

To extend or shorten the time-out session, set the CCASE_VIEW_IDLE_THRESH variable to the appropriate number of seconds.

Note: The default (and minimum) time-out for the snapshot view server processes using the variable is 2 hours and 10 minutes (7800 seconds).

Setting the CCASE_VIEW_IDLE_THRESH to 0 (zero) turns off the time-out session (i.e., snapshot views never go idle.)

The following formula can be used to assist in calculating the number of seconds:

(h * 60 * 60) + (m * 60) = total seconds

Where h = hours and m = minutes.

Example: To calculate a 3 hour and 15 minute time-out value in seconds.

3 * 60 * 60 = 10800
15 * 60 = 900

10800 + 900 = 11700 seconds

The environment variable can be set on Windows as a system EV and on UNIX or Linux can be applied by editing the startup script (ccase-home-dir/etc/clearcase or ccase-home-dir/bin/atria_start) to control the idle time-out.

Note: After the time out period has elapsed, running cleartool lsview may still show the dynamic view as active (an * will precede the name) or running cleartool lsview -long will show active flag set to YES. This "active" status does not refer to the state of the server process. It refers to having an open "handle" in the MVFS, local to the machine running lsview.

• On Windows you can run albd_list to verify that the view does not have an active process id (as the view will not appear in the list returned).
• On UNIX and Linux you run ps -elf | grep to see that there is no process that is running.

MANUALLY

If you don't have the above patches installed to better manage this behavior, you need to end the view server process. From the command line, run the cleartool endview -server command to stop the view server process after you have exited the view or are finished using it.

If running this command manually is not a viable option, consider creating a script to automate the job (see UNIX or Linux reference below for an example). There is no known script to use on Windows currently.

SCRIPT EXAMPLE (UNIX or Linux):

Here is an optional script that can be run on UNIX or Linux:

1. Create a shell script (in this example the script is named "quit") and make it executable.

=============
#! /usr/bin/sh
# this script is called "quit"

cleartool pwv -short |xargs cleartool endview -server
exit
=============

2. When exiting the view shell on UNIX or Linux, run "quit" instead of "exit" and the process will be terminated.

understand about the Active flag for dynamic and shapshot views

ClearCase checks the viewroot directory, typically /view on UNIX® and Linux® and the MVFS drive (by default M:\) on Microsoft® Windows®, for the presence of a view tag to report the Active state.

DYNAMIC VIEWS

Dynamic view tags are activated and made visible within the viewroot directory by starting the view using either the cleartool startview (Windows) or cleartool setview (UNIX/Linux) commands.

If the view tag is present in the viewroot directory, then the view's ACTIVE state is set to YES.

A dynamic view, will correctly display if that view is active or not.

Note: The * indicates the dynamic view is started.
C:\>cleartool lsview
* dynamic_view \\Host\ccstg_c\views\dynamic_view.vws
snapshot_view \\Host\ccstg_c\views\snapshot_view.vws
dynamic_view2 \\Host\ccstg_c\views\dynamic_view2.vws

C:\>cleartool lsview -long dynamic_view
Tag: dynamic_view
Global path: \\Host\ccstg_c\views\dynamic_view.vws
Server host: Host
Region: windows
Active: YES
View tag uuid:cd20acf1.f1cd4915.adde.65:03:52:0d:4f:26
View on host: Host
View server access path: c:\ClearCase_Storage\views\dynamic_view.vws
View uuid: cd20acf1.f1cd4915.adde.65:03:52:0d:4f:26
View owner: jdoe

C:\>cleartool lsview -long dynamic_view2
Tag: dynamic_view2
Global path: \\Host\ccstg_c\views\dynamic_view2.vws
Server host: Host
Region: windows
Active: NO
View tag uuid:25244aac.2a2148bd.9ca2.e4:1c:f4:bc:af:2e
View on host: Host
View server access path: c:\ClearCase_Storage\views\dynamic_view2.vws
View uuid: 25244aac.2a2148bd.9ca2.e4:1c:f4:bc:af:2e
View owner: jdoe

SNAPSHOT VIEWS

Snapshot views cannot be activated using the startview or setview command; therefore, a snapshot view tag is never made active in the viewroot directory.

So based on how ClearCase checks the active state of a view, a snapshot view will always show the status as inactive (Active: NO) even if a corresponding view server process is running for that view.

C:\>cleartool lsview -long snapshot_view
Tag: snapshot_view
Global path: \\Host\ccstg_c\views\snapshot_view.vws
Server host: Host
Region: windows
Active: NO
View tag uuid:0b5c58e8.0d7243c9.81db.1c:d5:1b:e5:8e:2f
View on host: Host
View server access path: c:\ClearCase_Storage\views\snapshot_view.vws
View uuid: 0b5c58e8.0d7243c9.81db.1c:d5:1b:e5:8e:2f
View attributes: snapshot
View owner: jdoe

understand about the .specdev file in /view directory

The .specdev file is a character special device file. It is used for all client communication, like cleartool, clearmake, clearaudit, and other ClearCase commands and processes.

If this file is not present, errors such as the following may occur:

cleartool: error: Unable to create directory <>: not a clearcase object.

RECREATE FILE

To recreate a missing .specdev file, cd to the /view directory and issue the following commands as root:

1. mknod .specdev c 0 0x000000

2. chmod 444 .specdev

3. chown root:root .specdev

Note: More information on special devices can be found by running man ioctl.

understand about View Profiles

About View Profiles
Base ClearCase includes a set of deprecated features called view profiles, which you can use to automate much of the work flow required to set up and maintain your team’s shared ClearCase configuration.

• The view profile feature set only exists on Microsoft Windows.
• There are no equivalent features for view profiles on UNIX® or Linux®.
• The view profile feature set does not exist on ClearCase LT® (CCLT).

Note: The Unified Change Management (UCM) process provides a more complete solution for organizing software development teams and has replaced all of the view profile functionality. Review Appendix A in the Managing Software Projects guide for information on moving from view profiles to UCM.

Enabling View Profiles
The first thing that needs to be established is the share to which the view profiles will be stored for all clients to use. The Windows share must be accessible to all ClearCase users.

Once the share is created, you can activate View Profiles on the clients.

1. Open the ClearCase Properties control panel applet (Click Start > Run type cc.cpl)

2. Click on the Options tab.

3. Check the Use view profiles for creating views radio button

4. Enter the path the Windows share where the view profiles will be stored.

5. Click OK

Creating View Profiles

1. Open the View Profile Explorer to create and work with the view profiles.



You can access the View Profile Explorer as follows:

· Start > Run type clearprojtool
Note: This command only works if View Profiles are enabled in the ClearCase control panel applet.

· From the GUI through the ClearCase Home Base on the Branches tab



Note: Prior to enabling View Profiles, if you used the ClearCase Home Base GUI, you may have noticed that there was not a Branches tab and if there was, only the Merge Manager appeared. After enabling View Profiles, there will be new options available.

Example before View Profiles were enabled:

Once the View Profile Explorer is open, create a view profile.




Fill in the fields for Step 1 and click Next




Select the VOB to be worked on for the project along with any related AdminVOB and click Next




Choose the branching strategy to deploy. Click Next

Note: This example will work on a branch other than main.




Choose the baseline label (checkpoint) to start from and click Next

Note: The project needs to be set up prior to configuring the view profile that includes a labeled set of elements to start from. In this example, the INITIAL label has been applied within the VOB \import.




Use an existing branch or create a new branch type to represent the shared location (integration branch) for the profile to merge to and click Next




Update the diagram (if needed) which helps represents the work flow of the view profile (visually). When complete, click Next

Example modification:

Click Tool Palette

Review the specifications of the view profile (including the config spec) and click Finish

Note: To see how to predefine load rules for snapshot views review technote 1248095 for more details.

You will now see the first (of many) View Profiles in the list

Using View Profiles

Everything else you need to know about View Profiles can be found in the on-line Help

Click Help > Using View Profile Explorer

FAQs

· Why can't the config_spec for a view be edited when the view is associated with a view profile?

This is by design. The only changes permitted fall in the middle of the config spec, as identified below:

# [CC_PROJECT - ClearCase View Profile Information
# Name - \ClearCase View Profiles\integ_branch
# ID - c44d6ae3-4b77-25f7-8ba8-1235e1474da 0.2
#
element * CHECKEDOUT
#
# Any modifications to this config spec should
# be made following this comment.
# CC_PROJECT]

<-------In this section you can add additional rules

# [CC_PROJECT - View Profile Config Spec
# Do not directly modify the text below, it has been
# automatically generated by the ClearCase View Profile Tool.

element * ...\integration\LATEST
element * REL1 -mkbranch integration
element * \main\0 -mkbranch integration
# CC_PROJECT]

·

Why do I see the following error starting my view?

Unable to perform view start-up operations related to the "view_tag" view's
ClearCase View Profile association.
Error 0x3e9 trying to mount VOB"\vob_tag"

The error is generated because the VOB that was removed is referenced in the view profile. Open the View Profile Explorer and edit the associated view profile and remove the VOB from the current VOB list.