adTempus 4.4.0 Release Notes

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.

See also related change CR00007235.

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.

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.

Changes were made to improve the performance (responsiveness) of the Console for customers with large amounts of history data, particularly when using the Job Monitor, Failed Jobs, and Alerts views.

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.

When a program run by adTempus fails with exit code -1073741502, this can indicate a lack of desktop heap memory that can cause additional jobs to fail with the same error. When this exit code is reported, adTempus will now log an Alert for the job, with a link to a KB article with more information about the error. An alert notification rule can be configured to notify administrators when this problem occurs.

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 you execute a database task to select a scalar value, the value will now be stored in the ADTTaskResult Job Variable in addition to the variable you specify in the task settings. It will also appear as the "Result" for the step in the job history.

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.

Added preliminary support for viewing the status of File Triggers. 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.16139 or later.

When it begins monitoring for a File Trigger, adTempus checks to see if the root folder for the path you have specified exists and is visible to the user account used for the job. If not, adTempus will log an Alert warning you of this condition, which may indicate that your trigger is misconfigured or does not have the appropriate security access.

When a Job Group is duplicated, the jobs within the group will no longer have " - Copy" appended to the name.

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.

When you search in the Deleted Objects window, the search shows objects based on the highlighted object type, rather than the checked object type(s). This problem was corrected.

For more information see Knowledge Base article K00000528.

When you connect the Console to an adTempus server running in Agent/Standalone mode, you should not be able to modify jobs that are managed by the Master. However, adTempus may allow you to do this. This problem was corrected.

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.

This problem was resolved.

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.

This problem was corrected so the "Step" column in the History pane of the job list will indicate which step failed.

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.

If you use the "Keep forever" setting for audit and snapshot records, adTempus mistakenly removes these records within 24 hours. The problem was corrected.

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.

When you use the option to "Save all imported objects if no problems are found" when importing jobs into adTempus, jobs are saved but are not scheduled for execution. Editing the job or restarting the adTempus service causes them to be scheduled.

For more information see Knowledge Base article K00000526.

When a Log Message is exported and imported, it is correctly linked to the Instance that it belongs to, if appropriate. However, the link to the owning job is lost. Therefore the message no longer appears on the Log Messages tab for the job, but does appear in the instance details window if it is associated with a specific instance.

This problem was resolved.

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.

This fix requires that the adTempus server be updated to resolve scenario 1, and the adTempus Console be updated to resolve scenario 2.

For more information see Knowledge Base article K00000534.

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.

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.