Which log file would show the following clue as to why and what needs to be done to resolve the issue so that the batches do not end up in Fixup?

A company has a corporate policy to install applications on a non-C: drive so they installed IBM Datacap on the E: drive on all machines. Rulerunner is configured to process PageId, Profiler and Export steps. While testing the OOTB TravelDocs application, the VScan step in DcDesktop creates batches successfully.

Rulerunner picks up the job from PageId step, processes it to the Profiler step, which also processes it.

However, instead of ending up on the Verify task when tested on the C: drive, the batches all end up in FixUp with pages set to Other when tested on the E: drive (see following screenshots for examples).

Which log file would show the following clue as to why and what needs to be done to resolve the issue so that the batches do not end up in Fixup?

A . profiler_rrs.log C travelDocs.app needs to be updated to with the fingerprint path
B . pageid_rrs.log C fingerprint database needs to be updated with the path to the fingerprints
C . vscan_rrs.log C user requires read+write access to the batches folder and fingerprints folder
D . fixup_rrs.log C user requires read_write access to the batches folder and travelDocs.app needs to be updated with the fingerprint path

View Answer

Answer: B

Explanation:

The X_rrs.log, where X is the name of the task. The file is in the batch folder of the application (for example, C:datacapTravelDocsbatches20130924.00001pageid_rrs.log), and contains information about actions that are completed by the Rulerunner engine.

Something that is fairly common, look in your fingerprint database to the Template table. In there, for the .tif and .cco file of every fingerprint there is a path stored there. You may need to do a search and replace to make sure the path is correct and pointed to your shared fingerprint directory.

References: https://www.ibm.com/support/knowledgecenter/en/SSZRWV_9.0.0/com.ibm.dc.admin.doc/ dclog002.htm