Overview of the cdb Commands

You can use the rsrc commands to manage resources. The cdb.rsrc commands include tools for checking in resources individually or in groups (through a batch files) for listing the versions of resources, determining where resources have been installed, and so on.

Checking in a resource creates a check-in job. A check-in job is a process that lasts until the resource has been fully entered in the repository and assigned a version number. The cdb.cj commands enable you to control and monitor check-in jobs.

Table 13–1 summarizes the CLI commands for managing resources.

In the descriptions that follow, the term <resource family name> means a resource name which designates the collection of all versions of resources checked in as that name. The term <resource specifier> indicates either a resourceID, or the human-friendly equivalent combination of a resource family name and a version number, separated by a colon (example: “bin/blip/blorp:1.1”).

cdb.rsrc.ci

Use the cdb.rsrc.ci command to check in certain components and their source objects. You will need to use this command in the following scenarios.

• You need to check in a browsable component (for example: file or Weblogic EJB)

  If you want to check in a non-browsable component, use the cdb.c.ci command. For a description of the command and its arguments, see cdb.c.ci.

• You need to check in source objects for a simple component.

• You need to check in the referenced components of a browsable, composite component.

Each invocation of the cdb.rsrc.ci command is considered a “check-in job,” and can be managed with the CLI commands for managing check-in jobs. For example, to determine which cdb.rsrc.ci commands are running, you can run the cdb.cj.la command, which lists all the current check-in jobs. You can also pass compCheckInID value returned by cdb.rsrc.ci as an argument to cdb.cj.lo to get status information about a specific check-in job.

cdb.rsrc.cib

The command is the “check-in batch” command. It checks in all the resources listed in a batch file.

Overview of Batch Files

The rsrc.cib operates on a batch file that includes a line for each resource that will be checked in. Batch files enable you to check-in large numbers of resources with a single command.

Each line in the batch file corresponds to a single resource on the local machine that will be checked in as a single resource. Each line consists of a series of fields that are separated by the pipe character (|). Some fields are optional and may be omitted. If an optional field is omitted but is followed by other fields, the omitted field should be followed by a | character, so that rsrc.cib can accurately identify each field.

You can include comments in a batch file. Any line that begins with the pound character (#) is interpreted as a comment.

Table 13–4 describes the syntax of a line of a batch file.

The table below lists the names that you can use in the fourth field of a batch file line to specify a platform for the component.

Example of a Line in a Batch File

To check in a local file named home/etc/myfile as the component mypath/mycomponentname as the resource type file for the platform Solaris 7 with the description “this is my file” and no designation as a configuration file, you would enter the following line in a batch file:

/home/myfile|mypath/mycomponentname|file|NM:Solaris 7|this is my file

If the file being checked in was a configuration file, you would add a boolean field to the end of the line and the field to true. For example:

/home/myfile|mypath/mycomponentname|file|NM:Solaris 7|this is my file|true 

If you wanted to omit a description for the mycomponent, you do change this line to the following (note the adjacent pipe separators):

/home/myfile|mypath/mycomponentname|file|NM:Solaris 7||true

To check in the component as a major version (e.g., 2.0 as opposed to 1.7), you would add true in the boolean field for major version check-ins:

/home/myfile|mypath/mycomponentname|file|NM:Solaris 7||true |true

If the check in was desired to not hide the previous component, the line above would become (note the additional false in the final field):

/home/myfile|mypath/mycomponentname|file|NM:Solaris 7||true |true|false

Similar format considerations apply to the optional boolean specifying whether to include owner and group information when storing permissions information.

Batch File Syntax

The N1 Service Provisioning System software applies these rules when parsing batch files.

• In fields that are known to be path names, slashes (whether forward or backward) are always translated to accommodate the convention used on the native file system.

• Blank lines are allowed as visual separators of clusters of files.

• Leading or trailing whitespace is not stripped from fields.

• Both absolute and relative paths are allowed in a batchfile. By default, relative paths are interpreted as being relative to the batchfile location; this can be overridden with the -pwdrelative flag, in which case relative paths will be interpreted as being relative to the current working directory.

Invocation

Batch check in via text file is invoked via a cdb.src.cib command ("cib" = check in batch) of the form

cdb.rsrc.cib -batchfile [batchfile location] [-haltonerror true|false] [-pwdrelative true|false]

Before checking in any resources, the cdb.rsrc.cib command performs a syntax check of the file. Next it verifies the existence of all the local files that are to be checked in. If cdb.rsrc.cib detects errors in either of these processes, it reports the errors and halts execution (regardless of the setting of the -haltonerror boolean argument described below).

The haltonerror Argument

The command line includes an optional -haltonerror argument (false by default) that designates whether or not an error from the check-in of a single file should halt the check-in of subsequent files. This boolean argument applies only to errors encountered after cdb.rsrc.cib has performed its preliminary error-checking (described in the section above).

The pwdrelative Argument

The command line includes an optional -pwdrelative provision (false by default) that designates whether relative paths in the batch file should be interpreted as being relative to the current working directory (pwdrelative = true) or relative to the location of the batchfile (pwdrelative = false).

Batch File Processing

Batchfile processing is non-transactional. This means that if batch file processing fails and/or halts before completion, any resources that have been successfully checked in remain checked in, and are not “un”-checked in.

Concurrent batch check ins are not arbitrated. If two different batch check-ins targeting the same set of resources begin to run at the same time, there is no mechanism throttling the processing of one batch file while another completes. Both batch files will be processed in the interleaved manner that results from their proximate timing.

cdb.cj.la

This command lists check-in jobs (components being checked in through the HTML user interface or through a CLI check-in command such as rsrc.ci). It lists all the jobs that are currently active, as well as the last 20 jobs that completed.

cdb.cj.lo

This command displays the status and details of the specified check-in job. You specify a job by its compCheckInID. This value is returned by cdb.rsrc.ci when you check in a resource.

Because this command requires the ID of the check-in job, it does not support ID NM: notation for its argument. See Appendix A for a detailed description of compCheckInId syntax.

cdb.cj.stop

This command stops the specified check-in job.

Because this command requires the ID of the check-in job, it does not support ID NM: notation for its argument. See Appendix A for a detailed description of CheckInJobID syntax.

cdb.rsrc.co

This command checks out the specified component. It transfers a copy from the repository to the local machine.

cdb.rsrc.rci

This command re-checks in a component. If a check-in job has been interrupted, you can use this command to repeat the check-in without artificially incrementing the version number of the checked-in component.