IBM Datacap Taskmaster Capture Client Service is not processing batches

Problem(Abstract)

The Datacap Taskmaster Client Service has a started status, but is not processing any batches.

Resolving the problem

First, review the following logs for errors, warnings and other information around the incident time.

• Datacap Taskmaster Client Service logs
• Batch logs
• Windows Application and System Event logs

If the logs do not immediately show the root cause, ensure the following scenarios do not apply:

• Login ID and station ID used by the client service have insufficient permissions, including user/group Client(s) permissions, Taskmaster Sub (Client Service) permissions, and individual privileges to the job-task pairings for both user/group and station.
• The Datacap Taskmaster Client Service is connecting to the incorrect Taskmaster Server.
• There are multiple instances of process TMrt.exe on the client service machine. If more than one instance exists, stop the client service by terminating each instance of TMrt.exe, TMSub.exe, BPilot.exe and DCOProcessor.exe, and then start the service. Then monitor for recurrence and try to isolate the problem to specific batches or tasks; contact IBM Support for further assistance as necessary.

Why is an error received when IBM Datacap Taskmaster Client Service VScan accesses a remote directory?

Problem(Abstract)

IBM Datacap Taskmaster Client Service reports 'Folder ... does not exist' on the VScan rule action SetSourceDirectory(), where the directory path is a remote shared directory.

Symptom

• Remote shared directory is specified using UNC path such as \\server\share.
• Remote directory does exist.
• Taskmaster Client (thick client) works (without reporting the error).
• Taskmaster Client Service Logon User is set to a user having full permission to read/write to the remote directory.
• Remote share is a Unix-hosted file system.
• vscan_rrs.log reports Error: Folder '\\server\share' does not exist.

Cause

The Logon ID format is not accepted by the remote host.

Environment

Windows 2008

Resolving the problem

Change the Taskmaster Client Service Windows service Logon ID from a "User1@Domain" format to a "Domain\User1" format. For example, use the format FINANCE\jdoe instead of jdoe@FINANCE.local.

IBM Datacap Taskmaster Capture is allowing only one client connection at a time

Problem(Abstract)

Datacap Taskmaster client application is allowing only one connection at a time.

Cause

The UNC path of Taskmaster client application is missing in the Datacap.xml.

Resolving the problem

Putting the UNC path to the application in the Datacap.xml file will resolve the issue.

To add the UNC path to an app, the format is as follows:
<app name="appname" ref="\\servername\Datacap\appname"/>

Here is the content of the default datacap.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<datacap ver="8.0">
<app name="1040EZ" ref="1040EZ"></app>
<app name="Express" ref="Express"></app>
<app name="Flex" ref="Flex"></app>
<app name="Survey" ref="Survey"></app>
<app name="APT" ref="APT"></app>
<app name="MClaims" ref="MClaims"></app>
<app name="AppWizard" ref="DStudio\AppWizard"></app>
</datacap>

Here is the content of the default datacap.xml file with a UNC path for 1040EZ:
<?xml version="1.0" encoding="UTF-8"?>
<datacap ver="8.0">
<app name="1040EZ" ref="servername\1040EZ"/>
<app name="Express" ref="Express"></app>
<app name="Flex" ref="Flex"></app>
<app name="Survey" ref="Survey"></app>
<app name="APT" ref="APT"></app>
<app name="MClaims" ref="MClaims"></app>
<app name="AppWizard" ref="DStudio\AppWizard"></app>
</datacap>

Maximum connections reached with IBM Datacap Taskmaster Capture

Problem(Abstract)

Datacap Taskmaster client applications fail login to the Taskmaster Server service. Logging shows the following error:

Login failed. Taskmaster has reached the maximum allowed number [#] of stations

Symptom

Users are able to login to the application using same credentials but different station ID.

Cause

Certain rare events can leave an orphaned login within Taskmaster. If enough of these occur for a specific station, than any further logins from that station will fail, as no more connections are available. This requires that either the connections be reset or the maximum increased.

Resolving the problem

Reset the connections using Taskmaster Client (8.0.1 and earlier)

1. Make sure that no client applications are logged in from the station that will be reset.
2. Run Taskmaster Client. It can be run from any station including the one being reset.
3. Log in as admin or any other user with full rights.
4. Select Settings, Stations, and highlight the station to be reset.
5. Click Advanced, Reset.
6. Click Yes of the warning window.
7. Click OK, Apply, and Done to close the remaining windows.

Reset the connections using Taskmaster Web

1. Make sure that no client applications are logged in from the station that will be reset.
2. Run Taskmaster Web. It can be run from any station including the one being reset.
3. Log in as admin or any other user with full rights.
4. Select Administrator, Stations.
5. Select the station to be reset, then Clear Virtuals.

Increase the maximum connections using Taskmaster Client (8.0.1 and earlier)

1. Run Taskmaster Client. It can be run from any station including the one being reconfigured.
2. Log in as admin or any other user with full rights.
3. Select Settings, Stations, and highlight the station to be reconfigured.
4. Click Advanced.
5. Change Maximum number of virtual stations to 1000 or some other large value.
6. Click OK, Apply, and Done to close the remaining windows.

Increase the maximum connections using Taskmaster Web

1. Run Taskmaster Web. It can be run from any station including the one being reconfigured.
2. Log in as admin or any other user with full rights.
3. Select Administrator, Stations, and select the station to be reconfigured.
4. Change Max N to 1000 or some other large value.
5. Click save and exit the screen.

Why is FNP8_Upload failing when using IBM Datacap Taskmaster Capture?

Problem(Abstract)

In the export.log file, the following errors were listed:

15:04:43.931 (313) t:1278 p:5E24A68 Upload failed.
15:04:43.931 (0) t:1278 p:5E24A68 ERROR!!! N-2146233088
Error description = Error executing the batch operation

....

15:04:43.932 (0) t:1278 p:5E24A68 Error (385875969=hex:17000001). In CIMainAlgorithm::execute4DCO: Aborting: Action [FNP8_Upload] requested abort [api source:]

15:04:43.932 (0) t:1278 p:5E24A68 EXCEPTION: code="385875969" msg="Aborting: Action [FNP8_Upload] requested abort" loc="CIMainAlgorithm::execute4DCO" API=""

Cause

Upon further investigation, it was found that one of the property fields was a choice list. The export log showed that the property list was being set to "", which was not a valid selection according to the choice list definition on the customer's IBM P8 Content Engine (CE).

It was necessary to remove the blank field from the Datacap choice list and correct the spelling of all items in the Datacap choice list. The Datacap choice list and the CE choice list must be identical, since the CE is case sensitive when comparing choice list fields.

Diagnosing the problem

Review the export.log and find all of the document properties that are being set by the function FNP8_SetProperty. Determine which ones are choice lists and what the return value is from the operator input. Verify that the spelling is identical to the CE property definition. Be aware that the spelling is case sensitive.

Resolving the problem

After the Datacap choice list content's spelling was corrected to match the CE choice list, the export operated correctly.

Document Class not found exporting documents with IBM Datacap Taskmaster Capture

Problem(Abstract)

When committing documents to IBM FileNet P8 Content Engine, the export fails. The error in the Task log shows as:

15:21:39.984 (1000) t:E04 p:AC18C80 Upload failed.
15:21:39.984 (0) t:E04 p:AC18C80 ERROR!!! N-2146233088
Error description = An exception occurred while creating a folder: 'Class MyP8DocClass not found.'
Error Source = DC_P8_Server

Symptom

Viewing a list of the Document Classes shows that the class does exist.

Cause

The Symbolic Name, not the Display Name is used when exporting to P8 Content Engine from Datacap Taskmaster.

Resolving the problem

Change the parameter in the FNP8_SetDocClassId action to reference the Symbolic Name of the Document Class, not the Display Name.

Exported dates to IBM FileNet Content Engine are one day off in IBM Datacap Taskmaster Capture

Problem(Abstract)

Dates exported to IBM FileNet P8 Content Engine show yesterday's date when viewed by an IBM FileNet Content Engine client

Cause

IBM FileNet Content Engine stores all time stamps using UTC format. If a date is passed into IBM FileNet Content Engine with no time component then the time defaults to midnight UTC, which may indicate the prior date when converted back into local time.

Taskmaster does not convert or handle dates in GMT/UTC and thus any date values must be formatted by the application rules prior to export to IBM FileNet Content Engine

Resolving the problem

Modify the date/time value into proper GMT/UTC format of YYYY-MM-DDTHH:MM[:SS] and then add a time offset to account for the GMT time difference, e.g. YYYY-MM-DDTHH:MM:SS-HH:MM, prior to export to FileNet P8.

The action IsFieldDateWithReformat from the Validations library can be called with a parameter of "s" (no quotation marks) to format a local date/time value to UTC; a GMT offset can be appended to a UTC value with any standard action such as rrSet from the rrunner library.

Example 1:

Description	Field Value (Case A)	Field Value (Case B)
Data captured	05/31/2012 15:00	05/31/2012
IsFieldDateWithReformat(s)	2012-05-31T15:00:00	2012-05-31T00:00:00
rrSet(@F+-07:00,@F)	2012-05-31T15:00:00-07:00	2012-03-15T00:00:00-07:00

Here the initial field value is first transformed to UTC. The rrSet action is called to append the GMT offset "-07:00" to the field value.

Example 2:

Description	Field Value (Case A)	Field Value (Case B)
Data captured	05/31/2012 15:00	05/31/2012
IsFieldDateWithReformat(s)	2012-05-31T15:00:00	2012-05-31T00:00:00
rrSet(@F+@CHR(43)+07:00,@F)	2012-05-31T15:00:00+07:00	2012-03-15T00:00:00+07:00

Here the initial field value is first transformed to UTC. The rrSet action is called to append the GMT offset "+07:00" to the field value, @CHR is used to avoid conflict with the concatenation operator.

Note: IBM FileNet Content Engine may have a back end setting for Daylight Savings Time (DST), thus modifying the GMT offset to account for DST may not be necessary.

Can I run multiple instances of IBM Datacap Taskmaster Capture Client on one workstation?

Question

Can I have multiple instances of Taskmaster Client running on the same workstation at the same time?

Answer

No. Before running a second instance of Taskmaster Client, the first instance must be ended.

Although some customers have run this configuration successfully, particularly with older versions, IBM does not support running more than one instance of Taskmaster Client on a workstation, as the two instances may conflict with each other in some situations. This includes the Taskmaster Client Service.

VScan intermittently aborts with IBM Datacap Taskmaster Capture

Problem(Abstract)

When running VScan using Rulerunner Quattro, intermittent aborts occur. This may happen even with long periods of inactivity or when no images are waiting to be processed.

Symptom

This issue can also cause Rulerunner Quattro to appear to hang.

Cause

When VScan is run by Rulerunner Quattro, it repeatedly checks for incoming files, with no delay between requests. This can create too much overhead for the file system to keep up with, causing file access to fail and the batch to abort.

Resolving the problem

Configure Rulerunner Quattro to add a small delay between reruns of VScan.

1. Run Rulerunner Quattro Manager.
2. On the Datacap Quattro tab, stop the service.
3. On the Datacap Login tab, click Connect.
4. On the Workflow tab, expand the hierarchy on the right and highlight VScan.
5. In the Settings section in the lower right, set skipsamebatch to 1.
6. Highlight the line labeled <dbs> above VScan in the thread hierarchy.
7. Set skipsamebatch to 1 there also.
8. Click Save, then go back to the Datacap Quattro tab and start the service.

Slowness in applications using Microsoft Access admin/engine databases in IBM Datacap Taskmaster Capture

Problem(Abstract)

Clients such as Taskmaster Client and Taskmaster Web are slow in an environment containing one or more applications that have Microsoft Access admin and engine databases in IBM Datacap Taskmaster Capture

Symptom

Latency may be apparent in client such as Taskmaster Client and Taskmaster Web when attempting to view the Job Monitor, Operations page, workflow, etc.

Cause

Only Taskmaster Server communicates to the admin and engine databases. In cases where either database is large, communication may be slow, which may lead to other certain incoming requests (e.g. Job Monitor page, running a new batch) to become backed up. When using multiple applications, one application's databases may impact other applications if they share the same Taskmaster Server.

Resolving the problem

Microsoft Access is not recommended in large scale environments, SQL Server or Oracle should be considered depending upon volume. However, even small volume systems using Microsoft Access may be affected over time if older batches and task statistics are not removed. Resolution steps A and B are recommended.

A) Decrease the size of the databases by removing or transferring any older unnecessary data. Deletion or transfer of database records is facilitated by NENU or AutoDelete, where NENU replaces AutoDelete in IBM Datacap Taskmaster Capture 8.0.0 and later. What data can or cannot be deleted or transferred will depend upon corporate policy and requirements:

1. Admin database - the [audit] table can be cleared if login and logoff records are not required.

2. Engine database - batches and task statistics can be removed based on a date range adequate for applicable retention policies.

i. Task statistics are contained in various tables such as [de2kst], [scan2kst], etc.
ii. Records for batches visible in the Job Monitor are stored in [queue], [qstats] and [tmbatch].
iii. The [debug] table will contain a record for each transaction that updates a batch status -- writing to debug is enabled on a client basis and will quickly grow.

Note: if updating the engine database manually (e.g. external to NENU), it is generally recommended to keep the file system and database in sync in some manner.

B) Compacting and repairing the Microsoft Access databases regularly during maintenance windows is recommended. It is feasible to automate compact and repair using some program or batch file. The databases should be compacted and repaired after using NENU or AutoDelete to clean up the databases.

IBM Datacap Taskmaster Capture service stuck in Stop Pending status

Problem(Abstract)

When stopping the Taskmaster Server Service, Taskmaster Client Service, or Datacap Rulerunner Quattro Service, it stays in the Stop Pending status in the Services window.

Cause

A service will go into Stop Pending status when it has been sent a stop request while busy finishing preexistent work. The service status changes from Stopping to Stop Pending when the stop request times out. The service, once finished with its work, will enter the Stopped state. If something prevents the service from finishing its work, it may remain indefinitely in the Stop Pending state.

Resolving the problem

It is recommended that the service be allowed to complete its work gracefully, but in certain rare cases it may be necessary to forcefully terminate the service. For example, if it is known that the service in question is hung and will not reach Stopped status even when given sufficient time.
Forcefully stopping the Datacap Taskmaster Client Service

1. Terminate TMSub.exe
2. Terminate any instance of TMrt.exe, if present
3. Terminate any instance of BPilot.exe (running under client service account), if present
4. Terminate any instance of DCOProcessor.exe, if present
5. Terminate any other instance of a process started by (custom) Taskmaster rules, if present

Forcefully stopping the Datacap Rulerunner Quattro Service

1. Terminate Quattro.exe
2. Terminate any instance of dqcs.exe, if present (Datacap Quattro Control Service)
   - Applicable to IBM Datacap Taskmaster Capture 8.0.0 and later
3. Terminate any instance of DCOProcessor.exe, if present
4. Terminate any other instance of a process started by (custom) Taskmaster rules, if present

Forcefully stopping the Datacap Taskmaster Server Service

1. Stop the Datacap Taskmaster Client Service and Datacap Rulerunner Quattro Service.
2. Stop any other client programs, including Taskmaster Client, DotEdit, Taskmaster Web, etc.
3. Terminate TMS.exe