The scheduler file name must be completely and absolutely specified and be given an ".exe" ending on Windows systems. This is because the JobScheduler requires the complete file name in order to be able to start either a job or itself.

The "-config=" prefix before file names can be omitted.

This option specifies the configuration file or configuration directory. Should a configuration directory be specified, then the JobScheduler will expect to find the configuration file in the configuration directory, under the name scheduler.xml.

On Unix systems: the JobScheduler writes its process ID (PID) in this file. This file is deleted by the JobScheduler on stopping.

See also and .

Note that if a port is blocked, the JobScheduler will attempt to access it for two minutes before terminating itself.

See also .

See also .

This option should only be used in exceptional situations, as it switches off the test whether or not a port has been set free by the operating system.

Calls setsockopt(socket,SOL_SOCKET,SO_REUSEADDR,true).

This option should only be used in an emergency, should a port be permanently blocked by the operating system although it is no longer used by an application. This can happen with Windows XP, when an application is terminated by a debugger and UNIX can take up to a minute to release a port.

In some situations the JobScheduler cannot be reached with -reuse-port via TCP or UDP, when the port is being used by other applications. The use of -reuse-port is not recommended.

The JobScheduler executes xml commands such as immediately on starting.

Specifies the Path/ Name for an alternative factory.ini file.

When references in this documentation are made to the factory.ini file, it should be clear that the value given in this option is meant.

See also

Specifies the Path/ Name for an alternative sos.ini global configuration file. Note that this file contains the JobScheduler license key.

This option is used when the JobScheduler is called from a Java class file (for example, when debugging) and jobs are to be started in their own processes.

The JobScheduler runs in the background under Unix, therefore no output can be written to the terminal; output for stdout und stderr should be redirected to a file in order to prevent loss.

-validate-xml- switches the validation off (should the schema have errors).

JobScheduler use a build-in schema for validating the configuration files. With this option you can overwrite it.

-env=NAME=VALUE sets the NAME environment variable.

Requires use of a database - see .

More than one JobScheduler with the same Scheduler-Id () and the same database can be started with -exclusive. In this case, then only one JobScheduler will become active. It is only after this active JobScheduler fails or is stopped (), that another JobScheduler will become active and take over operation. The takeover takes approximately one minute.

Warning: All participating JobSchedulers must be started -exclusive or . When one JobScheduler is started with and one without this setting, then two JobSchedulers will run simultaneously, which can lead to unexpected results.

See also .

Only possible in combination with .

A backup JobScheduler only takes over operation - it cannot start a new operation. This means that after the backup JobScheduler does not start, but waits for another JobScheduler to start operation.

-backup is allocated its own service name when used together with and . This means that the backup JobScheduler can be run on the same computer as the active JobScheduler as its own service.

The name of the main log file contains the "_backup" suffix.

Only possible in combination with .

When more than one inactive backup JobSchedulers are available to replace a failed JobScheduler, (), then operation is taken over by the JobScheduler allocated the lowest value.

Note that it is possible for another JobScheduler as that dictated by the highest backup-precedence to take over operation, should the backup JobSchedulers run on different computers and should the clocks of these computers not be synchronized,

The default value is 1, when is set, otherwise it is 0.

Requires use of a database (). More than one JobSchedulers can share the execution of orders, when they are all started under the same Scheduler-Id (), use the same database and the same configuration.

allows a job chain to be used for distributed operation.

The default directory is the live directory, which is specified in the ().

The JobScheduler looks in this directory for jobs, job chains, permanent orders, process classes and locks. 

scheduler -java-classpath = s:\prod\bind\sos.*.jar;c:\jar\my.jar;c:\jar\*

The Java CLASS_PATH setting is made here. This is a list of paths - on Windows Systems these paths are separated by semi-colons (;), on Unix systems by colons (:).

Note that jokers can be used in these paths. The JobScheduler then replaces these jokers with the respective file names. i.e. those existing in the file system.

  • On Windows systems, the * and ? characters may be used after the last directory separator.
  • On Unix systems the [ and ] characters can also be used. Jokers can be used in every folder name of a path (as in the csh shell).
  • Linux (GNU) also recognizes the {,} characters, when used in the following syntax:
    "xxx{alternative1,alternative2,...}xxx", e.g. /dir/sos.{hostware,mail.spooler}.jar.

The following points apply to every path in the class_path:

  • A path without a joker will be handed over to Java unchanged.
  • A path containing a joker will be converted to the existing path before being handed over.
  • Should no path corresponding to a joker be found then the path will be ignored.
  • A path will also be ignored should it refer to a directory which cannot be read.
  • Environment variables (e.g. ${HOME}) will be replaced before a path is converted.

These settings are generally made in the file.

This setting specifies the directory in which the HostJava is installed - e.g. -Djava.library.path=.

These options are passed to the Java Virtual Machine.

These settings are generally made using .

See

See

See also . 

c:\bin\scheduler.exe c:\scheduler\config.xml -log-dir=c:\scheduler\logs

The JobScheduler is not started by this option but installed as a Windows service. In this case the following command line options may be specified:









Note that -install-service=name is the same as -install-service -service-name=name.

Removes a service which was previously installed using -install-service.

-remove-service= name is the same as -remove-service -service-name= name.

Only used together with -install-service or -remove-service. When this option is missing but -id=is specified, then the JobScheduler uses the name sos_scheduler_ scheduler_id. If has been set, then this option adds _backup.

Only used in conjunction with the -install-service. This name is shown by the Windows service controller. It may contain spaces. Should this option not be specified, the JobScheduler creates a name from the service name (see -service-name=).

Only used together with the -install-service.

This option specifies a service such as a database server which must be running before Windows starts the JobScheduler. This option must be used in conjunction with the -install-service.

This option can be repeated should the JobScheduler require a number of services.

The name (or IP number) and port number of the JobScheduler being addressed.

The name of the temporary job process class -, see .

Script language, see .

Start time - in the form "yyyy-mm-dd HH:MM[:SS]". See .

A job will not be started after its start time has been passed.

The JobScheduler uses the current time from the computer on which it is running when, for example, starting jobs.

-at=now is the default setting and causes a job to be started immediately.

A temporary job is forwarded to the target JobScheduler, which is addressed using .

This job only exists until the JobScheduler is restarted. 

echo ls -l | scheduler -scheduler=localhost:4444 -at="2006-04-04 12:00"

The name of the job chain on which an order is to be run - see .

The order identifier - see .

An order can be given a title. See .

is used to define the JobScheduler which an order is forwarded to.

The order parameters (see ) can be forwarded to the command line in the form:name=value. 

scheduler -scheduler=localhost:4444 -job-chain=my_job_chain -order-id=123 city=Berlin phone="+4930 864790-0"

This option does not start a JobScheduler but sends an XML command to another JobScheduler on the same computer which has the same -tcp-port= option. This can be, for example, : -send-cmd="<terminate/>"

This command is sent to the IP address specified in the attribute or, should this not have been set, to 127.0.0.1.

Stops a JobScheduler whose process is specified in the file. The JobScheduler is stopped using kill -SIGKILL.

Stops the process with the specified PID using kill -SIGKILL. 

scheduler -kill -pid-file=/home/scheduler/scheduler.pid

Expands the Java Class Path, which is specified as a parameter. This means that jokers are processed as .

The JobScheduler writes the results to stdout. Unless otherwise specified in an option, the JobScheduler will then terminate itself, without any other output. 

export CLASSPATH="`scheduler -expand-classpath='/opt/java/lib/*.jar'`"

Causes the JobScheduler to output its version number and date when starting.

Shows the command line options.

Shows the command line options.

The JobScheduler is started using a straightforward command. 

C:\>…scheduler installation path…\bin\scheduler.exe …\my_scheduler_configuration.xml …
user@host:~>…installation path…/bin/scheduler …/my_scheduler_configuration.xml …

Parameters for the command line operations described here and which are written to the right of the "=" can be set in inverted commas ("") or in apostrophes / single quotes ('').

The JobScheduler installation program creates the start script - either .\bin\jobscheduler.cmd (Windows) or ./bin/jobscheduler.sh (Unix), in which command line options and environment variables are already set. This script can be modified as required.

Note that the start script and environment variables are described in the »Installation and Configuration« handbook.