In previous version of adTempus (3.x and earlier), using the Hold or Release action in a Job Control Action disabled all execution for the target job, because there was a single hold type. In adTempus 4.x, the Job Control Action only holds triggers for the target job, allowing manual and chained execution.

A new option has been added to configure this behavior globally to restore the previous capability. A future release will allow the option to be configured separately on each Job Control Action.

A new option has been added to handle cases where the Master loses communication with an Agent (because the Agent has been shut down or the network connection has failed). When this option is enabled, the Master will mark all jobs that were active on the Agent as "Abandoned." This is to assist in a scenario where a job is configured to not run if a previous instance is already running, or a queue has execution limits. Without the new auto-abandon option, in those scenarios, the Master would continue to think that the jobs on the Agent are active, until the connection to the Agent is restored and the Master receives updated status information. Thus new instances would be prevented from running.

This option currently is available only as a global configuration setting, which affects all agents, queues, and jobs.

To enable the option, go to the Advanced Server Options window in the Console and look for the option "DistributedScheduling:AbandonJobsWhenAgentLost". Set the Current Value to "true" and click OK to save the change.

In some scenarios (such as when database problems occur), adTempus may fail to record the completion of a job instance. This results in an instance that shows as active in the Console even though it is no longer running. Such a phantom instance may also disrupt job flow, in cases where other jobs depend on the state of the job, or where the job is configured to not allow multiple concurrent instances. Though the Console shows the "Terminate" command for the instance, using this command has no effect, as there is no real instance to terminate.

The adTempus server has been updated so that in situations like this the Terminate command will update the database record for the instance to show a status of "Unknown." The user can then use the "Override Status" command to set the instance to Succeeded or Failed as appropriate.

In rare cases (typically involving a corrupted user profile, or network connectivity problems), the logon process for a Windows user account may take a very long time to complete. In such cases, the job requesting the logon and any jobs subsequently triggered (even if they use a different user account) remain in "Starting" status with no indication of what the problem is.

adTempus has been updated to issue a warning message after waiting 1 minute for logon to complete and to fail the job after waiting 10 minutes. Additionally, other jobs that use different credentials are no longer delayed by the problem.

For more information see Knowledge Base article K00000543.

When you select the Remote Agents view in the adTempus Console, the Console fails with error "An error occurred on the server while processing the request."

This can happen if the Windows performance counters on the Master server have been corrupted. This indirectly causes a failure in adTempus when it is generating the load metrics reports that are shown in the Agents view.

The problem was corrected so that corrupted counters will no longer cause the problem.

I you have defined a Job Variable with a name that contains certain punctuation characters (such as "\"), any job that defines or inherits that variable will fail with error 104: "An internal error occurred".

To work around this problem, remove the punctuation character from the variable name.

For more information see Knowledge Base article K00000546.

This release includes an update to the third-party component adTempus uses for FTP and SFTP, which fixes some issues with this functionality.

A new option was added to the Object Change Log report to "Exclude system-generated changes." Checking this option excludes all events where the user is shown as "System." These events come from automated actions such as Job Variable Update tasks that modify a job definition.

Note: you can prevent adTempus from generating these change log entries in the first place, as described here.

For more information see Knowledge Base article K00000557.

Scripts can now trigger Responses for jobs. This can be used, for example, to make it easier for a script to trigger another job in a job chain.

To use this feature, add event "Invoked by a script" to the Response, and use the "tag" field to give the event a name or description. In the script, use the adTempus.ExecuteOnDemandResponses method to invoke the Response, passing the tag value to tell adTempus which response(s) to trigger.

For more information see Knowledge Base article K00000558.

When a File Transfer task uploads a file using FTP or SFTP, it uploads the file using a temporary name, then renames the temporary file to the final name. This is done so that any existing file is not corrupted in the event that the transfer does not complete successfully. However, in some scenarios the upload/rename operation causes problems and a direct upload is preferable.

A new advanced server option, "FileTransfer:UseTempFileForUpload", was added to control this. Set this option to False to turn on direct upload.

This setting affects all file transfer operations. A future version of adTempus will allow control over this setting at the file server or task level.

If the e-mail trigger encounters a login failure or other error that it interprets as a configuration error, it logs an Alert and stops polling the mail server until the mail connection settings have been checked and re-saved. This was intended to prevent repeated connection attempts using incorrect settings or bad credentials, but in practice sometimes causes the trigger to stop monitoring due to transient failures that are interpreted incorrectly.

The behavior has been changed so that the trigger will log an Alert on failure but will continue trying to connect.

When a File Trigger is configured to scan a folder but the job's user does not have permission for a higher-level folder in the hierarchy, the trigger ignores the folder but does not report an error.

For example, a trigger is configured to watch "d:\input files\customers\customer1\*.xml". The account that the job is running under has permission to view folders "d:\input files" and "d:\input files\customers\customer1" but does not have any permissions for "d:\input files\customers".

When scanning for trigger files, adTempus starts at the root folder and works its way down to the lowest level, one level at a time (this allows it to accommodate folder name wildcards). If it encounters a level where it does not have sufficient permission, it will either get an access error (if it does not have View permission) or will not "see" the next level of folders (if it does not have List permission). Therefore it never gets to the "d:\input files\customers\customer1" folder to look for files.

This behavior was changed so that when there are no wildcards in the path adTempus will scan the lowest-level target folder directly, so the trigger will work correctly as long as the job's user account has permission for that folder.

For more information see Knowledge Base article K00000561.