cdb.rsrc.cib

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

Overview of Batch Files

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

Each line in the batch file corresponds to a single component on the local machine that will be checked in as a single component. 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.

The following table describes the syntax of a line of a batch file.

The following table 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 component 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 Grid 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 components, 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).

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 components 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 components 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.