If you use the Run command in the Console when more than one job is selected, all selected jobs are executed, though this is easy to overlook in the Execution Options window.

A new warning message was added to prevent accidental execution of multiple jobs.

Previously, a Job would be shown in the Console with a red failure icon until the next successful run, even if all failed instances had been acknowledged.

This has been changed so that the failure icon appears "dimmed" once all failures have been acknowledged.

When the adTempus Console refreshes to show the latest data while you are in a job list view, the list scrolls to keep the selected job in view. If you had paged so that job was out of view, you lose your position.

This was corrected to maintain the correct scroll position rather than scrolling to the selected job.

When setting up an incoming mail server, if you leave the Server Port box empty, the Console gives error

After closing the error window, you can enter a port number value (use 0 for the default) and successfully save the provider.

If you duplicate an object (such as a Job Step) and then click Cancel in the edit window for the object or one of its children, the Console may fail with an "unexpected error" message.

This problem was resolved.

Consider the scenario where a Queue is configured to use Load Balancing across multiple computers, and a limit is set to restrict the number of jobs that can execute concurrently in the queue on a single computer.

In previous versions, if all available agents were at or above the limit, a job was still dispatched to an agent (generally the agent with the lowest number of active and pending jobs). The job would then be queued for execution on the agent until an execution slot was available.

This has the drawback of potentially sending a job to an agent where it will wait for a long time to execute, while jobs that get triggered later may get executed first on other agents whose jobs took less time to run.

This behavior has been changed so that jobs will only be dispatched to agents that have available execution slots. If no agent has an available slot, the job will remain queued until a slot is available. All jobs sent to the queue for execution will be dispatched to agents in the order that they were triggered.

For more information see Knowledge Base article K00000528.

The adTempus Console highlights jobs, groups, and queues that contain instances with an error state (such as failed) by showing an error icon next to the job, or on the group or queue icon. This feature was expanded to also highlight instances with a warning status (such as abandoned or aborted) by showing a warning icon. As with the error indicator, the warning indicator is removed when the instance's status is acknowledged.

See also related change CR00007234.

When you run the Engine Mode Utility, the Reset Master option may not be enabled when it should be when the utility starts.

Workaround: Click to select a different engine mode, then click back to the original setting. This should enable the option.

When you use an inline function call, the syntax for any code or strings in the call is processed in the C# language, even if the inline function library is set to use VB.NET. This can cause unexpected errors when compiling the code.

This was corrected so that inline function calls are processed in the same language specified for the InlineFunctions library.

For more information see Knowledge Base article K00000529.

If the same block of text calls the same Inline Function more than once, job execution fails with "an unexpected internal error."

This problem was corrected.

For more information see Knowledge Base article K00000530.

A job instance was previously waiting for a condition to be met. The condition has been met, but the job is now in status "Queued for Execution" because the execution limit for the Job Queue has been reached. If you use the "Force Execution" command in the Console to override the limit and force the instance to execute immediately, nothing happens. The instance will still execute when a slot becomes available in the Queue, but immediate execution cannot be forced.

This problem was resolved.

If a job is configured to use one of the Multiple Instance options other than "Execute," multiple instances may still be started for jobs assigned to a Queue that uses Load Balancing.

This problem was corrected.

When you view a job instance from the job history, the names/descriptions for job steps are not displayed. This is occurring because adTempus is failing to save this information in the history.

The problem was corrected so the information will be stored when jobs are executed. For jobs run before the update was applied, the Console will show the current description for the step.

A change made in version 4.3 had the unintended consequence that the status for a running job instance may not be correct. For example, it may show "Queued for Execution" when it should be "Running," or "Running" when it should show "Waiting for Condition." This problem only affects display of the status, not the actual execution of the job.

The problem was corrected.

If you have objects selected in the active view (e.g., the job list, Notification Recipients list, etc.) when you open the Export window, you will now be given the option to transfer the selections to the export window so those items are selected by default in the list of object available for export.

Previously there was no such link.

For more information see Knowledge Base article K00000526.

If you use the Job.ExecutionFinish, JobStep.ExecutionStart, or JobStep.ExecutionFinish variables in your job (for example, in notification messages set by responses), the following problems occur:

• The *.ExecutionFinish variables may not be set before Responses are executed, resulting in empty values if you use them in Responses.
  
• The JobStep.* variables are not defined when job-level Responses are executed (they are only available to step-level Responses)

Both of these problems were corrected.

When no steps within a job are executed (e.g., because they were disabled or their conditions were not met), adTempus reports the job with status "Not Run," which is misleading because this status is also used for cases where a job was aborted before it began execution.

Further, when such a job executes on an Agent, the Master continues to report the job as active even after it has finished because of a problem interpreting this status.

The behavior has been changed so that a job will be reported as "Succeeded" even if none of its steps ran. As a result of this change the Master now reflects the correct state of the job.

For more information see Knowledge Base article K00000534.

Inline scripting has been updated to correct some design limitations. The updates support:

• Nested inline function calls.
• Inline function calls that use variables as arguments, when those variables evaluate to inline function calls.
  

When an adTempus task runs an external PowerShell task with the option checked to capture the console output from the script, an error message is written to the adTempus diagnostic logs:

Failed to delete captured file PowerShell Output.txt
System.NullReferenceException: Object reference not set to an instance of an object.

This message does not cause any operational issues.

The underlying problem has been resolved.

When editing a Script Library, the "Included Script Libraries" list is always empty, so it is not possible to reference other Script Libraries.

This has been corrected so that a Script Library can reference other Script Libraries (so code in one library can call code in another).

For more information see Knowledge Base article K00000532.

When a user has been authenticated to adTempus using a dynamic login (based on Active Directory group membership), permissions assigned to the user may be cached until the next time the adTempus service is restarted. Therefore if the user's group membership changes, the user's permissions in the Console may not reflect that change until the next restart.

For example, user Rachel is a member of an Active Directory group that has been given permission to execute jobs in adTempus. She logs in to adTempus and is able to run jobs. She is subsequently removed from that Active Directory group, but when she logs in to adTempus she is still able to run jobs even though she should not be permitted. After the adTempus service is restarted, her permissions are correctly updated.

This problem was corrected so that cached permissions are discarded and the user's permissions are always recalculated each time she logs in to adTempus.

Note: Group membership changes won't be reflected until the user restarts the adTempus Console, as the permission assignment only happens when the user logs in. Also, it may be necessary for the user to log out of Windows for the user's login session to be updated with the group membership change.

If the target ZIP file is in a folder that does not exist, adTempus does not create it, and the compression task fails as a result.

This problem was corrected.

Added preliminary support for viewing the status of Job Triggers, allowing user to see which rules have been satisfied for the trigger, and by which job instances.

To display the status, right-click the job and select the Trigger Status command at the bottom of the pop-up menu.

This option is only available if both the Console and the server are running adTempus 4.3.1.16125 or later.

Only Job Triggers currently report status.

When a job is triggered by a Job Trigger, the Execution Reason for the instance lists the jobs and instances that satisfied the trigger. However, the instance number is always listed as 0 for all jobs.

This problem was fixed to show the correct instance number.

For more information see Knowledge Base article K00000518.

When you use one of the "{most recent|any} instance since previous [successful] execution of the current job" instance rules for a Job Trigger, adTempus may incorrectly trigger for an instance that ran prior to the most recent execution of the current job. This happens when the trigger targets more than one job. If one or more target rules was satisfied before the current execution but at least one was not, the target rules satisfied before the current execution may not be re-evaluated, causing the job to trigger without waiting for them to run again.

This problem was resolved.

When debug (diagnostic) logging is turned on for the adTempus service, File Triggers may fail if they are configured to detect modified files. An error is logged to the adTempus diagnostic log in this case: "Exception while checking monitor XXXXXX System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection."

Debug logging is turned off by default, so this problem does not affect most users.