When capturing files for a File Capture Action, or deleting files that have been captured, adTempus may fail to use the elevated logon context, resulting in error "Access to the path is denied" if the necessary permissions are assigned only to Administrators.

When adTempus fails to delete a captured file, it logs error ADT005055 ("Could not capture file") even though the file was successfully captured to the file history. This has been replaced with error ADT005409 ("Could not delete captured file").

This problem still occurred in some cases even after fix CR00005098 in adTempus 4.2. The problem occurred only when:

• A job runs in a Queue that is configured to use Load Balance or Slave mode
• The Queue is configured to check conditions on the Master
• The job has previously been sent to an Agent for execution following a condition check.

On subsequent execution attempts, the job will get stuck in "Waiting for Condition" status.

In addition, if the job is configured to not execute if another instance is already running, the job may be skipped even though no instance is active.

When you attempt to hold or release a job, queue, or group using the right-click context menu, the Console connection to the server may fail with the following error:

Message Number: ADT005166E Message: The server connection has failed or has been closed: There was an error while trying to serialize parameter http://arcanadev.com/adTempus/4.0:value. The InnerException message was 'Enum value '2147483646' is invalid for type 'ArcanaDevelopment.adTempus.Shared.HoldType' and cannot be serialized. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.'. Please see InnerException for more details.: Enum value '2147483646' is invalid for type 'ArcanaDevelopment.adTempus.Shared.HoldType' and cannot be serialized. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.

This problem was resolved.

Workaround

This problem only occurs when using the right-click context menu. You can still change the hold type by editing the job, queue, or group and changing the hold setting in the properties window.

If a user tries to duplicate an object (e.g., a Job), they get a permission error unless they have full control for the object.

This was corrected to work properly. A user can duplicate an object if the user has permission to view the object and to create new objects of that type. For example, to duplicate a Job, the user must have permission to view the job and also permission to create new jobs in the Group where the job is found.

If the Job Monitor view is configured to show both Active and Past instances, the Job Monitor stops updating the statuses of jobs that have been running longer than the "Past" time limit.

For example, if the Job Monitor is configured to show instances from the past 12 hours, any job that runs longer than 12 hours will no longer be updated in the Job Monitor, but will still appear there as active even if it has finished.

This problem was corrected. The update must be applied to the adTempus server; the Console software is not affected.

If a non-Admin user is granted "Execute" permission for a job, user should be able to terminate an active instance of the job, and to acknowledge instances and messages for the job. However, if the permissions are assigned at the Job level (rather than at the Group or Queue level), they are not properly inherited, and these options are not available to the user.

In some situations the Console showed a red "error" icon for jobs (indicating the existence of one or more failed instances for the job) even though no instances for the job appeared in the Failed Jobs view.

This problem was partially resolved in version 4.2 under CR00003058 but the problem remained in some scenarios.

The "Total Executions" count tracked for each job and shown on the Statistics page is double the actual execution count.

This problem was fixed so that executions are not double-counted going forward, but the existing (incorrect) count is not adjusted.

With adTempus 4.2 installed, when adTempus purges old history data from the database, records are left behind in some tables when they shouldn't be.

This update fixes the problem.

When you hold (disable triggers for) a Job Group, all jobs within the group should be dequeued (should no longer be triggered). Conversely, when you release (enable triggers for) a Job Group, all jobs within the group should resume executing based on their schedules or other triggers. However, in some cases this does not happen after you change the hold settings for a group.

If you subsequently edit and save a job, that job will then be queued or dequeued as expected. If you restart the adTempus service, all jobs will behave as expected.

This issue was resolved so jobs are queued/dequeued when the change is made to the group.

If you have defined an Alert Notification Rule, adTempus interprets the Minimum Interval setting incorrectly and sends alerts before the minimum interval as elapsed, but not after it has elapsed. This is the reverse of the expected behavior.

This problem was corrected.

A new option in the Import wizard allows you to only import objects that were explicitly exported.

For example, when you export a job, the export file also includes everything the job links to, including its Job Group, Job Queue, Credential Profile, Remote Agents, Notification Recipients, etc. By default, all of these additional objects get imported on the target server if they are newer than the existing versions on the target server.

In some cases (such as copying a job from your test server to your production server) you only want to import the job itself and not overwrite the existing settings for the other objects. When the "Don't import referenced objects that already exist on this server" option is checked, these objects will not be listed on the object selection page of the wizard and will not be imported unless they do not already exist.

In all cases, adTempus imports any linked objects that do not already exist on the target server.

If you have defined nested job variables, the nested variable(s) are not expanded when the environment block is set for programs run by adTempus.

For example, you have the following job variables:

• "VariableA" is set to "Value A"
• "VariableB" Is set to "The value is: %VariableA%"

VariableB is configured to be added to the environment for programs run by adTempus. If the program retrieves "VariableB" from the environment, it should get "The value is: Value A". However, it gets "The value is: %VariableA%" instead. This occurs even though the variable expansion works correctly elsewhere within adTempus and appears correctly in the debug log for the job.

When upgrading from adTempus 2 to adTempus 4, if a Messaging Service Provider has the maximum message size set to 0 (which indicates "no limit" in adTempus 2), adTempus does not include any attachments on notification messages.

Workaround: Edit Messaging Service Provider and click OK to update the limit to the default of 10MB.

When you run the Security Configuration Report, it may not show any data. This problem was corrected.

This problem was resolved. The update must be applied to the adTempus server; the Console software is not affected.

When a Program Execution Task has a Response configured to send notification on success or failure, the default notification message is a generic message: "The program has completed with exit code {0}". The message should indicate whether this is being treated as a success or failure.

The generic message ADT005003 has been replaced with the appropriate status message:

• ADT005252: Task ended with exit code {0}, which indicates failure according to the exit code rules for the step
• ADT005410: Task completed successfully with exit code {0}. 

When you execute a File Operation Task you can configure Responses based on the number of files processed. The following problems were corrected for those Responses:

• When you select "Affected file count matches a value," there was no way to specify the file count
• The responses for "No files affected" and "One or more files affected" were reversed
  

A user who has been granted Hold/Release permission for a job, group, or queue is unable to change the hold settings for the object unless the user also has Modify permission, which should not be required.

This problem has been corrected.

In the adTempus Database Utility, if you use the File/Set Connection command and cancel out of the connection dialog, subsequent attempts to open a new query tab result in error "SQL Server does not exist or access denied" because the tool has lost the database connection information.

If you use a Script Execution Task to run a script stored outside adTempus, and the path/filename of the script to execute contains Job Variables, adTempus does not expand the variables, and task execution fails because script file cannot be found. This problem was resolved to expand the job variables.

A File Trigger may not trigger for a file if all of the following are true:

• The target file is on a remote (network) drive.
• The trigger is configured to wait until x seconds after the last modification timestamp for the file.
• adTempus initially detects the file before the x seconds have elapsed.

In this scenario, adTempus may not "see" the file when it subsequently tries to check the modification timestamp, and therefore does not trigger the job.