catcr

Displays configuration record created by clearmake, omake, or clearaudit

APPLICABILITY

ClearCase (cleartool subcommand), Attache (command)

SYNOPSIS

catcr [ -r·ecurse | -fla·t | -uni·on | -che·ck [ -uni·on ] | -mak·efile ]

[ -sel·ect do-leaf-pattern ] [ -ci ] [ -typ·e { f | d | l } ... ]
[ -ele·ment_only ] [ -vie·w_only ] [ -cri·tical_only ] [ -nam·e tail-pattern ]
[ -zer·o ] [ -wd ] [ -nxn·ame ] [ -l·ong | -s·hort ] do-pname ...

DESCRIPTION

The catcr command displays the configuration records (CRs) for the specified derived objects (DOs) and, optionally, for their build dependencies. The ClearCase make tool (clearmake or omake) creates a CR each time it executes a build script that creates one or more DOs.

NOTE: ClearCase creates configuration records for dynamic views only.

For more information about configuration records and derived objects, see Derived Objects and Configuration Records in Building Software with ClearCase.

CRs and clearaudit

The clearaudit utility produces a CR when it exits. In this case, the build consists of all commands executed in the audited shell.

Controlling the Report

catcr allows precise control over report contents and format. It includes input and output filters and supports a variety of report styles. Input filters, such as -select, control which DOs are visited. All visited DOs can potentially appear in the final listing. Output filters, such as -view_only, control which DOs actually appear in the final listing. Often, this is a subset of all visited DOs.

You can tailor the report in several ways:

The -check option determines whether the CR contains any unusual entries. For example, it determines whether the CR contains multiple versions of the same element, or multiple references to the same element with different names.

By default, catcr suppresses a CR entirely if the specified filters remove all objects (useful for searching). With the -zero option, the listing includes the headers of such CRs.

DOs in Unavailable Views

catcr maintains a cache of tags of inaccessible views. For each view-tag, the command records the time of the first unsuccessful contact. Before trying to access a view, the command checks the cache. If the view's tag is not listed in the cache, the command tries to contact the view. If the view's tag is listed in the cache, the command compares the time elapsed since the last attempt with the time-out period specified by the CCASE_DNVW_RETRY environment variable. If the elapsed time is greater than the time-out period, the command removes the view-tag from the cache and tries to contact the view again.

The default time-out period is 60 minutes. To specify a different time-out period, set CCASE_DNVW_RETRY to another integer value (representing minutes). To disable the cache, set CCASE_DNVW_RETRY to 0.

PERMISSIONS AND LOCKS

Permissions Checking: No special permissions required. Locks: No locks apply.

OPTIONS AND ARGUMENTS

REPORTING ON DERIVED-OBJECT SUBTARGETS.  Default: catcr lists the derived-object subtargets used to build do-pname, but it does not examine or display subtarget CRs. The -recurse, -flat, -union, -check, and -makefile options direct catcr to recurse into subtarget CRs. Use -select to isolate the CRs of one or more subtargets; use -ci to examine the CRs of pre-built, checked-in DO versions.

-r·ecurse

Displays the CRs of any derived objects that are subtargets of do-pname. Each CR is displayed separately.
-fla·t

Similar to -recurse, but consolidates the CRs into a single list of versions and derived objects, with no duplicate entries. -flat produces one report for each do-pname on the command line. The report includes file-system objects only; no headers, variables and options, or build scripts. A number preceding each filename indicates the total number of times it was referenced during the build.
-uni·on

Produces one report for all derived objects on the command line. Like -flat, it consolidates the CRs of each do-pname and its subtargets into a single list of objects, with no duplicate entries. It then combines the separate lists into a single report with no duplicates. The report includes file-system objects only-no headers, variables and options, or build scripts are included.
-che·ck [ -uni·on ]

Flags entries in the CR that have unusual characteristics. It may optionally be specified with -union. This option determines whether a CR contains any of the following:

  • Versions that are not currently checked in. This includes versions that no longer exist (an intermediate version that only existed as a view-private file, for example), versions that are currently checked out, and versions that were explicitly removed with the rmver command.
  • Multiple versions of the same element. This can occur, for example, if a build used multiple libraries, which were built from different source versions.
  • Multiple references to the same element with different names, such as a renamed element in different directory versions.
-mak·efile

Similar to -recurse, but displays the CR in simple makefile format. The listing includes the dependencies and build script for each of the derived object's subtargets. Always include the -wd option with -makefile; this causes catcr to list pathnames with respect to the initial working directory of the build. (Note that this differs from the standard behavior of -wd). If you fail to include -wd, cleartool displays a warning message, and then displays the makefile without modifying dependency pathnames.
-sel·ect do-leaf-pattern

Starts the listing at the subtarget of do-pname that match the specified pattern. do-leaf-pattern can be a pattern (see the wildcards_ccase (ClearCase) or wildcards (Attache) reference page) that matches a simple file-name; it must not include a slash character (\) or the ellipsis wildcard ( ... ). Alternatively, it can be a standard pathname of a derived object.
This option is useful for isolating a derived object that was built as a dependency of another one. For example, this command displays the CR of the derived object named hello.obj that was used to build hello.exe in the current view:
cmd-context catcr -select hello.obj hello.exe
-ci (for use in recursive listings only)

By default, recursive listings do not display CRs for DO versions. This option displays the CRs for DO versions. -ci only has effect with -recurse, -flat, -union, and -makefile.

SPECIFYING KINDS OF OBJECTS TO DISPLAY.  Default: catcr reports on all objects in the CR, which may include source files, directories, and symbolic links; derived objects; makefiles; view-private files; and non-MVFS objects that were explicitly declared as dependencies.

-typ·e { f | d | l } ...

Restricts the listing to files only (f), or to directories only (d), or to links only (l). If you omit -type, a -short listing includes files only and a -long listing includes all three kinds. To specify multiple kinds of objects, group them into a single argument: -type fd.
-ele·ment_only

Lists versions of elements only, including checked-out versions. This option excludes from the listing derived objects (except DO versions), view-private files and directories, symbolic links, and non-MVFS objects.
NOTE: If a view-private file listed in the CR is converted to an element after the creation of the CR, and has at least one checked-in version, it is considered to be an element and is listed by -element_only.
-vie·w_only

Lists view-private objects only, including checked-out versions of elements. If you specify this option along with -element_only, the listing includes only checked-out versions of elements.
-cri·tical_only

Excludes from the listing any objects marked as "noncritical" in the CR. Objects with that property typically have it because the user specified the objects as dependents of the .NO_DO_FOR_SIBLING special target in a clearmake makefile, or as dependents of the .NODO_FOR_SIBLING special target in an omake makefile.
-nam·e tail-pattern

Restricts the MVFS objects listing to those whose final pathname component match the specified pattern. tail-pattern can include any of the wildcard characters described in the wildcards_ccase (ClearCase) or wildcards (Attache) reference page.

CONTROLLING REPORT APPEARANCE.  Default: catcr reports, in three sections, on MVFS objects, variables and options, and the build script. The report uses full pathnames, and it omits comments and directory versions.

-zer·o

Includes the CR header and options section, even if the specified filters remove all objects. The listing includes the target name, current view, and so on, but no information on particular file-system objects.
-wd

Lists pathnames relative to the current working directory, rather than full pathnames. With -makefile, displays pathnames relative to the initial working directory of the build.
-nxn·ame

Lists simple pathnames for MVFS objects, rather than version-extended pathnames or DO-IDs.
-l·ong

Expands the listing to include the kinds of objects in the CR and comments. With -makefile, adds comments only. For example, an object may be listed as a version, a directory version, or derived object. (See ls -long for a complete list.) Comments indicate whether an object is in makefile, a referenced derived object, or a new derived object.
-s·hort

Restricts the listing to file-system objects only (omits header information, variables and options, and build scripts). With -makefile, the listing also includes build scripts.

SPECIFYING THE DERIVED OBJECT.  Default: None.

do-pname ...

One or more pathnames, specifying the derived objects whose CRs are to be included in the listing. A standard or view-extended pathname specifies the DO in the view. An extended pathname with a DO-ID specifies a particular DO, irrespective of view (for example, hello.obj@@24-Mar.11:32.412).
Use the lsdo command to list derived objects with their DO-IDs.
do-pname can be a DO version, specified with any version-specification method (standard pathname, version-extended pathname, and so on).

EXAMPLES

Examples including wildcards or quoting are written for use in cleartool interactive mode. If you use cleartool single-command mode, you may need to change the wildcards and quoting to make your command interpreter process the command appropriately.

In cleartool single-command mode, cmd-context represents the command interpreter prompt. In cleartool interactive mode, cmd-context represents the interactive cleartool prompt. In Attache, cmd-context represents the workspace prompt.

NOTE: Most examples show the same CR processed with different options. Some output lines have been split for clarity.

cmd-context catcr bgrs.exe

Target bgrs.exe built by jones.dvt
Host "oxygen" running NT 3.51 (i486)
Reference Time 11-Dec-94.12:02:39, this audit started 11-Dec-94.12:04:52
View was oxygen:C:\USERS\jones\views\940615.vws
Initial working directory was Y:\vob1\docaux\bgr
----------------------------

MVFS objects:
----------------------------
\vob1\docaux\bgr\libbgr\libbgr.lib@@10-Dec.16:45.1893
\vob1\docaux\bgr\bgrs@@11-Dec.12:05.1956
\vob1\docaux\bgr\buga@@11-Dec.12:04.1926
.
.
.

\vob1\docaux\bgr\bugs.obj@@11-Dec.12:03.1902
\vob1\docaux\bgr\bugsched.obj@@11-Dec.12:04.1953
.
.
.
----------------------------
Build Script:
----------------------------
link /out:bgrs.exe main.obj pick.obj bugs.obj bugr.obj bugi.obj bugf.obj bugc.obj bugl.obj buge.obj bugd.obj buga.obj bugh.obj bugw.obj bugfld.obj bugdt.obj bugu1.obj bugu2.obj bugsched.obj ..\libbgr\libbgr.lib
----------------------------

cmd-context catcr -flat bgrs.exe

----------------------------
MVFS objects:
----------------------------
1 \vob1\docaux\bgr\buga.c@@\main\1 <19-Dec-94.11:49:03>
1 \vob1\docaux\bgr\bugc.c@@\main\1 <19-Dec-94.11:49:09>
1 \vob1\docaux\bgr\bugd.c@@\main\1 <19-Dec-94.11:49:14>
20 \vob1\docaux\bgr\bugs.h@@\main\3 <17-Jun-94.23:55:22>
1 \vob1\docaux\bgr\bugsched.c@@\main\1 <19-Dec-94.11:50:07>
.
.
.

 2 \vob1\docaux\bgr\bugw.obj@@11-Dec.12:04.1932
 2 \vob1\docaux\bgr\main.obj@@11-Dec.12:03.1896

The integer at the beginning of an entry indicates the number of times the object was referenced during the build. For example, \vob1\docaux\bgr\bugs.h was referenced 20 times.

cmd-context catcr -select bugsched.o -element_only bgrs.exe

Target bugsched.o built by akp.user
Host "oxygen" running NT 3.51 (i486)
Reference Time 11-Dec-94.15:23:21, this audit started 11-Dec-.94.15:23:39
View was oxygen:\users\people\akp\views\940615.vws
Initial working directory was J:\vob1\docaux\bgr

----------------------------
MVFS objects:
----------------------------
\vob1\docaux\bgr\bugs.h@@\main\3 <17-Jun-94.23:55:22>
\vob1\docaux\bgr\bugsched.c@@\main\2 <11-Dec-94.15:23:04>
\vob1\docaux\bgr\libbgr\stint.h@@\main\2 <08-Sep-94.10:06:04>

----------------------------
Build Script:
----------------------------
del -f bugsched.obj ; cl /c /I ..\libbgr -DBSD -DSCCS /Zi ..\bugsched.c
----------------------------

cmd-context catcr -name '*.h' bgrs.exe

----------------------------
MVFS objects:
----------------------------
20 \vob1\docaux\bgr\bugs.h@@\main\3 <17-Jun-94.23:55:22>
19 \vob1\docaux\bgr\libbgr\intstint.h@@\main\1 <19-Dec-94.11:54:50>
36 \vob1\docaux\bgr\libbgr\stint.h@@\main\2 <08-Sep-94.10:06:04>
1 \vob1\docaux\bgr\spar.h@@\main\1 <19-Dec-94.11:50:42>

SEE ALSO

clearaudit, clearmake, config_spec, diffcr, ls, lsdo, rmdo, wildcards, wildcards_ccase, Building Software with ClearCase



Feedback on the documentation in this site? We welcome any comments!
Copyright © 1999 by Rational Software Corporation. All rights reserved.