Basic Configuration
Before you run TES, you should customize its configuration to suit the needs of your organization. You can add or adjust production schedule parameters, mail configuration, default job properties, security restrictions and many other details. One of TES’s many strengths is its flexible architecture.
During installation of TES, one user account is created containing the installer’s user name. Included in the user record is a security policy which is a list of the TES functions that are available to you. By default, this account is considered the TES Administrator and has the ability to perform all functions (Super User).
Basic configuration is complete when you have finished adding users. Advanced configuration options include creating and editing security policies, setting logging options and creating queues and agent lists. The Cisco Tidal Enterprise Scheduler User Guide contains detailed information about using and configuring TES.
You can configure most properties of the master through the System Configuration dialog box of the Tidal Web client while other major master parameters are managed through the master.props file on the master machine as described later in this chapter.
Note Ensure that the regional settings used by the Tidal Web clients are the same as the regional settings used on the Window master. Different regional settings may use different formatting for dates and time. If the master is not using the same regional settings, alerts and job activity may not operate correctly.
Configuring Tidal Web client
Launching the Tidal Web client
To launch the Tidal Web client:
Go to http://<servername>:8080/client and log on using install Super User’s network credentials.
System Configuration
Before using TES, configure master operation parameters, job defaults, mail system connections (if you are using email), and job status sort order.
To configure:
Step 1 Launch the Tidal Web client.
Step 2 From the Activities menu, choose System Configuration. The System Configuration dialog box displays.
Figure 8-1 System Configuration Dialog Box
Refer to the Getting Started chapter in the Cisco Tidal Enterprise Scheduler User Guide for more information on the options in the System Configuration dialog box.
Master Tab
Basic operational behavior of the master is controlled by the settings on this tab.
This tab contains the following elements:
|
|
Master Configuration Data Panel
|
Future Days to Include in Schedule |
Controls the number of future days to include in the production schedule when the master does its daily compilation. Larger values let you schedule jobs farther into the future. Lower values reduce compilation time. Note When you change the Future Days to include Schedule value, the new value will not take effect until the production schedule is compiled. Compilation takes place at midnight, by default. |
Operator Alert Retention |
The number of days to keep operator alert information in the Job Activity pane. Note By default, alerts are kept for seven days. Alerts that are older than the Operator Alert Retention value are purged daily. |
Trigger History Retention (in days) |
Sets the default number of days to maintain event trigger history on the Trigger History tab of the Event Details dialog box. The maximum length of time to ke ep trigger history information is 9,999 days but this length of time requires very large amounts of hardware and resources and hampers performance. The default setting is for 30 days. |
Use Passwords to Run Windows Jobs |
Enables (if checked) Windows agents to use Windows passwords. Windows agents can be configured to use a per-job password. Each scheduled job can be configured to run under a specific username and password (runtime users). The job inherits the permissions and resources of the assigned user account. This means that all runtime users require valid passwords. Any jobs that log on as users with invalid or missing passwords will fail with a status of “Error Occurred.” TES stores the passwords in encrypted form within its own database. At no time is an unencrypted password echoed to the screen or made otherwise accessible to any user. Passwords are also encrypted when passed from a master to an agent. For more information on the security rights needed to run Windows jobs refer to the User Security Requirements.
Caution Checking the passwords of multiple users when running jobs restricts the Windows agent to only processing 30 jobs concurrently. If passwords are not used when running Windows jobs, the Windows agent can handle up to 80 concurrent jobs.
TES stores the passwords using 64-bit block cipher encryption within its own database. At no time is an unencrypted password echoed to the screen or made otherwise accessible to any user. Passwords are also encrypted when passed from a master to an agent. |
Automatic Daily History Cleanup |
When this option is selected, TES automatically purges the database everyday. By default, the purge is executed at the beginning of the new production day. Note The master will log any errors when purge is performed automatically. When this option is not selected, TES will not automatically purge your database of old information history. It is up to the user to manually perform the purge. The user can script or manually execute the purge. |
FTP Local User Mandatory |
Requires that a local (or runtime) user be selected on the Run tab of FTP job definitions. Using a runtime user adds additional security to FTP jobs. The default is to not use a runtime user (unselected). If this option is selected, any previous FTP jobs that were defined without assigning a local user, will error out until a local user is assigned to the job. |
Carryover Options for Unfinished Schedule Panel
|
Note The following exceptions apply to these global carryover settings:
- The carryover configuration of a parent job overrides the settings in its child jobs. So if the carryover option is disabled in a child job but the parent job is set to the carryover, the child job will be set to carryover.
- If a job is configured to run within a time window and the time window has passed when the job carries over then the job will not carryover once the job has timed out.
- Individual jobs can override global carryover settings by selecting the Disable carryover option on the Options tab of a job definition.
|
None (except Launched/Active Jobs) |
Do not transfer any jobs from the current production schedule to the next production schedule unless the jobs have already launched or are in active status. (On an individual basis, jobs can be prevented from carrying forward by selecting the Disable carryover option from the Options tab of the Job Definition dialog box.) |
Successors only (unless disabled for job) |
Transfers to the following production schedule any successor jobs from active jobs in the current production schedule unless the Disable carryover option was selected in a job’s definition. |
All Unfinished Jobs (unless disabled for job) |
Transfers any jobs that did not run in the current production schedule to the following production schedule unless the Disable carryover option was selected in a job’s definition. |
Wait until previous schedule completes before starting new schedule |
This option prevents any jobs from a new production schedule regardless of their priority from running until all of the jobs from the previous schedule are completed or cancelled. If the production day rollover is held up while waiting for the previous day’s jobs to complete, a warning is recorded in the Audit log. To rollover to a new production schedule after selecting this option, you must either cancel the previous day’s jobs that are still running or change the jobs’ status to completed. |
Days to Carry Over |
Use this option to specify the number of days to carry over unfinished jobs. When the number you specify is reached, TES will no longer include the jobs that have not run yet in the next production schedule. |
Production Day Offset [+/- hh:mm] |
The Production Day Offset value adjusts the beginning of the production “day” to start the specified number of hours/minutes before or after midnight of the “real” day. For example, if you enter a +03:00, your calendar for the day will not start until 3:00 am. Note If the production day offset is modified, you must recompile the current and future production schedule for the changes to take effect. If a negative offset is specified, the master should be restarted and then the current and future production schedules must be recompiled. |
Compile Offset [+/- hh:mm] |
This option adjusts your compile time to start the specified number of hours/minutes before or after the beginning of the production day. The default compile time is midnight, because midnight is the default time for the beginning of the production day. If you have set a Production Day Offset value (above) the Compile Offset value will be adjusted from the new beginning of the production day. |
Week Begins |
This option affects the starting date of all subset calendars that use weekly definitions. After changing the value in this tab, choose Recalculate from the Calendars pane context menu to have the changes take effect. |
Defaults Tab
The Defaults tab allows you set default job properties that will apply whenever a user create a new job. These defaults can be changed for individual job definitions.
This tab contains the following elements:
Table 8-1 Defaults Tab Elements
|
|
|
Agent Name |
Sets the default agent for the Agent Name setting in the Job/Group Definition dialog boxes. |
Job History Retention (in days) |
Sets the default number of days of job history to keep. The Job History Retention setting can be individually configured for jobs on the Options tab of the Job/Group Definition dialog boxes. The maximum length of time to keep job history information is 9,999 days but this length of time requires very large amounts of hardware and resources and hampers performance. |
Job Priority |
Sets the default for the Job Priority setting in the Job/Group Definition dialog boxes. |
If job is currently running |
Sets the default for the If job is currently running setting (concurrency) in the Job Definition dialog boxes. There are four options:
- Run Anyway Run another job instance even if the previous instance is still running.
- Skip Do not run another job instance if the previous instance is running.
- Defer until Normal Run another job instance only if the current job instance completes with a Normal status.
- Defer Until Complete Run another job instance only after the current job instance completes.
|
Base time needed to run job on |
Sets the default basis for evaluating whether jobs will complete before a scheduled outage. Whether jobs have adequate time to run can be based on either of the following factors:
- Estimated Duration The estimated duration for the command or executable as specified in the job definition. If the job has run more than once with the same command or executable, the estimated duration is the historical average of the job’s previous run times. You can also manually set the estimated duration time of a job in its definition.
- Maximum Duration The maximum duration for the command or executable as specified in the job definition. If the job has run more than once with the same command or executable, the estimated duration is the historical average of the job’s previous run times. You can also manually set the estimated duration time of a job in its definition.
|
If not enough time before outage |
Sets the default action for occasions when a job may run into an outage window as based on the evaluation option set in the Base time needed to run jobs on field. There are three options:
- Run Anyway Run the job instance even at the risk that the job may not complete before the outage window.
- Skip Do not run the job instance if it may run into an outage window.
- Defer Wait to run the job until after the outage window has ended.
|
Unscheduled allowed |
Sets the default for the Unscheduled Allowed setting in the Job Definition dialog boxes. |
Disable carryover |
Prevents any jobs that did not run during the current production schedule from being carried over to the next production schedule. If you wish to carry over jobs to the next production schedule, refer to the Carryover Options for Unfinished Schedule section on the Master tab to configure which jobs should carry over to the next day’s production schedule. |
For Unix, source user’s profile |
Allows you to execute Unix user profiles. This global option provides for the execution of all variables in a Unix user’s profile. This option is available in individual job definitions on the Options tab so that job instances do not have to default to a source user’s profile. Without this option, any Unix user profile variables that are referenced by scripts will not be executed, causing a job to fail in TES. |
Save Output |
Sets the default handling of job output.
- Discard Does not save the job output. (Default)
- Append Saves the complete output from each job instance, adding the output to the previous job instance’s output.
- Replace Saves the complete output from each job instance, overwriting the previous job instance’s output.
|
Summary Only for ERP Jobs |
This check box only applies to SAP, PeopleSoft and Oracle Applications jobs. Selecting this option saves the job output in a summary form. This option is useful when ERP jobs have long job output and you do not want the entire output file. Not available if the Discard option is selected. |
|
Public |
Sets the public option default in th e Variables, Calendars, Job Events, System Events and Actions dia log boxes. Public items are available to all users of TES with an appropriate security policy. |
Mail Tab
If you install TES in a network that supports email, the TES master can send messages to any user of that email system through the Mail tab.
You can send email outside of the company to any user or group of users (mailing list) with a valid email address.
Note If you are running Fault Tolerance, test email on the backup master as well as on the primary master. This ensures that in a failover situation, all email notifications will continue to function
.For TES to use Internet Mail effectively, the master machine must have a continuous Internet connection. If the mail system goes offline, you will miss email notifications.
Note It is acceptable for the master to be configured to use the LocalSystem option when using SMTP mail.
Prerequisites
Before using TES’s email functions:
Step 1 Select a user mail account for the TES master. Verify that this user can send email from outside of TES before designating it for use by the master. When the TES master sends email messages, the From: field of the message header will display this user name.
Step 2 Specify a user account in the Mail tab of the System Configuration dialog box. The account must be recognized by your existing email system.
Step 3 Using the Tidal Service Manager, set the TES master service to run as a user. The user must have access to the mail system and the advanced local user right Logon as a service.
For systems using Simple Mail Transport Protocol:
Step 1 Choose Internet Mail (SMTP) from the Mail System list.
Step 2 Enter an address separator into the Address Separator field. Enter a character that your mail system understands as a delimiter between multiple email addresses that are entered on one line. TES can accept only one character in the Address Separator field, although your mail system may understand more than one character as an address separator. For example, you may be able to use either a comma or a semi-colon between email addresses
Step 3 Type the directory path to your SMTP server location into the SMTP Server Address field.
Step 4 Type your internet email address in the Return Address field. This will be in a form similar to: username@yourcompany.com.
Logging Tab
In the Logging tab, you can set preferences related to TES audit, error and diagnostic messages.
Note It is recommended that anti-virus software either be disabled during diagnostic logging or configured to not check the diagnostic files that are created during diagnostic logging. The constant writing of diagnostic information to these files will consume too much attention from the anti-virus software and consume an extensive amount of system resources. By default, the diagnostics file for the Tidal Web client, sadiags.txt, is located at C:\Program Files\TIDAL\Scheduler\client. The default location for diagnostic logs on the master machine is C:\Program Files\TIDAL\Scheduler\master\logs. More information about diagnostic logging is available in Troubleshooting.
Table 8-2 Logging Tab Elements
|
|
Log Message Retention (in days) Panel
|
Audits |
The length of time to keep audit information. The maximum length of time to keep audit information is 9,999 days but this length of time requires very large amounts of hardware and resources and hampers performance. The default is seven days. |
Errors |
The length of time to keep error information. The maximum length of time to keep audit information is 9,999 days but this length of time requires very large amounts of hardware and resources and hampers performance. The default is 30 days. |
Audits Panel |
Select this check box to activate audit logging. When checked, auditing information will be collected and can appear in the Logs pane. The following is a list of available auditing sources:
- Master Displays audit messages that originate from the master.
- Client Displays audit messages that originate from all Tidal Web clients connected to the master.
- Agent Manager Displays audit messages that originate from licensed agents that run jobs. The Agent Manager:CQD category displays messages dealing with the underlying agent communications protocol.
- Fault Tolerance Displays audit messages from the Fault Monitor machine.
- Dependency Manager Displays messages about when dependencies for jobs and job groups are met.
- Job Manager Displays messages about the status of jobs.
- Action Manager Displays messages about all configured actions.
- Queue Manager Displays messages about queue activity.
- Agent Messenger:CQD Because of the volume of CQD diagnostic messages, you can clear the Agent Messenger: CQD source for messages while still gathering information regarding your agent(s) from the Agent Manager source.
|
Diagnostic Panel |
The following components can be monitored and their activity logged. |
Scheduler Log |
Records system level messages regarding the master |
Client Manager Log |
Records messages about Client Manager activity |
Agent Manager Log |
Records messages about the status of production schedules being compiled. |
Compiler Log |
Records messages about the status of production schedules being compiled. |
Job Manager Log |
Records messages about the status of jobs |
Event Manager Log |
Records messages about events defined in TES. |
Queue Manager Log |
Records messages about queue activity. |
Database Log |
Records messages relating to the state of the database. |
Communications Log |
Records messages concerning all defined connections and sockets. Be aware that setting this component to a high level of logging results in a large amount of information that consumes large amounts of disk space. |
Each component within the Diagnostic panel has a list with seven levels of progressively more detailed logging. Each level includes the messages of the previous levels of logging. The levels of logging are:
- None No logging for the component.
- Severe Logs only serious problems for that component. (default)
- Warning Logs potential problems for the component as well as messages from the Severe logging level.
- Info Logs status messages about the normal operation as well as messages from lower logging levels.
- Low Debug Logs important debugging messages as well as messages from lower logging levels.
- Medium Debug Logs an increasing amount of debugging information as well as messages from lower logging levels.
- High Debug Logs the largest amount of debugging information as well as messages from lower logging levels.
|
Client Diagnostics Panel |
Enables diagnostics for the Tidal Web client. Creates a text file called sadiags.txt in the directory where the Enterprise TES files reside. The sadiags.txt file can be opened in any text editor. This option replicates the Debug option available in the Poll Activity pane of the Master Status pane. |
Log Message Retention (in days) Panel
|
Audits |
The length of time to keep audit information. The maximum length of time to keep audit information is 9,999 days but this length of time requires very large amounts of hardware and resources and hampers performance. The default is seven days. |
Errors |
The length of time to keep error information. The maximum length of time to keep audit information is 9,999 days but this length of time requires very large amounts of hardware and resources and hampers performance. The default is 30 days. |
Note Do not delete the current log file, which is always the log file with the latest timestamp. Even if the file does not exist, the master will continue to relay diagnostic information to the log file until it has relayed 1 MB of information. At that point, the master starts a new log file but any diagnostic information from the time between the deletion of the current log file and the creation of a new log file is lost.
Audits Tab
The Audits tab lists all of the audit messages that can be issued by TES. You can exclude any single message from being issued. For each message, you can also specify whether it will be posted to the Windows event log, which can be seen in the Windows Event Viewer.
It is recommended that you keep the defaults on this tab. For more information about audit, error and diagnostic messages, refer to the Cisco Tidal Enterprise Scheduler User Guide.
Errors Tab
The Errors tab lists all of the error messages TES can issue.
Error messages can be viewed from the Logs pane. The first error message listed (with the 2000 ID number) is blank because it is available for creating a custom error message. Here you can instruct TES to exclude specific error messages.
It is recommended that you keep the defaults on this tab. For more information about audit, error and diagnostic messages, refer to the Cisco Tidal Enterprise Scheduler User Guide.
Job Status Order Tab
The Job Status Order tab allows you set the job status order used for sorting jobs and job groups by status in the Job Activity p ane.
In the Job Status Sort Order panel, the default when sorting jobs by status is to sort alphabetically.
A recommended sort order would be to place jobs in the following categories:
- Jobs that require immediate attention placed at the top of the list.
- Jobs that were operated on placed second.
- Jobs that failed based on normal conditions placed third.
- Jobs that are proceeding normally placed last in a typical status order
This tab contains the following elements:
Figure 8-2 Job Status Tab Elements
|
|
Group 1 |
Jobs that need immediate attention |
Waiting On Operator |
Jobs that are waiting for the operator to release them. |
Error Occurred |
Jobs that could not be started. |
Agent Inactive |
Jobs whose agents are currently not enabled. |
Agent Unavailable |
Jobs whose agents are unavailable. |
Orphaned |
Jobs whose agents became unavailable during execution. |
Externally Defined |
Jobs whose completion status needs to be set. |
Completed Abnormally |
Jobs that completed abnormally |
Group 2 |
Jobs that were operated on |
Held |
Operator put waiting job on hold. |
Cancelled |
Operator cancelled waiting job. |
Stopped |
Operator paused active job. |
Aborted |
Operator aborted active job. |
Group 3 |
Jobs that failed based on other external circumstances |
Timed Out For Day |
Job dependencies not met within time window. Will try to run again tomorrow. |
Timed Out |
Job dependencies not met within time window. |
Skipped |
Job skipped because another occurrence was already running. |
Deferred |
Job waiting for its previous occurrence to finish. |
Group 4 |
Jobs proceeding normally |
Scheduled |
Limited status for jobs in the Production Schedule. |
Waiting On Dependencies |
Jobs waiting on dependencies to be met. |
Waiting On Children |
Job groups with at least one child waiting to run. |
Waiting On Group |
Jobs waiting on group dependencies to be met. |
Waiting On Resource |
Jobs waiting for a system resource slot to run. |
Launched |
Jobs that have been submitted to an agent to run. |
Active |
Jobs running. |
Completed Normally |
Jobs completed normally. |
SAP Tab
This tab is for configuring the SAP adapter. The SAP Adapter requires a special license.
OracleApps Tab
This tab is for configuring the Oracle Applications Adapter. The Oracle Applications Adapter requires a special license.
Fault Tolerance Tab
This tab is for configuring failover to a backup master Scheduler.
Timezone Tab
The Timezone tab of the System Configuration dialog box allows you to define timezones where target application environments are based. This allows you to schedule a job or job group across a different timezone.
Other Tab
The Other tab has the following options that present job information.
This tab contains the following elements:
|
|
Job Definition Confirmations Panel
|
Confirm Job Enable |
Displays a confirmation message whenever a job is enabled |
Confirm Job Disable |
Displays a confirmation message whenever a job is disabled |
2.5.3 Compatibility |
|
Allow Job Rerun on any Completed Normally and Completed Abnormally Status |
Select to allow a rerun of a job that has completed with a status of Completed Normally or Completed Abnormally. |
Wait |
Specified interval in seconds after a connection is lost to either an agent or an adapter before the system event Lost connection to agent/adapter is triggered. The default value is a zero delay |
Remove the Browse button for Command and File parameters |
Select to disable the Browse option when entering Command an File parameters. |
Configuring the Master Parameters
You can change the properties of the master that were set during installation. Circumstances may force you to change the configuration of the master as it was originally installed.
The properties of the master are managed in a file called master.props that resides in the config directory on the master machine. A complete list of parameter settings and their default values managed by the master.props file is provided in Appendix C of the User Guide.
The master.props file on the master looks like the following example:
JdbcURL=jdbc:sqlserver://SJC-Q8-WVM3:1433;responseBuffering=adaptive
JdbcDriver=com.microsoft.sqlserver.jdbc.SQLServerDriver
Classpath=${TIDAL_HOME}\lib\Scheduler.jar;${TIDAL_HOME}\lib\sqljdbc.jar;${TIDAL_HOME}\lib\ojdbc14.jar;${CLASSPATH}
CMDMasterPort=6600
JAVA_HOME=C:\Program Files\Java\jre6
JVMARGS=-Xms1024m -Xmx2048m
You change the configuration properties of the master by manually adding a new property or modifying the value for an existing property. Be careful when changing the properties of the master, incorrect entries to the master.props file may prevent the proper operation of the master. Do not add a master property to the master.props file and leave it blank after the equals (=) sign.
Table 8-3 contains a subset of the properties that are managed in the master.props file are listed below:
Table 8-3 master.props properties
|
|
JdbcDriver |
Database connection driver |
JdbcURL |
Database connect string |
classpath |
The path to the packages used in the program |
JAVA_HOME |
The path to the Java home directory |
JVMARGS |
Property that sets the JVM argument (Windows only) |
snmphost |
Name of the machine where the SNMP software was installed. |
snmpport |
Number of the port used by the SNMP software. |
CMDMasterPort |
Number of the port that the command line program uses to connect to the master machine. |
EncryptAgent |
By default, the master will send data to the agent in encrypted form, without need to specify this parameter. To disable encryption, add this parameter with value (N) to master.props file and restart master service. |
AgentHeartBeatInt |
Seconds between heartbeats. |
AgentHeartbeatFailureCount |
Number of missed heartbeats allowed before declaring the connection bad. |
AgentResendMsgInt |
Time interval after which an unasked message is resent to the master. |
FileMonitorInt |
Specifies the time interval (in seconds) for an agent to check for files. |
DirectoryMonitorInt |
Specifies the time interval (in seconds) for an agent to check directories for files (file events). |
GWStartedTaskExclude |
Any job names that match the criteria listed in the GWStartedTaskPrefix parameter but that should not be considered a Started Task are listed here. The jobs listed in this parameter continue to be considered JES jobs. Each prefix in the list is separated by a comma. |
GWStartedTaskPrefix |
Any job names that match the criteria listed, will be monitored as Started Tasks unless explicitly excluded by GWStartedTaskExclude parameter. Each prefix in the list is separated by a comma. |