IPnom Home • Manuals • ClearCase

 Rational ClearCase Commands Reference

ClearCase Stuff:ClearCase LinksClearCase BooksClearCase Commands ReferenceClearCase ForumsClearCase News
Keyword Live Search (10 results max):
 Type in part of a ClearCase command in the search box.
 
Commands Index:
  intro
  annotate
  apropos
  catcr
  catcs
  cc.icon
  cc.magic
  cd
  chactivity
  chbl
  checkin
  checkout
  checkvob
  chevent
  chflevel
  chfolder
  chmaster
  chpool
  chproject
  chstream
  chtype
  chview
  clearaudit
  clearbug
  cleardescribe
  cleardiffbl
  cleardiff
  clearexport_ccase
  clearexport_cvs
  clearexport_pvcs
  clearexport_rcs
  clearexport_sccs
  clearexport_ssafe
  clearfsimport
  cleargetlog
  clearhistory
  clearimport
  clearjoinproj
  clearlicense
  clearmake
  clearmake.options
  clearmrgman
  clearprojexp
  clearprompt
  cleartool
  clearviewupdate
  clearvobadmin
  comments
  config_ccase
  config_spec
  cptype
  credmap
  creds
  deliver
  describe
  diffbl
  diffcr
  diff
  dospace
  edcs
  endview
  env_ccase
  events_ccase
  export_mvfs
  exports_ccase
  file
  find
  findmerge
  fmt_ccase
  getcache
  get
  getlog
  help
  hostinfo
  init_ccase
  ln
  lock
  lsactivity
  lsbl
  lscheckout
  lsclients
  lscomp
  lsdo
  lsfolder
  lshistory
  ls
  lslock
  lsmaster
  lspool
  lsprivate
  lsproject
  lsregion
  lsreplica
  lssite
  lsstgloc
  lsstream
  lstype
  lsview
  lsvob
  lsvtree
  makefile_aix
  makefile_ccase
  makefile_gnu
  makefile_pmake
  makefile_smake
  makefile_sun
  man
  merge
  mkactivity
  mkattr
  mkattype
  mkbl
  mkbranch
  mkbrtype
  mkcomp
  mkdir
  mkelem
  mkeltype
  mkfolder
  mkhlink
  mkhltype
  mklabel
  mklbtype
  mkpool
  mkproject
  mkregion
  mkstgloc
  mkstream
  mktag
  mktrigger
  mktrtype
  mkview
  mkvob
  mount_ccase
  mount
  msdostext_mode
  mvfslog
  mvfsstorage
  mvfstime
  mvfsversion
  mv
  omake
  pathnames_ccase
  permissions
  profile_ccase
  promote_server
  protect
  protectvob
  pwd
  pwv
  query_language
  quit
  rebase
  recoverview
  reformatview
  reformatvob
  register
  relocate
  rename
  reqmaster
  reserve
  rgy_backup
  rgy_check
  rgy_passwd
  rgy_switchover
  rmactivity
  rmattr
  rmbl
  rmbranch
  rmcomp
  rmdo
  rmelem
  rmfolder
  rmhlink
  rmlabel
  rmmerge
  rmname
  rmpool
  rmproject
  rmregion
  rmstgloc
  rmstream
  rmtag
  rmtrigger
  rmtype
  rmver
  rmview
  rmvob
  schedule
  schemes
  scrubber
  setactivity
  setcache
  setcs
  setplevel
  setsite
  setview
  shell
  snapshot.conf
  softbench_ccase
  space
  startview
  type_manager
  umount
  uncheckout
  unlock
  unregister
  unreserve
  update
  version_selector
  view_scrubber
  vob_restore
  vob_scrubber
  vob_sidwalk
  vob_snapshot
  vob_snapshot_setup
  wildcards_ccase
  winkin
  xclearcase
  xcleardiff
  xmldiffmrg

schedule

Schedules and manages jobs to be run one or more times

APPLICABILITY

ProductCommand type
ClearCasecleartool subcommand
ClearCase LTcleartool subcommand

Platform
UNIX
Windows

SYNOPSIS

  • ClearCase—Display information about jobs, tasks, or protection:
    sched·ule [ –f·orce ] [ –hos·t hostname ] –get
    [ –sch·edule | –job job-id-or-name | –tas·ks | –acl ]

  • ClearCase—Edit a schedule or the scheduler's protection information:
    sched·ule [ –f·orce ] [ –hos·t hostname ] –edi·t [ –sch·edule | –acl ]

  • ClearCase—Set a schedule or protection using definitions in a file:
    sched·ule [ –f·orce ] [ –hos·t hostname ] –set
    [ –sch·edule | –acl ] defn-file-pname

  • ClearCase—Perform an operation on a scheduled job:
    sched·ule [ –f·orce ] [ –hos·t hostname ]
    [ –del·ete | –run | –wai·t | –sta·tus ] job-id-or-name

  • ClearCase LT—Display information about jobs, tasks, or protection:
    sched·ule [ –f·orce ] –get [ –sch·edule | –job job-id-or-name
    | –tas·ks | –acl ]

  • ClearCase LT—Edit a schedule or the scheduler's protection information:
    sched·ule [ –f·orce ] –edi·t [ –sch·edule | –acl ]

  • ClearCase LT—Set a schedule or protection using definitions in a file:
    sched·ule [ –f·orce ] –set [ –sch·edule | –acl ] defn-file-pname

  • ClearCase LT—Perform an operation on a scheduled job:
    sched·ule [ –f·orce ] [ –del·ete | –run | –wai·t | –sta·tus ]
    job-id-or-name

DESCRIPTION

The schedule command creates and manages jobs related to ClearCase and ClearCase LT and arranges to execute them at specified times. A job consists of an executable program, or task, that the scheduler runs one or more times with a given set of arguments.

In ClearCase, the scheduler is available on any host that runs the albd_server. In ClearCase LT, the scheduler is available on the ClearCase LT server host only.

Note: For the pathnames of the files and directories described in this section, see the sections, UNIX Files and Windows Files.

Task and Job Storage

The scheduler relies on two data repositories:

  • A database of tasks available for scheduling
  • A database of jobs, or scheduled tasks

A task must be defined in the task database before you can schedule it. The task database is a single text file, task_registry. You can add task definitions to the task database by editing this file using a text editor. You must not change the definitions of standard tasks, but you can add your own task definitions at the end of the file. For more information, see “Task Definition Syntax”.

Standard tasks reside in the directory tasks. These tasks are not editable. Tasks that you define can reside anywhere in the file system, but the recommended location is the directory tasks. This directory contains a task, ccase_local_day, that is intended for user-defined operations to be run daily. The directory contains another task, ccase_local_wk, that is intended for user-defined tasks to be run weekly. You can customize these two tasks using a text editor or can create entirely new tasks.

The database of jobs is the file db. This is a binary file that you read and edit by using the schedule command. When you use the schedule command to change the job database, you use the job definition language described in “Job Definition Syntax”.

Task and Job Database Initialization

ClearCase and ClearCase LT install a template for an initial task database, which contains definitions for standard tasks, as the file task_registry. The albd_server uses this template to create the first version of the actual task database, task_registry.

Templates are installed for two customized tasks, ccase_local_day and ccase_local_wk, in the directory templates. The albd_server uses these templates to create initial versions of these tasks in the directory tasks.

ClearCase and ClearCase LT install an initial set of job definitions as the text file initial_schedule. These job definitions rely on task definitions in the task registry template. The albd_server uses these job definitions to create the first version of the job database, db.

Note: Do not edit or delete any files in the directory tree whose root is scheduler.

Default Schedule

When no job database exists, the albd_server uses the initial set of job definitions in the file initial_schedule to create a default schedule. This schedule consists of some jobs run daily and other jobs run weekly.

Daily jobs:

  • Scrub cleartext and derived object storage pools of all local VOBs, using scrubber.
  • Copy the VOB database for all local VOBs that are configured for snapshots, using vob_snapshot.
  • Copy the ClearCase registry from the primary registry server host (when run on a backup registry server host), using rgy_backup.
  • Run user-defined daily operations in ccase_local_day.
  • Generate and cache data on disk space used by all local views, using space.
  • Generate and cache data on disk space used by all local VOBs, using space.

Weekly jobs:

  • Scrub some logs (see the Administrator's Guide).
  • Scrub the databases of all local VOBs, using vob_scrubber.
  • Run user-defined weekly operations in ccase_local_wk.
  • Generate and cache data on disk space used by derived objects in all local VOBs, using dospace.

The default schedule also includes three jobs to automate the synchronization of MultiSite replicas. These jobs are designed to run daily but are disabled by default, whether or not MultiSite is installed. For more information about these jobs and how to enable them for use with MultiSite, see the Administrator's Guide for Rational ClearCase MultiSite.

Job Timing Options

You can arrange for a job to run under a variety of schedules:

  • Run daily or every n days, starting at a specified time of day and possibly repeating at a specified time interval during the day.
  • Run weekly or every n weeks, on one or more days of each week, starting at a specified time of day and possibly repeating at a specified time interval during the day.
  • Run monthly or every n months, on a specified day of the month, starting at a specified time of day and possibly repeating at a specified time interval during the day.
  • Run immediately after another job finishes.

For daily, weekly, and monthly schedules, you can specify starting and ending dates for the job. To run a job one time, you can specify a daily schedule with identical start and end dates.

Job Definition Syntax

The –edit and –set options create or modify jobs by using a declarative job definition language. The –get option displays a textual representation of currently defined jobs using the same language.

The job definition language has the following general features:

  • Each statement must occupy a single line, though job descriptions and output messages can occupy more than one line.
  • The language is case-insensitive.
  • Leading white space, lines beginning with a number sign (#), and blank lines are ignored, except within job descriptions.
  • The quotation character is double quote (").

A job definition file consists of a sequence of job definitions. Each job definition begins with the statement Job.Begin and ends with the statement Job.End. Between these statements are other statements that define job properties. A statement that defines a job property has the following form:

Job.property_namevalue

Some properties have fields. In this case the definition of a property consists of a sequence of statements, one for each field, with the following form:

Job.property_name.fieldvalue

Some fields themselves have subfields.

The value portion of some property definitions can contain a sequence of individual values separated by commas. No white space can appear before or after a comma that separates two values in a sequence. For the Args property, individual values are separated by white space.

Job properties are of two types:

  • Editable. You can define or modify the property. Some properties and fields are required; others are optional and have default values. When you define or modify a property, you must specify fields and subfields of that property in the order listed in Table 12 and Table 13.
  • Read-only. The scheduler defines the property, and you cannot define or modify it. When you create a job definition, the scheduler ignores all definitions of read-only properties. When you edit an existing job definition, the scheduler ignores all definitions of read-only properties except for Id. When you edit an existing job definition, the scheduler uses the Id, if present (and if not present, the Name), to identify the job to modify.

Table 12 lists editable job properties.

Table 12. Editable Job Properties

PropertyFieldValueDefault
Name name_string (quoted if it contains white space; must be unique across jobs)No default; a value is required.
DescriptionBegindesc_string (on subsequent lines only; maximum 255 characters)""
End(none) 
Schedule[a][b]No default; a value is required.
Task task_id (unsigned) | task_name (string)No default; a value is required.
Args arg_string [...] (arg_string quoted if it contains white space)No args
DeleteWhenCompleted TRUE | FALSE FALSE
NotifyInfoOnEventsJobBegin | JobEndOK | JobEndOKWithMsgs | JobEndFail | JobDeleted | JobModified [,...]If no NotifyInfo field is specified, no notifications are issued; if any NotifyInfo field is specified, all must be specified.
Usingemail
Recipientsaddress [,...]

Table 13 lists fields of the Schedule property. Schedules are of two types:

  • Periodic. The job runs on one or more days specified by the Monthly, Weekly, or Daily field.
  • Sequential. The job runs following completion of another job specified by the Sequential field.

The Monthly, Weekly, Daily, and Sequential fields are mutually exclusive; each job must have one and only one of these fields.

The StartDate, LastDate, FirstStartTime, StartTimeRestartFrequency, and LastStartTime fields are optional. One or more of these fields can appear along with a Monthly, Weekly, or Daily field. StartDate and LastDate determine the first and last dates the job is eligible to run on its monthly, weekly, or daily schedule. FirstStartTime determines what time the job first runs on each day it is scheduled. StartTimeRestartFrequency specifies an interval to wait before running the job again. LastStartTime is meaningful only with StartTimeRestartFrequency; it determines the last time the job is eligible to run on each day it is scheduled. If StartTimeRestartFrequency is specified for a job, the job will run every StartTimeRestartFrequency (for example, every two hours) until midnight or LastStartTime, whichever is earlier.

All dates and times are local to the host on which the scheduler is running. Date outputs are displayed in ISO format regardless of any user-specified preference for the display format of dates.

Table 13. Fields of the Job Schedule Property

Schedule fieldSubfieldValueDefault
MonthlyFrequencyevery_n_months (unsigned)No default; if any Monthly subfield is specified, all must be specified.
Dayday_number | ordinal_spec day_spec

(day_number ::= 1 ... 31)

(ordinal_spec ::= First | Second | Third | Fourth | Last)

(day_spec ::= Mon | Tue | Wed | Thu | Fri | Sat |Sun | Weekday | Weekendday | Day)

WeeklyFrequencyevery_n_weeks (unsigned)No default; if any Weekly subfield is specified, all must be specified.
DaysMon | Tue | Wed | Thu | Fri | Sat | Sun [,...]
DailyFrequencyevery_n_days (unsigned)No default
StartDate [d]dmonth[yy]yy

(month ::= January ... December | Jan ... Dec)

(Dates in ISO format are also accepted.)

Today
LastDate StartDate |[d]dmonth[yy]yy

(month ::= January ... December | Jan ... Dec)

(Dates in ISO format are also accepted.)

No last date
FirstStartTime [h]h:[m]m:[s]s (24-hour format)Now
StartTimeRestart Frequency [h]h:[m]m:[s]s (24-hour format)No restart
LastStartTime [h]h:[m]m:[s]s (24-hour format)Midnight
SequentialFollowsJobjob_id (unsigned) | job_name (string)No default

Table 14 lists read-only job properties. For the LastCompletionInfo property, ExitStatus is the value returned by the wait() system call on UNIX or by the GetExitCodeProcess() function on Windows. Only the first 511 bytes of standard output and error messages are displayed.

Table 14. Read-Only Job Properties

PropertyFieldValue
Id job_id (unsigned)
Predefined TRUE | FALSE
Created YYYYMMDDThh:mm:ss±hh:mm by user.group@host
LastModified YYYYMMDDThh:mm:ss±hh:mm by user.group@host
NextRunTime YYYYMMDDThh:mm:ss±hh:mm
RunningStatusProcessIdprocess_id (unsigned)
StartedYYYYMMDDThh:mm:ss±hh:mm
LastCompletionInfoProcessIdprocess_id (unsigned)
StartedYYYYMMDDThh:mm:ss±hh:mm
EndedYYYYMMDDThh:mm:ss±hh:mm
ExitStatusexit_status (hexadecimal)
Beginoutput_and_error_messages (on subsequent lines only)
End(None)

Following is an example definition the scheduler could display with the –get option for a job scheduled to run sequentially, including job properties defined by the scheduler:

Job.Begin
    Job.Id: 1
    Job.Name: "Daily VOB Pool Scrubbing"
    Job.Description.Begin:
Scrub the cleartext and derived object storage pools of all local VOBs.
    Job.Description.End:
    Job.Schedule.Daily.Frequency: 1
    Job.Schedule.StartDate: 2002-12-30
    Job.Schedule.FirstStartTime: 04:30:00
    Job.DeleteWhenCompleted: FALSE
    Job.Task: 3
    # Job.Task: "VOB Pool Scrubber"
    Job.Args:
    Job.NotifyInfo.OnEvents: JobEndOKWithMsgs,JobEndFail
    Job.NotifyInfo.Using: email
    Job.NotifyInfo.Recipients: root
    Job.Created: 2002-12-30T15:18:06-05 by rational.com/root@phenol
    Job.LastModified: 2002-12-30T15:18:06-05 by rational.com/root@phenol
    Job.Predefined: TRUE
    Job.NextRunTime: 2003-01-10T04:30:00-05
    Job.LastCompletionInfo.ProcessId: 21511
    Job.LastCompletionInfo.Started: 2003-01-09T04:30:00-05
    Job.LastCompletionInfo.Ended: 2003-01-09T04:39:27-05
    Job.LastCompletionInfo.ExitStatus: 0x100
    Job.LastCompletionInfo.Messages.Begin:
Thu Jan  9 04:39:26 EST 2003
ClearCase scrubber failed on phenol with exit status 1
Some VOBs were NOT scrubbed
See phenol:/var/adm/rational/clearcase/log/scrubber_log
    Job.LastCompletionInfo.Messages.End:
Job.End

Task Definition Syntax

A task must be defined in the task database before you can schedule the task. The task database is a text file, which you can edit using a text editor. The task database contains definitions that use a declarative task definition language similar to the job definition language.

The task definition language has the following general features:

  • Each statement must occupy a single line.
  • The language is case insensitive.
  • Leading white space, lines beginning with a number sign (#), and blank lines are ignored.
  • The quotation character is double quote (").

The task database file consists of a sequence of task definitions. Each task definition begins with the statement Task.Begin and ends with the statement Task.End. Between these statements are other statements that define task properties. A statement that defines a task property has the following form:

Task.property_namevalue

In the task database, definitions of standard tasks appear first. You must not change or delete any of these definitions. You can add task definitions of your own at the end of the task database file.

Table 15 lists task properties.

Table 15. Task Properties

PropertyValue
Idtask_id (unsigned; must be unique across tasks; for user-defined tasks, must be 100 or greater)
Namename_string (quoted if it contains white space; must be unique across tasks)
Pathnamepathname_string (quoted if it contains white space)
UIInfoinfo_string (private to ClearCase and ClearCase LT)

The scheduler uses the task Id property in a job definition to identify the task to run. If any scheduled jobs use a task Id, you must be careful not to change the task's Id property in the task database without also changing all references to that property in the database of scheduled jobs.

The Pathname value is the pathname of the executable to be invoked when the task is run. The pathname can be relative or absolute. If it is relative, the scheduler looks first for the task in these directories in this order:

PlatformFirst locationSecond location
UNIXccase-home-dir/config/scheduler/tasks/var/adm/rational/clearcase/scheduler/tasks
Windows ccase-home-dir\config\scheduler\tasksccase-home-dir\var\scheduler\tasks

The optional UIInfo property describes the task's command-line interface, such as the types of arguments the task can take. This property is used internally by ClearCase and ClearCase LT; do not specify it for a user-defined task.

Following is an example read-only definition for a standard task:

Task.Begin
    Task.Id:       2
    Task.Name:     "View Space"
    Task.Pathname: view_space.sh
    Task.UIInfo:   "view-spec"
Task.End

Following is an example definition for a user-defined task:

Task.Begin
    Task.Id:       100
    Task.Name:     "Daily Local Tasks"
    Task.Pathname: ccase_local_day.sh
Task.End

Job Execution Environment

Each task runs in a separate process started by the albd_server. A task has the following execution environment:

  • The user identity of the task is the same as that of the albd_server (root on UNIX; typically, the clearcase_albd account on Windows).
  • The standard input stream is closed.
  • Standard output and error messages are redirected to a file and captured by the scheduler as part of the job's LastCompletionInfo property.
  • The current directory is undefined.
  • Environment variables are those in effect for the albd_server. In addition, on Windows systems, CLEARCASEHOME is set to ccase-home-dir.

RESTRICTIONS

The scheduler maintains a single access control list (ACL). The ACL determines who is allowed access to the scheduler and to the ACL itself.

The –edit –acl and –set –acl options modify the ACL using a declarative ACL definition language. The –get –acl option displays the current ACL.

The ACL definition consists of a sequence of ACL entries. Each ACL entry must occupy a single line. Leading white space, lines beginning with number sign (#), and blank lines are ignored. Each ACL entry has the following form:

identity_type:identity access_type

Table 16 lists the identity types and identities allowed in ACL entries. The identity types are case insensitive.

Table 16. Identity Types and Identities in Scheduler ACL Entries

Identity TypeIdentity
Everyone(None)
Domaindomain_name
Groupdomain_name/group_name | domain_name\group_name
Userdomain_name/user_name | domain_name\user_name

In the identity portion of an ACL entry, the domain_name is an NIS domain for UNIX clients of the scheduler and a Windows NT Server domain for Windows clients of the scheduler. Note that you must supply a domain in the identity portion of a Group or User ACL entry. For an ACL entry with a Windows NT Server domain, group_name must be a global group, and user_name must be a domain user account. Names of domains, groups, and users are case insensitive for the scheduler.

Note that no white space can appear anywhere in an identity_type:identity specification.

Table 17 lists the access types allowed in ACL entries. The access types are case insensitive.

Table 17. Access Types In Scheduler ACL Entries

Access typeAccess to scheduleAccess to ACL
ReadRead onlyRead only
ChangeRead and write; can start jobsRead only
FullRead and write; can start jobsRead and write

Each combination of domain and group or of domain and user represents a single identity. (Note that NIS domains differ from Windows NT Server domains, so a group or user in an NIS domain represents a different identity from the same group or user in a Windows NT Server domain.) Each single identity can have only one access type. However, access rights are inherited from Everyone to Domain to Group to User in such a way that each user has the least restrictive of all these access rights that apply to that user. For example, if a user's ACL entry specifies Read access but the ACL entry for the user's group specifies Change access, the user has Change access. The order of ACL entries is not significant.

  • In ClearCase, root (UNIX) or a member of the ClearCase administrators group (Windows) always has Full access to the scheduler on the local host (the computer where that user is logged on).
  • In ClearCase LT, Full access is granted to the local administrator of the ClearCase LT server running on a Windows host or to root on a UNIX host

Access rights of these identities to a scheduler on a remote host are determined by the scheduler's ACL. The default ACL is as follows:

Everyone: Read

This means that by default, everyone can read the schedule, but only the highly privileged identities logged on to the computer where the scheduler is running can modify the schedule or the ACL.

Following is an example ACL definition:

# NIS domain acme.com
Domain:acme.com Read
# Windows NT Server domain acme
Domain:acme Read
Group:acme\users Change
User:acme.com\fran Full
User:acme\fran Full

OPTIONS AND ARGUMENTS

Specifying the Host

–hos·t hostname
Specifies the host whose schedule the command operates on. The ClearCase default is the local host. The ClearCase LT default is the ClearCase LT server host.

Disabling Prompts tor Confirmation

–f·orce
Suppresses all prompts to confirm changes. By default, the command asks for confirmation before changing a schedule or ACL.

Displaying Information About Jobs, Tasks, or ACL

–get [ –sch·edule ]
Displays currently scheduled jobs using the scheduler's job definition language. For more information, see “Job Definition Syntax”. This is the default action for the –get option.

–get –job job-id-or-name
Displays the currently scheduled job identified by job-id-or-name, which is either a number representing the job ID or a string representing the job name. The job display uses the scheduler's job definition language. For more information, see “Job Definition Syntax”.

–get –tas·ks
Displays the tasks defined in the task database using the scheduler's task definition language. For more information, see “Task Definition Syntax”.

–get –acl
Displays the scheduler's access control list (ACL) using the scheduler's ACL definition language. For more information, see Restrictions.

Editing a Schedule or ACL

–edi·t [ –sch·edule ]
Opens in a text editor a schedule that contains definitions of currently scheduled jobs that use the scheduler's job definition language. You can use the editor to add, delete, or modify job definitions. When you are finished, save the modified schedule and quit the text editor. The scheduler then replaces the current schedule with the edited version. For more information, see “Job Definition Syntax”. This is the default action for the –edit option.

–edi·t –acl
Opens in a text editor a file that contains the current ACL entries that use the scheduler's ACL definition language. You can use the editor to add, delete, or modify ACL entries. When you are finished, save the modified ACL and quit the text editor. The scheduler then replaces the current ACL with the edited version. For more information, see Restrictions.

Setting a Schedule or ACL Using Definitions in a File

–set [ –sch·edule ] defn-file-pname
Replaces all currently scheduled jobs with the jobs defined in the file whose pathname is defn-file-pname. The definitions in the file use the scheduler's job definition language. For more information, see “Job Definition Syntax”. This is the default action for the –set option.

–set –acl defn-file-pname
Replaces the current ACL with the ACL defined in the file whose pathname is defn-file-pname. The definitions in the file use the scheduler's ACL definition language. For more information, see Restrictions.

Operating on a Scheduled Job

–del·ete job-id-or-name
Deletes the scheduled job identified by job-id-or-name, which is either a number representing the job ID or a string representing the job name.

–run job-id-or-name
Immediately executes the scheduled job identified by job-id-or-name, which is either a number representing the job ID or a string representing the job name. The job is run in the scheduler's job execution environment. For more information, see “Job Execution Environment”.

–wai·t job-id-or-name
Waits for completion and displays status of the scheduled job identified by job-id-or-name, which is either a number representing the job ID or a string representing the job name. This option has no effect if the job is not running.

–sta·tus job-id-or-name
Displays the status of the scheduled job identified by job-id-or-name, which is either a number representing the job ID or a string representing the job name. Displays the most recent process ID, start time, end time, and exit status for the job.

EXAMPLES

The UNIX examples in this section are written for use in csh. If you use another shell, you may need to use different quoting and escaping conventions.

The Windows examples that include wildcards or quoting are written for use in cleartool interactive mode. If you use cleartool single-command mode, you may need to change the wildcards and quoting to make your command interpreter process the command appropriately.

In cleartool single-command mode, cmd-context represents the UNIX shell or Windows command interpreter prompt, followed by the cleartool command. In cleartool interactive mode, cmd-context represents the interactive cleartool prompt.

  • Display the scheduled job named "Daily VOB Pool Scrubbing".

    cmd-context schedule –get –job "Daily VOB Pool Scrubbing" 
    Job.Begin
        Job.Id: 1
        Job.Name: "Daily VOB Pool Scrubbing"
        Job.Description.Begin:
    Scrub the cleartext and derived object storage pools of all local VOBs.
        Job.Description.End:
        Job.Schedule.Daily.Frequency: 1
        Job.Schedule.StartDate: 2002-12-30
        Job.Schedule.FirstStartTime: 04:30:00
        Job.DeleteWhenCompleted: FALSE
        Job.Task: 3
        # Job.Task: "VOB Pool Scrubber"
        Job.Args: 
        Job.NotifyInfo.OnEvents: JobEndOKWithMsgs,JobEndFail
        Job.NotifyInfo.Using: email
        Job.NotifyInfo.Recipients: root
        Job.Created: 2002-12-30T15:18:06-05 by rational.com/root@phenol
        Job.LastModified: 2002-12-30T15:18:06-05 by rational.com/root@phenol
        Job.Predefined: TRUE
        Job.NextRunTime: 2003-01-10T04:30:00-05
        Job.LastCompletionInfo.ProcessId: 21511
        Job.LastCompletionInfo.Started: 2003-01-09T04:30:00-05
        Job.LastCompletionInfo.Ended: 2003-01-09T04:39:27-05
        Job.LastCompletionInfo.ExitStatus: 0x100
        Job.LastCompletionInfo.Messages.Begin:
    Thu Jan  9 04:39:26 EST 2003
    ClearCase scrubber failed on phenol with exit status 1
    Some VOBs were NOT scrubbed
    See phenol:/var/adm/rational/clearcase/log/scrubber_log
        Job.LastCompletionInfo.Messages.End:
    Job.End

  • Edit the scheduler ACL.

    cmd-context schedule –edit –acl 
    Replace the ACL? [yes]

  • Set the schedule on host acme1 from job definitions in the file jobdefs.txt.

    cmd-context schedule –host acme1 –set jobdefs.txt 
    Replace the entire schedule? [yes]

  • Display the status of the scheduled job with the ID 2.

    cmd-context schedule –status 2
    Job is not currently running.

        RunningJob.CompletionInfo.ProcessId: 21518
        RunningJob.CompletionInfo.Started: 2003-01-09T04:39:27-05
        RunningJob.CompletionInfo.Ended: 2003-01-09T04:40:03-05
        RunningJob.CompletionInfo.ExitStatus: 0x0

UNIX FILES

ccase-home-dir/config/scheduler/initial_schedule
ccase-home-dir/config/scheduler/tasks/templates/task_registry
ccase-home-dir/config/scheduler/tasks/templates/ccase_local_day.sh
ccase-home-dir/config/scheduler/tasks/templates/ccase_local_wk.sh
/var/adm/rational/clearcase/scheduler/db
/var/adm/rational/clearcase/scheduler/tasks/task_registry
/var/adm/rational/clearcase/scheduler/tasks/ccase_local_day.sh
/var/adm/rational/clearcase/scheduler/tasks/ccase_local_wk.sh

WINDOWS FILES

ccase-home-dir\config\scheduler\initial_schedule
ccase-home-dir\config\scheduler\tasks\templates\task_registry
ccase-home-dir\config\scheduler\tasks\templates\ccase_local_day.bat
ccase-home-dir\config\scheduler\tasks\templates\ccase_local_wk.bat
ccase-home-dir\var\scheduler\db
ccase-home-dir\var\scheduler\tasks\task_registry
ccase-home-dir\var\scheduler\tasks\ccase_local_day.bat
ccase-home-dir\var\scheduler\tasks\ccase_local_wk.bat

SPONSORED LINKS



 

ClearCase Links • ClearCase Books • ClearCase Commands Reference • ClearCase Forums • ClearCase News