Sun Management Center Change Manager 1.0 Reference Manual

Change Manager System Administration Commands

bart(1MCM)

NAME

bart– basic audit reporting tool

SYNOPSIS

/usr/bin/bart create

-n

-R

root_directory

-r

rules_file

-

/usr/bin/bart create

-n

-R

root_directory

-I

file_name

/usr/bin/bart compare

-i

attribute

-p

-r

rules_file

-

control-manifest

test-manifest

DESCRIPTION

The bart(1MCM) command is a tool that performs a file-level check of the software contents of a system. Users can optionally specify the files to track and the types of discrepancies to flag by means of a rules file. See bart_rules(4CM).

The bart command performs two basic functions:

bart create

The manifest generator tool takes a file-level ``snapshot'' of a system. The output is a catalog of file attributes referred to as a ``manifest.'' See bart_manifest(4CM).

Users can specify the list of files to be cataloged in three ways. Use bart create with no options, specify the files by name on the command line, or create a rules file with directives that specify which the files to monitor. See bart_rules(4CM).

By default, the manifest generator catalogs all attributes of all files in the root (/) file system. File systems mounted on the root file system are cataloged only if they are of the same type as the root file system.

For example, /, /usr, and /opt are separate UFS file systems. /usr and /opt are mounted on /. Therefore, all three file systems are cataloged. However, /tmp, also mounted on /, is not cataloged because it is a TMPFS file system. Mounted CD-ROMs are not cataloged since they are HSFS file systems.

bart compare

The report tool compares two manifests. The output is a list of per-file attribute discrepancies. These discrepancies are the differences between two manifests: a control manifest and a test manifest. A discrepancy is a change to any attribute for a given file cataloged by both manifests. Note that a new file or a deleted file in a manifest is reported as a discrepancy.

The reporting mechanism provides two types of output: verbose and programmatic. Verbose output is localized and presented on multiple lines, while programmatic output is more easily parsable by other programs. See OUTPUT.

By default, the report tool generates verbose output where all discrepancies are reported except for modified directory timestamps (the dirmtime attribute).

Note –

To ensure consistent and accurate comparison results, both control-manifest and test-manifest must be built with the same rules file.

Use the rules file to ignore specified files or subtrees when you generate a manifest or compare two manifests. Users can compare manifests from different perspectives by re-running the bart compare command with different rules files.

OPTIONS

The following options are supported:

-i attribute ...: Specifies the file attributes to be ignored globally. This option produces the same behavior as supplying the file attributes to a global IGNORE keyword in the rules file. See bart_rules(4CM).
-I [file_name...]: Inputs list of files. The file list can be specified at the command line or read from standard input.
-n: Prevents computation of content signatures for all regular files in the file list.
-p: Displays manifest comparison output in ``programmatic mode,'' which is suitable for programmatic parsing. The output is not localized.
-r rules_file: Uses rules_file to specify which files and directories to catalog, and to define which file attribute discrepancies to flag. If rules_file is -, then the rules are read from standard input. See bart_rules(4CM) for the definition of the syntax.
-R root_directory: Specifies the root directory for the manifest. All paths specified by the rules, and all paths reported in the manifest, are relative to root_directory.

OPERANDS

The following operands are supported:

control-manifest: Is the manifest created by bart create on the control system.
test-manifest: Is the manifest created by bart create on the test system.

OUTPUT

The bart create and bart compare commands write output to standard output, and write error messages to standard error.

The bart create command generates a system manifest. See bart_manifest(4CM).

When the bart compare command compares two system manifests, it generates a list of file differences. By default, the comparison output is localized. However, if the -p option is specified, the output is generated in a form that is suitable for programmatic manipulation.

Default Format

filename
	attribute	control:xxxx test:yyyy

filename: Name of the file that differs between control-manifest and test-manifest. For file names that contain embedded whitespace or newline characters, see Quoting Syntax in bart_manifest(4CM).
attribute: The name of the file attribute that differs between the manifests that are compared. xxxx is the attribute value from control-manifest, and yyyy is the attribute value from test-manifest. When discrepancies for multiple attributes occur for the same file, each difference is noted on a separate line.

The following default output shows the attribute differences for the /etc/passwd file. The output indicates that the size, mtime, and contents attributes have changed.

/etc/passwd:
  size  control:74  test:81
  mtime  control:3c165879  test:3c165979
  contents  control:daca28ae0de97afd7a6b91fde8d57afa
	test:84b2b32c4165887355317207b48a6ec7

Programmatic Format

filename attribute control-val test-val [attribute control-val test-val]*

filename: Same as filename in the default format.
attribute control-val test-val: A description of the file attributes that differ between the control and test manifests for each file. Each entry includes the attribute value from each manifest. See bart_manifest(4CM) for the definition of the attributes.

Each line of the programmatic output describes all attribute differences for a single file.

The following programmatic output shows the attribute differences for the /etc/passwd file. The output indicates that the size, mtime, and contents attributes have changed.

/etc/passwd size 74 81 mtime 3c165879 3c165979
	contents daca28ae0de97afd7a6b91fde8d57afa 84b2b32c4165887355317207b48a6ec7

EXIT STATUS

Manifest Generator

0: Success
1: Non-fatal error when processing files; for example, permission problems
>1: Fatal error; for example, invalid command-line options

Report Tool

0: No discrepancies reported
1: Discrepancies found
>1: Fatal error executing comparison

EXAMPLES

Example 1 Creating a Default Manifest Without Computing Checksums

The following command line creates a default manifest, which consists of all files in the / file system. The -n option prevents computation of checksums, which causes the manifest to be generated more quickly.

bart create -n

Example 2 Creating a Manifest for a Specified Subtree

The following command line creates a manifest that contains all files in the /home/nickiso subtree.

bart create -R /home/nickiso

Example 3 Creating a Manifest by Using Standard Input

The following command line uses output from the find(1) command to generate the list of files to be cataloged. The find output is used as input to the bart create command that specifies the -I option.

find /home/nickiso -print | bart create -I

Example 4 Creating a Manifest by Using a Rules File

The following command line uses a rules file, rules, to specify the files to be cataloged.

bart create -r rules

Example 5 Comparing Two Manifests and Generating Programmatic Output

The following command line compares two manifests and produces output suitable for parsing by a program.

bart compare -p manifest1 manifest2

Example 6 Comparing Two Manifests and Specifying Attributes to Ignore

The following command line compares two manifests. The dirmtime, lnmtime, and mtime attributes are not compared.

bart compare -i dirmtime lnmtime mtime manifest1 manifest2

Example 7 Comparing Two Manifests by Using a Rules File

The following command line uses a rules file, rules, to compare two manifests.

bart compare -r rules manifest1 manifest2

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWbart
Interface Stability	Evolving

changemgr(1MCM)

NAME

changemgr– Sun Management Center Change Manager command-line interface

SYNOPSIS

/opt/SUNWichange/bin/changemgr

command

options

operands

DESCRIPTION

The changemgr(1MCM) command is the command-line interface for the Sun Management Center Change Manager, henceforth referred to as Change Manager. This command-line interface performs the same operations that can be performed by using the browser user interface, such as software deployment tasks and system audit tasks.

Change Manager commands must be run by an authenticated user.

The command-line interface can be used to initiate a Change Manager session. A Change Manager session is a subshell in which you can run Change Manager commands as an authenticated user. You authenticate when you initiate the session. All operations run within the session are owned by the authenticated user.

The command-line interface can also run custom scripts that execute multiple Change Manager commands. The script support facilitates the execution of multiple Change Manager operations. Authentication is performed once for the script instead of once per command-line invocation.

OPTIONS

The changemgr command supports several command-line options.

Authentication Options

Other than the changemgr help commands, all commands must be authenticated. In the context of a session, the session's authenticated identity is used.

The following authentication options are supported:

-p file

file consists of a single line, which contains the password. If file is -, then the user can supply the password as standard input.

If the -p option is not supplied, then the changemgr command prompts the user for his password.

-u username

Specify the user name to authenticate. If the -u option is not supplied, the user is the current UNIX real user ID, as reported by id(1M).

Common Options

These options are used by more than one command.

-d domain

Specify the Sun Management Center administrative domain on which to operate. In the context of a session, the default is the domain specified by the session, if any. By default, domain is the user's home domain.

-o format

format is a blank-separated list or comma-separated list of property names. If you separate the property names with spaces, make sure that you surround the list of property names with quotes. The specified property values are displayed in a name=value format. If format is specified as all, then all properties are displayed. The output is suitable for programmatic parsing.

The output lists each file or folder on a line by itself. The name can be followed by property lines, which consist of a tab, property name, equals sign, and a property value. Each file or folder entry is separated from the next entry by a blank line.

For example, the output is arranged as follows:

path
        name=value
        ...

path
        name=value
        ...

...

OPERANDS

The following operands are supported:

filepath: An absolute path to a file or a relative (to the current directory) path to a file. This file path is not in the Change Manager repository.
relpath: Path to a file-like object (including a folder) that is relative to the top of the Change Manager repository.
relfilepath: Path to a file-like object (not including a folder) that is relative to the top of the Change Manager repository.
reldirpath: Path to a folder-like object that is relative to the top of the Change Manager repository.
.type: File name suffix that specifies the file type. File type suffixes are: .flar for archives, .miniroot for boot images, .bmft for manifests, .brul for audit rules files, .txt for reports, and .cmsp for shared profiles. Folders do not require a file name suffix.
topopath: Path to a topology object (including a host group) that is relative to the top of the selected administrative domain.
hostpath: Path to a managed host that is relative to the top of the selected administrative domain.
hostname: Network name of a host, for example, netherfield.sun.com.
grouppath: Path to a host group that is relative to the top of the selected administrative domain.

SUBCOMMANDS

The following sections describe the changemgr subcommands.

Sessions

changemgr session [-u username] [-p file] [-d domain] [command [command-arguments]]

Run the specified command in the context of a Change Manager session so that individual commands in a script (command) do not need authentication and startup overhead. The authentication and startup overhead is amoritized over all of the commands.

command is normally an sh(1) or ksh(1) script that contains Change Manager commands in the form of the command-line interface.

If command is sh or ksh, a subshell is spawned to create an interactive session. You are required to authenticate to initiate the session.

If command is not supplied, then an interactive subshell of $SHELL starts, if known to be compatible. If $SHELL is not compatible, then an interactive ksh subshell starts.

Note –

The csh(1) shell cannot be used to run scripts or initiate a session.

File Management Operations

changemgr mkdir [-u username] [-p file] new_reldirpath...

Create one or more folders in the Change Manager repository.

changemgr import [-u username] [-p file] filepath.[type] relfilepath.type

Import a single file, filepath.[type], to the repository as relfilepath.type. The file being imported can have any file suffix, but the file name in the repository must have the appropriate suffix.

changemgr import [-u username] [-p file] filepath.type... reldirpath

Import one or more files to the specified folder, reldirpath, in the repository.

Because this command uses the original file names when creating the files in the repository, the original names must have the appropriate suffixes.

changemgr export [-u username] [-p file] relfilepath filepath

Export a single file, relfilepath, from the repository as filepath.

changemgr export [-u username] [-p file] relfilepath... dirpath

Export one or more files to the specified folder, dirpath, outside of the repository.

changemgr files [-u username] [-p file] [-l] [-d] [-R] [-o format] [relpath...]

List the specified files and folders, or the contents of the specified folders. When no path is specified, the objects in the root of the repository are listed.

The default output format is one file or folder name per line.

-d: Present information about the folder itself, rather than about the folder's contents.
-l: Present more information in tabular output. This output is not suitable for programmatic parsing.
-R: Recursively list the contents of a folder.

changemgr delete [-u username] [-p file] relpath...

Delete the specified files and folders.

Note that only empty folders can be deleted.

changemgr fileset [-u username] [-p file] [-s name=value]... [-s name]... relpath...

Set properties for the specified files and folders by using the -s name=value option. The -s option with just the property name deletes the property.

-s name=value: Specify one or more name=value pairs. name is the property name, and value is the property value. Supply the -s option for each property value you want to set. If value is blank, then the property is assigned an empty value.
-s name: Specify one or more property names to delete, where name is the property name. Supply the -s option for each property you want to delete.

changemgr filemove [-u username] [-p file] old_relpath... new_dirpath

Move files and folders to another folder. The original file and folder names are unchanged. The destination folder must already exist.

old_relpath can be a folder or a file.

changemgr filemove [-u username] [-p file] old_relpath.type new_relpath.type

Rename a file or a folder. The type of the renamed file must stay the same.

Topology Operations

changemgr mkgroup [-u username] [-p file] [-d domain] new_grouppath...

Create one or more host groups.

changemgr hosts [-u username] [-p file] [-l] [-g] [-R] [-d domain] [-o format] [topopath...]

List information about topopath, which represents the specified managed hosts or host groups. With no path arguments, information is listed about the managed hosts and host groups in the root of the administrative domain.

The default output format is one managed host or host group name per line.

-g: Present information about the group itself, rather than about the group's contents.
-l: Present more information in tabular output. This output is not suitable for programmatic parsing.
-R: Recursively list the contents of a group.

changemgr add [-u username] [-p file] [-d domain] hostname hostpath

Register a network host name as a Sun Management Center host name. The host path includes the host group and the host name. The name of the managed host can be different from the network host name.

changemgr add [-u username] [-p file] [-d domain] hostname... grouppath

Add the specified managed hosts to the specified host group, with the managed host names equal to the network host names.

changemgr remove [-u username] [-p file] [-d domain] topopath...

Remove managed hosts and host groups from the topology.

changemgr hostset [-u username] [-p file] [-d domain] [-s name=value]... [-s name]... topopath...

Set properties for the specified managed hosts and host groups by using the -s name=value option. The -s option with just the property name deletes the property.

-s name=value: Specify one or more name=value pairs. name is the property name, and value is the property value. Supply the -s option for each property value you want to set. If value is blank, then the property is assigned an empty value.
-s name: Specify one or more property names to delete, where name is the property name. Supply the -s option for each property you want to delete.

changemgr hostmove [-u username] [-p file] [-d domain] old_topopath... new_grouppath

Move managed hosts or host groups to another host group. The destination host group must already exist.

changemgr hostmove [-u username] [-p file] [-d domain] old_topopath new_topopath

Rename a single managed host or host group.

Host Operations

changemgr update [-u username] [-p file] [-d domain] [-x operation] topopath...

Update the specified managed hosts to conform to the configuration specified by their properties.

If topopath is a host group, all members of the host group are updated.

-x operation: Specify the action to take after the update completes. If operation is reboot, then activate the newly installed software stack and reboot. If operation is halt, then activate the newly installed software stack and halt. The default operation is to reboot the managed host.

changemgr fallback [-u username] [-p file] [-d domain] [-x operation] topopath...

Restores the specified managed hosts to their state prior to the last changemgr update operation. This action only undoes the last update operation. This action does not change the parameters associated with the managed host. After the fallback operation, the managed host's running configuration will not match the parameters selected for it, which is the case immediately prior the update operation.

If topopath is a host group, all members of the host group are restored.

-x operation: Specify the action to take after the fallback completes. If operation is reboot, then activate the newly selected software stack and reboot. If operation is halt, then activate the newly selected software stack and halt. The default operation is to reboot the managed host.

changemgr reinstall [-u username] [-p file] [-d domain] topopath...

Reinstall the specified managed hosts. The reinstallation is equivalent to:

# reboot -- net - install

If topopath is a host group, all members of the host group are reinstalled.

changemgr setup [-u username] [-p file] [-d domain] topopath...

Set up files for initial installation. This operation is required before manually running boot net - install on the consoles of managed hosts.

If topopath is a host group, all files for the members of the host group are set up.

changemgr reboot [-u username] [-p file] [-d domain] topopath...

Reboot the specified managed hosts.

If topopath is a host group, all members of the host group are rebooted.

changemgr halt [-u username] [-p file] [-d domain] topopath...

Halt the specified managed hosts.

If topopath is a host group, all members of the host group are halted.

changemgr manifest [-u username] [-p file] [-d domain] -o relpathprefix [-r relfilepath.brul] topopath...

Create manifests for the specified managed hosts.

-o relpathprefix: Specify the prefix to use when creating manifests. The host name and suffix are appended to the prefix to form the name of the manifest.
-r relfilepath.brul: Specify the audit rules file to use when building manifests.

changemgr audit [-u username] [-p file] [-d domain] -o relfilepath.txt [-r relfilepath.brul] relfilepath.bmft topopath...

Compare managed host contents against a baseline manifest.

-o relfilepath.txt: Specify the file path of the report.
-r relfilepath.brul: Specify the audit rules file to use when auditing hosts.

changemgr info [-u username] [-p file] [-d domain] -o relfilepath.txt topopath...

Get software status information about the specified managed hosts. Store the results in the specified report.

-o relfilepath.txt: Specify the file path of the report.

Job Management Operations

changemgr jobs [-u username] [-p file] [-l] [-o format] [id...]

Display the status of all outstanding jobs or of specified jobs.

-l: Present more information in tabular output. This output is not suitable for programmatic parsing.

changemgr kill [-u username] [-p file] id...

Cancel currently running jobs or pending jobs.

changemgr ack [-u username] [-p file] id...

Acknowledge the completion of the specified jobs. This action discards the status of the specified jobs.

Use this command to purge completed job entries from the job list that were initiated by the browser interface.

Miscellaneous

changemgr help: Provide a one-line summary of the available subcommands. No authentication is required.
changemgr help subcommand: Provide a summary of the specified subcommand. No authentication is required.

EXAMPLES

Example 1 Running Commands in an Interactive Change Manager Session

The following example shows an interactive Change Manager session. The changemgr session command starts a subshell in which you can run authenticated changemgr commands.

This example shows how to purge a completed job from the job queue. This job, IC_1, was initiated from the browser interface. When the tasks are completed, exit the session by typing exit at the subshell prompt.

$ changemgr session
Password: password
$ changemgr jobs -l IC_1
IC_1     succeeded
$ changemgr ack IC_1
$ changemgr jobs l IC_1
$ exit

Example 2 Running Scripts in a Change Manager Session

This example shows how to use the changemgr session command to run a script. The command line runs the script called deploy-web, which contains the following:

$ cat deploy-web
#/bin/sh
changemgr import "$1" /
changemgr fileset -s MediaName=s9.miniroot "$1"
changemgr hostset -s base_config_flar_archive="/$1" "$2"
changemgr update "$2"
$

The following command line runs the deploy-web script.

$ changemgr session deploy-web web.flar host1

SunOS 5.9 Last Revised 15 October 2002

cmgetprop(1MCM)

NAME | SYNOPSIS | DESCRIPTION | EXAMPLES | SEE ALSO

NAME

cmgetprop– Get Change Manager property value

SYNOPSIS

cmgetprop

property-name

DESCRIPTION

The cmgetprop(1MCM) command writes the value of the specified property to standard output. Note that no value is returned when the property is not set.

Use the cmgetprop command in deployment finish scripts to get property values. Change Manager finish scripts are stored in the /etc/ichange.d directory.

The cmgetprop command is included in the $PATH supplied to the Change Manager finish scripts.

EXAMPLES

Example 1 Using the `cmgetprop` Command

The following line might exist in a Change Manager finish script.

FILENAME=`cmgetprop FNAME`

This code assigns the value of the FNAME property to the FILENAME variable.

cminst(1MCM)

NAME | SYNOPSIS | DESCRIPTION | SEE ALSO

NAME

cminst, cmuninst– Install or uninstall Change Manager software

SYNOPSIS

cminst

cmuninst

DESCRIPTION

The cminst command installs the Change Manager software on a Change Manager server or on a master system. A master system is one on which to create a software stack and build the Solaris Flash archive. The cmuninst command uninstalls the Change Manager software.

The cminst(1MCM) command must be run after the Sun Management Center software is installed and configured. Change Manager requires that you install the Sun Management Center premier package and add patch 110938-06 to the Change Manager server. Configure the Sun Management Center software on the Change Manager server by running the Sun Management Center es-setup command. See ``Installing and Configuring the Change Manager Server'' in Sun Management Center Change Manager 1.0 Administration Guide.

The cminst command determines whether the system being installed is the Change Manager server or a master system. If cminst detects Sun Management Center server software, it installs the Sun Management Center Web Console, Change Manager server and agent, and Change Manager application components. If, however, cminst detects only Sun Management Center agents, then it installs only the Change Manager agent component.

The cmuninst command only removes the Sun Management Center Web Console and Change Manager packages from the Change Manager server. It does not remove Change Manager data, which is the Change Manager database or the contents of the Change Manager repository.

Change Manager Server

The cminst command performs the following tasks when run on the Change Manager server:

Stops the Sun Management Center server
Installs the Sun Management Center Web Console package
Installs the Change Manager server and agent components
Installs the Change Manager application component
Runs es-setup to configure the Change Manager components
Creates the /var/opt/SUNWsymon/cfg/ichange.cfg file

If the /var/opt/ichange directory does not have enough available disk space for the repository, then edit the ichange.cfg file. Change the value of the cmdataroot parameter to point to another file system that has sufficient disk space.

Note –
After making changes to the ichange.cfg file, restart the Sun Management Center server by typing es-restart -S.
Asks you to provide the same Sun Management Center server seed you supplied when you configured Sun Management Center on the Change Manager server

If you change the value of the seed after running cminst, then you must update the agentseed parameter in the ichange.cfg file. Then, restart the Sun Management Center server.
Asks you to specify a directory in which to store the Change Manager database

This directory must have at least 500 Mbytes of available disk space.
Sets up the Change Manager database
Asks you to specify a directory in which to store the Change Manager repository

This directory might need several Gbytes of available disk space to store files such as Solaris Flash archives, Solaris boot images, and manifests.
Restarts the Sun Management Center server
Starts the Sun Management Center web server

The cmuninst command performs the following tasks when run on the Change Manager server:

Stops the Sun Management Center server
Uninstalls the Sun Management Center Web Console package
Uninstalls the Change Manager server and agent components
Preserves the Change Manager database
Preserves the ichange.cfg file
Preserves the Change Manager repository
Restarts the Sun Management Center server
Restarts the Sun Management Center web server

Master System

The cminst command installs the Change Manager agent package on the master system and restarts the Sun Management Center agents.

The cmuninst command performs the following tasks when run on a master system:

Stops the Sun Management Center agent
Uninstalls the Change Manager agent package
Restarts the Sun Management Center agent

cmsetup(1MCM)

NAME | SYNOPSIS | DESCRIPTION | OPTIONS | SEE ALSO

NAME

cmsetup– Set up or remove Change Manager data

SYNOPSIS

cmsetup

-c

-h

-s

-u

DESCRIPTION

The cmsetup(1MCM) command is used to initialize, re-initialize, or remove Change Manager data on the Change Manager server. Change Manager data includes both the metadata maintained in the database tables and the repository where files, such as Solaris Flash archives, Solaris boot images, and manifests, are stored.

When Change Manager is installed, the cminst(1MCM) command can either initialize Change Manager data immediately or, at the user's option, defer configuration. If you choose to have cminst initialize data, you will not have to run cmsetup. If you choose to defer configuration, you must run cmsetup manually.

The Change Manager database is dependent on the underlying Sun Management Center database. Therefore, you must run cmsetup(1MCM) whenever the Sun Management Center database has been re-initialized, such as by /opt/SUNWsymon/sbin/es-setup. cmsetup must be run after es-setup has completed. You must also run cmsetup after installing or re-initializing the Performance Reporting Manager (PRM) add-on.

OPTIONS

The following options are supported:

-c: Run es-setup to set up or re-initialize Change Manager data. This option must be used the first time that Change Manager software is installed, and whenever you want to re-initialize the Change Manager database.
-h: Run help. Use this option to obtain help in using this command.
-s: Run es-setup. This option initializes both Sun Management Center data and Change Manager data.
-u: Remove (unsetup) Change Manager data. This option removes the Change Manager database, removes all Change Manager data files, and disables boot services to the managed hosts.

Change Manager System Administration Commands

bart(1MCM)

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

OPERANDS

OUTPUT

Default Format

Programmatic Format

EXIT STATUS

Manifest Generator

Report Tool

EXAMPLES

Example 1 Creating a Default Manifest Without Computing Checksums

Example 2 Creating a Manifest for a Specified Subtree

Example 3 Creating a Manifest by Using Standard Input

Example 4 Creating a Manifest by Using a Rules File

Example 5 Comparing Two Manifests and Generating Programmatic Output

Example 6 Comparing Two Manifests and Specifying Attributes to Ignore

Example 7 Comparing Two Manifests by Using a Rules File

ATTRIBUTES

SEE ALSO

changemgr(1MCM)

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

Authentication Options

Common Options

OPERANDS

SUBCOMMANDS

Sessions

File Management Operations

Topology Operations

Host Operations

Job Management Operations

Miscellaneous

SEE ALSO

EXAMPLES

Example 1 Running Commands in an Interactive Change Manager Session

Example 2 Running Scripts in a Change Manager Session

cmgetprop(1MCM)

NAME

SYNOPSIS

DESCRIPTION

EXAMPLES

Example 1 Using the cmgetprop Command

SEE ALSO

cminst(1MCM)

NAME

SYNOPSIS

DESCRIPTION

Change Manager Server

Master System

SEE ALSO

cmsetup(1MCM)

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

SEE ALSO

Example 1 Using the `cmgetprop` Command