hvrscheduler - HVR Scheduler server.
hvrscheduler [-options] hubdb
The HVR Scheduler is a process which runs jobs defined in the catalog table HVR_JOB. This catalog table can be found in the hub database.
These jobs are generated by commands Hvrinit, Hvrrefresh and Hvrcompare. After they have been generated these jobs can be controlled by attributes defined by the jobs themselves and on the job groups to which they belong. These attributes control when the jobs get scheduled.
The first argument hubdb specifies the connection to the hub database. This can be an Oracle, Ingres, SQL Server, DB2, DB2 for I, PostgreSQL, or Teradata database depending on its form. See further section Calling HVR on the Command Line.
On Unix, the HVR Scheduler runs as a daemon. It can be started and stopped within the HVR GUI. Alternatively, on the Unix command line, it can be started using command hvrscheduler hubdb (no options) and stopped using hvrscheduler -k.
On Windows, the HVR Scheduler runs as a system service. It can be started and stopped within the HVR GUI. Alternatively, on the Windows command line, it can be created using command hvrscheduler -ac, started with hvrscheduler -as and stopped with hvrscheduler -ah.
Internally the HVR Scheduler uses a concept of 'Job Space', a two-dimensional area containing jobs and job groups. A job group may contain jobs and other job groups. In Job Space, jobs are represented as points (defined by X and Y coordinates) and job groups are represented as boxes (defined by four coordinates minimum X, maximum X, minimum Y and maximum Y). All jobs and job groups are contained within the largest job group, which is called system.
This section describes the options available for command hvrscheduler.
Administration operations for the HVR Scheduler Microsoft Windows system service. Allowed values of x are:
Several -ax operations can be supplied together, e.g. -acs (create and start) and -ahd (halt and destroy). Operations -as and -ah can also be performed from the window Settings ▶ ControlPanel ▶ Services of Windows.
Enroll the Scheduler Service in a Windows cluster named clus in the cluster group clusgrp. Once the service is enrolled in the cluster it should only be stopped and started with the Windows cluster dialogs instead of the service being stopped and started directly (in the Windows Services dialog or with options -as or -ah). In Windows failover clusters clsgrp is the network name of the item under Services and Applications. The group chosen should also contain the DBMS service for the hub database and the shared storage for HVR_CONFIG. The service needs to be created (with option -ac) on each node in the cluster. If this option is used to create the scheduler service in a cluster group, then it should also be added to option -sched_option of command Hvrmaint. This service will act as a 'Generic Service' resource within the cluster. This option must be used with option -a.
Set environment variable n to value v for this process and its children.
Specify hub database. Valid values are oracle, ingres, sqlserver, db2, db2i, postgresql, and teradata. See also section Calling HVR on the Command Line.
Interactive invocation. HVR Scheduler does not detach itself from the terminal and job output is written to stdout and stderr as well as to the regular logfiles.
Kill old HVR Scheduler and any jobs which it may be running at that moment.
Configure the HVR Scheduler system service to run under the current login account using password pwd, instead of under the default system login account. May only be supplied with option -ac. Empty passwords are not allowed. The password is stored (hidden) within the Microsoft Windows OS and must be re-entered if passwords change.
Internal slave co-process. The scheduler uses two co-processes at runtime; one to make SQL changes to the hub database (-swork), and the other for listening for database events (-slisten).
Timeout for connection to old HVR Scheduler process. The default is 10 seconds.
Connect to hub database using DBMS account user. For some databases (e.g. SQL Server) a password pwd must also be supplied.
The HVR Scheduler schedules jobs. Each job performs a certain task. At any moment a job is in a certain state. For instance, when a job is waiting to be run, it is in state PENDING; when a job is running, it is in state RUNNING.
Jobs can be either acyclic or cyclic. Acyclic jobs will only run once, whereas cyclic jobs will rerun repeatedly. When a cyclic job runs, it goes from state PENDING to RUNNING and then back to state PENDING. In this state it waits to receive a signal (trigger) in order to run again. When an acyclic job runs, it goes from state PENDING to RUNNING and then disappears.
If for some reason a job fails to run successfully the scheduler will change its state first to ALERTING, then RETRY and will eventually run again. If a job stays in state RUNNING for too long it may be marked with state HANGING; if it finishes successfully it will just become PENDING.
Each message written by an HVR job is redirected by the scheduling server to multiple logfiles. This means that one logfiles exists with all output from a job (both its stdout and stderr). But another file has the stderr from all jobs in the channel.
Scheduler attributes are a component which is used to internally communicate (at the moment that HVR Initialize is run) the definition of features such as Scheduling /CaptureStartTimes to the run-time system. They are exposed in the HVR User Interface to allow the verification that these Scheduling actions have been propagated to the run-time system.
These scheduler attributes will be redesigned in a future HVR version. It is recommended not to change scheduler attributes that HVR generates automatically or not to create new ones.
Maximum number of jobs which can be in RUNNING or HANGING state in job group. So if attribute quota_run 2 is added to job groups CHN1, CHN2 and quota_run 3 is added to job group SYSTEM, then only two jobs can run for each channel (CHN1 and CHN2) and only three jobs can run in the whole system.
Maximum number of child processes associated with jobs in job group, including running jobs, but excluding the scheduler's own 'slave' processes.
Limit the speed with which the scheduler starts jobs to no more than q job executions inside secs seconds. For example, quota_speed 20 1 means that if there are lots of job ready to be started, then the scheduler will only start 20 jobs per second.
Trigger cyclic job secs seconds after it last finished running (column job_last_run_end of HVR_JOB). If a cyclic job is not affected by any trig_delay attribute, it will remain PENDING indefinitely.
Trigger job at crono moment. For the format of crono see Scheduling /CaptureStartTimes.
Trigger job at specific (time) moment. Valid formats are YYYY-MM-DD [HH:MM:SS] (in local time) or YYYY-MM-DDTHH:MM:SS+TZD or YYYY-MM-DDTHH:MM:SSZ or today or now[±SECS] or an integer (seconds since 1970-01-01 00:00:00 UTC).
Allow n retries for an unsuccessful job. If n is zero no retry is allowed. Jobs unaffected by this attribute are not retried: on error they become FAILED directly.
Initially retry job after isecs and double this delay for each unsuccessful retry until fsecs is reached. Default value is 60 3600.
After job has been in RUNNING state for secs seconds, write time-out message and change its job state to HANGING. If secs is zero then no time-out will occur.
Terminates the job in RUNNING or HANGING state after it has run secs seconds. If secs is zero then no time-out will occur.
Set variable name to value val in job’s runtime environment.
Causes the HVR Scheduler to write a copy of each critical error tot the file named in the variable's value. This can be used to ensure all HVR error messages from different hub databases on a single machine can be seen by scanning a single file. Long messages are not wrapped over many lines with a backslash '\', but instead are written on a single line which is truncated to 1024 characters. Each line is prefixed with "HVR_ITO_AIC hubnode:hubdb locnode", although HVR is used instead of $HVR_ITO_AIC if that variable is not set.
Instructs the HVR Scheduler to listen on an additional (public) TCP/IP port number.
In Unix, start HVR Scheduler as a Unix daemon.
In Windows, create and start HVR Scheduler as a Windows Service.
When starting the HVR Scheduler it is important that a database password is not exposed to other users. This can be encrypted using command hvrcrypt.
Perl script used by scheduler to decide if jobs should be retried.
Patterns indicating which errors can be handled by retrying a job.
Current node running scheduler.
All messages for job jobname.
Only error messages for job jobname.
All messages for channel chn.
Only error messages for channel chn.
All messages for all jobs.
Only error messages for all jobs.
Log file for actions from control sessions.
Working directory for executing jobs.