The command is the “check-in batch” command. It checks in all the components listed in a batch file.
Table 3–38 Arguments and Result of the cdb.rsrc.cib
Argument/Result |
Syntax |
Description |
|
---|---|---|---|
batchfile |
[R] |
String |
The name of the batch file listing the components to be checked in |
haltonerror |
[O] |
Boolean |
When true, first error will halt batch execution, default true |
pwdrelative |
[O] |
Boolean |
When true, relative paths are relative to the user directory; otherwise they are relative to the batchfile location, defaults to false |
result |
String |
Message indicating the operation is complete |
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.
Table 3–39 Syntax of a Line in a Batch File
Content |
Optional/Required |
---|---|
The location of the component on the local machine |
Required |
The name to be assigned to the component when checked in |
Required |
The component type |
Required |
The platform the component is intended for expressed as a HostSetID in the form NM:<platform_name>, where <platform_name> is one of the platform names listed in Table 3–40. |
Optional |
A description of the component |
Optional |
A boolean designation of whether the file is a configuration file |
Optional (Default is false) |
A boolean designation of whether check-in should be assigned a major version number (e.g., 2.0) |
Optional (Default is false) |
A boolean designation of whether to hide the previous most recent version of the component |
Optional (Default is true) |
A boolean designation of whether to include owner information when storing permissions information |
Optional (Default is true) |
A boolean designation of whether to include group information when storing permissions information |
Optional (Default is true) |
A boolean designation of whether the files being checked in should be added to the existing files to create a new version, instead of creating a new version by completely replacing the existing files |
Optional (Default is true) |
If this component is being checked in a from a host, the host ID of the host from which the component is being checked in |
Optional |
A boolean designation of whether redundancy checking should apply |
Optional (Default is true) |
The name of the picker to use (optional, defaults to null for the default picker) | |
A Hashtable in string form containing extra options supported by the type's exporter. Note that the boolean values for the following cannot be specified using the extraOpts argument:
Instead, use the batch file format equivalent options to specify these values. |
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.
Table 3–40 Names for Platforms
Platform Name |
Description |
---|---|
any |
Any platform supported by the Sun N1 Service Provisioning System software |
AIX - any version |
Either IBM AIX 5.1 or IBM AIX 5.2 |
AIX 5.1 |
IBM AIX 5.1 |
AIX 5.2 |
IBM AIX 5.2 |
Solaris - any version |
SolarisTM 6, Solaris 7, or Solaris 8 releases |
Solaris 7 |
Solaris 7 release |
Solaris 8 |
Solaris 8 release |
Solaris 9 |
Solaris 9 release |
Solaris 10 |
Solaris 10 release |
Windows 2000 Server |
Microsoft Windows 2000 Server |
Red Hat Linux |
Red Hat Advanced Server 2.1 |
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.
The Sun 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.
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 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 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).
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.