CM2DDTS(1)
NAME
cm2ddts - integrate ClearDDTS into a CM system's user
interface
SYNOPSIS
cm2ddts [-w] "bugid [bugid ...]" -f filename [-f filename]
hostname whoami action [action ...]
DESCRIPTION
The cm2ddts utility is meant for users who want to create
their own interface for integrating a CM system into
ClearDDTS. The utility writes a transaction to the
ClearDDTS database queue and then potentially (-w option)
waits for the cm.in(1) utility to post the transaction to
the database.
To integrate a CM system with a defect tracking system, all
CM activities such as check-out and check-in must be
associated with a defect record.
-w Signals cm2ddts to wait up to 10 seconds
for the cm.in(1) to update the ClearDDTS database.
This is used by calls from xddts(1) and bugs(1) to
synchronize the update by the CM system with the
the display that the user sees on the screen.
-f filename Indicates the filename that the action(s)
specified on the command line should be performed
on. Multiple files can be specified but a W-f must
precede each filename.
bugid This argument is a space delimited list of the defect
record ids that the CM action is being performed on
behalf of. It must be specified as one argument so
don't forget the quotes for multiple bug ids.
hostname This argument specifies the name of the host where the
CM activity took place. The hostname parameter
allows mount locations under NFS to be accounted
for in uniquely identifying the file that was
checked in or checked out.
whomai This argument specifies the login id of the person
performing the CM action.
actions These arguments specify the CM actions that are to be
applied to each one of the files specified by the
W-f option. actions can be one or more of the
following:
-checkin check in file(s)
-checkout check out file(s)
-verinit check in file(s) for the first time
-uncheckin uncheck in file(s)
-uncheckout uncheck out file(s)
WARNINGS
Make sure that you specify the hostname, whoami and actions
in the order specified on the command line.
Synchronization problems may occur. The CM system may want
to post a change against a defect record where the record is
locked. In this case, the transaction is queued and the
ddts daemon ddtsclean(1) will take care of the problem of
posting the record later (generally at midnight).
SEE ALSO
batchbug(1), cm.in(1), ClearDDTS Administrator's Guide